How do I install the Gsp Spec Driven Planning skill?

Run npx skillmds@latest add mike007jd/gsp-spec-driven-planning-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Gsp Spec Driven Planning safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Gsp Spec Driven Planning?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Gsp Spec Driven Planning free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Gsp Spec Driven Planning?

mike007jd (@mike007jd) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Gsp Spec Driven Planning by mike007jd

Name: Gsp Spec Driven Planning
Author: mike007jd

File contents

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.

---name: gsp-spec-driven-planning-2description: 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.---# Game Spec-Driven Planning## GoalAdd a lightweight spec-driven planning layer to a game project without replacing the normal Game Superpowers tracks.## Artifact modelKeep 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`## OutputsFollow 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`## Workflow1. Decide whether the request should stay inline or become durable repo artifacts.2. Derive a stable `change-id` and 1-3 capability names.3. Use `gsp-requirements-brainstorm` to lock the requirement set when intent is still fuzzy.4. Write `proposal.md` for the user-facing goal, scope, affected capabilities, and acceptance signals.5. Write or update the capability delta under `changes/<change-id>/specs/<capability>/spec.md`.6. Use the design skills needed for the change, then consolidate the result into `design.md`.7. Use `gsp-implementation-plan` to produce `tasks.md`.## RoutingTypical 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.

Frequently asked questions

Gsp Spec Driven Planning