From foundry
Spec-first development methodology that creates detailed specifications before coding. Creates structured specs with phases, file-level details, and verification steps. Includes automatic AI review, modification application, and validation. TRIGGER when: user explicitly asks to create a spec or plan, OR model detects work that would benefit from a spec (new feature, multi-file refactor, API integration, architecture change) — in the latter case, confirm with the user before invoking. Never call mcp authoring/spec/plan tools directly for spec creation workflows. DO NOT TRIGGER when: a <command-name> tag is present in the current turn (skill already loaded), called from a subagent, single-file edits, trivial fixes, or exploratory spikes.
How this skill is triggered — by the user, by Claude, or both
Slash command
/foundry:foundry-specThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
`Skill(foundry:foundry-spec)` creates detailed JSON specifications before any code is written. It analyzes the codebase, designs a phased implementation approach, produces structured task hierarchies, and runs automatic quality checks including AI review.
references/ai-review.mdreferences/codebase-analysis.mdreferences/investigation.mdreferences/json-spec.mdreferences/metadata-management.mdreferences/modification-operations.mdreferences/modification-workflow.mdreferences/phase-authoring.mdreferences/phase-plan-template.mdreferences/plan-review-consensus.mdreferences/plan-review-dimensions.mdreferences/plan-review-workflow.mdreferences/task-hierarchy.mdreferences/troubleshooting.mdreferences/validation-fixes.mdreferences/validation-issues.mdreferences/validation-workflow.mdSkill(foundry:foundry-spec) creates detailed JSON specifications before any code is written. It analyzes the codebase, designs a phased implementation approach, produces structured task hierarchies, and runs automatic quality checks including AI review.
Core capabilities:
This skill follows a plan-first methodology. A markdown plan is MANDATORY before JSON spec creation, with human approval required after AI review.
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ 1. Analyze 2. Create Plan 3. Plan Review 4. APPROVAL 5. Create Spec 6. Spec Review 7. Validate │
│ ────────── ───────────── ──────────── ─────────── ───────────── ──────────── ────────── │
│ Explore/LSP → plan-create → plan-review → HUMAN GATE → spec-create → spec-review → validate-fix │
│ (understand) (MANDATORY) (AI feedback) (approve) (from plan) (MANDATORY) (auto-fix) │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
[x?]=decision ·(GATE)=user approval ·→=sequence ·↻=loop
- **Entry** → UnderstandIntent → Analyze[Explore|LSP]
- **Plan** (MANDATORY)
- `plan action="create"` → create markdown plan
- Fill in plan content with analysis results
- **Plan Review** → `plan action="review"`
- [critical/high?] → Revise plan, re-review
- ↻ Self-iterate until no critical/high issues remain
- Present final plan + review summary to user
- **(GATE: approve plan)**
- Present plan summary + AI review findings to user
- User must explicitly approve via AskUserQuestion
- [approved] → continue to spec creation
- [revise] → ↻ back to plan editing
- [abort] → **Exit** (no spec created)
- **Spec Creation** → `authoring action="spec-create"`
- `authoring action="phase-add-bulk"` ↻ per phase
- `authoring action="spec-update-frontmatter"` → mission/metadata
- **Spec Review** (MANDATORY) → `review action="spec"`
- [critical/high?] → `review action="parse-feedback"` → fix spec → re-review
- ↻ Self-iterate until no critical/high issues remain
- Present final spec + review summary to user
- (GATE: approve remaining modifications) → `spec action="apply-plan"`
- **Validate** → `spec action="validate"` ↻ [errors?] → `spec action="fix"`
- **Exit** → specs/pending/{spec-id}.json
Use for:
Do NOT use for:
foundry-implement)| Router | Key Actions |
|---|---|
authoring | spec-create, spec-update-frontmatter, phase-add-bulk, phase-move, phase-update-metadata, assumption-add, assumption-list, constraint-add, constraint-list, risk-add, risk-list, question-add, question-list, success-criterion-add, success-criteria-list |
spec | validate, fix, apply-plan, completeness-check, duplicate-detection, stats, analyze-deps |
review | spec, parse-feedback, list-tools |
task | add, remove, move, update-metadata |
Critical Rule: NEVER read spec JSON files directly with Read() or shell commands.
Before creating any plan:
metadata.missionUse Explore subagents for large codebases (prevents context bloat), or Glob/Grep/Read for targeted lookups.
LSP-Enhanced Analysis for refactoring:
documentSymbol - Understand file structurefindReferences - Assess impact (count affected files)goToDefinition - Navigate to implementationsSee
references/codebase-analysis.mdfor detailed patterns.
This step is REQUIRED. All specifications must begin as markdown plans before JSON conversion.
mcp__plugin_foundry_foundry-mcp__plan action="create" name="Feature Name"
The command creates a template at specs/.plans/feature-name-YYYY-MM-DD.md (date is auto-appended). Fill in all sections:
metadata.mission)After completing the plan:
See
references/phase-authoring.mdfor templates and bulk macros. Seereferences/phase-plan-template.mdfor the plan structure.
After completing the markdown plan, run AI review to catch issues before JSON conversion:
mcp__plugin_foundry_foundry-mcp__plan action="review" plan_path="specs/.plans/feature-name-YYYY-MM-DD.md"
Review output: Saved to specs/.plan-reviews/<plan-name-YYYY-MM-DD>-review.md
Important: Use the actual
plan_pathreturned by the create step — do not hardcode the path.
All 6 dimensions are always assessed: Completeness, Architecture, Sequencing, Feasibility, Risk, Clarity.
Self-iterate before presenting to user: Address all critical and high issues yourself:
See
references/ai-review.mdfor review output format and iteration workflow.
Before creating the JSON spec, obtain explicit user approval.
Present to user:
Use AskUserQuestion with options:
CRITICAL: Do NOT proceed to JSON spec creation without explicit "Approve" response.
mcp__plugin_foundry_foundry-mcp__authoring action="spec-create" name="feature-name" template="empty" plan_path="specs/.plans/feature-name-YYYY-MM-DD.md" plan_review_path="specs/.plan-reviews/feature-name-YYYY-MM-DD-review.md"
Important: Use the actual paths returned by the create and review steps. The date suffix is auto-generated.
Add phases with tasks:
mcp__plugin_foundry_foundry-mcp__authoring action="phase-add-bulk" spec_id="{spec-id}" phase='{"title": "Implementation", "description": "Core work"}' tasks='[{"type": "task", "title": "Build core logic", "task_category": "implementation", "file_path": "src/core.py", "acceptance_criteria": ["Workflow works"]}]'
Update metadata:
mcp__plugin_foundry_foundry-mcp__authoring action="spec-update-frontmatter" spec_id="{spec-id}" key="mission" value="Single-sentence objective"
After creating the spec, populate structured metadata extracted from the approved plan:
# Add constraints from plan
mcp__plugin_foundry_foundry-mcp__authoring action="constraint-add" spec_id="{spec-id}" text="Must maintain backward compatibility with v2 API"
# Add risks from plan
mcp__plugin_foundry_foundry-mcp__authoring action="risk-add" spec_id="{spec-id}" description="OAuth provider rate limits" likelihood="medium" impact="high" mitigation="Implement token caching"
# Add open questions from plan
mcp__plugin_foundry_foundry-mcp__authoring action="question-add" spec_id="{spec-id}" text="Which OAuth scopes are required for the admin flow?"
# Add success criteria from plan
mcp__plugin_foundry_foundry-mcp__authoring action="success-criterion-add" spec_id="{spec-id}" text="All protected endpoints return 401 without valid token"
# Add assumptions
mcp__plugin_foundry_foundry-mcp__authoring action="assumption-add" spec_id="{spec-id}" text="Single GCP project for staging and production"
See
references/metadata-management.mdfor full action reference and workflow. Seereferences/json-spec.mdandreferences/task-hierarchy.mdfor structure details.
After spec creation, the spec review compares the JSON spec against its source plan:
mcp__plugin_foundry_foundry-mcp__review action="spec" spec_id="{spec-id}"
Action name: Use
action="spec"(canonical). The alias"spec-review"also works but"spec"is preferred.
The spec review compares the JSON spec against its source plan to catch translation gaps — evaluating coverage, fidelity, success criteria mapping, and preservation of constraints, risks, and open questions. The response includes a verdict of aligned, deviation, or incomplete.
Prerequisites for spec review to succeed:
spec-create + phase-add-bulk)metadata.plan_path must point to an existing plan file (set during spec-create)foundry-mcp.toml or environment)If the review returns success: false:
error_code in the response — common causes:
SPEC_NOT_FOUND: Verify spec_id is correct via spec action="list"AI_NO_PROVIDER: Check AI provider configurationAI_PROVIDER_TIMEOUT: Retry with a higher ai_timeout value"spec" and "spec-review" are identicalSelf-iterate before presenting to user: Address all critical and high issues yourself:
review action="parse-feedback"See
references/plan-review-workflow.mdfor detailed review workflow. Seereferences/plan-review-dimensions.mdfor review dimensions. Seereferences/plan-review-consensus.mdfor interpreting results.
If review finds issues, parse and apply feedback:
# Parse review feedback into modifications
mcp__plugin_foundry_foundry-mcp__review action="parse-feedback" spec_id="{spec-id}" review_path="path/to/review.md"
# Preview changes (always preview first!)
mcp__plugin_foundry_foundry-mcp__spec action="apply-plan" spec_id="{spec-id}" modifications_file="suggestions.json" dry_run=true
# Apply changes (backup created automatically)
mcp__plugin_foundry_foundry-mcp__spec action="apply-plan" spec_id="{spec-id}" modifications_file="suggestions.json"
See
references/modification-workflow.mdfor detailed workflow. Seereferences/modification-operations.mdfor operation formats.
Validate and auto-fix the specification:
# Validate
mcp__plugin_foundry_foundry-mcp__spec action="validate" spec_id="{spec-id}"
# Auto-fix common issues
mcp__plugin_foundry_foundry-mcp__spec action="fix" spec_id="{spec-id}"
# Re-validate until clean
mcp__plugin_foundry_foundry-mcp__spec action="validate" spec_id="{spec-id}"
Exit codes:
See
references/validation-workflow.mdfor detailed workflow. Seereferences/validation-fixes.mdfor fix patterns. Seereferences/validation-issues.mdfor issue types.
Use this approach for efficient spec creation:
Step 1: Create spec from approved plan
mcp__plugin_foundry_foundry-mcp__authoring action="spec-create" name="my-feature" template="empty" plan_path="specs/.plans/my-feature-YYYY-MM-DD.md" plan_review_path="specs/.plan-reviews/my-feature-YYYY-MM-DD-review.md"
Both
plan_pathandplan_review_pathare required. Create these first viaplan action="create"andplan action="review". Use the actual paths returned by those steps.
Step 2: Add phases with bulk macro
mcp__plugin_foundry_foundry-mcp__authoring action="phase-add-bulk" spec_id="{spec-id}" phase='{"title": "Phase 1"}' tasks='[...]'
Step 3: Fine-tune tasks Use modification operations to adjust individual tasks.
Step 4: Update frontmatter
mcp__plugin_foundry_foundry-mcp__authoring action="spec-update-frontmatter" spec_id="{spec-id}" key="mission" value="..."
For implementation or refactoring tasks, set metadata.file_path to a real repo-relative path. Do not guess or use placeholders. If unclear, use task_category: "investigation" first.
| Template | Use Case | Required Fields |
|---|---|---|
empty | All specs (blank with no phases) | Add phases via phase-add-bulk |
| Category | Requires file_path |
|---|---|
investigation | No |
implementation | Yes |
refactoring | Yes |
decision | No |
research | No |
| Node Type | type Value | Key Fields |
|---|---|---|
| Task | "task" | task_category, file_path |
| Research | "research" | research_type, blocking_mode, query |
| Verification | "verify" | verification_type |
See
references/task-hierarchy.mdfor research node patterns and blocking modes.
| Type | Purpose |
|---|---|
run-tests | Execute test suite |
fidelity | Compare implementation to spec |
manual | Manual testing checklist |
Best Practice: Every phase should end with a fidelity review task (
verification_type: "fidelity"). This ensures implementation matches the spec before moving to the next phase. Thefoundry-reviewskill performs this comparison.
| Status | Description |
|---|---|
pending | Not yet started |
in_progress | Currently being worked on |
completed | Finished successfully |
blocked | Cannot proceed |
If >6 phases or >50 tasks, recommend splitting into multiple specs.
specs/pending/{spec-id}.jsonspecs/.plan-reviews/{plan-name-YYYY-MM-DD}-review.mdspecs/.spec-reviews/{spec-id}-spec-review.mdPlanning:
references/investigation.mdreferences/phase-authoring.mdreferences/phase-plan-template.mdreferences/json-spec.mdreferences/task-hierarchy.mdreferences/metadata-management.mdreferences/codebase-analysis.mdReview:
references/plan-review-workflow.mdreferences/plan-review-dimensions.mdreferences/plan-review-consensus.mdModification:
references/modification-workflow.mdreferences/modification-operations.mdValidation:
references/validation-workflow.mdreferences/validation-fixes.mdreferences/validation-issues.mdGeneral:
references/ai-review.mdreferences/troubleshooting.mdnpx claudepluginhub foundry-works/claude-foundry --plugin foundryTransforms ideas into structured specifications (requirements, design, tasks) before implementation. Use when building features, fixing bugs, refactoring, or designing systems.
Writes a structured specification before coding, with a gated workflow of specify, plan, tasks, and implement phases. Use when requirements are ambiguous or the change is non-trivial.
Guides GitHub Spec-Kit CLI integration for 7-phase constitution-based spec-driven feature development, managing .specify/specs/ directories with phases: Constitution, Specify, Clarify, Plan, Tasks, Analyze, Implement.