story-done
Skill4 starsChanged 47 days agoMITView on GitHub
Verifies a story is truly done — every acceptance criterion has a passing test with output, lint/typecheck/security checks pass, review APPROVED, docs updated — then closes it, updates roadmap and session state, opens the PR if none exists and merges it on green CI, each behind its own gate. Run after /code-review, or for 'close the story', 'S-NNN is done', 'merge the PR'.
- Commits and pushes
10 other projects use a version of this.
Adopted by
Most recently taken up by
- striderZA/OpenCodeGameStudiostheir own version, first seen Nov 4, 2026
- Donchitos/Claude-Code-Game-Studiostheir own version, first seen Oct 19, 2026
- venus2099/codex-game-studiostheir own version, first seen Oct 17, 2026
- ShiningPlague/shiningplague-studiotheir own version, first seen Oct 11, 2026
- HunLuanZhiZhu/Game-Studios-Plugintheir own version, first seen Oct 5, 2026
- dawn840705/claude-code-studiostheir own version, first seen Aug 28, 2026
Used with
Projects with it also use vertical-slice.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
hongyuancSkillvertical-slice
Build and evaluate a production-quality vertical slice before advancing from Pre-Production to Production.
Also in 4 projects that use this
Other versions10 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 10
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- striderZA/OpenCodeGameStudios★ 118same name
- cenconq25/claude-code-app-studio★ 40same name
- dawn840705/codex-code-studios★ 17same name
- lilangMax/ClaudeCodeGameStudios★ 8same name
- hongyuanc/codex-game-studios★ 5same name
- dawn840705/claude-code-studios★ 1same name
- HunLuanZhiZhu/Game-Studios-Plugin★ 1same name
- venus2099/codex-game-studios★ 1same name
- ShiningPlague/shiningplague-studio★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository52 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- testing/CLAUDE.mdCLAUDE.md
- a11y-auditSkill
- adoptSkill
- api-contractSkill
- architecture-decisionSkill
- architecture-reviewSkill
- backlogSkill
- brainstormSkill
- changelogSkill
- code-reviewSkill
- collaboration-protocolSkill
- create-storiesSkill
- data-modelSkill
- dependency-auditSkill
- deploySkill
- design-systemSkill
- dev-storySkill
- docsSkill
- feature-specSkill
- game-conceptSkill
- hardenSkill
- helpSkill
- hotfixSkill
- impactSkill
- incidentSkill
- initSkill
- migrateSkill
- pentestSkill
- perf-auditSkill
- product-specSkill
- qa-planSkill
- refactorSkill
- release-checklistSkill
- retrospectiveSkill
- security-auditSkill
- setup-stackSkill
- skill-improveSkill
- skill-testSkill
- sprint-planSkill
- sprint-statusSkill
- stack-updateSkill
- startSkill
- team-featureSkill
- team-gameSkill
- team-releaseSkill
- team-securitySkill
- tech-debtSkill
- test-setupSkill
- threat-modelSkill
- updateSkill
- ux-specSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 1 is distinctive, and 6 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Run the tests from the criteria matrix and the whole affected package.
- Very specific: line 31
Run lint/typecheck; govulncheck / audit when dependencies changed.
- Very specific: line 33
Put the output in the report.
- Very specific: line 40
Findings recorded: every ARCH-NNN/SEC-NNN in the card has a row in production/findings.md.
- Very specific: line 48
Verdict point: every item ✅ (item 10 may read pending) → DONE, continue.
- Very specific: line 55
The edits: read references/close-edits.md and apply its four edits — actual time (Actual:, ⏱ Nh, both ends in one clock), roadmap line …
- Very specific: line 60
Only on DONE, after Phase 4 or through the re-run rule.
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Story Done
Language, <hooks>, agent and command namespaces, gate mechanics (record Gate → ask → clear; consent marker after the "write" answer) and the CI wait: docs/coordination-rules.md § Skill conventions. Every mutation (files, git, merge) has its own gate, asked by this session, never by a subagent.
Glossary:
<default>— the default branch (masterormain);<branch>— the story branch (Branch:in the session state, elsegit branch --show-current).<card>—production/stories/S-NNN-*.md;<sprint>—production/sprints/sprint-NN.mdwhen a sprint's roadmap heading holds the story.- Three places — the roadmap line, the roadmap's
## Docs→ production/stories/ row, the<sprint>## Storiesrow (two without a sprint). - Re-run rule —
/story-done S-NNNon a story alreadyDonewith an open PR skips to Phase 5 and its merge question. - GitHub MCP — with a GitHub MCP server the user added (
mcp__github__*; the plugin declares none — playbook § MCP), PR creation, merge and run watch may use its tools (create_pull_request,merge_pull_request, the actions tools) instead ofgh; the gates and the order do not change, and the tool output is quoted whereghoutput would be.
Phase 1: Story and evidence
- Pick the story (as
/dev-storyPhase 1):- The argument (a story path or
S-NNN), elseTask:inproduction/session-state/active.md, else ask — oneAskUserQuestion: the stories inReview(most recently started first, Recommended) · another story (say which) · stop. A story taken from the session state is named in the report's first line, so a staleTask:closes no wrong story. - Status
Review→ continue. - Status
Donewith an open PR (gh pr list --head <branch>) → the re-run rule: skip Phases 2–4, go to Phase 5. ReadyorIn Progress→NOT DONE (story not in Review — run /dev-story S-NNN, then /code-review); nothing is written.- Wording exception: a
Ready/In Progressstory whose branch carries afeat(S-NNN)commit (git log origin/<default>..<branch> --oneline | grep 'S-NNN') and a PR (gh pr list --head <branch>) was implemented and never stamped →NOT DONE (implemented but never set to Review — set it and re-run), naming the commit and the PR; the status is not changed here.
- The argument (a story path or
- Read the story, the feature-spec criteria, and the latest
/code-reviewreport (chat history, orproduction/reviews/if kept).
Phase 2: Run
- Run the tests from the criteria matrix and the whole affected package.
- Run lint/typecheck;
govulncheck/auditwhen dependencies changed. - For UI: axe on new pages (if e2e exists).
- Put the output in the report. Anything red →
NOT DONE.
Phase 3: DoD checklist
Each item is ✅ or an open item named in the report; recipe (exact commands): references/dod-checks.md, read here.
- Criteria ↔ tests: the criterion → test → result table rendered in the chat message (rule 7), not just written to the story file.
- The studio's review ran: a studio reviewer's
SubagentStopinproduction/session-logs/agent-audit.logafter the branch's first commit — the log, not the chat;security-sensitive→appsec-engineeramong them. Missing →NOT DONE (no studio review), naming the reviewer. - Review APPROVED: the reviewers' own verdict after the last fix (
/code-reviewPhase 5), not the parent's summary of it. - Findings recorded: every
ARCH-NNN/SEC-NNNin the card has a row inproduction/findings.md; an ID without a row is an open item, not a formality. - Docs (README/API/runbook) updated; contract and codegen in sync.
- TODOs carry an id (
rules/comments.md): every addedTODO/FIXME/HACKnames an id present in the roadmap or the backlog; a bare TODO or an unknown id is an open item, fixed by/backlog addand the id, never by deleting the TODO. - Branch pushed, tree clean:
git status --shortempty,.claude/agent-memory/**included (memory rides the story's commits, git-workflow § Agent memory). - No stash:
git stash listempty; an entry is an open item until the user applies or drops it, never a place to park memory files. - Memory commit for uncommitted memory files: one more
feat(S-NNN)/fix(S-NNN)commit of.claude/agent-memory/on the branch, behind<hooks>session-state.sh set Gate "/story-done Phase 3: commit agent memory?"→ oneAskUserQuestion→<hooks>session-state.sh set Gate "—"; nevergit stash, never a discard. - CI green on the branch:
gh run list --branch <branch>whenghexists; in progress → the CI wait. No run because the workflows trigger onpull_requestand no PR exists yet →pending (the PR opened in Phase 4 starts it), not open: DONE proceeds, Phase 5 step 1 waits for it.
Verdict point: every item ✅ (item 10 may read pending) → DONE, continue; otherwise NOT DONE (items) and stop — nothing written, nothing merged.
Phase 4: Close
Only on DONE.
- Close gate: show the draft as the resulting rows (
Actual: Nh/⏱ Nh, roadmap line,## Docsrow,<sprint>row;PR #Nis a placeholder until step 3 knows the number);<hooks>session-state.sh set Gate "/story-done Phase 4: close S-NNN?"; oneAskUserQuestion: "May I write<card>,production/roadmap.mdand<sprint>as shown, commitdocs: close S-NNN — Done, PR #N, push, and open the PR if none exists?" — close and open the PR (Recommended) · close without the PR · not now. Then<hooks>session-state.sh set Gate "—". The answer covers the close only, never the merge; "not now" ends with the verdict. - Count before editing:
grep -c "⏱" production/roadmap.mdandgrep -c "🔗 \[PR #" production/roadmap.md. - After the "yes":
touch .claude/.write-consent, then the PR number before any edit (the roadmap link,## Docsrow and commit carry it): a PR exists →gh pr view --json number,url; none and "close and open the PR" →gh pr create --fillnow, then read its number and URL; "close without the PR" → no PR number anywhere (references/close-edits.md§ Without a PR). - The edits: read
references/close-edits.mdand apply its four edits — actual time (Actual:,⏱ Nh, both ends in one clock), roadmap line ([x],🔗 PR,Updated:),## Docsrow,<sprint>row — oneEditper row, never a heredoc or a file rewrite. - Prove the edit, never assume it: run the two counts again, re-read the
## Docsrow, andgrep -E "^\| S-NNN .*Done" <sprint>when there is a sprint row.⏱or🔗 PRmissing from any of the three places → an unfinished DoD item in the report, numbers quoted: an answer can carry numbers that never reached the file. - Commit and push: stage exactly
<card>,production/roadmap.md(its story line and## Docsblock) and<sprint>when its row changed;git commit -m "docs: close S-NNN — Done, PR #N"(no PR:docs: close S-NNN — Done);git push, so the PR carries the close commit.
Phase 5: Merge (.claude/docs/git-workflow.md, step "Merge")
Only on DONE, after Phase 4 or through the re-run rule. No PR ("close without the PR", or no gh and none opened by hand) → skipped; say how to finish: open the PR, then re-run /story-done S-NNN (re-run rule).
- Wait for CI on the PR's latest commit: one background
gh run watch <run-id> --exit-status(orgh pr checks <n> --watch), § CI wait. Red →NOT DONE (CI red), nothing merged, the Phase 4 close stays (the DoD held on green CI in Phase 3; a red close commit is a new branch failure, not a reopened story); one report line "closed, not merged: CI red on<commit>"; after the fix, re-run/story-done S-NNN(re-run rule). - Merge gate:
<hooks>session-state.sh set Gate "/story-done Phase 5: merge PR #N?"; a separateAskUserQuestion: "PR #N is open and CI is green. Merge it into<default>and delete the branch now?" — merge now (Recommended when CI is green) · leave the PR open. Then<hooks>session-state.sh set Gate "—". - "yes":
- A draft PR (opened by
/dev-storyPhase 6) →gh pr ready <n>first. gh pr merge --merge --delete-branch(--squashonly when the project's CLAUDE.md says so).git switch <default> && git pull --ff-only origin <default>; delete the local story branch.<hooks>session-state.sh clear(the same writer/dev-storyused, so the file keeps its shape).
- A draft PR (opened by
- "no" (or no answer) → the PR stays open,
Branch:stays in the session state; how to merge later: re-run/story-done S-NNN(re-run rule), or merge on GitHub andgit switch <default> && git pull --ff-only origin <default>. - Without
gh: the same, by hand.NOT DONE→ nothing is merged.
Verdict: DONE | NOT DONE (reasons).
Next step — one AskUserQuestion:
- Sprint over (no
- [ ]line left under its roadmap heading after this close, or the heading's end date — its second ISO date — has passed) →/web-studio:retrospective NN(copy mode/retrospective NN) (Recommended): nothing else closes a sprint, and the next story would start in one that no longer exists ·/web-studio:sprint-status· stop. No/clear+dev-storyoption. - Otherwise →
/clear, then/web-studio:dev-story S-NNN(copy mode/dev-story S-NNN) (Recommended): a fresh session on the fresh default branch (rule 13); quote the statuslinectx:share when known ·/web-studio:sprint-status· stop. - Continuing the next story here is an "Other" the user types, never an option offered.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

