Spec-Driven Develop plugin
A plugin with three skills for large development work: project analysis, phased tasks tracked as GitHub Issues, parallel agents and code review
- 992 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- Creates, groups and closes Issues, milestones and labels in your GitHub repository through the gh CLI
- Parallel lanes (Tier 2) write code in isolated worktrees and commit fixes directly to lane branches themselves
- The execution phase merges several tasks into one PR and pushes changes to a shared integration branch
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add plugins/spec-driven-developDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Creates, groups and closes Issues, milestones and labels in your GitHub repository through the gh CLI
- Parallel lanes (Tier 2) write code in isolated worktrees and commit fixes directly to lane branches themselves
- The execution phase merges several tasks into one PR and pushes changes to a shared integration branch
This is third-party code. Review the repository files before installing.
What it does
Spec-Driven Develop is a Claude Code, Codex and OpenCode plugin with three skills and no slash commands: spec-driven-develop carries a large task (such as 'rewrite the project in Rust') through seven phases, from architecture analysis to archiving the artifacts. Phase 1 assesses modules and risks, phase 2 asks clarifying questions based on that analysis, phase 3 breaks the work into tasks and parallel lanes, and phase 5 presents the plan for confirmation and only then executes the tasks, merging several closed GitHub Issues into one PR with a `Closes #N` line for each. When a GitHub repository is detected, tasks automatically become Issues with per-phase milestones and priority and size labels; without `gh` or a GitHub repo, the skill falls back to plain Markdown files with no tracker link. An adaptive-control loop compares actual effort against the estimate after every task and keeps a cumulative drift score: at 20% drift across a phase's tasks the plan is simply annotated with a warning, at 40% execution halts to re-decompose the remaining tasks, and at 60% the workflow returns to the clarification phase to re-evaluate scope. The second skill, Deep Discuss, triggers on phrases like 'let's discuss' or 'I'm stuck on a decision' and runs a structured seven-phase discussion: it first confirms it understands the problem, then checks whether there's enough information, and only after that moves to solution options with trade-offs, never proceeding to execution without the user's explicit 'go'. The third skill, Review SPD, looks at uncommitted changes, a date-range of commits or a branch diff and gathers findings aimed at bugs and regressions rather than general code style.
Who it is for. For developers steering a large rewrite or migration through an agent who want phased work tracked as GitHub Issues, rather than one long session with no intermediate checkpoints.
Good fit when
- You want to break a large task (a stack migration, an architecture change) into phases with tasks and dependencies
- The project is already on GitHub and you want tasks to turn into Issues with milestones and labels automatically
- You want a structured discussion before deciding a technical question, with an explicit 'go' before moving to code
- You want a review of a diff or a date range of commits aimed at bugs and regressions, not general style notes
Not a fit when
- The task is one or two files or a simple edit: seven phases and Issue tracking are excessive for that scope
- There's no `gh` installed and no GitHub repository, but you specifically want Issue tracking: without them the skill automatically falls back to local Markdown files
- You need an unlimited number of parallel work lanes: the protocol caps parallel lanes at four at a time
- You want a skill that writes code without confirming the plan first: phase 5 shows the plan and waits for agreement before executing tasks
Example request
Break down the task of migrating the service to TypeScript into phases, analyze the current architecture and show me the plan before startingLimitations
License is MIT.
- Parallel work lanes (Tier 2) require disjoint file sets, effort of at least L per lane, independent verifiability, and are capped at four lanes at a time.
- The independent code-reviewer subagent is used only for Tier 2 lanes and high-risk changes; ordinary cases are reviewed by the main agent itself.
- GitHub mode turns on automatically when a repository and `gh` are detected; without them, all tracking falls back to plain Markdown files with no Issues, milestones or labels.
- The `scripts/install-agents.sh` script syncs the skills into `~/.agents/skills` only for agents that read that shared folder; Claude Code and Codex connect through their own plugin format instead.
- The drift thresholds (20%, 40%, 60% of a phase's tasks) are computed over the whole phase, so a reaction to plan drift doesn't appear right after the first over-budget task, but once the share of drifted tasks accumulates.
How to disable. Remove the plugin with the command matching your plugin manager (for Claude Code, `/plugin uninstall spec-driven-develop`), or delete the plugin folder from `~/.claude/plugins/` by hand. GitHub Issues, milestones and labels it created stay in the repository and are closed or deleted separately.
FAQ
Does Spec-Driven Develop need GitHub to work?
No, without `gh` installed or a GitHub repository, the skill automatically falls back to a local mode with plain Markdown files instead of Issues, milestones and labels. The full mode with Issues, milestones, labels and a project board only turns on when both are detected.
Can the skill start writing code without confirming the plan?
No, phase 5 presents the final plan and waits for the user's agreement before executing tasks in parallel or sequentially. Before that phase, the agent asks clarifying questions based on the phase 1 analysis.
What happens if real work drifts from the plan?
An adaptive-control loop compares actual effort to the estimate after every task and keeps a cumulative drift figure for the whole phase. Past thresholds of 20%, 40% and 60% the response escalates from a warning to a halt and a scope re-evaluation back in phase 2.
How is Review SPD different from an ordinary code review?
It looks at uncommitted changes, commits in a chosen date range or a diff between branches, and focuses on findings that point to bugs and regressions. General code-style and formatting notes are outside this skill's scope.
How many parallel work lanes can run at once?
The protocol caps parallel lanes (Tier 2) at four at a time, and each lane has to work on a disjoint file set with enough work on the project's own sizing scale. Only Tier 2 lanes and high-risk changes go through an independent reviewer agent before merging.
Discussion
No questions or reviews yet.
Related
PluginsA Claude Code plugin: spec-driven development over a single SPEC.md file, a loop of seven commands with no sub-agents
Goal Workflow
goal-workflow
19 skills for Claude Code: PRD, spec, GitHub Issues, batch implementation with review and pull request merging, plus refactoring and diagrams
A skills library that gives coding agents a development process: brainstorming, planning, TDD, subagents and code review
A plugin for Claude Code and Codex: turns a feature request into a spec and executes it task by task with fresh context
Two skills for spec-driven development: /spec asks questions and saves a document to specs/, /spec-impl implements an approved spec step by step
A Claude Code plugin: 39 commands for PRs, review, commits and specs, nine expert roles and hooks, in eight language versions
Comparison with similar tools
Entries that share the main search query, and how they differ.
| Entry | Official | Repository stars | Main difference |
|---|---|---|---|
| Spec-Driven Develop (this entry) | no | 992 | |
| CCPM | no | 8,414 | the same genre of GitHub-Issue-driven development with parallel agents in a git worktree, but without an adaptive-control loop with drift thresholds |
| BMad Method | no | 54,458 | walks from an idea and a PRD to architecture and stories through separate skills, rather than one seven-phase loop with automatic Issue tracking |
README in short
The repository description opens with a fact table meant for citing in search results: category, main users, supported agents, key concepts and license. A detailed breakdown of the main skill's seven phases with a diagram follows, plus separate sections on Deep Discuss and Review SPD, and a section on the S.U.P.E.R architectural backbone drawing on engineering-cybernetics principles. Install instructions for different agents and an FAQ on compatibility and limits close out the description.