Files

T

Gabor Körber 8028411cbb 📝 Document Spire planning research and 0.2.2 decisions

2026-10-15 21:31:07 +02:00

30 KiB

Raw Permalink Blame History

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):

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.
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".
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.
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").
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.
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.
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.
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.
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.

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)

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.
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.
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.

30 KiB Raw Permalink Blame History Unescape Escape