/default-mode

Default Mode Reference

This is the full creative cycle planning flow. Fires when the user picks "Add stories now" at Step 1b. Brainstorms stories, captures sparks (with optional creative-spark per story), reviews the cycle, and offers planning paths.

The orchestrator command (`commands/craft-cycle-design.md`) defines the routing - this reference contains the full mode flow.

---

**Tracker issue check**: read `.craft/cycles/[PLANNING_CYCLE]/cycle.yaml`. If it has a non-empty `source_issue`, Read `${CLAUDE_PLUGIN_ROOT}/commands/references/tracker-follow.md` with that cycle's directory and continue only through its `## Continue`. A cycle without a `source_issue` skips this and nothing below changes.

Step 2: Story Brainstorm

> "Let's map out the stories for this cycle. > > What needs to happen to achieve: **[goal]**?"

Help the user decompose the cycle into stories through conversation:

• What are the pieces?
• What's the user journey?
• What are the dependencies?

**Note:** Don't automatically invoke `creative-spark` here. The user usually knows what stories they need — they're decomposing a known feature. Creative exploration happens per-story in Step 3.

**Only invoke `creative-spark`** if the user is genuinely unsure what stories the cycle needs (e.g., "I don't know where to start" or "What would you suggest?").

**Waiting designs (before presenting):** Read `"${CLAUDE_PLUGIN_ROOT}/commands/references/story-from-craft-designs.md"` with the Read tool - never via the Skill tool - and run its `## Search` once. If nothing waits, the list below reads exactly as it would without this step. If a design waits (a mockup that converged or was parked, an annotate run still open), judge each one against the cycle goal and the discussion:

• A design that fits the goal goes into the numbered list as a story candidate with its type tag and a source tag, `*From the <slug> <mockup|annotate run>* (<status word>, waiting)`, after its one-line description. It counts as one deliverable like any other story line.
• A design that does not fit is named once, after the list, on a single line: `Also waiting, not in this goal: <slug> (<kind>, <date>)`. List several as one line, comma-separated.

This adds no question: the save question that closes the list carries it.

Present initial story list with inferred type tags (`ui`, `technical`, or `content`). Infer the type from conversational context — if the story involves visual design, layout, or animation it's `ui`; if it's API routes, data, or infrastructure it's `technical`; if it's copy, tone, or onboarding flow it's `content`.

**Scope check (before presenting):** Before showing the story list, evaluate whether the story count matches the scope complexity. Count the concrete deliverables in the cycle goal and discussion — interactive features, distinct pages/views, API endpoints, data models, content surfaces. Apply these heuristics:

• If deliverables-per-story ratio exceeds ~3, the stories are probably too coarse
• If any single story covers more than one distinct concern (e.g., "build layout AND wire interactions AND add animations"), it should likely split
• If the project has existing completed cycles, compare story count against similar-scope cycles in `.craft/cycles/`

If the scope looks thin, include a **Scope check** note inline with the story list. If the count looks reasonable, present the list without commentary.

**When the check fires:**

> "Based on our discussion, I'm thinking these stories: > > 1. **[Story idea 1]** `ui` — [one line] > 2. **[Story idea 2]** `ui` — [one line] > 3. **[Story idea 3]** `ui` — [one line] *From the <slug> <mockup|annotate run>* (<status word>, waiting) > > **Scope check:** This cycle covers [N deliverables] but only has [M] stories. [Specific concern — e.g., "Story 2 alone covers 5 interactive commands with distinct animations - that could be 8+ chunks. Consider splitting into separate stories per command group."] You can proceed as-is or adjust. > > Also waiting, not in this goal: <slug> (<kind>, <date>) > > Save these as the sparks?"

**When the check doesn't fire:**

> "Based on our discussion, I'm thinking these stories: > > 1. **[Story idea 1]** `ui` — [one line] > 2. **[Story idea 2]** `technical` — [one line] > 3. **[Story idea 3]** `ui` — [one line] *From the <slug> <mockup|annotate run>* (<status word>, waiting) > > Also waiting, not in this goal: <slug> (<kind>, <date>) > > Save these as the sparks?"

What each reply does:

• **A yes** saves the list as it stands: jump to **Step 3-Fast** below.
• **Going through them one at a time** runs every story through Step 3 (per-story flow).
• **Adding, dropping or combining stories** edits the list and shows it again, ending on the same question.
• **A reply that is none of these** gets the same question back, with the list unchanged. Never assume what it means.

Don't proceed until the user confirms the story list is complete.

Step 2.7: Story-Source Routing (Per Story, Before Step 3 or Step 3-Fast)

**Design-extraction moment.** This runs first, before the `cycle.yaml` read below, so a freeform cycle never skips it. For each story the user kept that carries a source tag from Step 2 (a story tied to a waiting design), the story is produced from that design, not from a fresh spark:

1. Run the `## Pick` of `story-from-craft-designs.md` with that design named (the conversation already named it, so there is no confirm and no question), then its `## Hand-off`. The graduation reference it reads writes the story, pre-filled, and marks the record graduated. 2. Move the written story into this cycle: `bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/move-story.sh" "<story path the graduation reference reported>" "<this cycle's directory name>"` (the full directory name, for example `<N>-<cycle-name>`). 3. Continue with the next kept story.

A design-tied story skips the planning routing below and the Step 3a-3e / Step 3-Fast template. Handle the kept list in order