Superpowers 6.3.0: what is actually covered before it is uninstalled

• Run: 2026-08-28, read from ~/.claude/plugins/cache/claude-plugins-official/superpowers/6.3.0.
• Why: the parked row justified uninstalling on the premise that "the repo-native replacements already exist: code-review-rigor, tdd and verified-done all say they were harvested from it." That covers 3 of 14 skills. This maps the other eleven before anything is removed.
• Read, not title-matched. Every row below is against the skill's own description and, where the answer was not obvious, its content. A title match is not a coverage match.

The headline: nothing substantive is lost, and two of them are things this repo actively does NOT want

Eleven of the fourteen are covered, self-referential, or contrary to house rules. One is a real gap and it is small. Two are partial and the partial half is covered elsewhere.

The map

Superpowers skill	Repo-native cover	Verdict
verification-before-completion	verified-done	Covered. Says it was harvested from this one
test-driven-development	tdd	Covered. Same, harvested
receiving-code-review	code-review-rigor	Covered. Same, harvested
systematic-debugging	debug	Covered. Repo-native, and carries this codebase's own instrument gotchas, which the generic one cannot
using-git-worktrees	worktree	Covered, and the repo version is stronger. It carries rules 14, 15 and 17 and the branch guard, which is the part that actually matters here
writing-plans	planning	Covered. Plus docs/planning/ conventions the generic skill knows nothing about
finishing-a-development-branch	session-pr + pr-workbench	Covered. One PR per session and the merge gate are house rules the generic skill would contradict
requesting-code-review	pr-workbench, plus AGENTS.md rule 21	Covered. Rule 21 is stricter: a senior engineer other than the author approves, and opening the PR is not the notification
using-superpowers	none needed	Self-referential. It exists to teach an agent to use the plugin's own skills. Removing the plugin removes the thing it points at
dispatching-parallel-agents	none, deliberately	CONTRARY TO HOUSE RULES. AGENTS.md is explicit that she dispatches every session and an agent never spawns one. Its absence is a gain
subagent-driven-development	none, deliberately	Same. "You only write the prompts. Unless I tell you to run the session yourself, you NEVER delegate"
executing-plans	partial: the agenda and project-manager	Partial, covered in practice. Executing a plan with review checkpoints is what the daily agenda and its task blocks already are
brainstorming	partial: planning, plus the brainstorm.md convention	Partial. planning starts at scoping; exploring intent BEFORE that is done in a project's brainstorm.md, which is a convention rather than a skill
writing-skills	nothing	THE ONE REAL GAP. See below

The one real gap, and why it is smaller than it looks

Nothing in the repo covers the craft of writing or editing a skill. self-improve covers the decision (which layer does this belong in, and it must be proposed rather than applied), and it names the mechanics (edit .agents/skills/<name>/skill.md, never the synced copy, then npm run sync:skills). What it does not cover is what a good skill looks like.

Three things already carry most of that weight, which is why this is a gap rather than a hole:

• .agents/rules/project/writing-into-documents.md owns the document shape, and it is stricter than the generic skill: sections are questions, every claim becomes a heading, and every template in a file changes in the same edit as the prose.
• docs/projects/agent-workflow-hierarchy/design.md owns the routing test for which layer a piece of guidance belongs in.
• self-improve owns when a learning graduates and who approves it.

So the missing piece is narrow: no single place says how to write the skill itself once you know it belongs in one. That is worth a small repo-native skill eventually, and it is not a reason to keep a 14-skill plugin installed.

What the hooks/ and scripts/ directories actually do

Nobody had looked, and the answer is that neither does anything for this repo.

hooks/ is ONE hook, and it is self-referential.

hooks.json registers a single SessionStart hook on startup|clear|compact. All it does is read skills/using-superpowers/SKILL.md and inject it into context wrapped in <EXTREMELY_IMPORTANT>.

It reads no repo state, writes nothing, and touches no file. Removing the plugin removes an injection of the plugin's own introduction, which is exactly as circular as it sounds. Nothing in Lantern depends on it.

scripts/ are the plugin's OWN maintenance scripts.

bump-version.sh, sync-to-codex-plugin.sh, package-codex-plugin.sh, lint-shell.sh. They are for developing and releasing the plugin, not for anything a consumer runs. None is referenced anywhere in this repo.

Recommendation

Proceed with the uninstall. The premise was incomplete but the conclusion holds, and it holds more strongly than the parked row argued: two of the fourteen actively contradict house rules about who dispatches agents, and the hook is circular.

One follow-up worth filing rather than doing now: a small repo-native skill covering how to write a skill, pointing at the three pieces that already exist rather than restating them.

What this map does NOT settle

• Whether anything outside this repo uses the plugin. This checks Lantern. Her other projects share the same user-level Claude configuration, and a plugin uninstall is global rather than per-repo.
• The uninstall itself is a change to ~/.claude/settings.json, which is her user-level configuration and this session's own config. That needs her word directly rather than a relay, and is not done here.