A Claude Code plugin that bootstraps and drives GitHub's spec-kit — a Spec-Driven Development (SDD) toolkit where a written spec, not the code, is the source of truth.

Unlike upstream's own distribution model (which scaffolds its slash commands into .claude/skills/ on every repo you run specify init in), this plugin vendors the /speckit-* skills once, here, and they're available in every repo the moment this plugin is installed — no per-repo skill files, nothing to commit or gitignore, nothing to re-install per project.

Install

claude plugin add https://git.oleks.space/oleks/claude-plugin-spec-kit.git

That's it — every repo you open now has /speckit-constitution, /speckit-specify, /speckit-clarify, /speckit-plan, /speckit-tasks, /speckit-checklist, /speckit-analyze, /speckit-implement, /speckit-converge, and /speckit-taskstoissues available, with no per-repo setup for the skills themselves.

Usage

/spec-kit:init              # bootstrap this repo's .specify/ + specs/ state
/spec-kit:status            # show which SDD phase the feature is in
/spec-kit:track             # link/sync feature <-> Gitea epic+milestone+wiki
/spec-kit:help              # print the full setup + per-feature usage guide

New to this plugin? Run /spec-kit:help for the full step-by-step — setup, which command to run at each phase, and when /spec-kit:track fits in.

A given repo still needs /spec-kit:init once, to lay down the parts of spec-kit that are genuinely per-project — .specify/templates, .specify/scripts, .specify/memory/constitution.md, and specs/ (where spec.md/plan.md/tasks.md for each feature actually live). That's real project state; it can't be made global. It runs specify init with the generic integration pointed at a throwaway directory it deletes immediately after, specifically so nothing lands under .claude/ — the skills themselves are never written into the repo.

/speckit-constitution      # once per project — non-negotiable principles
/speckit-specify <feature> # spec.md — user scenarios, requirements, success criteria
/speckit-clarify           # up to 5 targeted questions, encoded back into the spec
/speckit-plan              # plan.md — architecture, data model, contracts
/speckit-tasks             # tasks.md — dependency-ordered task list
/speckit-checklist         # custom review checklist (security, UX, perf, ...)
/speckit-analyze           # cross-check spec/plan/tasks for contradictions
/speckit-implement         # execute tasks.md
/speckit-converge          # catch up tasks.md after drift or a partial implement
/speckit-taskstoissues     # hand tasks.md off as GitHub issues instead

The spec-kit-workflow skill triggers on phrases like "use spec kit", "spec-driven development", "write a spec for this feature" — it'll suggest /spec-kit:init on a repo missing .specify/ and the right next speckit-* skill as work progresses.

Gitea tracking

Tracking is opt-in per feature — nothing gets created on Gitea until you run /spec-kit:track. Once you do:

The feature gets an epic-labelled Gitea issue (the same convention this fleet's cluster plugin already understands — gitea-tools' epic_for_issue lookup, steward-agent's epic dependency graphs) plus a speckit:<phase> label that advances as the feature moves through specify → clarify → plan → tasks → analyze → implement → done.
A dedicated spec-kit: <feature-slug> milestone, so its native progress bar tracks child-task completion without any spec-kit-specific percentage math. Named deterministically per feature — never auto-attached to an existing sprint/release milestone, since picking among those is a judgment call best left to the user. Closes automatically once the phase reaches speckit:done and every assigned issue is actually closed (never forced).
A Specs/<feature-slug> wiki page (the same nested-title convention as this fleet's Kaizen/Pomodoro pages), re-synced from spec.md/plan.md/ tasks.md on every /spec-kit:track run.
Running /speckit-taskstoissues and then /spec-kit:track again turns tasks.md into child issues wired into the epic's checklist and the milestone, with add_dependency links mirroring tasks.md's dependency order.
From there, task-level implementation rides the fleet's existing anxious:wip-claim (claim/release) and anxious:delivery-flow (branch → commit-with-ref → PR) skills instead of a bespoke tracking mechanism — this plugin adds exactly one new label taxonomy (speckit:* phases) and nothing else.
--no-milestone / --no-wiki flags on /spec-kit:track skip either piece per repo if you don't want it.

Requires the cluster plugin (declared as a dependency) for its Gitea MCP tools.

Why vendor the skills, but not the project scaffolding

These are two different kinds of upstream content, and they get opposite treatment on purpose:

.specify/templates, .specify/scripts, per-feature specs/ — these are genuinely per-project: which script type a repo uses, what's actually in spec.md for this feature. There's no "global" version of a feature spec. This plugin doesn't vendor or reimplement any of it — /spec-kit:init always calls the real specify init and lets it lay these down, so they stay in sync with whatever spec-kit version is installed.
The /speckit-* skill definitions — these are identical text regardless of which repo they run in (they just shell out to .specify/scripts/... relative to the current repo). Letting specify init regenerate a copy into every repo's .claude/skills/ is pure duplication with no per-repo variation, so this plugin vendors them once (skills/speckit-*/SKILL.md) instead.

Vendoring the skills does reintroduce a drift risk: they can go stale against upstream, which is exactly what happened to this plugin's own docs before (oleks/claude-plugin-spec-kit#1). bin/sync-vendored-skills.sh is the mitigation — a maintainer tool that regenerates a scratch specify init --integration claude and diffs it against the vendored copies, run as part of any version bump that touches spec-kit compatibility. It's not exposed to end users of the plugin; it's a plugin-maintenance step, not a runtime command.

If a repo genuinely needs the upstream .claude/skills/speckit-*/ copies too (e.g. contributors without this plugin installed still need /speckit-*), that's a deliberate exception — run specify init --integration claude --here --force directly instead of /spec-kit:init.

License

MIT