DonchitosandClaude Opus 5.5
be8993bbc5
Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
2.9 KiB
/story-done — Phase 1: Find the Story
Part of
/story-done.SKILL.mdnames when to read this file; the settings it resolved and the rules under its later headings still apply here.
Phase 1: Find the Story
See .claude/docs/director-gates.md for the full check pattern. Individual gate definitions live in .claude/docs/director-gates/[gate-id].md — the spawned agent reads its own gate file; do not read it in the parent session.
Every AskUserQuestion call follows .claude/docs/automation-modes.md
(collaborative asks always · guided major-only · autonomous logs and proceeds;
automation_always_ask categories always prompt).
Workflow tier: resolved per the story's system (per
.claude/docs/workflow-modes.md) — the GDD filename stem of the story's
GDD: path (design/gdd/<stem>.md → <stem>), with the [system] segment of
its TR-[system]-NNN ID accepted only as a fallback alias: use the
system_overrides row for that system if the block lists one, else the
project value. It governs which Phase 4 deviation checks run — see Phase 4.
Workflow companion — modes.story_granularity (resolved above — supplied by
modes.rigor unless set explicitly): cadence expectation only — story-done fires every 3–5 days at
coarse, every 1–2 days at balanced, multiple times/day at fine. It
does not change any completion check.
qa.level: controls whether test evidence is required, where
testing.strict controls whether a failure blocks and workflow controls which
docs exist. modes.rigor sets qa.level and workflow together; set either
explicitly to vary it alone. testing.strict is not fronted by rigor at all.
At minimal, no test evidence is required → skip the Logic, Integration and
Config/Data evidence checks (Phase 3), the >50%-untested traceability escalation,
and the Phase 4b QA gate; the acceptance-criteria verification still runs, and so
do the Visual/Feel and UI screenshot gate and the Run result: check for other
story types — the look is never waived. At
standard, the story's own type requires evidence; at full, every type does.
testing.strict then decides whether present-but-failing evidence blocks.
(rigor: minimal sets both; qa.level: minimal on its own leaves the workflow
tier where it was.)
If a file path is provided (e.g., /story-done production/epics/core/story-damage-calculator.md):
read that file directly.
If no argument is provided:
- Check
production/session-state/active.mdfor the currently active story. - If not found there, read the most recent file in
production/sprints/and look for stories marked IN PROGRESS. - If multiple in-progress stories are found, use
AskUserQuestion:- "Which story are we completing?"
- Options: list the in-progress story file names.
- If no story can be found, ask the user to provide the path.