pixelheros/CCGS Skill Testing Framework/skills/pipeline/dev-story.md

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.