agentsclimarketplace

Speq plan

Skill marconae/speq-skill/.claude/skills/speq-plan

A light-weight and straightforward system for spec-driven development with Claude Code or OpenAI Codex. Written in Rust πŸ¦€

Install
npx -y skills add marconae/speq-skill --skill speq-plan

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

What its author says it does

Copied from the file, not written here

Plan a feature or change through a clarifying interview, producing spec deltas, plan.md, and decision-log.md via planner-agent with adversarial review. Use when the user asks to plan, spec, design, or scope a new feature, a change or removal of existing behavior, a refactor, or a fix β€” before any implementation.

SKILL.md

6.6 KB, as published. Nobody here has run it

Spec Planner (Orchestrator)

This skill is a thin orchestrator: it conducts the clarifying interview, collects context, and delegates the heavy planning work (spec delta authoring, test mapping, task decomposition) to the planner-agent sub-agent. Orchestration is cheap; reasoning is expensive β€” the split concentrates reasoning where defects compound.

Required Skills (for the orchestrator)

Invoke before starting:

  • /speq-cli β€” Spec discovery and search

planner-agent and plan-reviewer invoke their own required skills.

Workflow

0. Load Project Hook (orchestrator)

Check for .speq/plan-hook.md in the repo root.

  • Present: read it. Announce "Loaded project hook: .speq/plan-hook.md". Its content is authoritative β€” it may add, change, or override any part of this skill's workflow below when the two conflict.
  • Absent: continue normally, no mention.

1. Discovery (orchestrator)

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.

2. Clarifying Interview (orchestrator)

Apply the Socratic Method via AskUserQuestion β€” never assume. Decompose the problem space using MECE partitioning:

  • Probe β€” surface hidden assumptions with open-ended questions
  • Partition β€” present alternative solutions as MECE options
  • Challenge β€” test design tradeoffs through guided counterexamples

Record answers in a concise interview summary to pass to the sub-agent.

3. Plan Name (orchestrator)

Pattern: <verb>-<feature-scope>[-<qualifier>]

VerbWhen
addNew feature
changeModify existing
removeDeprecate/delete
refactorRestructure, same behavior
fixBug or spec mismatch

4. Delegate to planner-agent

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.

5. Review planner-agent output (orchestrator)

When the sub-agent returns:

  1. Confirm speq plan validate <plan-name> passed (re-run if uncertain)
  2. List all created files
  3. If the sub-agent escalated a question back to you, resolve it with the user and respawn with the clarification

6. Adversarial Plan Review (orchestrator)

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:

  1. Respawn 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.
  2. Respawn plan-reviewer for round 2, passing the round-1 BLOCKER list so it confirms each is actually resolved before checking for new ones.
  3. Do not loop a third time, even if round 2 surfaces new BLOCKERs.

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.

7. Explain next steps (orchestrator)

  • Inform the user that the plan is created and ready for review
  • List all created files
  • Report any ADVISORY findings from step 6 so the user sees them before implementing
  • Inform the user to call /speq-implement <plan-name> to continue
  • Inform the user to call /clear to start implementing with a fresh context window
  • If Claude Code is in "plan mode", call ExitPlanMode and ask to proceed with cleared context

Spec Hierarchy (reference)

specs/
β”œβ”€β”€ <domain>/<feature>/spec.md     # Permanent
β”œβ”€β”€ _plans/<plan-name>/            # Active
└── _recorded/<plan-name>/         # Archived

Work Split (reference)

StepPerformed byWhy
Discovery, interview, coordinationThis skill (pins Sonnet)Conversational, tool-call heavy
Spec delta authoring, ADR, task decompositionplanner-agent sub-agentReasoning-heavy; defect here compounds through implementation
Adversarial review, revision loopplan-reviewer sub-agentCatches 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.

Anti-Patterns

PatternWhy Wrong
Authoring plan.md or spec deltas in the orchestratorplanner-agent owns all plan authoring
Skipping the clarifying interviewContent comes from user answers, never assumptions
A third review roundReview is bounded to 2 rounds β€” after that, the user decides
Persisting ADVISORY findings or looping on themReport-only; they never gate
Embedding spec content in plan.mdPlans reference delta files

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.