Claude gets creative: a skill for brainstorming in rounds

A Claude Code skill that runs a creativity session in three rounds with a human verdict after each. The result is a design note and tickets.

Ask a model for ideas and you get the obvious ones. Good ideas come when a human pushes back in between. The creative skill gives that a fixed shape: one technique per round, then your verdict, then the next round on top of what survived.

Why it exists: while designing Wunschwelt, a small multiplayer game, Claude's first ideas for an animal collection were the ones every game already has. Rounds with a verdict in between turned them into a design the code can actually compute.

Example question: How do we get people to open a new reading app every day?

Claude stops after each round and waits for your verdict. Every idea must pass one question: how does the code know? A rule that cannot be computed is not a rule.

The session ends with a design note (decisions, mechanisms, tuning numbers) and tickets in your tracker.

Save this as ~/.claude/skills/creative/SKILL.md and type /creative, or just ask for a brainstorm.

---
name: creative
description: "Guided creativity session between Claude and the user - three techniques in fixed rounds (\"Like X, but ...\", reverse brainstorming, \"what makes us do it in real life\"), the user judges after every round, the result is a design note and tickets. Use when the user asks for a brainstorm, a creativity session, ideas for a feature or a design, says \"let's get creative\" (in any language), names one of the three techniques, or opens a ticket that asks for a brainstorm."
---


A model predicts; on its own it lands on the obvious. The ideas get good
when the user pushes back between the rounds ("hundreds of options for ten
users?", "how does the code know the user is stuck?"). This skill is the
frame for that: one technique per round, then the user's verdict, then the
next technique on top of what survived. Never run the rounds in one go.

## 0. The question

- State the question in one sentence and what a good answer must do
  (e.g. "how do we get people to come back every week?").
- If a ticket or issue holds the session, read it and its comments first;
  mark it as in progress in the project's tracker.
- Name the constraints already known (platform, budget, audience, what
  exists). Ask nothing that the code or the ticket answers.

## 1. Round one: "Like X, but ..."

- Pick five existing things that already do what the question asks
  (products, services, rituals, objects; for a habit: a fitness tracker, a
  language app, a gym membership, ...). Prefer famous ones: their strength
  is proven.
- For each, write at least five sentences of the form "Like X, but ...":
  each keeps what makes X work and turns one thing toward our project.
- Mark the two or three strongest with a short reason.
- Show it, then stop and wait. The user says what is good, what is a
  problem, and what to dig into.

## 2. Round two: reverse brainstorming

- Take the user's open points from round one as the targets.
- Ask the reverse question: "How do we make this as bad / boring /
  frustrating as possible?" Write 8 to 12 honest answers.
- Turn each answer around into a rule or mechanic. Keep the pairs visible
  (bad -> turned), the reader must see where each idea came from.
- Every open point gets a concrete proposal with numbers or a mechanism,
  not a mood. Where a proposal needs a decision, give options and a
  recommendation.
- Show it, then stop and wait. Record the user's decisions word for word
  (they become the rules of the design).

## 3. Round three: what makes us do it in real life

- Ask why people do the thing without any product around it
  (a habit: the morning coffee, the weekly market, a walk with a friend).
- For each real example: what is the pull (routine, company, a small reward,
  the place, the season), and what our project can borrow.
- Put it on top of rounds one and two: what it adds, what it confirms,
  what it replaces.
- Show it, then stop and wait.

## 4. Hard questions to ask yourself every round

- How does the code know? A rule that cannot be computed is not a rule.
  If it cannot, propose the data that makes it computable or drop it.
- What does it cost to run: model calls, storage, screen space, the
  user's attention?
- What happens at scale (many users, many items, a long time)?
- Can it be tuned without a deploy? Every number goes into the project's
  config, never into code.
- Is it fair and kind to the people who use it (no dark patterns, no
  punishing absence)?

## 5. The outcome

- A design note, as a comment on the session ticket or as a file in the
  project's docs: the decisions first, each with its mechanism and its
  tuning numbers; what was dropped and why in one line each. Facts only,
  no tour of how we got there.
- Build tickets in the project's tracker, small enough for one session
  each, with dependencies in the order they build on each other, and the
  tuning numbers named in them. No tracker: a numbered task list in the
  note.
- Move the session ticket to review.
- Report to the user: the note's link or ticket, the new ticket ids, what
  needs a decision before building starts.

## Style

- Chat in the user's language; the note and tickets follow the project's
  language rule.
- Short sentences, concrete examples from the project, numbers where they
  help.
- Disagree when a point does not hold, and say why; the user wants a
  partner, not an echo.