Plan

Skill pooyagolchian/specforge/plugins/specforge/skills/plan

Spec-driven AI development lifecycle for Claude Code — spec-kit + AI-DLC fused, with hook-enforced human-approval gates. Installable plugin + marketplace.

Install

npx -y skills add pooyagolchian/specforge --skill plan

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

2 things to look at

13 days oldThe repository was created 13 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 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.

What its author says it does

Copied from the file, not written here

Produce the technical implementation plan (the HOW) for an approved feature spec. Use when the user wants to plan a feature, design the architecture, decide the tech approach, or move from spec to implementation design. Writes plan.md plus research.md, data-model.md, contracts/, and quickstart.md, and checks the plan against the constitution.

SKILL.md

3.2 KB, as published. Nobody here has run it

/specforge:plan — design HOW to build it

Translate an approved spec into a concrete technical plan. This is the Construction design step. Consider delegating to the architect subagent. The human's approval of this plan is what unblocks code edits (together with the spec approval).

When to use

A feature spec exists and the user is ready to design the implementation.
Trigger words: "plan", "design", "architecture", "how should we build".

Preconditions

The active feature's spec.md should be reviewed. Ideally specify is already approved (/specforge:approve specify). If the spec still has [NEEDS CLARIFICATION], run /specforge:clarify first.

Steps

Read the active feature's spec.md, the project constitution.md, and specforge/inputs/tech-environment.md (honor its constraints; never use a prohibited library).
Write plan.md from ${CLAUDE_SKILL_DIR}/../_shared/plan-template.md (or the skeleton below):
- Constitution Check — for each principle, state compliance or a justified exception.
- Technical Approach and Architecture (components, data flow, a diagram).
- Technology Decisions table grounded in tech-environment.md.
- Requirement → Design Traceability — every FR/NFR maps to a design element.
- Risks & Mitigations.
Generate the companion artifacts in the feature dir:
- research.md — options considered, decisions + rationale.
- data-model.md — entities, fields, relationships, validation.
- contracts/ — API endpoints / event / schema specs.
- quickstart.md — how to run and verify once built.
Update specforge/state.md: add/ensure | NNN-slug | plan | done | <date> |.
Audit: | <today ISO-8601> | NNN-slug | plan | Plan + companions drafted |.
Tell the user the plan is ready for review. Emphasize: once they run /specforge:approve specify and /specforge:approve plan, the gate opens and /specforge:tasks → /specforge:implement can proceed.

Plan skeleton (if the shared template is unavailable)

# Implementation Plan: <name>
- Feature ID: NNN · Spec: ./spec.md · Status: Draft
## Constitution Check   (per-principle compliance/exception)
## Technical Approach
## Architecture         (components, data flow, diagram)
## Technology Decisions (table; grounded in tech-environment.md)
## Requirement → Design Traceability  (every FR/NFR mapped)
## Companion Artifacts  (research.md, data-model.md, contracts/, quickstart.md)
## Risks & Mitigations
## Review Checklist (gate)

Guardrails

The plan must satisfy every FR/NFR in the spec — a complete traceability table is required so /specforge:analyze can verify coverage.
Respect the constitution; if you must deviate, document it as an explicit exception, don't hide it.