ryan/stickman
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: Update developer instructions and spec pipeline descriptions for clarity and improved validation processes

Browse Source
This commit is contained in:
ryan
2026-10-13 21:44:40 -04:00
parent d8b1b1164b
commit 628c07e70e
2 changed files with 12 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.codex/skills/spec-pipeline/SKILL.md
+8 -5
View File
@@ -1,6 +1,6 @@
---
name: spec-pipeline
description: "Lean implementation loop: UI/UX (Ideas -> Spec) -> Architect (Clarify -> Spec) -> Developer -> User Verification."
description: "Stickman Studio feature workflow: UI/UX and architecture specs, implementation, agent-run behavior verification, then user verification."
---
## Execution Logic
@@ -27,15 +27,18 @@ description: "Lean implementation loop: UI/UX (Ideas -> Spec) -> Architect (Clar
4. **Phase 1b: User Feedback & Spec Generation**
- User approves, modifies, or selects choices from `@architect`'s proposal.
- `@architect` writes the finalized specification to `docs/specs/[feature-name].md` and logs decisions in `docs/architecture/tech_debt_and_optimizations.md`.
- The spec states observable acceptance outcomes and the user path that produces each one. For interactions involving physics, timing, saving/loading, or multiple systems, name a small repeatable runtime scenario and what to measure; do not prescribe a test implementation unless it is needed to protect a specific behavior.
- **STOP:** Wait for final user sign-off on the spec before invoking developer.
5. **Phase 2: Implementation & Engine Validation**
5. **Phase 2: Implementation & Agent Verification**
- `@developer` updates code and scenes using targeted diffs based on `docs/specs/[feature-name].md`.
- `@developer` runs headless syntax verification.
- If static check fails, `@developer` fixes the code immediately.
- `@developer` runs Godot syntax/import checks and focused existing regression suites, then fixes failures.
- `@developer` adds focused automated coverage where it can meaningfully verify the feature's observable acceptance outcomes. For cross-system or runtime behavior, construct a small repeatable scene or fixture (in memory or as a saved scene), use the real production spawning/input/action paths where practical, advance frames or physics ticks, and assert the resulting state. A check that nodes, signals, layers, or helper calls exist is insufficient when the requirement concerns what actually happens during play.
- When the outcome is visual or interactive, run the affected scene and inspect rendered output or a capture where the environment permits. Record what was observed; a headless launch or successful screenshot command alone does not prove visual correctness. If rendering or GUI access is unavailable, report that limit explicitly and leave a focused visual check for the user.
- `@developer` reruns the relevant checks after fixes and reports commands, pass/fail results, the measured behavior, and any unverified acceptance outcome. Do not claim a feature is verified from syntax checks or debug prints alone.
6. **Phase 3: User Hand-off (Stop)**
- Present the changes to the user to test inside the Godot Editor.
- Present the implementation and agent verification evidence. Give the user only the remaining visual, usability, or environment-dependent checks to perform in the Godot Editor; clearly identify any acceptance outcome the agent could not verify.
7. **Phase 4: Documentation (Triggered manually by user)**
- Only call `@writer` after the user confirms: "Feature verified and working."