22 KiB
Superpowers Skills Review — Direct Utilization in Manual Slop
Status: Research-only review (2026-06-19). Tier 1 Orchestrator sole-author. Sibling to nagent_review_20260608 and fable_review_20260617.
Scope: 14 superpowers-plugin skills + 5 project MMA skills + dual-convention + anything else.
Verdict taxonomy: Hybrid (primary: PARITY/PARTIAL/GAP/ARCH-DIFF/SUBSUMED; integration tag: INTEGRATED/INTEGRATE-PARTIAL/INTEGRATE/REJECT-WITH-REASON/N/A).
Plugin version: [recorded at start of Phase 2]
Project commit: [recorded at start of Phase 2]
0. TL;DR + How to Read This Report
[Section 0 — written at the END after all 16 sections + side artifacts are complete; for now: <!-- written in Phase 7 -->]
1. Using Superpowers
1. Using Superpowers
1.1 What the skill prescribes
The using-superpowers skill establishes the foundational "skill before action" discipline: invoke the Skill tool to load a relevant skill BEFORE any response or action — including clarifying questions. The skill's red-flag table is explicit: rationalizing that a skill is "overkill," "I'll just check files quickly," or "I'll gather information first" is a STOP signal. The skill flow is: receive message → check if any skill applies (even at 1%) → invoke the Skill tool → follow the skill exactly. Instruction priority is also locked: user instructions > skills > default system prompt.
1.2 Mapping to the project's existing pattern
Manual Slop's agent-directive corpus already encodes this discipline, but via file reads rather than a Skill tool:
| Superpowers rule | Project equivalent | Where |
|---|---|---|
| "Skill before action" | "Session Start Checklist (MANDATORY)" — block progress until checklist is complete | conductor/workflow.md §"Session Start Checklist" |
| "Read the rules first" | AGENTS.md is the top-level entry point; it's literally the first file any agent reads | AGENTS.md:1 ("Manual Slop is a local GUI orchestrator...") |
| "User instructions take precedence" | CLAUDE.md says "this project is no longer actively used with Claude Code. For project context, see AGENTS.md. The conductor system in ./conductor/ is the cross-tool abstraction and works with any agent toolchain." | CLAUDE.md:1 |
| "Invoke skill, don't rationalize" | Hard ban list (git restore, git stash, day estimates, opaque types) — "If you think you need one, ASK FIRST." | AGENTS.md "Critical Anti-Patterns" |
The 12-item Session Start Checklist (conductor/workflow.md §"Session Start Checklist") includes reading AGENTS.md, conductor/workflow.md, conductor/tech-stack.md, conductor/product.md, conductor/product-guidelines.md, the data-oriented design styleguide, the Python styleguide, the type-aliases styleguide, the error-handling styleguide, the relevant docs/guide_*.md, and conductor/tracks.md. This is the project's "skills catalog" — file-based rather than tool-based.
1.3 Gaps
- No explicit "skill check before action" prompt in the Session Start Checklist. The checklist is exhaustive but procedural; it doesn't say "announce which skill(s) you are invoking." For an OpenCode-based workflow this is fine (the user's session-start message itself triggers the mma-orchestrator + tier-1 skills per the skill activation protocol in
conductor/workflow.md§"Conductor Token Firewalling"). For ad-hoc use of an agent in a fresh context, the checklist could explicitly include "announce which superpowers/agent skill(s) you are invoking" as item 13. - The skill file (
SKILL.md) is a Claude Code concept. Other environments (Gemini CLI, raw GPT) don't have a Skill tool. The project's file-based pattern is more portable. This is not a gap per se, but an architectural observation. - AGENTS.md is mandatory read; the conductor styleguides are mandatory read;
docs/guide_*.mdis "consult as relevant." The skill hierarchy (skill > skill > skill) doesn't fully map to the project's tier-of-mandatory-ness. Section 16 (dual-convention) flags this.
1.4 Recommendation summary
The project follows the discipline. No code/spec changes recommended. The deferred rebuild may want to add the "announce which skill(s)" prompt to the Session Start Checklist for fresh-context agents.
Verdict.
| Field | Value |
|---|---|
| Primary | PARITY |
| Integration tag | INTEGRATED |
| Section size | brief |
| Cross-refs | nagent_review_20260608 §3.6 (instruction priority), fable_review_20260617 §14 ("Anti-User Watchdog Patterns") |
Rationale. The project's Session Start Checklist + AGENTS.md + conductor/.md + docs/guide_.md pipeline is the file-based equivalent of the superpowers Skill tool. Both enforce "rules before action." The project already includes instruction priority (CLAUDE.md > AGENTS.md > system prompt) and a 12-item mandatory checklist.
Recommended change. (blank — no rebuild action.)
2. Brainstorming
2. Brainstorming
2.1 What the skill prescribes
The brainstorming skill is the HARD-GATE entry point for any creative work. The skill's anti-pattern table is unambiguous: "This is too simple to need a design" is itself a design failure. The 9-step checklist is:
- Explore project context (files, docs, recent commits)
- Offer visual companion (own message; only if visual questions ahead)
- Ask clarifying questions (one at a time; multiple-choice preferred)
- Propose 2-3 approaches with trade-offs
- Present design in sections scaled to complexity; user approves each
- Write design doc to
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md - Spec self-review (placeholder scan, internal consistency, scope check, ambiguity check)
- User reviews the written spec
- Invoke writing-plans skill (the only terminal state)
The skill's process flow is a strict DAG with writing-plans as the only exit. It explicitly forbids jumping to frontend-design, mcp-builder, or any other implementation skill directly.
2.2 Mapping to the project's existing pattern
The project's spec convention is the conductor/track convention (conductor/tracks/<id>/spec.md), not the superpowers default (docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md). This is per user directive Q4 = A (see metadata.json format_choice). The structure of the project's specs is highly aligned with the brainstorming skill's requirements, though:
| Brainstorming requirement | Project equivalent | Where |
|---|---|---|
| "Explore project context first" | Tier 1 Track Initialization Rules §"Audit Before Specifying" (per conductor/workflow.md) — mandatory py_get_code_outline + py_find_usages + get_git_diff before writing requirements |
conductor/workflow.md §"Tier 1 Track Initialization Rules" |
| "Ask clarifying questions, one at a time" | The "Planning Session Workflow" in workflow.md §"Planning Session Workflow" prescribes brainstorming with multiple-choice preferred; the spec for this track was authored via such a dialogue | conductor/workflow.md §"Planning Session Workflow" |
| "Propose 2-3 approaches with trade-offs" | The "Propose 2-3 approaches" step is part of the brainstorming skill; the project's Tier 1 spec template §3 "Goals" includes "approach comparisons" implicitly via the priority-ordered goals | Spec template (this file's parent structure) |
| "Spec self-review" (placeholder scan, internal consistency, scope check, ambiguity check) | The Tier 1 Track Initialization Rules §1 "Spec format" mandates these checks; the workflow's "Phase Completion Verification and Checkpointing Protocol" includes self-review | conductor/workflow.md §"Tier 1 Track Initialization Rules" |
| "User reviews written spec before proceeding" | The "Planning Session Workflow" §5 explicitly says "User reviews the spec. Revise until approved. The spec MUST be approved before the plan is written. A plan for an unapproved spec is wasted effort." | conductor/workflow.md §"Planning Session Workflow" |
| "Invoke writing-plans as the only terminal state" | The workflow's "Planning Session Workflow" says "After spec approval, write plan following writing-plans skill" | conductor/workflow.md §"Planning Session Workflow" |
2.3 Where the project already follows the brainstorming discipline
- All four sibling review tracks (
nagent_review_20260608,fable_review_20260617,intent_dsl_survey_20260612, this track) followed the brainstorming discipline: each has a spec.md with explicit "Current State Audit" sections citing file:line references, "Goals" sections in priority order, "Architecture Reference" sections linking to existing docs, and "Out of Scope" sections. This is the conductor convention's equivalent of the brainstorming checklist. - The
conductor/workflow.md"Planning Session Workflow" is itself a project-specific re-encoding of the brainstorming skill, with the conductor-specific twist that the spec is committed (per-file atomic) before the plan is written. - The "User reviews written spec before proceeding" gate is enforced: every track on the project has spec + plan pairs that were user-approved (per the
tracks.mdrows with "spec ✓, plan ✓, ready to start" status).
2.4 Where the project doesn't follow the discipline
- "Offer visual companion (own message)" — not used. The project's brainstorming happens via inline text dialogue in the session, not via a separate browser-based message. This is a Claude Code feature (the visual companion is a browser-based UI); OpenCode does not have an equivalent. ARCH-DIFF: the project's text-only brainstorming is functionally equivalent for non-visual features but cannot mock up UI affordances interactively.
- "Multiple-choice preferred" — partially used. The
intent_dsl_survey_20260612/spec.md§3.1 shows the project does use multiple-choice ("Use A / Use B / Use C" style questions), but this track's spec.md does not have visible multiple-choice answers; the questions are open-ended with the user picking the approach in their direct response. - "No jumping to implementation before spec approval" — partially enforced. The workflow.md §"Task Workflow" starts with "Initialize MMA Environment" before "Select Task"; this presumes the spec is approved. But the project has had agents start coding in response to user requests without going through the spec-first pattern (e.g., quick fixes, follow-up tracks). The pattern is enforced for new tracks, not for one-off edits.
- "Section self-review is 4 specific checks (placeholder, internal consistency, scope, ambiguity)" — partially followed. The brainstorming skill's self-review is a 4-item checklist; the project's equivalent is the workflow's "Phase Completion Verification and Checkpointing Protocol" §2 which is more elaborate (5+ checks per phase). The project goes deeper than the skill here.
- "Default location
docs/superpowers/specs/" — explicitly overridden by user choice. This is the dual-convention topic flagged in Section 16.
2.5 Recommendations summary
The project follows the brainstorming discipline. The dual-convention question (docs/superpowers/specs/ vs conductor/tracks/<id>/spec.md) is the only major surface difference, and it's a user-chosen override. The deferred rebuild may want to:
- HIGH: Add a "spec-first is mandatory for any creative work" prompt to the Session Start Checklist (item 13), explicitly calling out the "no jumping to implementation" rule. The project enforces this for new tracks; making it explicit for ad-hoc edits would close the partial-coverage gap.
- MEDIUM: Add a "multiple-choice preferred" guidance note to the spec template. The pattern exists in some specs; codifying it would reduce open-ended-question ambiguity.
- LOW: Consider adding a visual-companion equivalent for the next time the project does UI work. This is environmental (Claude Code feature), not a project-level change.
Verdict.
| Field | Value |
|---|---|
| Primary | PARTIAL |
| Integration tag | INTEGRATE-PARTIAL |
| Section size | deep-dive |
| Cross-refs | nagent_review_20260608 §3 (the durable-work thesis is the meta-design philosophy behind brainstorming); fable_review_20260617 §3 (Fable's product branding vs the project's "honest about gaps" approach); intent_dsl_survey_20260612 §1 (the survey was brainstormed using this discipline) |
Rationale. The project's spec + plan + conductor/track convention is a faithful re-encoding of the brainstorming skill, with three gaps: (a) ad-hoc edits can skip the spec-first gate; (b) the "offer visual companion" rule is environmentally unavailable; (c) the multiple-choice preference is used inconsistently across specs.
Recommended change. Add a "spec-first is mandatory for any creative work" prompt to the Session Start Checklist (item 13); add a "multiple-choice preferred" guidance note to the spec template; defer the visual-companion question to the deferred rebuild (it's an environment question, not a project question).
3. Writing Plans
3. Writing Plans
3.1 What the skill prescribes
The writing-plans skill is the executable counterpart to brainstorming. It assumes the engineer has zero context for the codebase and questionable taste. The skill's bite-sized granularity rule is the load-bearing constraint: "Each step is one action (2-5 minutes)." A plan with vague steps ("implement the feature", "write tests", "add error handling") is a plan failure; the skill enumerates these as forbidden placeholder patterns. The plan header is mandatory (Goal / Architecture / Tech Stack), and the self-review is a 3-check inline pass: (1) spec coverage, (2) placeholder scan, (3) type consistency. The execution handoff offers two choices: subagent-driven (fresh subagent per task with two-stage review) or inline execution (batch with checkpoints).
3.2 Mapping to the project's existing pattern
The project's conductor/workflow.md §"Task Workflow" is a project-specific re-encoding of writing-plans, with 12 steps vs the skill's 5-step Task Structure template:
| writing-plans element | Project equivalent | Where |
|---|---|---|
| Plan header (Goal, Architecture, Tech Stack) | Every plan.md has a header section (Goal + Architecture + Tech Stack + Spec reference + Blocked-by); see e.g. this track's plan.md:3-16 |
conductor/tracks/<id>/plan.md (universal) |
| "Files: Create / Modify / Test" lists | The "Files" section in every Task N; exact paths always | Universal |
| "Step 1: Write failing test" | "Step 4: Write Failing Tests (Red Phase)" — the "Pre-Delegation Checkpoint" sub-step adds a stage/commit rule | conductor/workflow.md §"Task Workflow" step 4 |
| "Run it to make sure it fails" | "CRITICAL: Run the tests and confirm that they fail as expected. This is the 'Red' phase of TDD. Do not proceed until you have failing tests." | conductor/workflow.md §"Task Workflow" step 4 |
| "Implement the minimal code to make the test pass" | "Implement to Pass Tests (Green Phase)" — also requires tier-3-worker delegation | conductor/workflow.md §"Task Workflow" step 5 |
| "Commit" | "9. Commit Code Changes: CRITICAL - ATOMIC PER-TASK COMMITS" | conductor/workflow.md §"Task Workflow" step 9 |
| "Self-Review" | "Phase Completion Verification and Checkpointing Protocol" — much more elaborate than the skill's 3-check self-review; includes automated tests, API hooks, user confirmation | conductor/workflow.md §"Phase Completion Verification" |
| "Execution Handoff" | "Verify via API Hooks" + the live_gui fixture convention for integration tests | conductor/workflow.md §"Verification via API Hooks" |
3.3 Where the project already follows the discipline
- Every track on the project has a plan.md with bite-sized steps. Examples:
nagent_review_20260608/plan.md(research-style plan with report sections as tasks),fable_review_20260617/plan.md(research-style plan with cluster sub-agent dispatches as tasks),data_oriented_error_handling_20260606/plan.md(refactor-style plan with audit-script updates as tasks). All three have tasks with concrete file:line references and verification steps. - Per-file atomic commits + git notes. This is the project's strict convention (
conductor/workflow.md§"Task Workflow" step 9 + step 10); the writing-plans skill's "Commit" step is augmented with the "Attach Task Summary with Git Notes" step. The project goes deeper than the skill here. - "No placeholders" rule. The workflow.md's "Plan format" section explicitly bans vague tasks; the project's plans are uniformly bite-sized. The skill's forbidden patterns ("TBD", "TODO", "implement later", "fill in details") are also forbidden in the project.
- The "exact file paths always" rule is enforced; every plan task lists exact file:line references (e.g., this track's plan.md §"Phase 2 Task 5" cites
C:\Users\Ed\.cache\opencode\packages\superpowers@git+https_\github.com\obra\superpowers.git\node_modules\superpowers\skills\brainstorming\SKILL.md). - The "DRY, YAGNI, TDD, frequent commits" maxims are present in both skill and project; the project's added maxims are "1-space indentation" and "no day estimates" (per
conductor/workflow.md§"Code Style" + §"Tier 1 Track Initialization Rules").
3.4 Where the project doesn't follow the discipline
- The skill's "Subagent-Driven (recommended)" execution path is NOT the project's default. The project's tier model is hierarchical (4 tiers: orchestrator, tech-lead, worker, qa) and the tier-3-worker dispatch is via OpenCode Task tool (per
conductor/workflow.md§"Conductor Token Firewalling"). The skill's "fresh subagent per task" pattern is the tier-3-worker pattern; the project's tier-2 tech-lead maintains persistent context. This is ARCH-DIFF (architectural difference): the project uses a more elaborate hierarchy than the skill's flat 2-option menu. - "Visual Companion offer (own message)" — not applicable to plan-writing (it's a brainstorming skill, not a writing-plans skill).
- The skill's "subagent-driven" recommendation requires a subagent-capable platform. The project's tier-3 workers run via OpenCode's subagent system; not all environments have this. The project's tier-2 in-line execution path is the fallback; the skill's "inline execution" is the fallback too, but the project lacks the skill's "two-stage review" between subagent and continuation (the project uses Tier 4 QA agents for failure analysis).
- The "Code Style: 1-space indentation for Python" reminder is in the project's tier-3-worker dispatch prompt per
conductor/workflow.md§"Task Workflow" step 4 + step 5 ("ALWAYS explicitly mention 'Use exactly 1-space indentation for Python code' when prompting a sub-agent"). The skill does not have this — Python-style is environment-specific.
3.5 Recommendations summary
The project follows the discipline with one architectural difference (4-tier hierarchy vs 2-option menu) and three elaborations (per-file atomic commits + git notes; "no day estimates"; "1-space indentation" reminder for tier-3 workers). The deferred rebuild may want to:
- LOW: Add a note to
conductor/workflow.md§"Task Workflow" that the "Subagent-Driven" option maps to "Tier 3 worker per task + Tier 4 QA on failure" (the project's tiered equivalent). This is a naming-bridge, not a behavior change. - LOW: Codify the "1-space indentation" reminder in a tier-3-worker dispatcher template (
.agents/skills/mma-tier3-worker/SKILL.mdalready has this as a hard rule per the skill content). Currently the reminder is in workflow.md + dispatch prompt, not in the skill itself. The deferred rebuild could move it.
Verdict.
| Field | Value |
|---|---|
| Primary | PARITY |
| Integration tag | INTEGRATED |
| Section size | deep-dive |
| Cross-refs | nagent_review_20260608 §3 (the durable-work thesis shapes how plans are written — bite-sized, atomic, recoverable); fable_review_20260617 §3 (the cluster-sub-agent dispatch pattern is a writing-plans innovation the project already uses for research tracks); intent_dsl_survey_20260612 §3 (the survey plan uses tier-3-worker dispatches for cluster research, mirroring the skill's subagent-driven option) |
Rationale. The project's 12-step task workflow is a faithful elaboration of writing-plans. Every required element (header, Files section, bite-sized steps, self-review, no placeholders) is present. The architectural difference (4-tier hierarchy vs 2-option menu) is a project-specific design that subsumes the skill's option; the project uses tier-3 workers (the skill's subagent option) plus tier-4 QA (extra) plus tier-2 persistent context (extra).
Recommended change. (blank — no rebuild action. The project is in alignment.)