reliquary/docs/workpad/research/2026-10-15-11-superpowers-alternatives.md

# Superpowers alternatives — pcvelz fork, upstream state, Matt Pocock skills

**Date**: 2026-10-15
**Model**: claude-opus-5-5 (Opus 5.5)
**Method**: shallow `git clone` of all three repos into `/tmp/sp-research/` (read as data, nothing executed); fork diffed against upstream via a local `upstream` remote. `gh` was denied in this session, so repo stats come from one WebFetch scrape of the GitHub pages.
**Snapshots**: obra/superpowers `bb92a77` (v7.0.0, 2026-10-09) · pcvelz/superpowers `cb12f4f` (6.5.3-dev, 2026-09-18) · mattpocock/skills `49dd158` (2026-10-09)

## Summary

- **pcvelz/superpowers** ("Superpowers Extended for Claude Code") is a fork that is Claude-Code-only and adds features. It **adds** ceremony rather than cutting it: native Tasks with `json:metadata`, `.tasks.json` persistence, hook-enforced gates (model-tier routing, commit strategy, user-gate revalidation, a handoff guard that forces the "Subagent-Driven" choice), and a more aggressive `using-superpowers`. It keeps the per-task implementer, review and 5-round fix loop in full ("Default Subagent-Driven — the review loop is the point"). Token cost is handled only by **routing subagents to cheaper models**, not by doing less. Scope creep is not addressed. It is also **3 upstream releases behind** (it lacks v6.4.1 Native execution, v6.4.2 leaner plans and v7.0.0 brainstorming), and those are exactly the upstream releases that cut cost.
- **Upstream obra/superpowers v7.0.0** has already moved toward leaner defaults: brainstorming that sizes the work, plans that record decisions rather than code, and a "Native" inline execution mode with one final review. Its **default execution recommendation is still subagent-driven development (SDD)**. SDD costs 2 to 12 dispatches per task plus a final review, fix wave and re-review. The reviewer prompts still contain the scope expanders: "a spec's silence is not permission", the Review Focus extra tests, and "YAGNI never downgrades a finding".
- **mattpocock/skills** is the opposite philosophy: small, composable, user-invoked skills with no hooks and no enforcement. `grill-me` and `grill-with-docs` are one-line wrappers around a ~330-word `grilling` primitive (a design-tree interview in rounds, one recommended answer per question). `grill-with-docs` also maintains `GLOSSARY.md` and ADRs. `to-spec`, `to-tickets` and `implement` give a light spec template, vertical-slice tickets and a 100-word implement loop with one two-axis review. Its handoff support is a 144-word `handoff` plus a phase-boundary decision tree. It has no journal concept, no plan document (tickets replace plans) and no Rust or harness specifics.
- **Fit for Spire**: the pcvelz fork is a poor fit (it adds gates, the review loop stays the default, and it is a single maintainer who is lagging upstream). Matt's `grilling` and `to-spec`/`to-tickets` are the best source material to *distill* for "design" and "plan". Spire's existing lean `implementation` skill already covers execution better than either. Handoffs and journals have to come from Spire itself, because nobody in this set provides them.

---

## 1. pcvelz/superpowers vs obra/superpowers

### Identity and stated motivation

