원클릭으로
speq-plan
Plan and create spec deltas for new features or changes to existing features.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Plan and create spec deltas for new features or changes to existing features.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Audit a speq project's health — spec-library structure, feature/decision-log/plan validation, mission-to-spec sync, unrecorded plans, and gitignore hygiene — then guide fixes. Use when the user asks to audit, health-check, doctor, lint, or sanity-check the specs or repo, or after cloning or inheriting a speq project.
Code review tag taxonomy and findings output format — guardrail violations, dead code, obsolete tests, bad comments, optimizations, YAGNI/over-engineering. Triggered by code-reviewer.
Headless follow-up to speq-plan-pr. Continues on a plan's feat/plan-name branch, runs speq-implement, bumps the version, runs the real test suites, records only if green, then pushes and opens/updates a PR. Arg: plan name, PR number, or branch name.
Orchestrate implementation of reviewed plans according to the spec deltas. Arg: <plan-name>.
Create specs/mission.md via interactive interview. Detects brownfield vs greenfield.
Headless, non-interactive version of speq-plan. Plans a feature without a live interview, commits the result to a feat/plan-name branch, and opens a PR. If a decision genuinely needs a human, it persists the partial plan and open questions and asks in a PR comment instead of blocking. Arg — plan name, feature intent text, PR number, or branch name.
| name | speq-plan |
| description | Plan and create spec deltas for new features or changes to existing features. |
| model | sonnet |
This skill is a thin orchestrator. It conducts the clarifying interview, collects context, and then delegates the heavy planning work (spec delta authoring, test mapping, task decomposition) to the planner-agent sub-agent.
Why this split: Orchestration (asking questions, reading a few files, shepherding the workflow) does not need expensive reasoning. The actual planning — architectural tradeoffs, MECE decomposition, ADR authoring — does. Splitting the work concentrates reasoning on the step that benefits from it.
Invoke before starting:
/speq-cli — Spec discovery and searchThe planner-agent sub-agent invokes /speq-planning, /speq-code-tools, /speq-ext-research, and /speq-cli itself; plan-reviewer invokes /speq-plan-review.
Check for .speq/plan-hook.md in the repo root.
Use speq CLI to understand what exists:
speq domain list
speq feature list
speq search query "<relevant terms>"
This is lightweight — enough context to ask good clarifying questions, not a full exploration.
Apply the Socratic Method via AskUserQuestion — never assume. Decompose the problem space using MECE partitioning:
Record answers in a concise interview summary to pass to the sub-agent.
Pattern: <verb>-<feature-scope>[-<qualifier>]
| Verb | When |
|---|---|
add | New feature |
change | Modify existing |
remove | Deprecate/delete |
refactor | Restructure, same behavior |
fix | Bug or spec mismatch |
Spawn the planner sub-agent with everything it needs:
Delegate to planner-agent — Plan <plan-name>
## Plan Name
<plan-name>
## User Intent
<1-3 sentence summary of what the user wants>
## Clarifying Interview Results
<verbatim Q&A from the AskUserQuestion exchanges>
## Existing Context
<output of relevant `speq search` / `speq feature get` calls>
## External Research
<any research already conducted, or "none — agent to research as needed">
## Project Hook
<if active: note ".speq/plan-hook.md — read it and apply it" — otherwise omit this section>
## Your Task
Produce spec deltas and plan.md per the `planner-agent` workflow. Tag tasks requiring deep reasoning with [expert] so the implementer orchestrator can route them to implementer-expert-agent.
Return the list of files created and the validation result.
When the sub-agent returns:
speq plan validate <plan-name> passed (re-run if uncertain)planner-agent is both author and, until now, sole judge. Before handing the plan off, spawn plan-reviewer — a diabolus advocatus — to challenge it. Bounded to 2 rounds total.
Round 1:
Delegate to plan-reviewer — Review <plan-name> (round 1)
## Plan Name
<plan-name>
## User Intent
<verbatim original request>
## Clarifying Interview Results
<verbatim Q&A>
## Plan Artifacts
plan.md, decision-log.md, and every specs/_plans/<plan-name>/**/spec.md delta
## Project Hook
<if active: note ".speq/plan-hook.md — read it and apply it" — otherwise omit this section>
If BLOCKER findings exist:
planner-agent with only the BLOCKER list, instructing it to revise the specific plan/spec-delta content addressing each one, log each resolved blocker as a ## Review Findings entry in decision-log.md ([plan-review] title prefix), and re-run speq plan validate.plan-reviewer for round 2, passing the round-1 BLOCKER list so it confirms each is actually resolved before checking for new ones.If BLOCKERs remain after round 2 — use AskUserQuestion: present the remaining blockers, let the user accept the risk and proceed, or give guidance and respawn planner-agent manually.
ADVISORY findings are never looped on or persisted — carry them into step 7's report so the user sees them before implementing.
/speq-implement <plan-name> to continue/clear to start implementing with a fresh context windowExitPlanMode and ask to proceed with cleared contextspecs/
├── <domain>/<feature>/spec.md # Permanent
├── _plans/<plan-name>/ # Active
└── _recorded/<plan-name>/ # Archived
| Step | Performed by | Why |
|---|---|---|
| Discovery, interview, coordination | This skill (pins Sonnet) | Conversational, tool-call heavy |
| Spec delta authoring, ADR, task decomposition | planner-agent sub-agent | Reasoning-heavy; defect here compounds through implementation |
| Adversarial review, revision loop | plan-reviewer sub-agent | Catches intent drift, infeasibility, and ambiguity before implementation, not after |
Each sub-agent pins its own model and effort in its frontmatter, so planning quality is independent of the parent session's configuration.