speckit-plan
Skill0 starsChanged 17 days agoMITView on GitHub
Execute the implementation planning workflow using the plan template to generate design artifacts.
We split this skill into the rules it gives an agent
19 rules. 6 are common, 0 are distinctive, and 13 are very specific to this project.
6
Common
Most of the 119 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 22
Check if .specify/extensions.yml exists in the project root.
- Very specific: line 23
If it exists, read it and look for entries under the hooks.before_plan key
- Common: line 24
If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
- Very specific: line 27
If the hook has no condition field, or it is null/empty, treat the hook as executable
- Very specific: line 28
If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation
- Very specific: line 29
When constructing slash commands from hook command names, replace dots (.) with hyphens (-).
- Very specific: line 53
If no hooks are registered or .specify/extensions.yml does not exist, skip silently
- Very specific: line 57
Setup: Run .specify/scripts/bash/setup-plan.sh --json from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH.
- Very specific: line 59
Load context: Read FEATURE_SPEC and .specify/memory/constitution.md.
- Very specific: line 61
Execute plan workflow: Follow the structure in IMPL_PLAN template to:
- Very specific: line 75
If it does not exist, or no hooks are registered under hooks.after_plan, skip to the Completion Report.
- Very specific: line 76
If it exists, read it and look for entries under the hooks.after_plan key.
- Common: line 77
If the YAML cannot be parsed or is invalid, skip hook checking silently and continue to the Completion Report.
- Common: line 145
Document the contract format appropriate for the project type
- Common: line 150
Document runnable validation scenarios that prove the feature works end-to-end
- Common: line 152
Use links or references to contracts and data model details instead of duplicating them
- Very specific: line 153
Do not include full implementation code, model/service/controller bodies, migrations, or complete test suites
- Very specific: line 154
Keep this artifact as a validation/run guide.
- Common: line 160
Use absolute paths for filesystem operations.
“Common” is measured: kept by at least 6 in 10 of the 119 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
User Input
$ARGUMENTSYou MUST consider the user input before proceeding (if not empty).
Pre-Execution Checks
Check for extension hooks (before planning):
- Check if
.specify/extensions.ymlexists in the project root. - If it exists, read it and look for entries under the
hooks.before_plankey - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
- Filter out hooks where
enabledis explicitlyfalse. Treat hooks without anenabledfield as enabled by default. - For each remaining hook, do not attempt to interpret or evaluate hook
conditionexpressions:- If the hook has no
conditionfield, or it is null/empty, treat the hook as executable - If the hook defines a non-empty
condition, skip the hook and leave condition evaluation to the HookExecutor implementation
- If the hook has no
- When constructing slash commands from hook command names, replace dots (
.) with hyphens (-). For example,speckit.git.commit→/speckit-git-commit. - For each executable hook, output the following based on its
optionalflag:- Optional hook (
optional: true):## Extension Hooks **Optional Pre-Hook**: {extension} Command: `/{command}` Description: {description} Prompt: {prompt} To execute: `/{command}` - Mandatory hook (
optional: false):
After emitting the block above you MUST actually invoke the hook and wait for it to finish before continuing. Run it the same way you would run the command yourself in this agent/session (the invocation may differ from the literal## Extension Hooks **Automatic Pre-Hook**: {extension} Executing: `/{command}` EXECUTE_COMMAND: {command} Wait for the result of the hook command before proceeding to the Outline.{command}id shown above, e.g. a skills-mode agent runs it as/skill:speckit-...or$speckit-...). Emitting the block alone does not run the hook.
- Optional hook (
- If no hooks are registered or
.specify/extensions.ymldoes not exist, skip silently
Outline
- Setup: Run
.specify/scripts/bash/setup-plan.sh --jsonfrom repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'''m Groot' (or double-quote if possible: "I'm Groot"). - Load context: Read FEATURE_SPEC and
.specify/memory/constitution.md. Load IMPL_PLAN template (already copied). - Execute plan workflow: Follow the structure in IMPL_PLAN template to:
- Fill Technical Context (mark unknowns as "NEEDS CLARIFICATION")
- Fill Constitution Check section from constitution
- Evaluate gates (ERROR if violations unjustified)
- Phase 0: Generate research.md (resolve all NEEDS CLARIFICATION)
- Phase 1: Generate data-model.md, contracts/, quickstart.md
- Phase 1: Update agent context by running the agent script
- Re-evaluate Constitution Check post-design
Mandatory Post-Execution Hooks
You MUST complete this section before reporting completion to the user.
Check if .specify/extensions.yml exists in the project root.
- If it does not exist, or no hooks are registered under
hooks.after_plan, skip to the Completion Report. - If it exists, read it and look for entries under the
hooks.after_plankey. - If the YAML cannot be parsed or is invalid, skip hook checking silently and continue to the Completion Report.
- Filter out hooks where
enabledis explicitlyfalse. Treat hooks without anenabledfield as enabled by default. - For each remaining hook, do not attempt to interpret or evaluate hook
conditionexpressions:- If the hook has no
conditionfield, or it is null/empty, treat the hook as executable - If the hook defines a non-empty
condition, skip the hook and leave condition evaluation to the HookExecutor implementation
- If the hook has no
- When constructing slash commands from hook command names, replace dots (
.) with hyphens (-). For example,speckit.git.commit→/speckit-git-commit. - For each executable hook, output the following based on its
optionalflag:- Mandatory hook (
optional: false) — You MUST emitEXECUTE_COMMAND:for each mandatory hook:
After emitting the block above you MUST actually invoke the hook and wait for it to finish before continuing. Run it the same way you would run the command yourself in this agent/session (the invocation may differ from the literal## Extension Hooks **Automatic Hook**: {extension} Executing: `/{command}` EXECUTE_COMMAND: {command}{command}id shown above, e.g. a skills-mode agent runs it as/skill:speckit-...or$speckit-...). Emitting the block alone does not run the hook. - Optional hook (
optional: true):## Extension Hooks **Optional Hook**: {extension} Command: `/{command}` Description: {description} Prompt: {prompt} To execute: `/{command}`
- Mandatory hook (
Completion Report
Command ends after Phase 2 planning. Report branch, IMPL_PLAN path, and generated artifacts.
Phases
Phase 0: Outline & Research
- Extract unknowns from Technical Context above:
- For each NEEDS CLARIFICATION → research task
- For each dependency → best practices task
- For each integration → patterns task
Generate and dispatch research agents:
For each unknown in Technical Context: Task: "Research {unknown} for {feature context}" For each technology choice: Task: "Find best practices for {tech} in {domain}"- Consolidate findings in
research.mdusing format:- Decision: [what was chosen]
- Rationale: [why chosen]
- Alternatives considered: [what else evaluated]
Output: research.md with all NEEDS CLARIFICATION resolved
Phase 1: Design & Contracts
Prerequisites: research.md complete
- Extract entities from feature spec →
data-model.md:- Entity name, fields, relationships
- Validation rules from requirements
- State transitions if applicable
- Define interface contracts (if project has external interfaces) →
/contracts/:- Identify what interfaces the project exposes to users or other systems
- Document the contract format appropriate for the project type
- Examples: public APIs for libraries, command schemas for CLI tools, endpoints for web services, grammars for parsers, UI contracts for applications
- Skip if project is purely internal (build scripts, one-off tools, etc.)
- Create quickstart validation guide →
quickstart.md:- Document runnable validation scenarios that prove the feature works end-to-end
- Include prerequisites, setup commands, test/run commands, and expected outcomes
- Use links or references to contracts and data model details instead of duplicating them
- Do not include full implementation code, model/service/controller bodies, migrations, or complete test suites
- Keep this artifact as a validation/run guide; implementation details belong in
tasks.mdand the implementation phase
Output: data-model.md, /contracts/*, quickstart.md
Key rules
- Use absolute paths for filesystem operations; use project-relative paths for references in documentation
- ERROR on gate failures or unresolved clarifications
Done When
- Plan workflow executed and design artifacts generated
- Extension hooks dispatched or skipped according to the rules in Mandatory Post-Execution Hooks above
- Completion reported to user with branch, plan path, and generated artifacts
Trending
Cooling: 8 new projects took it in the last 4 weeks, 0.5× the 4 weeks before.
Other versions124 projects use a version of this.
Word for word · 1
- rshade/finfocus★ 11100% same
Edited · 120
- pmndrs/react-spring★ 29k85% same
- unoplatform/uno★ 10k84% same
- elsa-workflows/elsa-core★ 7.9k93% same
- hhyo/Archery★ 7.1k98% same
- pamburus/hl★ 3.3k91% same
- nornir-automation/nornir★ 1.6k96% same
- cloudposse/atmos★ 1.4k85% same
- Azure/agent-landing-zone★ 1.2k97% same
- Azure/GPT-RAG★ 1.2k97% same
- dotCMS/core★ 97191% same
110 more not listed
Wrote their own version · 3
- sunhaoyu-1990/Claude-Code-Cock★ 8same name
- sarveshtalele/mcp-skills-registry★ 2same name
- TienDat-Vna/BackSpec★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use speckit-agent-context-update, speckit-git-commit and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Sorcha-PlatformSkillspeckit-agent-context-update
Refresh the managed Spec Kit section in the coding agent context file
Also in 12 projects that use this
Sorcha-PlatformSkillspeckit-git-commit
Auto-commit changes after a Spec Kit command completes
Also in 34 projects that use this
patterson-agentsSkillspeckit-baseline
Generate feature specifications by analyzing existing source code.
Also in 3 projects that use this
patterson-agentsSkillclaude-command-converter
Convert Claude Code commands (.claude/commands/*.md) to standard Agent Skills (skills/*/SKILL.md). Use when migrating slash commands to portable skill format, creating skills from existing commands, or standardizing command definitions across AI runtimes.
Also in 3 projects that use this
SentrySkillcommit
Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.
Also in 4 projects that use this
GoogleSkillcode-review
Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.
Also in 4 projects that use this
- +4 more from Sorcha-Platform
In this repository15 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/00-global.mdcCursor rule
- .cursor/rules/01-git-commits.mdcCursor rule
- .cursor/rules/10-php-symfony-bundle.mdcCursor rule
- .cursor/rules/40-tests-quality.mdcCursor rule
- .cursor/rules/50-docs-and-release.mdcCursor rule
- speckit-analyzeSkill
- speckit-checklistSkill
- speckit-clarifySkill
- speckit-constitutionSkill
- speckit-convergeSkill
- speckit-implementSkill
- speckit-specifySkill
- speckit-tasksSkill
- speckit-taskstoissuesSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

