Studio Next-Step Help

Step 4m: The Minimal Path (workflow: minimal only)

At minimal the route is the catalog's paths.minimal, not a phase: engine → design/game-brief.md → stories → /dev-story ↔ /story-done. Resolve it in one call:

Bash: bash .claude/scripts/artifact-check.sh --path minimal

Map the statuses exactly as in Step 4. implement and story-done are NO_CHECK by design — the story status lines below are their check. The next step is the first of these that applies:

1. engine-setup not PRESENT → /setup-engine
2. game-brief not PRESENT → /brainstorm (at minimal it writes the one-page brief)
3. create-stories not PRESENT → /create-stories with no argument (at minimal it builds the stories straight from the brief's MVP list)
4. Stories exist → the list below was printed by .claude/scripts/story-status.sh before you read this skill: one line per unfinished story, already in the route's order — IN_REVIEW, then IN_PROGRESS, then TODO (a Ready or Not Started story) in build order — then BLOCKED, OTHER, NO_STATUS and the COMPLETE count:

!bash "${CLAUDE_SKILL_DIR}/../../scripts/story-status.sh"

Next up is the story on the first IN_REVIEW, IN_PROGRESS or TODO line. The list is already current; do not run the script again, and do not re-read or re-rank the story files: an In Review story is closed before an In Progress one continues — its work is written, and /story-done is quick.

• IN_REVIEW → its work is written and waiting to be closed: /story-done [path]
• IN_PROGRESS → it is not done — whatever the code or commits suggest, only /story-done makes a story Complete. Recommend /story-done [path] only if the user, active.md or the git log says its implementation is written; otherwise /dev-story [path] to carry on
• TODO → /dev-story [path]
• a BLOCKED story → name it and its blocker; it is never Next up
• no IN_REVIEW, IN_PROGRESS or TODO line, but BLOCKED, OTHER or NO_STATUS lines remain → nothing can be built next, and the build order is not done. Name each of those stories with its status as written, and a blocked story's blocker (read it from that story's file). Next up is clearing the first of them: resolve its blocker, or give an OTHER or NO_STATUS story a Status: line the route reads (Ready once it can be built)
• every story Complete (or Done) → the brief's build order is done. Say so, and offer three ways on: play the build; add the next stories from the brief with /create-stories; or, if the game has outgrown a one-page brief, /settings to raise modes.rigor.

At minimal, never present any of these as required or as a blocker: the game concept doc, art bible, systems map, GDDs, /create-epics, a sprint plan, /gate-check, or sprint close-out (/smoke-check, /team-qa, /retrospective). The brief replaces the design docs and its build order replaces the sprint plan (.claude/docs/workflow-modes.md — minimal floor). Every one of them still runs if the user asks for it; mention one only when the user's argument asks about it.

Then skip Steps 5 and 8, and present with the minimal shape in Step 7.

Step 5: Find Position and Identify Next Steps

From the completion data, determine:

1. Last confirmed complete step — the furthest completed required step
2. Current blocker — the first incomplete required step (this is what the user must do next)
3. Optional opportunities — incomplete optional steps that can be done before or alongside the blocker. Surface these per the workflow tier: at full, list all of them; at standard, list an optional doc only if it is required for the current system/phase (do not flag genuinely-optional docs as gaps). At minimal this step does not run — Step 4m replaces it
4. Upcoming required steps — required steps after the current blocker (show as "coming up" so user can plan ahead)

If the user provided an argument (e.g. "just finished design-review"), use that to advance past the step they named even if the artifact check is ambiguous.

Step 6: Check for In-Progress Work

If active.md shows an active task or epic:

• Surface it prominently at the top: "It looks like you were working on [X]"
• Suggest continuing it or confirm if it's done

Step 7: Present Output

Keep it short and direct. This is a quick orientation, not a report.

## Where You Are: [Phase Label]

**In progress:** [from active.md, if any]

### ✓ Done
- [completed step name]
- [completed step name]

### → Next up (REQUIRED)
**[Step name]** — [description]
Command: `[/command]`

### ~ Also available (OPTIONAL)
- **[Step name]** — [description] → `/command`
- **[Step name]** — [description] → `/command`

### Coming up after that
- [Next required step name] (`/command`)
- [Next required step name] (`/command`)

---
Approaching **[next phase]** gate → run `/gate-check` when ready.

At minimal use this shape instead — no phase label, no gate line. N counts only stories whose status line says Complete or Done, and only those go under ✓ Done. N and M are the two numbers on the COMPLETE line; it names no finished story, so ✓ Done gives their count, not their titles:

## Where You Are: Minimal path — [N] of [M] stories complete

**In progress:** [from active.md, if any]

### ✓ Done
- Engine: [engine] · Game brief · [N] stories

### → Next up
**[Story NNN: title]** — [what it delivers]
Command: `/story-done [story-path]` for an In Review story, or an In Progress one whose work is written; otherwise `/dev-story [story-path]`

### Coming up after that
- [the next Ready stories in build order, at most 3]

Formatting rules:

• ✓ for confirmed complete
• → for the current required next step (only one — the first blocker)
• ~ for optional steps available now
• Show commands inline as backtick code
• If a step has no command (e.g. "Implement Stories"), explain what to do instead of showing a slash command
• For MANUAL steps, ask the user: "I can't tell if [step] is done — has it been completed?"

Verdict: COMPLETE — next steps identified.

Step 8: Gate Warning (if close)

Skip this step at minimal — the minimal path has no phase gates.

After the current phase's steps, check if the user is likely approaching a gate:

• If all required steps in the current phase are complete (or nearly complete), add: "You're close to the [Current] → [Next] gate. Run /gate-check when ready."
• If multiple required steps remain, skip the gate warning — it's not relevant yet.

Step 9: Escalation Paths

After the recommendations, if the user seems stuck or confused, add:

---
Need more detail?
- `/project-stage-detect` — full gap analysis with all missing artifacts listed
- `/gate-check` — formal readiness check for your next phase
- `/start` — re-orient from scratch
- `/settings` — if the process feels mismatched to your project, adjust
  `modes.rigor`. Apply the change-triggers in
  `.claude/docs/settings-guidance.md § 4`: a **lower** tier when the user sounds
  overwhelmed by process (and rigor isn't already `minimal`), or a **higher** tier
  when the project has outgrown it (many systems, or in Production on
  `workflow: minimal`)

Only show this if the user's input suggested confusion (e.g. "I don't know", "stuck", "lost", "not sure"). Don't show it for simple "what's next?" queries. Show the /settings rigor line only when a settings-guidance.md § 4 trigger actually fires — the user sounds overwhelmed (and rigor isn't already minimal), or the project has outgrown its tier — not on every confused query. At minimal, leave out the /gate-check line: the minimal path has no phase gates (Step 4m).

Collaborative Protocol

• Never auto-run the next skill. Recommend it, let the user invoke it.
• Ask about MANUAL steps rather than assuming complete or incomplete.
• Match the user's tone — if they sound stressed ("I'm totally lost"), be reassuring and give one action, not a list of six.
• One primary recommendation — the user should leave knowing exactly one thing to do next. Optional steps and "coming up" are secondary context.