Installing and Running the Toolkit

Everything else in this collection describes the method. This describes the software that runs it.

Verified end to end against Spec Kit 0.14.3.dev0 with the Claude integration: CLI install, project init, catalog-based extension install, preset install, hook registration, and command resolution.

What it actually is

Not a fork that drifts away from upstream. Two installable components layered onto stock Spec Kit:

Component	ID	What it does
Extension	agentic	Adds commands — restraint, security, verify, retrospective, skills, audit, debt, quickfix. Registers hooks on after_plan, after_tasks and after_implement.
Preset	agentic	Replaces three core commands — plan, tasks, implement — with versions carrying model routing, parallel waves, context injection, and the pre-task review.

That split matters for maintenance. Extensions are additive files that never collide with upstream, so they survive any release. The preset does overwrite core commands, but it's built on upstream's current command bodies with roughly 40–80 changed lines each — taking a new Spec Kit release is a small merge, not a rewrite.

Source: joexbayer/spec-kit-agentic.

Install

Install the CLI, then a project.

# 1. The CLI (requires uv)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 2. A project
specify init my-project --integration claude
cd my-project

# 3. The extension, from the catalog
specify extension catalog add \
  https://raw.githubusercontent.com/joexbayer/spec-kit-agentic/main/extensions/catalog.json \
  --name agentic --install-allowed
specify extension add agentic

# 4. The preset, from a clone
git clone https://github.com/joexbayer/spec-kit-agentic
specify preset add --dev spec-kit-agentic/presets/agentic

--integration picks the agent. claude, copilot, cursor-agent, codex, gemini and a couple of dozen others are supported — the commands are written to be agent-neutral, so the workflow is the same whichever you pick.

Confirm it took:

specify extension list      # → Commands: 8 | Hooks: 3 | Status: Enabled
specify preset list         # → Templates: 3 | enabled
ls .claude/skills/speckit-agentic-*      # Claude
ls .claude/commands/speckit.agentic.*    # slash-command agents

One thing that trips people up

The separator depends on your agent. Claude installs Spec Kit content as skills, one directory per command, with hyphens:

.claude/skills/speckit-agentic-verify/SKILL.md

So under Claude you type /speckit-agentic-verify, not /speckit.agentic.verify. Slash-command agents get the dotted form. It's the same command — the integration picks the separator, which is why command bodies reference each other through an agent-neutral token rather than a hard-coded spelling.

This article uses the dotted form throughout for readability. Translate mentally if you're on Claude, Codex, or Kimi.

The command surface

Core Spec Kit, unchanged:

/speckit.constitution   /speckit.specify   /speckit.clarify
/speckit.plan           /speckit.tasks     /speckit.implement
/speckit.analyze        /speckit.checklist

Added by the extension:

/speckit.agentic.restraint       ladder against the plan, before tasks exist
/speckit.agentic.verify          adversarial review across seven dimensions
/speckit.agentic.retrospective   post-mortem → amendments + skill candidates
/speckit.agentic.skills          materialise the skill candidates
/speckit.agentic.security        security controls into tasks, before implementation
/speckit.agentic.audit           whole-repo over-engineering sweep
/speckit.agentic.debt            harvest deliberate-shortcut markers
/speckit.agentic.quickfix        the fast lane

plan, tasks and implement keep their names — the preset changes what they do, not what you type.

A full run

/speckit.constitution     # once per project
/speckit.specify          # describe WHAT, never HOW
/speckit.clarify          # answers fold back into spec.md
/speckit.plan             # stops at preview.md and waits for you
/speckit.agentic.restraint
/speckit.tasks
/speckit.agentic.security
/speckit.implement
/speckit.agentic.verify
/speckit.agentic.retrospective
/speckit.agentic.skills

Three of those you won't usually type. The after_plan, after_tasks and after_implement hooks offer restraint, security and verify at the right moment and prompt before running. All are optional by design — a gate that fires without asking gets resented, then disabled.

For a typo or a one-line fix, skip all of it:

/speckit.agentic.quickfix   fix the off-by-one in the pagination cursor

It checks its preconditions first and will refuse. Rejection is a normal outcome, not a failure — see Spec-Driven Workflow.

Configuration

Optional. Written to .specify/extensions/agentic/agentic-config.yml; every command falls back to sane defaults when it's missing.

quickfix:
  protected_globs: ["**/migrations/**", "**/auth/**", "**/*.sql"]
  max_files: 2
  max_lines_changed: 20

restraint:
  intensity: "full"      # lite | full | ultra

security:
  asvs_level: 2          # OWASP ASVS 5.0 level: 1 | 2 | 3
  owasp_review: true     # walk the Top 10:2025 explicitly
  regimes: []            # cra | nis2 | gdpr | dora | nsm — only what applies

verify:
  dry_rounds: 2          # empty rounds before the hunt converges
  refutation_votes: 3    # independent attempts to kill each finding

promotion:
  threshold: 3           # recurrences before a failure becomes a rule

Two worth tuning on day one.

protected_globs — the fast lane earns its speed by being narrow. Migrations, auth and schema files should never take it.

security.regimes — leave it empty unless a regime genuinely applies. The commands will not invent obligations the project has not claimed, which is the right default: a baseline nobody can satisfy gets ignored wholesale.

restraint.intensity — a dial, not a switch. lite nudges, full enforces the ladder on every new construct, ultra demands written justification for each new file, dependency and layer and turns necessity findings into blockers at verify. Prototypes tolerate more; load-bearing code less. See The Restraint Principle: YAGNI for Agents.

Roles

The extension ships prompt contracts under .specify/extensions/agentic/roles/ — orchestrator, worker, explorer, reviewer. Prepend one to a subagent's prompt, then the task-specific content.

They exist because without a written contract every dispatch re-improvises its framing and the guarantees drift. The worker contract carries the allowlist and the CONTEXT_INSUFFICIENT protocol; the reviewer contract makes independence structural rather than a matter of instruction. Detail in Subagents and Context Injection and Trust but Verify.

Claude Code specifics

docs/claude-code.md in the extension maps the harness onto the workflow: subagents for the role contracts, parallel fan-out for implementation waves and the verify hunt, worktree isolation when several agents write at once, background execution for slow gates, loop-until-dry for convergence, and hooks for the things a prompt can't guarantee.

All of it is use-if-present. Every command degrades to a single-agent sequential pass, because a command that breaks on a missing harness feature is a broken command.

One rule worth lifting out of that document: if you find yourself writing "always remember to X" into a prompt, X wants to be a hook. An instruction is a request; a hook is a guarantee.

Staying current

Upstream ships often. Taking a release costs almost nothing, by design:

1. specify self upgrade — the CLI comes straight from upstream, so nothing here gates it.
2. The extension needs nothing. Additive files don't collide with anything upstream changes.
3. Re-apply the preset's diff onto the new plan, tasks and implement bodies. It's roughly 40–80 changed lines per command against upstream's own text, kept deliberately small so this stays a merge rather than a rewrite.
4. Re-run specify extension add / preset add in your projects to pick up the new copies.

Do not vendor a copy of Spec Kit and edit it in place. That's the shape the first version of this project took, and it ends badly: a repository sharing no history with upstream, unable to take a release, one "Sync fork" click away from losing the customisations entirely. The components live in their own repo precisely so upstream stays upstream.