GitHub - kborovik/pilot-skills: Claude Code plugin marketplace — sdd (spec-driven dev) and gh (GitHub workflow) plugins

4 min read Original article ↗

Claude Code plugin marketplace. pilot-spec drives spec-driven dev, pilot-plan drafts the GitHub paperwork, pilot-core ships shared skills.

The bet

Consistency is the only quality that survives velocity.

Modern LLMs write code faster than any human can read it — and faster than the agent can stay coherent with itself. Vibe coding outruns spec-driven dev right up to the third feature that contradicts the first two. Multi-agent orchestration makes it worse: sub-agents race on shared files, tooling glues the diffs together, and the reasoning ends up scattered across N transcripts nobody reads.

pilot-spec inverts that. Single-thread Claude. One SPEC.md. Math-glyph compression. §V invariants are the part the agent re-reads every turn, so task ten is built against the same constraints as task one. The human reviews the spec, not every diff — consistency holds without slowing the agent down.

Generation is cheap. The spec is what costs, and what's worth keeping. A token costs fractions of a cent; a tight §V invariant costs a real conversation. That's the half worth paying for — code gets rewritten, but §V invariants outlive the framework swap, and §B rows outlive the bug.

Why it works

  • One file, not a tree. SPEC.md is the whole spec — invariants, tasks, bugs — in a single file. Multi-file spec systems (e.g. GitHub Spec Kit) fan out across spec/, plan/, tasks/ — past a certain size, no agent run sees all of it, and the spec stops being a shared reference.
  • Deterministic re-grounding. Come back to the repo after a week, run /sdd:check — read-only drift report: what §V invariants the code violates, what §T tasks remain. Re-onboarding is one command, not transcript archaeology.
  • The drift report stays signal. /sdd:check is only as good as the spec is current. backprop fires automatically on every test/build failure — §B row plus, usually, a new §V invariant — so the spec stays honest, and the report stays trustworthy.

pilot-spec — spec-driven dev

One spec file. Five commands. Main-thread writes.

/sdd:design    # propose-then-critique structural design → draft @ designs/<slug>.md
/sdd:spec      # write or amend the spec — invariants (§V), tasks (§T), bugs (§B)
/sdd:build     # plan-then-execute next task; auto-backprops on test/build failure
/sdd:check     # read-only drift report — code vs §V / §I / §T (--incremental for fast re-runs)
/sdd:explain   # decompress any §X.n citation back into plain English
  • SPEC.md is the only spec file. No docs/ tree, no JSON sidecars.
  • /sdd:spec is the only writer. /sdd:build may flip a task status cell (. → x); everything else routes through /sdd:spec.
  • Math-glyph compression. §V / §T / §B rows are ~30% denser than minimal prose and ~90% denser than the operator-facing prose a reviewer actually reads — bench, methodology, and worked examples in benchmarks/glyph/README.md.
  • Backprop reflex. Every test failure becomes a §B row plus, usually, a §V invariant the spec never forgets.
   ┌────────────┐   ┌────────────┐   ┌────────────┐   ┌────────────┐
   │/sdd:design │──►│ /sdd:spec  │──►│ /sdd:build │──►│ /sdd:check │
   │  propose   │   │  mutator   │   │ plan→exec  │   │ read-only  │
   └────────────┘   └─────▲──────┘   └─────┬──────┘   └─────┬──────┘
                          │                │                │
                          │                ▼ on failure     │ on drift
                          │          ┌────────────┐         │
                          │          │  backprop  │         │
                          │          │ §B (+ §V)  │         │
                          │          └─────┬──────┘         │
                          │                │                │
                          └────────────────┴────────────────┘
                                     amend SPEC.md

Full manual → pilot-spec/README.md.

pilot-plan — GitHub workflow

/gh:issue, /gh:pr, /gh:commit, /gh:merge, /gh:release. Drafts the human-facing text around the code — issue descriptions, PR bodies, commit messages, release notes — in steno-style shorthand, so the human edit is minutes, not paragraphs. Workflow only — no code development.

Full manual → pilot-plan/README.md.

pilot-core — shared skills

Foundation plugin. Ships socratic (intent-gate) and steno (human-facing shorthand) for cross-plugin reuse via namespaced refs (core:socratic, core:steno). Both pilot-spec and pilot-plan declare it as a dependency; Claude Code auto-installs.

Install

Add the marketplace (one-time):

/plugin marketplace add kborovik/pilot-skills

Install pilot-spec (spec-driven dev — pilot-core auto-installs):

/plugin install sdd@pilot-skills

Install pilot-plan (GitHub workflow — pilot-core auto-installs):

/plugin install gh@pilot-skills

Attribution

The sdd plugin (directory pilot-spec/) is adapted from JuliusBrussee/cavekit, MIT-licensed. See pilot-spec/README.md for full attribution.

License

MIT. See LICENSE. Upstream cavekit attribution: pilot-spec/README.md.