- It is a GitHub fork ("forked from obra/superpowers"; ~1.3k stars, 92 forks, 1 open issue, 1 open PR, per a WebFetch scrape that was not verified via the API). The plugin name is `superpowers-extended-cc`.
- README "Why This Fork Exists" (`README.md` lines ~5–20): upstream is cross-platform, so "features unique to Claude Code fall outside the scope of the upstream project" (it cites obra/superpowers PR #344). The goal is to "leverage Claude Code-native features as they're released" while "Track upstream — stay compatible with obra/superpowers core workflow".
- The motivation is **harness integration and enforcement** ("Execution on rails", "no front-running", "Skills prose is not enforcement; agents skip instructions under load. So every layer here is executed by Claude Code's hook system"). It is not about reducing ceremony.

### Sync and maintenance

- Merge-base with upstream: `b36e082` = upstream **v6.3.0** (2026-08-12). The fork re-anchored on 2026-09-12 after an upstream history rewrite (commit `11314cb`). Because of that rewrite, git's "853 commits ahead" is inflated, since most of those are upstream commits under old hashes.
- **Behind by 3 upstream releases**: v6.4.1 (09-18, Native execution and `diagnosing-superpowers`), v6.4.2 (09-25, leaner plans), v7.0.0 (10-09, rebuilt brainstorming). The last fork commit is 2026-09-18, which is about 4 weeks without a merge.
- Merge cadence has been steady historically (upstream merges in 2026-03, -04, -05, -06, -07, -08, -09). Fork-specific work is almost entirely by one person (Peter van Velzen, 133 commits; the next is a drive-by contributor). Fork commit volume by month: Jun 149, Jul 75, Aug 22, Sep 6, so it is **slowing**.
- **Version numbers collide**: the fork calls itself 6.5.x while sitting on upstream 6.3.0 content. Upstream is at 7.0.0.

### Concrete diff (fork HEAD vs merge-base v6.3.0; 52 files, +4697/−943 in skills/commands/hooks)

**Added**
- `skills/specifying-gates/SKILL.md` (~990 words) and `skills/checking-gates/SKILL.md` (~770 words): user-thrown gate specification and checking.
- `skills/shared/task-format-reference.md` (~1590 words): Goal/Files/Acceptance Criteria/Verify task format with a `json:metadata` fence and `modelTier`.
- `commands/onboard.md`, `commands/specify-gate.md`, `commands/gate-check.md`.
- Plugin hooks (`hooks/hooks.json`): `pre-taskcreate-model-tier`, `pre-taskcreate-commit-strategy`, `pre-agent-model-routing`, `pre-askuser-handoff-guard`, and an expanded `session-start`.
- Opt-in example hooks (`hooks/examples/`): `pre-commit-check-tasks.sh` (blocks `git commit` with incomplete tasks), `post-task-complete-revalidate.sh`, `stop-revalidate-user-gates.sh`, `pre-task-blockedby-enforce.sh`, `pre-agent-task-dispatch-validate.sh`, `post-agent-return-validate.sh` (forces evidence tokens in subagent reports), `stop-deflection-guard.sh` (blocks "context is full" excuses below 50% usage), `stop-wait-guard.sh`.
- Optional config files: `docs/superpowers/model-routing.json` (`mechanical`/`standard`/`frontier` mapped to haiku/sonnet/inherit) and `docs/superpowers/workflow.json` (`commitStrategy: at-end`).

**Changed (all additive in ceremony)**
- `writing-plans/SKILL.md`: **3594 words vs upstream 1639**. It keeps the pre-6.4.2 framing ("engineer has zero context for our codebase and questionable taste", a "No Placeholders" section, full code in steps). It adds a mandatory TaskCreate per task with a verbatim Goal/Files/AC/Verify body, `grep -c` self-checks over `.tasks.json`, user-gate tagging, and a HARD-GATE handoff through `AskUserQuestion` with exactly two options. The recommendation is "**Default Subagent-Driven — the review loop is the point.** Recommend Parallel Session only for a nearly-exhausted session; task count alone is never the reason. Cost is your human partner's reason, not yours" (`skills/writing-plans/SKILL.md` ~line 213). The `pre-askuser-handoff-guard` hook enforces this menu.
- `subagent-driven-development/SKILL.md`: 5500 words vs upstream 4873. It keeps the full upstream v6.3 loop: per-task spec and quality review, a 5-round fix loop with scoped re-reviews, a final whole-branch review and one fix wave. Additions are TaskCreate/TaskUpdate integration, plus one commit "optimize skill instructions against opus 5 verbosity" (`12f552a`). That commit adds "ledger records STATE, not reasoning", appends via shell heredoc instead of Edit, and shrinks completed task descriptions so harness reminders re-inject less text. These are useful **context-hygiene** tweaks. They do not reduce reviews.
- `brainstorming/SKILL.md`: upstream v6.3 three-path router plus a HARD-GATE, "MUST NOT call EnterPlanMode/ExitPlanMode", and a REQUIRED native-task creation section during design.
- `executing-plans/SKILL.md`: the old upstream stub plus Task bootstrap and resume from `.tasks.json`, worktree reuse, a "consult the plan author via ListAgents + SendMessage" step (the "architect pattern"), and a non-skippable user-gate rule. It does **not** have upstream's v6.4.1 Native mode (one final review, ledger, `task-start`/`task-done`).
- `using-superpowers/SKILL.md`: keeps or restores the **stronger** older wording ("This is not negotiable. This is not optional."; a dot graph with "About to EnterPlanMode? DON'T"; "Instructions say WHAT, not HOW. 'Add X' or 'Fix Y' doesn't mean skip workflows."). It removes the non-Claude harness references.
- TDD is unchanged: the Iron Law and "Delete means delete" are still present.

**Removed**
- Non-Claude harness references (`codex-tools.md`, `gemini-tools.md`, `hermes-tools.md`, `pi-tools.md`, `antigravity-tools.md`), `hooks-cursor.json`, systematic-debugging test fixtures and creation log, `brainstorming/spec-document-reviewer-prompt.md` (upstream v7 also replaced it), and `writing-plans/plan-document-reviewer-prompt.md` (upstream also removed it in v6.4.2).

### Ceremony: cut vs kept

| Ceremony | Fork |
|---|---|
| Per-task implementer subagent and task review (spec + quality) | **Kept**, and recommended as the default by a hook-guarded handoff |
| 5-round fix loop with scoped re-reviews | **Kept** |
| Final whole-branch review and fix wave | **Kept** |
| TDD mandate (Iron Law) | **Kept** |
| verification-before-completion | **Kept**, plus hook-enforced evidence for user-gates and optional subagent-evidence hooks |
| Brainstorming HARD-GATE before any code | **Kept**, plus native task creation during design |
| Full-code plans ("zero context, questionable taste") | **Kept** (upstream dropped this in v6.4.2) |
| Plan-mode use | **Forbidden** (EnterPlanMode/ExitPlanMode banned in brainstorming, writing-plans and executing-plans) |

### Does it address the user's three pains?

- **Token spend**: partly, and only by price. Model-tier routing (README "Subagent Model Routing") names the problem exactly: "a ten-task plan means thirty-plus top-tier subagent dispatches". Its answer is a cheaper model per seat, not fewer seats. `commitStrategy: at-end` and ledger trimming are small context savings.
- **Review-loop overhead**: **no**. The loop is the declared point of the fork.
- **Scope creep**: **no**. The fork adds no scope-discipline rules. Its user-gate machinery prevents agents from *skipping* verification, which pushes the other way.

### Harness-specific features (Claude Code)

Native Tasks (TaskCreate/TaskUpdate/TaskList with `blockedBy`), the `CLAUDE_CODE_ENABLE_TODO_TOOLS=1` requirement (the README says Claude Code 2.1.233 removed task tools by default), PreToolUse/PostToolUse/Stop hooks, `AskUserQuestion` menus, agent chat (`ListAgents`/`SendMessage`) for executor-to-plan-author consultation, a ban on plan mode, and a `Stop` hook that detects context-deflection excuses. The **ideas** in this list are the fork's most reusable part (cross-session `.tasks.json`, the architect-consultation link, the hook-based model-tier gate). The **implementation** is heavy: the hooks are hundreds of lines of bash each (`pre-agent-model-routing` is 558 lines).

---

## 2. Upstream obra/superpowers v7.0.0: what the default flow imposes

Flow: `using-superpowers` → `brainstorming` → `writing-plans` → (`subagent-driven-development` | `executing-plans`) → `finishing-a-development-branch`, with `test-driven-development`, `verification-before-completion`, `using-git-worktrees` and `requesting-code-review` pulled in along the way.

**Cost drivers, with citations (paths relative to the repo root):**

1. **Skill-check-everything bootstrap.** `skills/using-superpowers/SKILL.md:11-20`: "If you think there is even a 1% chance a skill might apply … you ABSOLUTELY MUST invoke the skill" before any response, including clarifying questions or exploring. Line 22: brainstorm before entering plan mode. This is injected at SessionStart.
2. **Brainstorming gate and builder check.** `skills/brainstorming/SKILL.md:129-143` now sizes the work: a quick task is just done, a small change is agreed in chat, a project gets a design doc. This is a real improvement. Projects still get a **builder-check subagent** (`:160-177`) and a HARD-GATE (`:179-193`): nothing is built until the human approves, and after approval the next step must be `writing-plans` "and no other skill".
3. **Plan format.** `skills/writing-plans/SKILL.md:43-50, 94-138`: every task follows a 5-step RED/verify-fail/implement/verify-pass/commit pattern with an Interfaces block. `:77-87` adds a **Review Focus** section: up to 5 failure modes "the spec implies but no task's tests exercise", each turned into an extra test in a task (`:173`). That is **plan-time scope growth by design**. v6.4.2 cut plan bloat ("A plan longer than the code it describes has written the code instead", `:157-161`; the proportion check at `:175`). Release notes credit this with "a quarter of the time and about a third of the tokens" on an Opus 5.5 over-planning report.
4. **Handoff** (`:179-204`): the human must review the plan and pick **Subagent-driven** ("Most thorough; costs a fresh context per task and per review") or **Native** ("Cheapest and fastest; no independent review until the end").
5. **SDD per-task loop.** `skills/subagent-driven-development/SKILL.md`:
   - `:8, :308-314`: implementer subagent plus a task reviewer for **every** task. "Never skip the task review". Both a spec verdict and a quality verdict are required.
   - `:162-182`: a pre-flight conflict **table** written to the ledger, with one row per task pair that shares a file or interface and one row per task.
   - `:372-403`: fix loop of **up to 5 rounds**, each one fix dispatch plus one scoped re-review. Rounds 4–5 use a fresh implementer on a more capable model.
   - `:445-469`: a final whole-branch review on the most capable model, then ONE fix subagent, then one scoped re-review.
   - `:131-154`: a ledger file with workspace scripts (`sdd-workspace`, `task-brief`, `review-package`).
   - `:408`: "Never fix findings yourself in the controller session", so every fix costs another dispatch.
   - Per task: **minimum 2 dispatches, maximum 12**. Plus 3 at the end.
   - `:184-219`: model-selection guidance (cheap tiers for mechanical tasks, mid-tier as the reviewer floor) exists but is advisory.
6. **Reviewer prompts that widen scope.**
   - `skills/requesting-code-review/code-reviewer.md:33-41`: "a reasonable person's expectation is a requirement, and a spec's silence is not permission".
   - `:43-47`: a "Declined to judge" list that the executor must rule on line by line.
   - `skills/subagent-driven-development/task-reviewer-prompt.md:~66-71`: "'left it per YAGNI,' 'kept it simple deliberately' … a stated rationale never downgrades a finding's severity."
   - Together with Review Focus, these are the most direct cause of **scope expanding beyond the plan**: findings about unspecified behavior enter the fix loop as Important.
7. **Native execution** (`skills/executing-plans/SKILL.md:8-19, 164-232, 234-289`): inline execution where TDD is the per-task gate, a completion contract under `verification-before-completion` (`:207-220`), `task-done` must record passing tests in the ledger, and one final review on the most capable model plus one fix pass. This is the cheapest upstream path, but it is **not** the default recommendation.
8. **Iron-law skills.** `skills/test-driven-development/SKILL.md:31-43` ("NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST … Delete means delete"). `skills/verification-before-completion/SKILL.md:14-17` ("NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE"). v6.4.1 also made "the project's suite defines green", so the full test suite is run, which is expensive on Rust test suites.
9. **Worktree setup** before execution (`subagent-driven-development/SKILL.md:124-129`; `using-git-worktrees`).

Upstream's own evidence of the cost problem: RELEASE-NOTES v6.4.1 ("a real session's final-review fix wave cost more than all its tasks combined", carried into `SDD/SKILL.md:458-461`; the controller "one layer down" on a mid-tier model measured about half the cost) and v6.4.2 (Opus 5.5 "would sometimes try to implement the entire project while designing the plan"). Upstream also now ships `diagnosing-superpowers` (v6.4.1) for post-mortems of expensive sessions.

---

## 3. Matt Pocock's skills (github.com/mattpocock/skills)

~292k stars, 24.5k forks, 166 open issues, 16 open PRs (WebFetch scrape). The repo started 2026-02-03 and is very active (Jul 182, Aug 116, Sep 36, Oct 50 commits). Install: `claude plugin install mattpocock-skills@claude-plugins-official` (per README; not verified). Curation is strict: `SCOPE.md` closes new-skill proposals and rejects "a harness-specific branch" or config options.

### Philosophy (README.md, "Why These Skills Exist")

- "Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve. These skills are designed to be small, easy to adapt, and composable. They work with any model."
- The README names four failure modes, each with a fix: misalignment (grilling), verbosity (a shared `GLOSSARY.md` "ubiquitous language", which it argues makes the agent "spend fewer tokens on thinking"), broken code (feedback loops and `/tdd`), and a ball of mud (deep modules, `/improve-codebase-architecture`).
- **User-invoked vs model-invoked split**: orchestration skills set `disable-model-invocation: true`, so they only run when the human types them. This is the structural opposite of superpowers' "1% rule".
- **Context hygiene** (`skills/engineering/ask-matt/SKILL.md` and `PHASE-BOUNDARIES.md`): keep grill → spec → tickets in one unbroken window; `/clear` between `/implement` tickets; a "smart zone" of about 150k tokens; compact only at phase boundaries.

### grill-me / grill-with-docs (exact)

- `skills/productivity/grill-me/SKILL.md` (user-invoked) is a single line: **"Call the Skill tool with "grilling"."** The original (Feb 2026) text was the well-known one-liner: *"Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one."*
- `skills/engineering/grill-with-docs/SKILL.md` (user-invoked) is also one line: **"Call the Skill tool twice, for "grilling" and "domain-modeling"."**
- `skills/productivity/grilling/SKILL.md` (~330 words, model-invoked) is the actual primitive:
  - Map the work as a **design tree**. Work it in **rounds**: each round asks the whole **frontier**, meaning every decision whose prerequisites are settled.
  - Number the questions and give a **recommended answer** for each, worded so "yes" accepts it. Recompute the frontier after each round.
  - "Finding *facts* is your job, never the user's": dispatch a sub-agent for lookups and don't block on it. "The *decisions* are the user's."
  - Done when the frontier is empty. "Do not act on it until the user confirms you have reached a shared understanding."
  - It deliberately has **no question cap** (`.out-of-scope/question-limits.md`, which cites a report of "Codex just asked me 200 questions").
- `skills/engineering/domain-modeling/SKILL.md` (~490 words):
  - Challenge terms against `GLOSSARY.md`, sharpen fuzzy language, stress-test with invented edge-case scenarios, and cross-check claims against code.
  - Update `GLOSSARY.md` inline: no implementation details, using `GLOSSARY-FORMAT.md`.
  - Offer ADRs **sparingly**: only when a decision is hard to reverse, surprising without context, *and* the result of a real trade-off (`ADR-FORMAT.md`).
  - Multi-context repos use a `GLOSSARY-MAP.md`.

### Related skills (design / planning / PRD / issues / handoff / TDD)

| Skill | Words | What it gives |
|---|---|---|
| `engineering/to-spec` | ~490 | "Do NOT interview": synthesizes the conversation into a spec and publishes it to the issue tracker. It first agrees **test seams** with the user ("the ideal number is one"). Template: Problem Statement, Solution, a long numbered **User Stories** list, Implementation Decisions (modules, interfaces, schema, API; **no file paths or code**), Testing Decisions, Out of Scope, Further Notes. This is the PRD equivalent; the old `write-a-prd` and `prd-to-issues` are now deprecated. |
| `engineering/to-tickets` | ~920 | Splits work into **tracer-bullet vertical slices**, each with **blocking edges**, each fitting one fresh context. Prefactor first ("make the change easy, then make the easy change"). Wide refactors use **expand–contract**. The human approves the breakdown. Tickets are published as local files under `.scratch/<feature>/issues/NN-*.md` or as tracker issues. No file paths or code. **This replaces a "plan".** |
| `engineering/implement` | ~100 | Implement from a spec or ticket, use `tdd` "at pre-agreed seams", typecheck and run single test files regularly, run the full suite **once at the end**, run `code-review` **once**, commit. |
| `engineering/implement-spec` | ~435 | Treats tickets as a task graph. Parallel implementer subagents work the ready frontier, each in its own worktree; a merger subagent integrates; **one** `code-review` on the integration branch; **one** implementer fixes all findings. Communication goes through "context pointers", not pasted content. |
| `engineering/tdd` | ~575 | Red→green in vertical slices. "Test only at pre-agreed seams", confirmed with the user. Anti-patterns: implementation-coupled, tautological and horizontal-slicing tests. "Refactoring is not part of the loop". No delete-the-code iron law. |
| `engineering/code-review` | ~1090 | Two parallel sub-agents: **Standards** (repo docs plus a Fowler smell baseline, where "the repo overrides") and **Spec**. The Spec reviewer explicitly reports "behaviour in the diff that wasn't asked for (**scope creep**)". Reports are capped at under 400 words each. No fix loop and no re-review are prescribed. |
| `engineering/wayfinder` | ~2075 | For efforts too large for one session: a map of **decision tickets** on the tracker, resolved one at a time; it "hands off, it doesn't build" and merges into `/to-spec`. |
| `engineering/prototype` | ~490 | Throwaway prototype to answer one design question, kept on a `prototype/<name>` branch as a primary source. |
| `engineering/codebase-design`, `improve-codebase-architecture` | ~850 / ~900 | Deep-module vocabulary (module, interface, depth, seam, adapter, leverage, locality) and an architecture survey. |
| `engineering/retro` | ~680 | After a session, suggests changes to the **environment** (checks, standards, steering files), not to the code. |
| `productivity/handoff` | ~145 | Writes a handoff doc to `$TMPDIR` (**not the workspace**), with a "suggested skills" section. Doesn't duplicate specs, plans, ADRs or commits ("reference them by path"), redacts secrets, and tailors to the next session's focus. |
| `in-progress/claude-handoff` | ~220 | Same as `handoff`, then launches `claude --bg --name "<name>" -- "$(cat <file>)"` as a background agent. This is Claude-Code-specific and still in progress. |
| `productivity/wait-what` | 60 | "Re-pitch" in simplified English using the glossary vocabulary. |

### How much structure for design / plan / handoff?

- **(a) Design**: strong on the *process* (grilling plus domain modeling) and light on the *artifact*. The only document template is `to-spec`'s (PRD-like, user-story heavy, no architecture section beyond "Implementation Decisions"). There is no "design doc" with alternatives considered, risks or invariants; ADRs cover only individual hard-to-reverse decisions.
- **(b) Plan**: there is **no plan document**. Tickets (vertical slices with blocking edges and acceptance criteria, no file paths or code) *are* the plan. There are no per-task interfaces or signatures, no verification commands per ticket, and no explicit gate or phase structure.
- **(c) Handoffs and journals**: handoff is a one-paragraph prompt to a temporary file, deliberately ephemeral. The phase-boundary tree (continue / clear / handoff / subagent / compact) is well reasoned. There is **no journal or append-only session log** and no durable record of dead ends. `retro` is the closest thing, and it targets the environment, not a history.

### What would be missing if Opus 5.5 "figures out the rest"

- **Verification policy for Rust**: which `cargo` checks run per block vs per phase (`check`/`clippy`/`nextest`), when the full suite runs, mutation checks. Matt's `implement` only says "typecheck regularly, full suite once at the end".
- **Stop and scope rules for execution**: Matt's Spec reviewer *flags* scope creep, but nothing says what happens to findings (fix once? park?). There is no fix-round cap and no "rulings" record.
- **Durable session memory**: no journals and no ledger. The handoff goes to `/tmp` and dies.
- **Plan-to-code reconciliation**: no step that tests the plan against the code before building (Spire's `implementation` already has this).
- **Model and effort routing**: none. The repo states "They work with any model" and refuses harness-specific branches (`SCOPE.md`).
- **Orchestration contracts**: `implement-spec` describes parallel implementers and a merger, but gives no report contract, failure handling or worktree-collision rules.
- **Tracker dependency**: `to-spec`, `to-tickets` and `implement` assume an issue tracker configured by `/setup-matt-pocock-skills`. Local `.scratch/` files are supported, but this does not map onto Spire's `docs/workpad/` layout without adaptation.

---

## 4. Other lightweight alternatives (noted in passing; not researched)

1. **Upstream's own Native path.** `superpowers:executing-plans` (v6.4.1+) with v6.4.2 lean plans: inline execution, TDD as the gate, one final review. If superpowers stays installed for older models, this is the mode to point at, not SDD.
2. **Harness built-ins in this Claude Code build.** A `code-review` skill with effort levels (low…max) and `--fix`, and a `simplify` skill. Together they could stand in for the single end-of-phase review without any plugin. Plan mode is also available, which pcvelz bans.
3. Matt's README names **GSD, BMAD and Spec-Kit** as the "own the process" frameworks it positions against. These are heavier, not lighter, and were not examined.

---

## Fit for Spire

Scores run from 1 (bad) to 5 (good) for Spire's goal: lean execution on Opus 5.5 with distilled design, plan and handoff guidance.

| Criterion | pcvelz fork | Upstream v7 (SDD default) | Upstream v7 (Native path) | Matt Pocock skills |
|---|---|---|---|---|
| Token cost | 2. Same seat count, cheaper models per seat; large always-on prose (plans ~3.6k words, SDD ~5.5k) | 1. 2–12 dispatches per task plus final review | 4. One context plus one final review | 5. Tiny skills, user-invoked, nothing auto-loaded |
| Gate/review overhead | 1. Adds hook gates; the review loop is the declared default | 1. Per-task review, 5-round loop, re-reviews | 3. TDD per task, completion contract, ledger scripts, full-suite green | 4. One two-axis review; the grilling gate can be long (no cap, by design) |
| Scope discipline | 1. Nothing new; user-gates push toward more work | 2. Review Focus and "silence is not permission" widen scope; rulings ledger helps visibility | 2. Same plan format (Review Focus) and same final reviewer prompt | 4. Spec reviewer flags unrequested behaviour; Out of Scope section; vertical slices. No rule for what happens next |
| Design guidance | 3. Upstream v6.3 brainstorming plus tasks | 4. v7 brainstorming is good (sizing, playback, builder check) but heavy | (same as SDD column) | 4. `grilling` is excellent for alignment; `to-spec` template is light; ADR and glossary discipline is a plus |
| Plan guidance | 2. Old full-code plans plus metadata ceremony | 4. v6.4.2 "plan records decisions" plus Interfaces blocks is the best plan *format* here | (same) | 3. Tickets (vertical slices, blocking edges, AC). No interfaces or verify commands |
| Handoff/journal guidance | 3. Architect-consultation link and `.tasks.json` resume are Claude-native ideas; no journals | 2. Ledger survives compaction but is deleted at finish | 2. Same | 2. `handoff` (to `/tmp`) plus phase-boundary tree; no journals |
| Maintenance risk | 1. Single maintainer, 3 releases behind, slowing, version collision, heavy bash hooks | 3. Active (v7 on 10-09), but churns fast and keeps re-deciding defaults | 3. Same repo | 4. Very active, curated, but closed to proposals; harness-agnostic by policy; deprecations happen (PRD skills) |
| Harness-awareness | 5. Deeply Claude-Code-native (Tasks, hooks, AskUserQuestion, agent chat) | 2. Cross-platform, with per-harness reference files | 2 | 1. Deliberately harness-neutral (only `claude-handoff`, still in progress) |

**Reading the table for Spire's decision:**

- Don't adopt the pcvelz fork. Mine three of its ideas instead: the `json:metadata` and `.tasks.json` cross-session resume pattern; the executor consulting the plan author via `ListAgents`/`SendMessage`; and model-tier tags on tasks (as advisory notes, not hook gates).
- Treat the upstream v6.4.2 plan format ("a plan is the set of decisions the implementer cannot make alone"; Interfaces blocks; the proportion check) as the best plan-writing reference. **Drop** Review Focus and the "spec's silence is not permission" reviewer clause, because they are the scope-creep vectors.
- Take Matt's `grilling` primitive (frontier rounds, a recommended answer per question, facts looked up by the agent and decisions left to the user) as the core of Spire's design step. Take `domain-modeling`'s ADR triple-test, and `to-tickets`' vertical-slice and expand–contract rules for plan slicing.
- Handoffs and journals have to be Spire's own; no option supplies them. Matt's phase-boundary tree is a good input for the "when to hand off" rule.
- Spire's existing `plugins/spire/skills/implementation/SKILL.md` (large blocks, a cheap gate between them, one review per phase, fix once, stop) is already leaner than every execution path surveyed here.

## Could not verify

- Repo stats (stars, forks, issues, PRs) come from one WebFetch page scrape; `gh api` was denied. They were not cross-checked.
- The contents of the fork's issue tracker and discussions were not read, so community reception and bug reports are unknown. Whether pcvelz plans to merge upstream v6.4.x/v7.0.0 is unknown.
- No empirical token or cost measurements were run. Cost statements come from the repos' own docs and release notes plus dispatch counting.
- No Rust-specific behaviour of any option was tested. None of the three repos contains Rust-specific guidance.
- The Claude Code facts the fork claims (task tools disabled by default since 2.1.233; `TaskGet` not returning `metadata`) were not verified against harness docs.
- The `mattpocock-skills@claude-plugins-official` install path was not verified.
- The contents of Matt's `skills/deprecated/` were not inspected beyond a README stub.