Spec-driven development toolkit: create, review, and iterate on feature specifications with an expert review panel.
Collegium spec reviewer — finds what will break. Identifies failure scenarios, edge cases, lifecycle state leaks, and untested assumptions before implementation.
Use this agent when you need to review recently written or modified code for quality, structure, and best practices. Invoke after completing a logical chunk of implementation, before committing, or when explicitly asked to review. Also use when reviewing a plan's proposed file structure before implementation.
Pure diagnostic agent for deep root-cause analysis. Use when investigating any bug, error, failure, or unexpected behavior — frontend, backend, infrastructure, or cross-cutting. This agent NEVER writes or modifies code. It only investigates and returns a diagnosis. Pass it: (1) the problem / symptoms, (2) reproduction steps if known, (3) relevant file paths, error messages, or logs. Use proactively whenever a user reports something broken or behaving unexpectedly.
Use this agent when you need comprehensive research on a specific topic, technology, or problem domain. This agent excels at gathering information from multiple sources, synthesizing complex information, and preparing detailed research outputs that other AI agents can use as foundation for their work. <example> Context: The user needs to understand a new technology before implementing it. user: "I need to implement WebRTC for our video chat feature. Can you research the key concepts and implementation considerations?" assistant: "I'll use the deep-research-analyst agent to gather comprehensive information about WebRTC." </example> <example> Context: The user is evaluating different architectural patterns. user: "We're deciding between microservices and monolithic architecture for our new project. I need a detailed comparison." assistant: "Let me engage the deep-research-analyst agent to research both architectural patterns thoroughly." </example> <example> Context: The user encounters an unfamiliar error or issue. user: "We're getting CORS errors in production but not in development. I need to understand why this happens and all possible solutions." assistant: "I'll use the deep-research-analyst agent to investigate CORS issues and their solutions comprehensively." </example>
Collegium spec reviewer — evaluates how the design fits with the existing system. Catches boundary violations, data flow issues, blast radius problems, and integration mismatches.
Deep code quality review focused on cohesion, understandability, editability, testability, and debuggability. Produces an impact/effort matrix with actionable findings.
Run pre-spec reconnaissance (prep), load an existing spec to resume work, update progress after implementation, review with the collegium panel, or create a new one. Use when starting a session around a feature, when the user mentions a spec by name, when asked to prep, scope, or review/critique a spec, or after completing implementation work.
Universal structural quality principles for code and plans. Evaluates mechanism vs business logic separation, file/function size, composability, and reusability. Works before writing code (on plans) or after (on implementations). Trigger on "review structure", "check structure", "structural review", or when code/plans need decomposition review.
Uses power tools
Uses Bash, Write, or Edit tools
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
A spec-driven development toolkit for Claude Code. Write specifications first, review them with an expert panel, then implement with confidence.
Prep → Create → Review → Implement → Update → Handoff → Resume → ...
This plugin gives you the complete lifecycle:
| Step | What you do | What the plugin provides |
|---|---|---|
| Prep | /spec prep my-feature | Pre-spec reconnaissance. Align on the real change, scaffold the folder + a ≤30-line product-brief.md (business only, no code), then fan out adaptive recon waves (read-only Explore agents) across two lenses — implementation (seam, reuse, blast radius, tests) then craft (naming, fixtures, extraction-for-reuse) — locking ground truth into research/. One hard stop — right after the brief. |
| Create | /spec my-feature | Interactive spec creation — decisions, wireframes, API contracts, per-phase plans. Consumes prep's brief + research when present; otherwise cold-discovers. |
| Review | /spec my-feature + "review" | Fully autonomous: 5 expert agents evaluate the spec in parallel, findings are synthesized, written to immutable reviews/<date>.md, applied to the spec + ledger, and committed as one [review] commit — no prompts. Only contradictions and rethink verdicts wait for you, recorded as open decision ledger entries |
| Update | /spec my-feature + "update" | Checks off sub-items inside phase entries, captures durable learnings as ledger entries, updates the code map |
| Status | /spec my-feature status | Print a 4-column phase snapshot — Phase, Status (✅ done / 🟡 WIP (x/y) / 🟢 active / ⬜ pending), Delivers, Work — without the resume briefing. active is reserved for the first unchecked phase; later unchecked phases are pending. Work falls back to N/A if the phase has no implementation guidance. Format is a markdown table — never cards or vertical lists. |
| Handoff | /spec my-feature + "handoff" | Reflects on the session and redirects findings: durable learnings → ledger, pending state → in-flight.md. Commits and signals. |
| Resume | /spec my-feature | Two-stage. Stage A: prints the status table, reads in-flight.md if present, suggests the next chunk, halts. Stage B (only on confirmation): loads stable references + the active phase entry + filtered ledger + scoped code-map, then hands off to execute mode. |
| Execute | (entered automatically from Resume Stage B) | Inner work loop. Decompose the chunk into testable units, run red→green→commit per unit, update the phase entry's sub-checkboxes, add ledger entries for durable learnings, and trigger /spec handoff before hitting ~75% of the context budget. |
No arguments required for the feature name — the /spec skill infers it from conversation context. Sub-commands (prep, create, resume, review, update, handoff, status, list) can lead or trail the feature name: /spec resume my-feature, /spec my-feature resume, or /spec resume (alone, with the feature inferred from context) all work.
A spec is only as good as the facts under it. Writing technical.md and phase plans straight from a customer ask bakes in assumptions — the wrong gate, a reinvented mechanism, an unseen blast radius. Prep front-loads the grounding: a frozen ≤30-line business brief becomes the contract, then read-only Explore agents fan out in adaptive waves — each wave aimed by the last one's findings at whatever's still unknown — until the codebase ground truth is locked into research/ — across two lenses: implementation (where the change lives, what to reuse, blast radius) and craft (naming, test fixtures, extraction-for-reuse), so the result reads like the codebase wrote it. Only then does /spec create write the spec, citing verified file:line facts instead of guesses. The single human checkpoint sits where it matters most: right after the brief, before any token is spent on recon.
A non-trivial spec carries hundreds of KB across design.md, technical.md, ledger entries, and per-phase plans. Loading all of it on every /spec resume burns 100K+ tokens before any work starts.
Stage A reads only progress.md and per-phase Goal/Implementation lines — same materials as /spec status. The user sees the full picture (table + suggested next chunk) and decides what to work on. Stage A renders bullets, not paragraphs — every line earns its place, and there's no magic-word CTA: any natural confirmation ("yep", "go ahead", "do this phase") triggers Stage B. Stage B then loads the focused subset relevant to that decision and hands off to execute mode, which runs the per-unit TDD loop and watches the context budget so the session ends cleanly via /spec handoff before the window fills up.
When you trigger a review, 5 agents launch in parallel:
npx claudepluginhub anton-haskevych/spec-driven --plugin spec-drivenAI image and video generation prompt engineering. Craft optimized prompts for Google Imagen/Veo and OpenAI models. Activates automatically when visual assets are needed.
Agent infrastructure guide for Claude Code. Routes knowledge to the right artifact AND scope — git-tracked team knowledge by default, personal memory as the exception. Keeps files small with topic-owned, on-demand rules that split before they become god-files. Audits health and emits concrete actions; ships a personal-memory guard hook.
Specification-Driven Development with Process Discipline for Claude Code
Spec-driven development methodology for Claude Code. Provides skills for requirements engineering (EARS format), design documentation, task breakdown, AI prompting strategies, quality assurance, and troubleshooting.
Specification-driven development workflow: specify → plan → tasks → implement
Spec-driven development with search, conflict detection, and reporting
Spec Driven Development toolkit - structured specification, planning, and implementation workflows for systematic feature development
Spec-driven development with task-by-task execution. Research, requirements, design, tasks, autonomous implementation, and epic triage for multi-spec feature decomposition.