Gsp spec driven planning

Skill mike007jd/game-superpowers/skills/gsp-spec-driven-planning

Use when the user wants a persistent requirements/spec/design/tasks workflow, asks for OpenSpec-style planning, or needs durable change artifacts in the target repo.From its SKILL.md

Install

npx -y skills add mike007jd/game-superpowers --skill gsp-spec-driven-planning

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.7 KB, 579 tokens by cl100k_base, as published. Nobody here has run it

Game Spec-Driven Planning

Goal

Add a lightweight spec-driven planning layer to a game project without replacing the normal Game Superpowers tracks.

Artifact model

Keep stable capability specs separate from one change's working set.

Living specs:
- specs/<capability>/spec.md
Change package:
- changes/<change-id>/proposal.md
- changes/<change-id>/design.md
- changes/<change-id>/tasks.md
- changes/<change-id>/specs/<capability>/spec.md

Outputs

Follow the gsp-orchestrator output strategy:

inline (default): keep the proposal, design, and task structure in conversation only.
minimal: write the change package under changes/<change-id>/.
full: write the change package and create or update the matching living specs under specs/<capability>/.

Use:

../../shared/reference/spec-driven-workflow.md
../../shared/templates/change-proposal.md
../../shared/templates/capability-spec.md
../../shared/templates/change-design.md
../../shared/templates/change-tasks.md

Workflow

Decide whether the request should stay inline or become durable repo artifacts.
Derive a stable change-id and 1-3 capability names.
Use gsp-requirements-brainstorm to lock the requirement set when intent is still fuzzy.
Write proposal.md for the user-facing goal, scope, affected capabilities, and acceptance signals.
Write or update the capability delta under changes/<change-id>/specs/<capability>/spec.md.
Use the design skills needed for the change, then consolidate the result into design.md.
Use gsp-implementation-plan to produce tasks.md.

Routing

Typical downstream skills:

gsp-requirements-brainstorm
gsp-mechanics-systems-design
gsp-ux-flow-designer
gsp-feedback-design
gsp-implementation-plan

Add gsp-scope-profile, gsp-build-strategy, or gsp-production-code when the change needs stronger scope or quality controls.

Important rules

Keep specs/ durable and capability-oriented. Do not dump one-off implementation notes into them.
Keep one changes/<change-id>/ folder per meaningful user-facing change.
Put design decisions in design.md, not in tasks.md.
Keep traceability explicit. A proposal should name the capabilities it changes, the design should name the requirements it covers, and tasks should point back to the requirement or design area they implement.
If the user did not ask for persistent artifacts, do not force file creation.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.