添加 claude code game studios 到项目
This commit is contained in:
panw
205
CCGS Skill Testing Framework/skills/pipeline/dev-story.md
Normal file
205
CCGS Skill Testing Framework/skills/pipeline/dev-story.md
Normal file
@@ -0,0 +1,205 @@
|
||||
# Skill Test Spec: /dev-story
|
||||
|
||||
## Skill Summary
|
||||
|
||||
`/dev-story` reads a story file, loads all required context (referenced ADR,
|
||||
TR-ID from the registry, control manifest, engine preferences), implements the
|
||||
story, verifies that all acceptance criteria are met, and marks the story
|
||||
Complete. The skill routes implementation to the correct specialist agent based
|
||||
on the engine and file type — it does not write source code directly.
|
||||
|
||||
In `full` review mode, an LP-CODE-REVIEW gate runs before marking the story
|
||||
Complete. In `lean` or `solo` mode, LP-CODE-REVIEW is skipped and the story is
|
||||
marked Complete after the user confirms all criteria are met. The skill asks
|
||||
"May I write" before updating story status and before writing code files.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
Verified automatically by `/skill-test static` — no fixture needed.
|
||||
|
||||
- [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
|
||||
- [ ] Has ≥2 phase headings
|
||||
- [ ] Contains verdict keywords: COMPLETE, BLOCKED, IN PROGRESS, NEEDS CHANGES
|
||||
- [ ] Contains "May I write" collaborative protocol language (story status + code files)
|
||||
- [ ] Has a next-step handoff at the end (`/story-done`)
|
||||
- [ ] Documents LP-CODE-REVIEW gate: active in full mode, skipped in lean/solo
|
||||
- [ ] Notes that implementation is delegated to specialist agents (not done directly)
|
||||
|
||||
---
|
||||
|
||||
## Director Gate Checks
|
||||
|
||||
In `full` mode: LP-CODE-REVIEW gate runs after implementation is complete and all
|
||||
criteria are verified, before marking the story Complete.
|
||||
|
||||
In `lean` mode: LP-CODE-REVIEW is skipped. Output notes:
|
||||
"LP-CODE-REVIEW skipped — lean mode". Story is marked Complete after user confirms.
|
||||
|
||||
In `solo` mode: LP-CODE-REVIEW is skipped with equivalent notes.
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — Story implemented and marked Complete (full mode)
|
||||
|
||||
**Fixture:**
|
||||
- A story file exists at `production/epics/[layer]/story-[name].md` with:
|
||||
- `Status: Ready`
|
||||
- A TR-ID referencing a registered requirement
|
||||
- At least 2 Given-When-Then acceptance criteria
|
||||
- A test evidence path
|
||||
- Referenced ADR has `Status: Accepted`
|
||||
- `docs/architecture/control-manifest.md` exists
|
||||
- `.claude/docs/technical-preferences.md` has engine and language configured
|
||||
- `production/session-state/review-mode.txt` contains `full`
|
||||
|
||||
**Input:** `/dev-story production/epics/[layer]/story-[name].md`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill reads the story file and all referenced context
|
||||
2. Skill verifies the ADR is Accepted (no block)
|
||||
3. Skill routes implementation to the correct specialist agent
|
||||
4. All acceptance criteria are verified as met
|
||||
5. LP-CODE-REVIEW gate spawns and returns APPROVED
|
||||
6. Skill asks "May I update story status to Complete?"
|
||||
7. Story status is updated to Complete
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Skill reads story before spawning any agent
|
||||
- [ ] ADR status is checked before implementation begins
|
||||
- [ ] Implementation is delegated to a specialist agent (not done inline)
|
||||
- [ ] All acceptance criteria are confirmed before LP-CODE-REVIEW
|
||||
- [ ] LP-CODE-REVIEW appears in output as a completed gate
|
||||
- [ ] Story status is updated to Complete only after gate approval and user consent
|
||||
- [ ] Test file is written as part of implementation (not deferred)
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Failure Path — Referenced ADR is Proposed
|
||||
|
||||
**Fixture:**
|
||||
- A story file exists with `Status: Ready`
|
||||
- The story's TR-ID points to a requirement covered by an ADR with `Status: Proposed`
|
||||
|
||||
**Input:** `/dev-story production/epics/[layer]/story-[name].md`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill reads the story file
|
||||
2. Skill resolves the TR-ID and reads the governing ADR
|
||||
3. ADR status is Proposed — skill outputs a BLOCKED message
|
||||
4. Skill names the specific ADR blocking the story
|
||||
5. Skill recommends running `/architecture-decision` to advance the ADR
|
||||
6. Implementation does NOT begin
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Skill does NOT begin implementation with a Proposed ADR
|
||||
- [ ] BLOCKED message names the specific ADR number and title
|
||||
- [ ] Skill recommends `/architecture-decision` as the next action
|
||||
- [ ] Story status remains unchanged (not set to In Progress or Complete)
|
||||
|
||||
---
|
||||
|
||||
### Case 3: Ambiguous Acceptance Criteria — Skill asks for clarification
|
||||
|
||||
**Fixture:**
|
||||
- A story file exists with `Status: Ready`
|
||||
- Referenced ADR is Accepted
|
||||
- One acceptance criterion is ambiguous (not Given-When-Then; uses subjective language like "feels responsive")
|
||||
|
||||
**Input:** `/dev-story production/epics/[layer]/story-[name].md`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill reads the story and identifies the ambiguous criterion
|
||||
2. Before routing to the specialist, skill asks the user to clarify the criterion
|
||||
3. User provides a concrete, testable restatement
|
||||
4. Skill proceeds with implementation using the clarified criterion
|
||||
5. Skill does NOT guess at the intended behavior
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Skill surfaces the ambiguous criterion before implementation starts
|
||||
- [ ] Skill asks for user clarification (not auto-interpretation)
|
||||
- [ ] Implementation begins only after clarification is provided
|
||||
- [ ] Clarified criterion is used in the test (not the original vague version)
|
||||
|
||||
---
|
||||
|
||||
### Case 4: Edge Case — No argument; reads from session state
|
||||
|
||||
**Fixture:**
|
||||
- No argument is provided
|
||||
- `production/session-state/active.md` references an active story file
|
||||
- That story file exists with `Status: In Progress`
|
||||
|
||||
**Input:** `/dev-story` (no argument)
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill detects no argument is provided
|
||||
2. Skill reads `production/session-state/active.md`
|
||||
3. Skill finds the active story reference
|
||||
4. Skill confirms with user: "Continuing work on [story title] — is that correct?"
|
||||
5. After confirmation, skill proceeds with that story
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Skill reads session state when no argument is provided
|
||||
- [ ] Skill confirms the active story with the user before proceeding
|
||||
- [ ] Skill does NOT silently assume the active story without confirmation
|
||||
- [ ] If session state has no active story, skill asks which story to implement
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Director Gate — LP-CODE-REVIEW returns NEEDS CHANGES; lean mode skips gate
|
||||
|
||||
**Fixture (full mode):**
|
||||
- Story is implemented and all criteria appear met
|
||||
- `production/session-state/review-mode.txt` contains `full`
|
||||
- LP-CODE-REVIEW gate returns NEEDS CHANGES with specific feedback
|
||||
|
||||
**Full mode expected behavior:**
|
||||
1. LP-CODE-REVIEW gate spawns after implementation
|
||||
2. Gate returns NEEDS CHANGES with 2 specific issues
|
||||
3. Story status remains In Progress — NOT marked Complete
|
||||
4. User is shown the gate feedback and asked how to proceed
|
||||
|
||||
**Assertions (full mode):**
|
||||
- [ ] Story is NOT marked Complete when LP-CODE-REVIEW returns NEEDS CHANGES
|
||||
- [ ] Gate feedback is shown to the user verbatim
|
||||
- [ ] Story status stays In Progress until issues are resolved and gate passes
|
||||
|
||||
**Fixture (lean mode):**
|
||||
- Same story, `production/session-state/review-mode.txt` contains `lean`
|
||||
|
||||
**Lean mode expected behavior:**
|
||||
1. Implementation completes
|
||||
2. LP-CODE-REVIEW gate is skipped — noted in output
|
||||
3. User is asked to confirm all criteria are met
|
||||
4. Story is marked Complete after user confirmation
|
||||
|
||||
**Assertions (lean mode):**
|
||||
- [ ] "LP-CODE-REVIEW skipped — lean mode" appears in output
|
||||
- [ ] Story is marked Complete after user confirms criteria (no gate required)
|
||||
- [ ] Skill does NOT block on a gate that is skipped
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Does NOT write source code directly — delegates to specialist agents
|
||||
- [ ] Reads all context (story, TR-ID, ADR, manifest, engine prefs) before implementation
|
||||
- [ ] "May I write" asked before updating story status and before writing code files
|
||||
- [ ] Skipped gates noted by name and mode in output
|
||||
- [ ] Updates `production/session-state/active.md` after story completion
|
||||
- [ ] Ends with next-step handoff: `/story-done`
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
|
||||
- Engine routing logic (Godot vs Unity vs Unreal) is not tested per engine —
|
||||
the routing pattern is consistent; engine selection is a config fact.
|
||||
- Visual/Feel and UI story types (no automated test required) have different
|
||||
evidence requirements and are not covered in these cases.
|
||||
- Integration story type follows the same pattern as Logic but with a different
|
||||
evidence path — not independently fixture-tested.
|
||||
Reference in New Issue
Block a user