What it does well that yours lacks:
using-superpowers bootstrap + session-start injection. A skill injected at session start (and re-injected after compaction) whose core is the rationalization red-flags table — twelve "thought → reality" pairs neutralizing the exact excuses models use to skip process ("this is too simple," "let me explore first," "I remember this skill — skills evolve, read the current version"). [content] for the table itself → paste into your build prompt or a small always-loaded doc, ~30 minutes. [mechanics] for the injection: needs an OpenCode plugin hook — but Superpowers ships a working OpenCode plugin doing exactly this, so the mechanism is copyable rather than inventable. This is the highest-value adoption in the entire comparison set for your 🔧 goal.executing-plans and subagent-driven-development. The two missing execution-orchestration skills (§1.6.1): batch-with-human-checkpoints vs fresh-subagent-per-task with two-stage review (spec compliance, then code quality) and explicit failure handling. [content] — direct port, rename reviews to your @code-review/verification vocabulary. This is your biggest pipeline gap closed for a day's work.using-git-worktrees + finishing-a-development-branch. Isolated worktree per feature (clean test baseline before work starts) and a disciplined branch-completion flow (verify tests → present merge/PR/keep/discard → cleanup). Both fit your feat/<user>-<hash>-<desc> convention and your no-squash policy naturally. [content].receiving-code-review. How to respond to review feedback without over-complying or thrashing — the complement your tool-driven @code-review lacks (you generate findings; nothing governs consuming them). [content], small.- A real harness test suite.
tests/ covers plugin loading, skill priority, explicit-skill-request handling, per-platform behavior — including an opencode/ suite with shell scripts driving real sessions. This is the working model for turning your Phase-1 eval skeleton into something executable. [content + light mechanics] (shell scripts against opencode run).
Checked and not lacking: your brainstorming/writing-plans/verification match or exceed current upstream in rigor (fast-path, Interfaces block, verdict template); your @debug content is deeper than systematic-debugging (once its permissions are fixed); your permission model and validate-harness CI have no upstream equivalent.
Satellites, briefly: superpowers-marketplace is Claude Code distribution metadata — not applicable; the pattern of a curated multi-plugin index is only relevant if you someday ship multiple plugins. superpowers-skills is the community-editable skill library auto-cloned to a user directory — the engine/content split is the interesting idea: if your template gets adopters, splitting .opencode/skills/ process skills into a separately-updatable repo lets downstream projects pull skill updates without re-templating 🌍 (defer until there are adopters). superpowers-developing-for-claude-code ships a vendored-official-docs skill with a self-update script (42 doc files + fetch script + quick-reference table, progressive disclosure) — port the pattern as an opencode-docs skill mirroring opencode.ai/docs, so agents stop guessing OpenCode config semantics (your /research currently fills this gap expensively). [content + small script]. superpowers-lab: finding-duplicate-functions (two-phase semantic-duplication detection — classical extraction, then LLM intent-clustering) is portable [content] and pairs well with /improve-architecture's deletion-test; mcp-cli is low relevance to your stack today.
What it does well that yours lacks:
using-superpowersbootstrap + session-start injection. A skill injected at session start (and re-injected after compaction) whose core is the rationalization red-flags table — twelve "thought → reality" pairs neutralizing the exact excuses models use to skip process ("this is too simple," "let me explore first," "I remember this skill — skills evolve, read the current version"). [content] for the table itself → paste into your build prompt or a small always-loaded doc, ~30 minutes. [mechanics] for the injection: needs an OpenCode plugin hook — but Superpowers ships a working OpenCode plugin doing exactly this, so the mechanism is copyable rather than inventable. This is the highest-value adoption in the entire comparison set for your 🔧 goal.executing-plansandsubagent-driven-development. The two missing execution-orchestration skills (§1.6.1): batch-with-human-checkpoints vs fresh-subagent-per-task with two-stage review (spec compliance, then code quality) and explicit failure handling. [content] — direct port, rename reviews to your@code-review/verificationvocabulary. This is your biggest pipeline gap closed for a day's work.using-git-worktrees+finishing-a-development-branch. Isolated worktree per feature (clean test baseline before work starts) and a disciplined branch-completion flow (verify tests → present merge/PR/keep/discard → cleanup). Both fit yourfeat/<user>-<hash>-<desc>convention and your no-squash policy naturally. [content].receiving-code-review. How to respond to review feedback without over-complying or thrashing — the complement your tool-driven@code-reviewlacks (you generate findings; nothing governs consuming them). [content], small.tests/covers plugin loading, skill priority, explicit-skill-request handling, per-platform behavior — including anopencode/suite with shell scripts driving real sessions. This is the working model for turning your Phase-1 eval skeleton into something executable. [content + light mechanics] (shell scripts againstopencode run).Checked and not lacking: your brainstorming/writing-plans/verification match or exceed current upstream in rigor (fast-path, Interfaces block, verdict template); your
@debugcontent is deeper thansystematic-debugging(once its permissions are fixed); your permission model and validate-harness CI have no upstream equivalent.Satellites, briefly: superpowers-marketplace is Claude Code distribution metadata — not applicable; the pattern of a curated multi-plugin index is only relevant if you someday ship multiple plugins. superpowers-skills is the community-editable skill library auto-cloned to a user directory — the engine/content split is the interesting idea: if your template gets adopters, splitting
.opencode/skills/process skills into a separately-updatable repo lets downstream projects pull skill updates without re-templating 🌍 (defer until there are adopters). superpowers-developing-for-claude-code ships a vendored-official-docs skill with a self-update script (42 doc files + fetch script + quick-reference table, progressive disclosure) — port the pattern as anopencode-docsskill mirroring opencode.ai/docs, so agents stop guessing OpenCode config semantics (your/researchcurrently fills this gap expensively). [content + small script]. superpowers-lab:finding-duplicate-functions(two-phase semantic-duplication detection — classical extraction, then LLM intent-clustering) is portable [content] and pairs well with/improve-architecture's deletion-test;mcp-cliis low relevance to your stack today.