mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
Release 1.1.0 — one config file, and a process weight you choose
`project.yaml` at the repo root is now the single source of truth for a project's configuration, replacing `production/stage.txt`, `production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all three still read as a fallback; nothing is force-deleted). **`modes.rigor` — one question instead of six.** `minimal`, `standard` or `full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`, `modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to `minimal`, which is a change from 1.0's behaviour: the heavier tier was measured costing several times more to reach working code without producing a better result, and returning nothing when a fresh developer inherited the project. Pin `modes.rigor: standard` to keep 1.0's process level. Also in this release: - `/settings` to view or change any setting, and `project.local.yaml` for per-developer preferences that should not be committed. - `system_overrides` to hold one system to a higher standard than the rest of the project, and `testing.strict` to set per test type whether missing evidence blocks a story or warns. - A story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot retained in `production/qa/evidence/`. A parse check is not a run. This holds at every rigor level, including `minimal`, where automated tests are waived but the look is not. - The code root is engine-specific and enforced as such: Godot `src/`, Unity `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a project laid out any other way. - Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh` converts a 1.0 layout, non-destructively by default, with a report to review before `--finalize` deletes anything. - Ask-before-write holds regardless of personal automation settings. Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes: CHANGELOG.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd
This commit is contained in:
co-authored by
Claude Opus 5
parent
984023ddac
commit
d05699707f
@@ -0,0 +1,81 @@
|
||||
# /create-stories — Handoff Contract
|
||||
|
||||
## Role in Pipeline
|
||||
Decomposes a single epic into implementable story files by tracing GDD acceptance
|
||||
criteria through ADR decisions and manifest rules — sits between `/create-epics`
|
||||
and `/story-readiness` + `/dev-story`.
|
||||
|
||||
## Inputs Required
|
||||
|
||||
### Files That Must Exist
|
||||
| File | Required Fields / Sections | Read-Only? |
|
||||
|------|---------------------------|-----------|
|
||||
| `production/epics/[epic-slug]/EPIC.md` | `Layer:`, `GDD:` path, `Architecture Module:`, `## Governing ADRs` table, `## GDD Requirements` table with TR-IDs | Yes |
|
||||
| `design/gdd/[filename].md` | All 8 required sections, especially `## Acceptance Criteria`, `## Formulas`, `## Edge Cases` | Yes |
|
||||
| `docs/architecture/adr-NNNN-[slug].md` (all governing ADRs) | `Status:`, `Decision`, `Implementation Guidelines`, `Engine Compatibility`, `Engine Notes` | Yes |
|
||||
| `docs/architecture/control-manifest.md` | Layer rules (required patterns, forbidden patterns, guardrails), `Manifest Version:` date in header | Yes |
|
||||
| `docs/architecture/tr-registry.yaml` | All TR-IDs for the epic's system, with stable `id` values | Yes |
|
||||
|
||||
### Preconditions
|
||||
- `/create-epics` has been run and the target `EPIC.md` has `Status: Ready`
|
||||
- The EPIC.md contains a populated `## GDD Requirements` table (not empty)
|
||||
- All governing ADRs listed in the EPIC.md exist as files
|
||||
- Foundation epics have stories created before Core epics are started; Core before Feature; Feature before Presentation
|
||||
|
||||
## Outputs Produced
|
||||
|
||||
### Files Written
|
||||
| File | Guaranteed Fields / Sections | Notes |
|
||||
|------|------------------------------|-------|
|
||||
| `production/epics/[epic-slug]/story-NNN-[slug].md` | `Epic:`, `Status:`, `Layer:`, `Type:`, `Manifest Version:`, `## Context` (GDD path + `TR-[system]-NNN` + ADR reference + ADR Decision Summary + Engine/Risk + Engine Notes + Control Manifest Rules), `## Acceptance Criteria`, `## Implementation Notes`, `## Out of Scope`, `## Test Evidence`, `## Dependencies` | Created per story |
|
||||
| `production/epics/[epic-slug]/EPIC.md` | `## Stories` table replacing the "Not yet created" placeholder | Updated in-place |
|
||||
|
||||
### Output Guarantees
|
||||
- Every story file contains a `TR-[system]-NNN` reference in its `## Context` section (or `TR-[system]-???` with a warning if the registry has no match)
|
||||
- Every story file contains an `ADR Governing Implementation:` line referencing at least one ADR, or an explicit `No ADR applies` note
|
||||
- Every story file has a `Status:` field — either `Ready` or `Blocked` (if the governing ADR is `Proposed`)
|
||||
- Every story file has a `Type:` field — one of: Logic, Integration, Visual/Feel, UI, Config/Data
|
||||
- Every story file has a `Manifest Version:` field matching the date from `docs/architecture/control-manifest.md`'s header at time of writing
|
||||
- Every story file has a `## Test Evidence` section stating the expected evidence location for its type
|
||||
- Every story file has a `## Acceptance Criteria` section with at least one checkbox item copied from the GDD
|
||||
- Every story file has a `## Dependencies` section (may say "None" but is never omitted)
|
||||
- The EPIC.md `## Stories` table is updated with a row per story including `#`, `Story` title, `Type`, `Status`, and `ADR`
|
||||
- Stories with a `Proposed` ADR have `Status: Blocked` and a note: `BLOCKED: ADR-NNNN is Proposed — run /architecture-decision to advance it`
|
||||
- Every story file has an `Engine` and a `Risk` field. `Risk` is taken from `docs/engine-reference/<engine>/VERSION.md`; when that file is missing or assigns no level, `Risk` is **`NOT ASSESSED (no VERSION.md risk rating)`** — never a guessed level
|
||||
- **`NOT ASSESSED` is an emittable value of the `Risk` field**, and downstream readers must handle it. `/dev-story` treats it as HIGH when deciding whether to spawn the engine specialist: an unknown risk is not a low one
|
||||
|
||||
## Immutability Rules
|
||||
- READS but does NOT modify: the epic's GDD, all ADR files, `docs/architecture/tr-registry.yaml`, `docs/architecture/control-manifest.md`
|
||||
- MODIFIES: `production/epics/[epic-slug]/story-NNN-[slug].md` (creates), `production/epics/[epic-slug]/EPIC.md` (updates Stories section only)
|
||||
|
||||
## Hard Constraints (Never Violate)
|
||||
- Never start implementation — this skill stops at the story file level
|
||||
- Never invent acceptance criteria — all criteria must come from the GDD
|
||||
- Never invent implementation notes — all guidance must come from the referenced ADR
|
||||
- Never write story files without presenting the full story list for approval first
|
||||
- Never mark a story `Status: Ready` if its governing ADR has `Status: Proposed`
|
||||
- Never omit the `Manifest Version:` field — downstream readiness checks depend on it
|
||||
- Never reuse a story number (NNN) that already exists in the epic directory
|
||||
|
||||
## Downstream Skill Expects
|
||||
**Next skill:** /story-readiness (then /dev-story)
|
||||
|
||||
It will read:
|
||||
- Each `story-NNN-[slug].md` file — specifically: `Status:`, `Type:`, `Manifest Version:` (header), `TR-[system]-NNN` (in `## Context`), `ADR Governing Implementation:` line, `## Acceptance Criteria` section, `## Test Evidence` section, `## Dependencies` section
|
||||
- `docs/architecture/control-manifest.md` — to compare its `Manifest Version:` against the story's embedded version
|
||||
- The referenced ADR file — to verify its `Status:` field is still `Accepted`
|
||||
|
||||
It assumes:
|
||||
- `Manifest Version:` in the story header is a date string that can be compared against the manifest's current `Manifest Version:` date
|
||||
- `TR-[system]-NNN` IDs are resolvable in `docs/architecture/tr-registry.yaml`
|
||||
- The ADR referenced by name in `ADR Governing Implementation:` exists as a file in `docs/architecture/` (pattern: `adr-NNNN-[slug].md`)
|
||||
- `Status: Ready` means the story is a candidate for assignment (not Draft, not in progress)
|
||||
- `## Acceptance Criteria` contains checkbox items that are directly testable
|
||||
- `## Test Evidence` specifies an exact file path or evidence doc path where proof will be stored
|
||||
|
||||
## Known Fragile Points
|
||||
- If the story file format (header field names, section names, checkbox syntax) changes, `/story-readiness` will silently skip checks for fields it cannot parse — stories may pass readiness that should fail
|
||||
- If `control-manifest.md` is regenerated with a new `Manifest Version:` date after stories are written, all existing stories will show a stale manifest version and fail the readiness manifest check — every story in the epic will need its `Manifest Version:` updated
|
||||
- If a governing ADR is renumbered or its file is renamed after stories are written, the `ADR Governing Implementation:` reference in story files will point to a missing file and `/story-readiness` will BLOCK those stories
|
||||
- If `tr-registry.yaml` deprecates or supersedes a TR-ID that is already embedded in story files, `/story-readiness` will flag those stories as NEEDS WORK
|
||||
- The EPIC.md Stories table update is append-style — if `/create-stories` is run twice for the same epic, duplicate rows will appear in the table
|
||||
@@ -1,13 +1,18 @@
|
||||
---
|
||||
name: create-stories
|
||||
description: "Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance criteria, story type, and test evidence path. Run after /create-epics for each epic."
|
||||
description: "Break one epic into implementable stories embedding TR-ID, ADR guidance, acceptance criteria. Reads the control manifest. After /create-epics."
|
||||
argument-hint: "[epic-slug | epic-path] [--review full|lean|solo]"
|
||||
user-invocable: true
|
||||
allowed-tools: Read, Glob, Grep, Write, Task, AskUserQuestion
|
||||
allowed-tools: Read, Glob, Grep, Write, Agent, AskUserQuestion
|
||||
model: sonnet
|
||||
agent: lead-programmer
|
||||
---
|
||||
|
||||
!`source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 2>/dev/null && resolve_config --keys review_mode,automation,workflow,docs.density,story_granularity,system_overrides`
|
||||
|
||||
Resolved above — use as-is; `--review` overrides `review_mode`. No block →
|
||||
defaults in `.claude/docs/config-resolution.md`.
|
||||
|
||||
|
||||
# Create Stories
|
||||
|
||||
A story is a single implementable behaviour — small enough to complete in one
|
||||
@@ -27,38 +32,135 @@ then Core, and so on — matching the dependency order.
|
||||
|
||||
## 1. Parse Argument
|
||||
|
||||
Extract `--review [full|lean|solo]` if present and store as the review mode
|
||||
override for this run. If not provided, read `production/review-mode.txt`
|
||||
(default `lean` if missing). This resolved mode applies to all gate spawns
|
||||
in this skill — apply the check pattern from `.claude/docs/director-gates.md`
|
||||
before every gate invocation.
|
||||
|
||||
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`** for this epic's system (per `.claude/docs/workflow-modes.md`) —
|
||||
use the `system_overrides` row for `<system>` if the block lists one, else the
|
||||
project value. `<system>` is the epic slug / its GDD system. The tier sets which prerequisites block — see the note in Step 2.
|
||||
|
||||
**`story_granularity`** — it sets each
|
||||
story's AC load: **5–10 ACs covering a whole feature** at `coarse`, **2–4 ACs
|
||||
covering one task** at `balanced` (default), **1 AC** at `fine` (the story name is
|
||||
the AC restatement). Group or split ACs into stories to hit the target.
|
||||
|
||||
**`docs.density`** — it controls the *depth* of each story's prose (context,
|
||||
implementation notes, ADR summary), not the AC count (that is
|
||||
`story_granularity`) and never the AC text itself. `modes.rigor` sets it
|
||||
alongside `workflow`; set `docs.density` explicitly to vary story prose alone:
|
||||
`terse` = notes as bullets, no preamble; `balanced` = short context paragraph +
|
||||
notes (default); `thorough` = full context, implementation guidance, and ADR
|
||||
rationale. The embedded TR-ID reference, ADR Version stamp, and acceptance
|
||||
criteria are structural and are never trimmed by density.
|
||||
|
||||
- `/create-stories [epic-slug]` — e.g. `/create-stories combat`
|
||||
- `/create-stories production/epics/combat/EPIC.md` — full path also accepted
|
||||
- No argument — ask: "Which epic would you like to break into stories?"
|
||||
Glob `production/epics/*/EPIC.md` and list available epics with their status.
|
||||
- No argument — at `minimal` there are no epics yet (Option A): skip to Step 2's
|
||||
`minimal` branch and synthesize the epic from `design/game-brief.md`. At
|
||||
`standard`/`full`, ask "Which epic would you like to break into stories?" and
|
||||
Glob `production/epics/*/EPIC.md` to list available epics with their status.
|
||||
|
||||
> **If that glob returns nothing at `standard`/`full`, stop — do not build a
|
||||
> question with no options.** Report:
|
||||
> "No epics found under `production/epics/`. Run `/create-epics layer: foundation`
|
||||
> first — an epic is what this skill decomposes."
|
||||
>
|
||||
> **The zero-epic path is load-bearing.** Asking which epic *and* globbing to
|
||||
> list them leaves an `AskUserQuestion` with nothing to offer when the glob is
|
||||
> empty. Route to `/create-epics` instead — it is named as **Previous step**
|
||||
> in this skill's own header.
|
||||
>
|
||||
> Note what this skill guarded and what it did not. Step 2's ADR validation is
|
||||
> thorough: three tiers, each with its own stop condition, and an explicit
|
||||
> message naming the missing file. That is the **deepest** input. The **first**
|
||||
> input — does an epic exist at all — went unchecked. Guarding the far end of a
|
||||
> chain while leaving the near end open is the shape to watch for.
|
||||
>
|
||||
> At `minimal` this does not apply: there are deliberately no epics, and the
|
||||
> branch above synthesizes one from the brief.
|
||||
|
||||
---
|
||||
|
||||
## 2. Load Everything for This Epic
|
||||
|
||||
Read in full:
|
||||
> **`minimal` tier — synthesize the epic from the brief** (Option A). At
|
||||
> `minimal` there is no `/create-epics` step and no `EPIC.md`. Instead:
|
||||
> 1. Read `design/game-brief.md` in full (it is one page).
|
||||
> 2. Synthesize an implicit epic: write a lightweight
|
||||
> `production/epics/<slug>/EPIC.md`, where `<slug>` is the brief's slugified
|
||||
> working title (`mvp` if untitled) — goal = the brief's one-sentence pitch,
|
||||
> scope = its MVP feature list, ordering = its **Build order**. Keep it terse;
|
||||
> this is the container `/dev-story` and `/sprint-status` expect.
|
||||
> 3. Generate **one coarse story per MVP feature** (Step 3+), in Build-order
|
||||
> sequence, each traced to the brief (not a GDD/TR-ID). Leave stories unblocked
|
||||
> on ADR grounds — none exist at this tier.
|
||||
> Skip the GDD, control-manifest, TR-registry, and ADR reads below (none exist at
|
||||
> `minimal`), then continue to Step 3 with the synthesized epic.
|
||||
|
||||
For `standard`/`full` (a `/create-epics` epic exists), read in full (these are small):
|
||||
|
||||
- `production/epics/[epic-slug]/EPIC.md` — epic overview, governing ADRs, GDD requirements table
|
||||
- The epic's GDD (`design/gdd/[filename].md`) — read all 8 sections, especially Acceptance Criteria, Formulas, and Edge Cases
|
||||
- All governing ADRs listed in the epic — read the Decision, Implementation Guidelines, Engine Compatibility, and Engine Notes sections
|
||||
- `docs/architecture/control-manifest.md` — extract rules for this epic's layer; note the Manifest Version date from the header
|
||||
- `docs/architecture/tr-registry.yaml` — load all TR-IDs for this system
|
||||
- The epic's GDD (`design/gdd/[filename].md`) — at `full` read all 8 sections; at `standard` the 5 required sections (+ conditional Formulas); at `minimal` the GDD may not exist — work from the epic brief + acceptance criteria. Always prioritise Acceptance Criteria, Formulas, and Edge Cases where present.
|
||||
- `docs/architecture/control-manifest.md` — grep only this epic's layer (`Grep pattern="^## <layer> Layer Rules" path="docs/architecture/control-manifest.md" output_mode="content" -A 40`) plus the header Manifest Version date, not a full read of all layers
|
||||
- `docs/architecture/tr-registry.yaml` — grep only this system's entries (`Grep pattern="system: <slug>" path="docs/architecture/tr-registry.yaml" output_mode="content" -B1 -A5`, or `id: TR-<slug>-`), not the whole cross-system registry
|
||||
|
||||
**ADR existence validation**: After reading the governing ADRs list from the epic, confirm each ADR file exists on disk. If any ADR file cannot be found, **stop immediately** before decomposing any story:
|
||||
**Load each governing ADR by section — never with an unbounded full read.** A
|
||||
substantial ADR exceeds the 25k-token `Read` cap, and a capped read's only
|
||||
recovery is paging through the remainder — the most expensive possible way to
|
||||
read a file (measured at 103k tokens on a 34k-token ADR vs ~54k for targeted
|
||||
reads of the same file). Per ADR:
|
||||
|
||||
1. **Map the headings** (cheap — line numbers only):
|
||||
```
|
||||
Grep pattern="^## |^### Implementation Guidelines" path="docs/architecture/[adr-file].md" output_mode="content" -n
|
||||
```
|
||||
2. **Bounded-read exactly the sections this skill consumes**, using the line
|
||||
numbers from the map to set `Read(offset, limit)` spans that end where the
|
||||
next section begins:
|
||||
- `## Summary` and `## Decision` (including its `### Implementation
|
||||
Guidelines` subsection) — these feed the story's ADR Decision Summary
|
||||
and Implementation Notes.
|
||||
- `## Engine Compatibility` — feeds the story's Engine, Risk, and Engine
|
||||
Notes fields. (Engine Notes is a *story* field derived from this
|
||||
section — it is not an ADR section name; do not search for one.)
|
||||
3. **Capture the `## Last Verified` date**:
|
||||
```
|
||||
Grep pattern="^## (Last Verified|Date)" path="docs/architecture/[adr-file].md" output_mode="content" -A 1
|
||||
```
|
||||
Use `Last Verified`, falling back to `Date`, then to `unversioned` if both
|
||||
are absent. This becomes the story's `ADR Version` stamp — `/dev-story`
|
||||
uses it to decide whether it can trust this story's distilled summary
|
||||
instead of re-opening the ADR.
|
||||
|
||||
Skip Context, Alternatives Considered, Consequences, Risks, and any
|
||||
Amendments Log unless a section you loaded explicitly cross-references one of
|
||||
their entries — then take only the referenced entry with one more bounded
|
||||
read. If the heading map comes back empty (a nonstandard ADR predating the
|
||||
template), fall back to one full `Read` — and if that read truncates at the
|
||||
cap, do **not** page through the remainder; grep for the story-relevant
|
||||
content directly and flag the ADR for `/architecture-decision [file]
|
||||
retrofit`.
|
||||
|
||||
**ADR existence validation** (tier-gated — resolved in Step 1): After reading the governing ADRs list from the epic, confirm each referenced ADR file exists on disk.
|
||||
|
||||
- **`full`** — if **any** referenced ADR file cannot be found, **stop immediately** before decomposing any story.
|
||||
- **`standard`** — stop only if a **critical (Foundation-layer) ADR** is missing; for a missing non-critical ADR, **warn and continue** (the story embeds the ADR reference and is set `Status: Blocked` until the ADR exists).
|
||||
- **`minimal`** — no ADR requirement; do **not** stop. Embed any ADR references that do exist; otherwise decompose against the brief + acceptance criteria and leave stories unblocked on ADR grounds.
|
||||
|
||||
When stopping (full / standard-critical):
|
||||
|
||||
> "Epic references [ADR-NNNN: title] but `docs/architecture/[adr-file].md` was not found.
|
||||
> Check the filename in the epic's Governing ADRs list, or run `/architecture-decision`
|
||||
> to create it. Cannot create stories until all referenced ADR files are present."
|
||||
|
||||
Do not proceed to Step 3 until all referenced ADR files are confirmed present.
|
||||
At `full`, do not proceed to Step 3 until all referenced ADR files are confirmed present.
|
||||
|
||||
Report: "Loaded epic [name], GDD [filename], [N] governing ADRs (all confirmed present), control manifest v[date]."
|
||||
Report: "Loaded epic [name], GDD [filename], [N] governing ADRs [ADR status], [manifest status]." State the **actual** situation for the resolved tier — e.g. "all confirmed present, control manifest v[date]" at full; "M present, K missing non-critical (embedded + Blocked)" at standard; "no ADRs / manifest required" at minimal. Do not assert "all confirmed present" if any referenced ADR was missing, or name a manifest version when none exists.
|
||||
|
||||
---
|
||||
|
||||
@@ -87,8 +189,11 @@ For each GDD acceptance criterion:
|
||||
2. Each group = one story
|
||||
3. Order stories: foundational behaviour first, edge cases last, UI last
|
||||
|
||||
**Story sizing rule:** one story = one focused session (~2-4 hours). If a
|
||||
group of criteria would take longer, split into two stories.
|
||||
**Story sizing rule:** size each story to the resolved `modes.story_granularity`
|
||||
target (above). The "~2-4 hours / one focused session" heuristic is the
|
||||
`balanced` default — at `coarse` a story spans a whole feature (5–10 ACs,
|
||||
multi-day), at `fine` a story is a single AC. Split or group criteria to hit the
|
||||
resolved target, not a fixed session length.
|
||||
|
||||
For each story, determine:
|
||||
- **GDD requirement**: which acceptance criterion(ia) does this satisfy?
|
||||
@@ -110,24 +215,17 @@ For each story, determine:
|
||||
- `lean` → skip (not a PHASE-GATE). Note: "QL-STORY-READY skipped — Lean mode." Proceed to Step 5 (present stories for review).
|
||||
- `full` → spawn as normal.
|
||||
|
||||
After decomposing all stories (Step 4 complete) but before presenting them for write approval, spawn `qa-lead` via Task using gate **QL-STORY-READY** (`.claude/docs/director-gates.md`).
|
||||
After decomposing all stories (Step 4 complete) but before presenting them for write approval, spawn `qa-lead` **once** via `Agent` using gate **QL-STORY-READY** (`.claude/docs/director-gates/ql-story-ready.md`). A single call returns **both** the readiness verdict and the test-case specs — do not spawn `qa-lead` a second time to generate specs.
|
||||
|
||||
Pass: the full story list with acceptance criteria, story types, and TR-IDs; the epic's GDD acceptance criteria for reference.
|
||||
Pass: the full story list with acceptance criteria, story types, and TR-IDs; the epic's GDD acceptance criteria for reference. Require in the return:
|
||||
1. The QL-STORY-READY verdict per story (ADEQUATE / GAPS / INADEQUATE).
|
||||
2. For every story it marks **ADEQUATE**, its test-case spec block (formats below) — one Given/When/Then per acceptance criterion for Logic and Integration stories, or manual verification steps for Visual/Feel and UI stories.
|
||||
|
||||
Present the QA lead's assessment. For each story flagged as GAPS or INADEQUATE, revise the acceptance criteria before proceeding — stories with untestable criteria cannot be implemented correctly. Once all stories reach ADEQUATE, proceed.
|
||||
Present the assessment. For each story flagged GAPS or INADEQUATE, revise the acceptance criteria before proceeding — untestable criteria cannot be implemented correctly; those stories carry no specs until they reach ADEQUATE (re-request specs for just those in a follow-up call only if a revision was needed). Once all stories are ADEQUATE, proceed with the returned specs.
|
||||
|
||||
**Before generating test specs**: Glob `production/qa/qa-plan-*.md` for the most recently modified file. If found, read it and check whether it contains test case specifications for the stories in this epic (look for story titles or slugs in the plan's Automated Tests Required section). If matching specs exist:
|
||||
- Use `AskUserQuestion`:
|
||||
- Prompt: "A QA plan exists at [path] with test specs for some of these stories. How do you want to proceed?"
|
||||
- Options:
|
||||
- `Use existing specs from the QA plan — embed them into the story files (Recommended)`
|
||||
- `Ask qa-lead to generate fresh specs — override the QA plan`
|
||||
- `Skip test spec generation — I'll fill in ## QA Test Cases manually`
|
||||
- If "Use existing specs": extract the test case specs from the qa-plan for each matching story and embed them directly into the `## QA Test Cases` section. No qa-lead spawn needed for those stories. Only spawn qa-lead for stories with no coverage in the qa-plan.
|
||||
- If "Generate fresh": proceed with the qa-lead spawn below as normal.
|
||||
- If "Skip": leave `## QA Test Cases` with a placeholder: `*Test cases not yet defined — run /qa-plan to generate them.*`
|
||||
**Prefer an existing QA plan when one already covers a story** — this substitutes for the qa-lead's specs, it does not add a spawn. Glob `production/qa/qa-plan-*.md` for the most recent file; if it holds test specs for stories in this epic (match titles/slugs in its Automated Tests Required section) that differ from the qa-lead's, use `AskUserQuestion` (Use QA-plan specs / Use qa-lead specs / Skip and leave `*Test cases not yet defined — run /qa-plan to generate them.*`). Either way no additional `qa-lead` spawn occurs.
|
||||
|
||||
**After ADEQUATE** (or after qa-plan import): for every Logic and Integration story, ask the qa-lead to produce concrete test case specifications — one per acceptance criterion — in this format:
|
||||
The spec block formats — Logic/Integration:
|
||||
|
||||
```
|
||||
Test: [criterion text]
|
||||
@@ -181,6 +279,34 @@ Use `AskUserQuestion`:
|
||||
|
||||
For each story, write `production/epics/[epic-slug]/story-[NNN]-[slug].md`:
|
||||
|
||||
> **At `minimal` tier the Context/traceability inputs do not exist** (no GDD, ADR,
|
||||
> TR registry, or control manifest). Fill the template from the brief instead —
|
||||
> apply this mapping exactly, so every run is deterministic rather than improvised:
|
||||
> - **GDD** → `design/game-brief.md`
|
||||
> - **Requirement** → `Brief MVP feature N` (the feature this story implements — NOT a `TR-[system]-NNN` ID)
|
||||
> - **ADR Governing Implementation / ADR Decision Summary / ADR Version** → `N/A (minimal — no ADRs)`
|
||||
> - **Manifest Version** and **Control Manifest Rules (this layer)** → `N/A (minimal — no control manifest)`
|
||||
> - **Engine** and **Risk** → read `docs/engine-reference/<engine>/VERSION.md`
|
||||
> (engine from `engine.name`). **Engine** is `engine.name` + `engine.version`.
|
||||
> **Risk** is the risk level that file assigns to the pinned version — its
|
||||
> post-cutoff timeline row, or its stated overall risk. If the file is missing
|
||||
> or assigns no level, write `NOT ASSESSED (no VERSION.md risk rating)` — never
|
||||
> guess a level.
|
||||
>
|
||||
> > **This field is load-bearing and had no rule, so it was improvised.**
|
||||
> > `/dev-story` Phase 3 spawns the engine specialist as a mandatory secondary
|
||||
> > "when engine risk is HIGH (from the ADR or VERSION.md)". At `minimal` there
|
||||
> > is no ADR, so `VERSION.md` is the *only* source — and nothing here told this
|
||||
> > skill to read it. A story written with an invented `Risk: MEDIUM` against a
|
||||
> > `VERSION.md` rating of HIGH silently disables the specialist review. In the
|
||||
> > run that found this, that review was what caught two wrong engine defaults.
|
||||
> > Treat `NOT ASSESSED` as HIGH for the spawn decision: an unknown risk is not
|
||||
> > a low one.
|
||||
> - **Engine Notes** → `none (no ADR engine-compatibility analysis at minimal)`
|
||||
> - The Acceptance-Criteria source line → "From `design/game-brief.md` (the **Player goal & fail state** field + the MVP feature this story implements), scoped to this story" — derive concrete, testable ACs from what the user wrote there rather than inventing them from a bare MVP bullet
|
||||
> - The **`## QA Test Cases`** section → at any tier where the QL-STORY-READY / qa-lead gate is skipped (`minimal`, or `lean`/`solo` review mode) no qa-lead specs are authored; write "*N/A — no qa-lead specs at this tier; implement against the Acceptance Criteria above*" rather than improvising test cases.
|
||||
> - Any **Test Evidence / DoD** line is governed by `qa.level`, not this template — at `qa.level: minimal` it is **waived** (advisory, never "must exist and pass").
|
||||
|
||||
```markdown
|
||||
# Story [NNN]: [title]
|
||||
|
||||
@@ -200,6 +326,7 @@ For each story, write `production/epics/[epic-slug]/story-[NNN]-[slug].md`:
|
||||
|
||||
**ADR Governing Implementation**: [ADR-NNNN: title]
|
||||
**ADR Decision Summary**: [1-2 sentence summary of what the ADR decided]
|
||||
**ADR Version**: [the ADR's `## Last Verified` date, else its `## Date`, else `unversioned`]
|
||||
|
||||
**Engine**: [name + version] | **Risk**: [LOW / MEDIUM / HIGH]
|
||||
**Engine Notes**: [from ADR Engine Compatibility section — post-cutoff APIs, verification required]
|
||||
@@ -240,7 +367,7 @@ change meaning. This is what the programmer reads instead of the ADR.]
|
||||
|
||||
## QA Test Cases
|
||||
|
||||
*Written by qa-lead at story creation. The developer implements against these — do not invent new test cases during implementation.*
|
||||
*Written by qa-lead at story creation. The developer implements against these — do not invent new test cases during implementation. (At tiers where the QL-STORY-READY gate is skipped — `minimal`, or `lean`/`solo` review mode — no qa-lead specs exist; see the `minimal` mapping note above.)*
|
||||
|
||||
**[For Logic / Integration stories — automated test specs]:**
|
||||
|
||||
@@ -261,9 +388,11 @@ change meaning. This is what the programmer reads instead of the ADR.]
|
||||
|
||||
## Test Evidence
|
||||
|
||||
*Governed by `qa.level`: at `qa.level: minimal` the evidence below is **waived** (advisory, never "must exist and pass").*
|
||||
|
||||
**Story Type**: [type]
|
||||
**Required evidence**:
|
||||
- Logic: `tests/unit/[system]/[story-slug]_test.[ext]` — must exist and pass
|
||||
- Logic: `tests/unit/[system]/[story-slug]_test.[ext]` — must exist and pass (`/story-done` checks that it EXISTS; pass/fail is established by `/gate-check` and `/smoke-check`, both later)
|
||||
- Integration: `tests/integration/[system]/[story-slug]_test.[ext]` OR playtest doc
|
||||
- Visual/Feel: `production/qa/evidence/[story-slug]-evidence.md` + sign-off
|
||||
- UI: `production/qa/evidence/[story-slug]-evidence.md` or interaction test
|
||||
@@ -294,7 +423,7 @@ Replace the "Stories: Not yet created" line with a populated table:
|
||||
|
||||
### Also update `production/epics/index.md`
|
||||
|
||||
Find the row in the index table matching this epic (by epic name or slug). Update its `Stories` column from `Not yet created` to `[N] stories` (where N is the count just written). If the index file does not exist, skip silently.
|
||||
Find the row in the index table matching this epic (by epic name or slug). Update its `Stories` column from `Not yet created` to `[N] stories` (where N is the count just written). If the index file does not exist, say so in one line — `Systems index not updated: design/gdd/systems-index.md absent` — and continue. Do not skip silently: the index is what a reader consults to learn which epics have stories, so an un-updated one keeps reporting `Not yet created` for work that now exists, and nothing else would ever reveal the gap.
|
||||
|
||||
---
|
||||
|
||||
@@ -320,6 +449,10 @@ Note in output: "Work through stories in order — each story's `Depends on:` fi
|
||||
|
||||
## Collaborative Protocol
|
||||
|
||||
**Applies in `collaborative` mode (the default).** For `guided` and
|
||||
`autonomous` modes, see `.claude/docs/automation-modes.md` — the rules below
|
||||
describe what collaborative mode requires, not universal behavior.
|
||||
|
||||
1. **Read before presenting** — load all inputs silently before showing the story list
|
||||
2. **Ask once** — present all stories for the epic in one summary, not one at a time
|
||||
3. **Warn on blocked stories** — flag any story with a Proposed ADR before writing
|
||||
|
||||
Reference in New Issue
Block a user