manual_slop/conductor/tracks/superpowers_review_20260619/report.md

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_*.md is "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:

1. Explore project context (files, docs, recent commits)
2. Offer visual companion (own message; only if visual questions ahead)
3. Ask clarifying questions (one at a time; multiple-choice preferred)
4. Propose 2-3 approaches with trade-offs
5. Present design in sections scaled to complexity; user approves each
6. Write design doc to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
7. Spec self-review (placeholder scan, internal consistency, scope check, ambiguity check)
8. User reviews the written spec
9. 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.md rows 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.md already 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.)

4. Test-Driven Development

4. Test-Driven Development

4.1 What the skill prescribes

The test-driven-development skill is rigid — explicitly classified as "Rigid (TDD, debugging): Follow exactly. Don't adapt away discipline" per the skill's self-classification. The Iron Law is unambiguous: "NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST." Violating the letter of the rules is violating the spirit of the rules. The Red-Green-Refactor cycle is the only acceptable flow: RED (write failing test) → Verify RED (watch it fail correctly) → GREEN (minimal code to pass) → Verify GREEN (all green) → REFACTOR (clean up, keep tests green) → Next. The skill's "common rationalizations" table is exhaustive ("Too simple to test", "I'll test after", "Deleting X hours is wasteful", "TDD is dogmatic, being pragmatic means adapting") with explicit counters. The verification checklist is mandatory: every function has a test, watched each test fail, minimal code to pass, all tests pass, output pristine, real code (not mocks), edge cases covered.

4.2 Mapping to the project's existing pattern

The project has TDD as a load-bearing discipline with extensive elaboration. The project's TDD enforcement is multi-layered:

TDD skill rule	Project equivalent	Where
Iron Law: no production code without failing test	conductor/workflow.md §"Task Workflow" step 4 "Write Failing Tests (Red Phase)": "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 step 4
Red-Green-Refactor cycle	Same — step 4 = Red, step 5 = "Implement to Pass Tests (Green Phase)", step 6 = Refactor (optional but recommended)	conductor/workflow.md steps 4-6
"Watch it fail"	Explicit: "Run the tests and confirm that they fail as expected"	conductor/workflow.md step 4
"No exceptions without partner permission"	AGENTS.md Critical Anti-Patterns: "Do not skip TDD - write failing tests before implementing functionality"	AGENTS.md "Critical Anti-Patterns"
"Delegation: tier-3 worker writes the test"	conductor/workflow.md step 4 + step 5: "Delegate Test Creation: Do NOT write test code directly. Spawn a Tier 3 Worker via the OpenCode Task tool with subagent_type: 'tier3-worker' and a surgical prompt specifying WHERE (file:line range), WHAT (test to create), HOW (which assertions/fixtures to use), and SAFETY (thread constraints if applicable)."	conductor/workflow.md steps 4-5
"Mocking anti-patterns"	conductor/product-guidelines.md "Testing Requirements" → "Structural Testing Contract": "Ban on arbitrary core mocking with unittest.mock.patch (unless explicitly authorized for a specific boundary test). All integration and end-to-end testing must use the live_gui fixture."	conductor/product-guidelines.md "Testing Requirements"
"Verification Checklist" (test fails for expected reason, etc.)	conductor/product-guidelines.md "Quality Gates" + the Phase Completion Verification and Checkpointing Protocol	conductor/workflow.md "Phase Completion Verification"
"Skip markers are documentation, not avoidance"	conductor/workflow.md "Skip-Marker Policy" — explicit policy with review checklist; AGENTS.md "Do not use @pytest.mark.skip as an excuse to AVOID fixing the underlying bug"	conductor/workflow.md "Skip-Marker Policy" + AGENTS.md
"Debugging Integration: bug → write failing test reproducing it"	conductor/workflow.md "systematic-debugging" reference + the verification-before-completion pattern	conductor/workflow.md + AGENTS.md
"Live GUI testing" (the project's elaboration)	tests/conftest.py defines 7 conftest fixtures (isolate_workspace, reset_paths, reset_ai_client, vlogger, kill_process_tree, mock_app, live_gui); the live_gui fixture is session-scoped and uses the Hook API for end-to-end testing	tests/conftest.py + docs/guide_testing.md

4.3 Where the project already follows the discipline

• Every track on the project follows the Red-Green-Refactor cycle. Examples from the chronology: mcp_architecture_refactor_20260606 (Phase 1 = audit tests pass = baseline; Phase 2 = write new tests; Phase 3 = refactor; etc.); data_oriented_error_handling_20260606 (Phase 1 = baseline green; subsequent phases add tests before refactoring); default_layout_install_20260629 (Phase 1 = failing test for "panels invisible on empty INI"; subsequent phases = minimal fix).
• The "don't keep code as reference" rule is enforced. The user's cruft_elimination_20260627 track explicitly removed legacy code without TDD justification; the default_layout_install_followup_20260629 track added failing tests for stale INI handling.
• The "no mocks for core infrastructure" rule is enforced via the audit script scripts/audit_main_thread_imports.py (main-thread-purity invariant) and the Structural Testing Contract (live_gui standard).
• The "verification before completion" discipline is enforced via the Phase Completion Verification and Checkpointing Protocol (must run automated tests + API hooks + user confirmation before checkpoint).
• The 251 test files (per docs/guide_testing.md) are evidence of the project's TDD commitment.

4.4 Where the project doesn't follow the discipline

• "Throwaway prototypes" exception is acknowledged in the skill but the project doesn't have an explicit "prototype" affordance. The TDD skip is rare in the project; when it happens (e.g., the cruft_elimination_20260627 track's audit-script work), it's documented as an exception.
• "Generated code" exception — n/a for this project (no code generation from LLMs to runtime code).
• "Configuration files" exception — partially followed. TOML config changes (presets.toml, personas.toml, manual_slop.toml) are made without TDD in some tracks (e.g., presets_ai_settings_ux_20260311); the convention is that config changes don't need new tests if the existing config-loading tests still pass.
• "No exceptions without partner permission" — partially followed. The TDD skill's exception list is small ("Throwaway prototypes", "Generated code", "Configuration files") and each requires partner permission. The project has more flexible exception usage; the partner is the user, but the user doesn't have to give explicit permission for each config-file change.
• The skill's "Test passes immediately → you're testing existing behavior, fix test" rule has surfaced in the project as the isolation-pass verification fallacy (per conductor/workflow.md §"Isolated-Pass Verification Fallacy"): tests that pass in isolation but fail in batch. The project has a dedicated rule for this; the skill does not.

4.5 Recommendations summary

The project follows the TDD discipline strictly. The four elaborations (tier-3-worker delegation; live_gui standard; skip-marker policy; isolated-pass verification rule) go beyond the skill. The deferred rebuild may want to:

• LOW: Add a note to conductor/workflow.md §"Task Workflow" step 4 + step 5 that the "tier-3 worker dispatches the failing test" rule is the project's elaboration of the skill's "write the test first" rule. This is documentation, not a behavior change.
• LOW: Codify the "configuration files" exception explicitly. Currently the project applies this exception case-by-case; codifying the rule would reduce ambiguity.

Verdict.

Field	Value
Primary	PARITY
Integration tag	INTEGRATED
Section size	deep-dive
Cross-refs	nagent_review_20260608 §10 ("durable tests" — nagent's principle that tests are durable artifacts); fable_review_20260617 §13 ("Genuinely Useful Patterns" includes the project's testing discipline); intent_dsl_survey_20260612 §6 (the survey's "AI-agent properties" include the project's testing rigor)

Rationale. The project's 12-step task workflow + AGENTS.md "Critical Anti-Patterns" + Structural Testing Contract is a faithful re-encoding of the TDD skill with four project-specific elaborations. The iron law is enforced via step 4's "Do not proceed until you have failing tests" rule. The Red-Green-Refactor cycle is the workflow steps 4-6.

Recommended change. (blank — no rebuild action. The project is in alignment.)

5. Verification Before Completion

5. Verification Before Completion

5.1 What the skill prescribes

The verification-before-completion skill is rigid — same status as TDD. The Iron Law: "NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE." The Gate Function is a 5-step process: IDENTIFY (what command proves this claim?) → RUN (execute the FULL command fresh) → READ (full output, exit code, failure counts) → VERIFY (does output confirm the claim?) → ONLY THEN (make the claim). The skill's Common Failures table is the canonical list of what "verification" means: Tests pass = test command output (0 failures); Linter clean = linter output (0 errors); Build succeeds = build command (exit 0); Bug fixed = test original symptom (passes); Regression test works = red-green verified; Agent completed = VCS diff shows changes; Requirements met = line-by-line checklist.

The skill's Red Flags list the linguistic telltales: "should", "probably", "seems to"; expressing satisfaction before verification ("Great!", "Perfect!", "Done!"); about to commit without verification; trusting agent success reports; partial verification; "just this once"; tired and wanting work over; ANY wording implying success without verification.

The Rationalization Prevention table is exhaustive: "Should work now" → RUN; "I'm confident" → Confidence ≠ evidence; "Linter passed" → Linter ≠ compiler; "Agent said success" → Verify independently; "I'm tired" → Exhaustion ≠ excuse; "Different words so rule doesn't apply" → Spirit over letter.

5.2 Mapping to the project's existing pattern

The project has a multi-layered verification regime that goes beyond the skill's iron law:

Skill rule	Project equivalent	Where
"Tests pass" requires test command output	conductor/workflow.md §"Quality Gates" — "All tests pass"; the batched runner scripts/run_tests_batched.py provides tier-based filtering and parallelization	conductor/workflow.md + scripts/run_tests_batched.py
"Build succeeds" requires exit 0	conductor/tech-stack.md + pyproject.toml — but the project doesn't have a build step (interpreted Python), so verification is "tests + import-check + smoke run"	Project-wide
"Bug fixed" requires test of original symptom	conductor/workflow.md "systematic-debugging" reference + the project's "Bug found → write failing test reproducing it" rule (per TDD skill integration)	conductor/workflow.md
"Regression test works" requires red-green-red cycle	Project follows TDD strictly (per Section 4); red-green is enforced via the workflow's "Write Failing Tests" step	conductor/workflow.md §"Task Workflow" step 4
"Agent completed" requires VCS diff verification	conductor/workflow.md §"Conductor Token Firewalling" tier-4 QA dispatch — agents report failures, humans check VCS diffs	conductor/workflow.md
"Requirements met" requires line-by-line checklist	conductor/workflow.md §"Phase Completion Verification and Checkpointing Protocol" — automated tests + API hooks + user confirmation	conductor/workflow.md
"Express satisfaction before verification"	AGENTS.md "Critical Anti-Patterns" — implicit (the user calls out "Express satisfaction before verification" patterns; the docs use neutral language)	AGENTS.md
"About to commit/push/PR without verification"	The project's per-task atomic commits + git notes enforce this: every commit has a verification step in its plan.md task	conductor/workflow.md §"Task Workflow" step 9
"Trusting agent success reports"	Tier-4 QA agents are dispatched to summarize errors, not to claim success; the project's tier-3 worker success reports are checked via VCS diff	conductor/workflow.md §"Conductor Token Firewalling"
"Partial verification"	The Isolated-Pass Verification Fallacy rule (per conductor/workflow.md §"Isolated-Pass Verification Fallacy"): "A test that passes in isolation but fails in batch is failing — it's just that the failure is masked by isolation."	conductor/workflow.md
"Tired and wanting work over"	n/a — no explicit anti-rationalization table for this	—

5.3 Where the project already follows the discipline

• The Phase Completion Verification and Checkpointing Protocol is the project's verification gate. It runs (1) automated tests in batches (max 4 files at a time, with timeouts), (2) automated API hook verification, (3) presents results to the user for confirmation. This goes BEYOND the skill's "make the claim with evidence" by adding user confirmation.
• The Skip-Marker Policy is project-specific: @pytest.mark.skip is documentation of a known failure, not an excuse to avoid fixing. The skill doesn't have this discipline; the project's policy is that skip markers must document the underlying issue and the fix path.
• The Isolated-Pass Verification Fallacy rule is a project-specific elaboration: tests that pass in isolation but fail in batch are FAILING. The skill's Common Failures table says "Tests pass = Test command output: 0 failures" but doesn't address the isolation-vs-batch distinction.
• The "Verification before completion" AGENTS.md reference is implicit in the per-task atomic commits + git notes workflow: every commit has a verification step recorded in its plan.md task.

5.4 Where the project doesn't follow the discipline

• "Tired and wanting work over" is not explicitly addressed. The project's verification is procedural, not anti-rationalization. This is a softer gap; in practice the user catches it.
• The skill's "Trusting agent success reports" rule is partially addressed by the tier-4 QA dispatch pattern, but tier-3 workers are trusted to commit code without per-task human review (per conductor/workflow.md §"Task Workflow" step 5). The project uses tier-2's per-task git notes as the verification artifact, but the user doesn't approve each task before the next starts.
• The skill's "ANY wording implying success without verification" rule is enforced by the project's reporting style (neutral language in commits + git notes), but there's no audit that flags overly-satisfied phrasing.
• "Verify Fix Worked" (Phase 4 of systematic-debugging) maps to "run tests after fix" but the project doesn't have a dedicated verification step that says "verify the original symptom is gone" — it relies on the test suite as the proxy.

5.5 Recommendations summary

The project follows the discipline with significant elaborations (Phase Completion Verification, Skip-Marker Policy, Isolated-Pass Verification Fallacy). The deferred rebuild may want to:

• MEDIUM: Add a "verification ritual" anti-rationalization table to conductor/workflow.md §"Task Workflow" step 9 ("Commit Code Changes"). The table would catch the soft gaps: "tired", "should work", "agent said success". The current project relies on user review to catch these; codifying the table would make them explicit.
• LOW: Consider adding a verification-before-completion SKILL.md to .agents/skills/ mirroring the superpowers one. The project's discipline is currently embedded in workflow.md prose; a dedicated skill would make it toolable for agents that use the Skill tool.

Verdict.

Field	Value
Primary	PARITY
Integration tag	INTEGRATED
Section size	deep-dive
Cross-refs	nagent_review_20260608 §10 ("durable verification"); fable_review_20260617 §13 (project's evidence-first approach vs Fable's persona-first approach); intent_dsl_survey_20260612 §6 (verification is one of the project's "AI-agent properties" the survey documents)

Rationale. The project's verification regime is a faithful re-encoding of the skill with three project-specific elaborations (Phase Completion Verification, Skip-Marker Policy, Isolated-Pass Verification Fallacy). The Iron Law is enforced via the per-task commit + git note + user-confirmation gate. The skill's anti-rationalization table is mostly present in prose form, but the "tired" and "should work" patterns are not explicitly caught.

Recommended change. Add a "verification ritual" anti-rationalization table to conductor/workflow.md §"Task Workflow" step 9; consider promoting the verification discipline to a dedicated .agents/skills/verification-before-completion/SKILL.md mirroring the superpowers plugin.

6. Systematic Debugging

6. Systematic Debugging

6.1 What the skill prescribes

The systematic-debugging skill is the canonical anti-pattern against "random fixes waste time and create new bugs." The Iron Law: "NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST." The skill's 4-Phase model is exhaustive:

Phase 1 — Root Cause Investigation: (1) Read error messages carefully; (2) Reproduce consistently; (3) Check recent changes (git diff, recent commits); (4) Gather evidence in multi-component systems (log what enters/exits each boundary); (5) Trace data flow (root-cause-tracing.md for the backward-tracing technique).

Phase 2 — Pattern Analysis: (1) Find working examples; (2) Compare against references (read reference implementation COMPLETELY); (3) Identify differences; (4) Understand dependencies.

Phase 3 — Hypothesis and Testing: (1) Form single hypothesis ("I think X is the root cause because Y"); (2) Test minimally (smallest possible change, one variable); (3) Verify before continuing; (4) When you don't know, say so.

Phase 4 — Implementation: (1) Create failing test case (TDD); (2) Implement single fix (no bundled refactoring); (3) Verify fix; (4) If fix doesn't work: STOP and count — if <3, return to Phase 1; if ≥3, STOP and question architecture (Phase 4.5).

The Red Flags are extensive: "Quick fix for now, investigate later"; "Just try changing X and see if it works"; "Add multiple changes, run tests"; "Skip the test, I'll manually verify"; "It's probably X, let me fix that"; "I don't fully understand but this might work"; "Pattern says X but I'll adapt it differently"; "One more fix attempt" (when already tried 2+); each fix reveals new problem in different place.

6.2 Mapping to the project's existing pattern

The project has a comprehensive Process Anti-Patterns section in AGENTS.md and a "Process Anti-Patterns (Added 2026-06-09)" section in conductor/workflow.md. Together they map directly to the skill's 4-Phase model:

Skill rule	Project equivalent	Where
Phase 1: "Read Error Messages Carefully"	The "Deduction Loop (kill it)" anti-pattern: "You are allowed to run a failing test at most 2 times in a single investigation. After the 2nd failure, STOP running the test. Read the relevant source code (get_file_slice or py_get_skeleton), predict the failure mode from the code, and instrument ALL the relevant state in one pass before the next run."	AGENTS.md "Process Anti-Patterns" §1
Phase 1: "Reproduce Consistently"	The "Isolated-Pass Verification Fallacy" rule (per Section 5 above): tests passing in isolation but failing in batch is FAILING.	conductor/workflow.md §"Isolated-Pass Verification Fallacy"
Phase 1: "Check Recent Changes"	The "Inherited-Cruft Pattern (kill it)" anti-pattern: "If the file is already in a broken state from a previous session, the FIRST thing you do is ask the user: 'this file is in a broken state from a previous agent. do you want me to (a) revert the working tree and start from a clean baseline, (b) finish the previous agent's intent, or (c) abandon the work entirely?'"	AGENTS.md "Process Anti-Patterns" §4
Phase 1: "Gather Evidence in Multi-Component Systems"	The Deduction Loop rule's "instrument ALL the relevant state in one pass before the next run" + scripts/audit_* scripts (audit_main_thread_imports, audit_weak_types, etc.)	AGENTS.md §1 + scripts/audit_*
Phase 2: "Find Working Examples"	The project's MCP tools (e.g., py_get_skeleton, py_get_code_outline) enable finding similar patterns in the codebase; the project's "Current State Audit" step in tier-1 specs	conductor/workflow.md §"The Surgical Methodology"
Phase 3: "Form Single Hypothesis"	The Deduction Loop's "predict the failure mode from the code" step enforces single-hypothesis discipline	AGENTS.md §1
Phase 4: "Create Failing Test Case"	TDD (per Section 4 above); the project uses tier-3 worker dispatches to write the failing test	conductor/workflow.md §"Task Workflow" step 4
Phase 4: "If 3+ Fixes Failed: Question Architecture"	The Deduction Loop's "If you've tried 3 times and the test still fails, STOP and report to the user" + the "Inherited-Cruft Pattern" + the Surrender pattern's "5 things to do before surrendering"	AGENTS.md §1 + §4 + §6
"Just try this first, then investigate"	The Deduction Loop's "You are allowed to run a failing test at most 2 times" — strictly bound the trial-and-error budget	AGENTS.md §1
"Multiple fixes at once saves time"	The Deduction Loop's "instrument ALL the relevant state in one pass before the next run" — one-pass instrumentation, then run ONCE more	AGENTS.md §1
"I see the problem, let me fix it"	The "Report-Instead-of-Fix Pattern (kill it)": "A status report is allowed only when: You have actually tried the fix and it failed with evidence, OR You are blocked on a decision the user must make. A status report is NOT allowed when: You are avoiding a hard problem by writing prose about it."	AGENTS.md §2
"I'm confident"	The Deduction Loop's "predict the failure mode from the code" — confidence is replaced with code-derived prediction	AGENTS.md §1
"I'm tired" / "Manager wants it fixed NOW"	n/a — the project doesn't have this explicit anti-pattern; the user catches it via the report-instead-of-fix rule	—

6.3 Where the project already follows the discipline

• The Deduction Loop rule is the project's most explicit anti-rationalization rule. It says "run at most 2 times, then STOP, then predict from code, then instrument once, then run once more." This maps directly to the skill's Phase 1 "Reproduce Consistently" + Phase 3 "Test Minimally".
• The Report-Instead-of-Fix Pattern (kill it) maps to the skill's "Don't pretend to know" rule. The project's rule is stricter: a 200-line status report is forbidden; a 5-10-sentence status report is allowed only when blocked.
• The Inherited-Cruft Pattern (kill it) maps to the skill's "Check Recent Changes" Phase 1 rule. The project adds a layer: if the file is broken from a previous session, ASK the user before fixing.
• The Verbose-Commit-Message Pattern (kill it) is project-specific: commit messages are 1-3 sentences, not 50-line reports. This is the "stop writing prose about work" anti-pattern.
• The Isolated-Pass Verification Fallacy is the project's anti-pattern for Phase 4 step 3 ("Verify Fix"). It says the fix isn't verified until it passes in batch.

6.4 Where the project doesn't follow the discipline

• "If 3+ Fixes Failed: Question Architecture" is partially followed. The Deduction Loop says "STOP and report to the user" after 3 fixes, but doesn't explicitly say "question architecture". The project does have the "Inherited-Cruft Pattern" rule (which is a form of architecture questioning) but it's framed around broken-file state, not failed-fix state.
• "Quick fix for now, investigate later" is not explicitly addressed. The Deduction Loop catches the symptom (running the test 3 times) but not the rationalization ("I'll investigate later").
• "I don't fully understand but this might work" is caught by the Report-Instead-of-Fix rule (status reports are forbidden when avoiding a hard problem), but there's no explicit "say you don't understand" rule.
• The skill's "Defense in Depth" + "Condition-Based Waiting" techniques are mentioned in the project (the live_gui test fixture uses condition polling; the result_types.py uses defense-in-depth Result[T]) but they're not codified as project anti-patterns.
• The skill's "Trace Data Flow" (root-cause-tracing.md) is implicit in the project's MCP tool usage (py_find_usages, py_get_definition, py_get_imports) but no explicit "use the tracing technique" rule.

6.5 Recommendations summary

The project follows the systematic-debugging discipline with significant elaborations (Deduction Loop, Report-Instead-of-Fix, Inherited-Cruft, Verbose-Commit-Message, Isolated-Pass Fallacy). The project goes BEYOND the skill in catching rationalization patterns. The deferred rebuild may want to:

• MEDIUM: Add explicit "Question Architecture" rule to AGENTS.md §"Process Anti-Patterns": "After 3 failed fix attempts, stop and question the architecture before attempting Fix #4. The pattern may be fundamentally wrong; discuss with the user before continuing."
• LOW: Add an explicit "Defense in Depth" + "Condition-Based Waiting" reference section to AGENTS.md or to a new conductor/code_styleguides/debugging.md styleguide.

Verdict.

Field	Value
Primary	PARITY
Integration tag	INTEGRATED
Section size	deep-dive
Cross-refs	nagent_review_20260608 §10 ("durable debugging" — the project's test discipline); fable_review_20260617 §13 (project's debugging is "genuinely useful" pattern); intent_dsl_survey_20260612 §6 (debugging is one of the project's "AI-agent properties")

Rationale. The project's AGENTS.md + workflow.md Process Anti-Patterns section is a faithful re-encoding of the skill's 4-Phase model with five project-specific elaborations. The Deduction Loop + Report-Instead-of-Fix + Inherited-Cruft rules map directly to the skill's Phase 1, Phase 3, and Phase 4. The skill's "Question Architecture" rule is partially followed but could be explicit.

Recommended change. Add explicit "Question Architecture" rule to AGENTS.md §"Process Anti-Patterns" (mirror the skill's Phase 4.5); consider a conductor/code_styleguides/debugging.md for the supporting techniques (defense-in-depth, condition-based waiting, root-cause-tracing).

7. Subagent-Driven Development

7. Subagent-Driven Development

7.1 What the skill prescribes

The subagent-driven-development skill is the "execute plan by dispatching fresh subagent per task, with two-stage review after each" pattern. Core principle: "Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration." The "continuous execution" rule says: "Do not pause to check in with your human partner between tasks. Execute all tasks from the plan without stopping. The only reasons to stop are: BLOCKED status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete. 'Should I continue?' prompts and progress summaries waste their time — they asked you to execute the plan, so execute it."

The Process flow per task: (1) Dispatch implementer subagent; (2) Implementer asks questions? (yes → answer, no → proceed); (3) Implementer implements, tests, commits, self-reviews; (4) Dispatch spec reviewer subagent; (5) Spec reviewer confirms code matches spec? (yes → dispatch code quality reviewer; no → implementer fixes); (6) Dispatch code quality reviewer subagent; (7) Code quality reviewer approves? (yes → mark task complete; no → implementer fixes); (8) Loop to next task.

The Model Selection guidance is hierarchical: cheap models for mechanical implementation (1-2 files, clear specs); standard models for integration (multi-file coordination); most capable models for architecture/design/review.

The Implementer Status enum is 4-state: DONE (proceed to spec review); DONE_WITH_CONCERNS (read concerns; address correctness/scope concerns before review; note observations and proceed); NEEDS_CONTEXT (provide missing context, re-dispatch); BLOCKED (assess: context problem → provide more; needs more reasoning → upgrade model; too large → break into smaller; plan wrong → escalate to human).

The Red Flags list: "Never start implementation on main/master without explicit user consent"; "Never skip reviews"; "Never proceed with unfixed issues"; "Never dispatch multiple implementation subagents in parallel"; "Never make subagent read plan file (provide full text)"; "Never skip scene-setting context"; "Never ignore subagent questions"; "Never accept 'close enough' on spec compliance"; "Never start code quality review before spec compliance is ✅"; "Never move to next task while either review has open issues".

7.2 Mapping to the project's existing pattern

The project's MMA (Multi-Model Architecture) is a faithful re-encoding of subagent-driven-development with three elaborations (4-tier hierarchy, context-amnesia tier-3 workers, tier-4 QA as second-stage review):

Skill rule	Project equivalent	Where
"Fresh subagent per task"	"Tier 3 Worker: Stateless Tier 3 Worker for surgical code implementation and TDD" (per .agents/skills/mma-tier3-worker/SKILL.md); "Context Amnesia (Tiers 3 & 4): The OpenCode Task tool enforces 'Context Amnesia' by executing sub-agents in a stateless manner."	conductor/workflow.md §"Conductor Token Firewalling" + .agents/skills/mma-orchestrator/SKILL.md
"Two-stage review (spec then quality)"	The Tier 4 QA agent as the second-stage review (per conductor/workflow.md §"Conductor Token Firewalling"): "Tier 4 (Utility/QA): gemini-2.5-flash-lite. Used for log summarization and error analysis. Operates statelessly (Context Amnesia) but has access to diagnostic tools."	conductor/workflow.md §"Conductor Token Firewalling"
"Continuous execution"	The Tier 2 Tech Lead maintains persistent memory (per the same section): "Unlike the stateless sub-agents (Tiers 3 & 4), the Tier 2 Tech Lead does NOT use Context Amnesia during track implementation to ensure continuity of technical strategy."	conductor/workflow.md §"Conductor Token Firewalling"
"Spec compliance review"	Tier 3 worker's surgical prompt includes "specification" via file:line references + behavior verification; the tier-2 tech-lead reviews the diff before committing (per conductor/workflow.md §"Task Workflow" step 9: per-task atomic commits + git notes)	conductor/workflow.md §"Task Workflow"
"Code quality review"	Tier 4 QA agent dispatched on failure: "If you run a test or command that fails with a significant error or large traceback... DO spawn a stateless Tier 4 agent to diagnose the failure."	.agents/skills/mma-orchestrator/SKILL.md §"The Tier 4 QA Agent (Diagnostics)"
"Model Selection"	The project's model selection is hierarchical: Tier 1 (gemini-3.1-pro-preview, strategic), Tier 2 (gemini-3-flash-preview, tech-lead), Tier 3 (gemini-2.5-flash-lite, worker), Tier 4 (gemini-2.5-flash-lite, qa). The "least powerful model that can handle each role" rule applies.	conductor/workflow.md §"Conductor Token Firewalling"
"Implementer Status: DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED"	The project's tier-3 worker dispatch is via OpenCode Task tool with subagent_type: 'tier3-worker'; the tier-3 worker reports back to the tier-2 orchestrator. The project doesn't have a strict 4-state status enum but the equivalent is the worker's response ("completed successfully" vs "needs context" vs "blocked").	conductor/workflow.md §"Task Workflow" step 5
"Surgical prompt: WHERE/WHAT/HOW/SAFETY/COMMIT"	The project's tier-3 worker dispatch prompt template (per conductor/workflow.md §"Task Workflow" step 4 + step 5): "WHERE (file:line range), WHAT (test to create), HOW (which assertions/fixtures to use), and SAFETY (thread constraints if applicable)"	conductor/workflow.md §"Task Workflow" steps 4-5
"Pre-Delegation Checkpoint"	conductor/workflow.md §"Task Workflow" step 4 + step 5: "Pre-Delegation Checkpoint: Before spawning a worker for dangerous or non-trivial changes, ensure your current progress is staged (git add .) or committed. This prevents losing iterations if a sub-agent incorrectly uses git restore."	conductor/workflow.md §"Task Workflow"
"Never dispatch multiple implementation subagents in parallel"	The project's tier-2 orchestrator dispatches tier-3 workers one at a time (no parallel worker dispatches); the parallel-execution pattern is for tasks, not subagents within a task	Project-wide
"Never make subagent read plan file (provide full text)"	The project's tier-3 dispatch prompts include the full task context inline (per conductor/workflow.md §"Task Workflow" step 4-5 example prompts)	conductor/workflow.md §"Task Workflow"
"Subagent follow TDD for each task"	The project's tier-3 worker is required to follow TDD: "Subagents follow TDD naturally" (per the skill) + the project's workflow step 4 ("Write Failing Tests (Red Phase)") is part of every tier-3 dispatch prompt	conductor/workflow.md
"AST Skeleton & Outline Views" for subagent context	The project's tier-2 uses manual-slop_py_get_skeleton and manual-slop_py_get_code_outline MCP tools to provide curated context to tier-3 workers (per .agents/skills/mma-orchestrator/SKILL.md §"AST Skeleton & Outline Views")	.agents/skills/mma-orchestrator/SKILL.md
"Repeated failures → upgrade model"	The project's tier-3 dispatch supports --failure-count for model escalation: "If a Tier 3 Worker fails multiple times on the same task, it may lack the necessary capability. You must track failures and retry with --failure-count (e.g., --failure-count 2). This tells mma_exec.py to escalate the sub-agent to a more powerful reasoning model"	.agents/skills/mma-orchestrator/SKILL.md §"Handling Repeated Failures"
"Per-Task Decision Protocol" (architectural vs cosmetic)	conductor/workflow.md §"Per-Task Decision Protocol": small decisions decide yourself; large decisions escalate. Maps to the skill's "If the task requires more reasoning, re-dispatch with a more capable model" + "If the plan itself is wrong, escalate to the human"	conductor/workflow.md §"Per-Task Decision Protocol"

7.3 Where the project already follows the discipline

• The 4-tier MMA is a direct implementation of subagent-driven-development. The Tier 3 Worker is "fresh subagent per task" with surgical prompts. The Tier 4 QA is "two-stage review" (specifically for error analysis, not success claims). The Tier 2 Tech Lead is "persistent memory" (the skill doesn't have this role, but the project uses it for continuity).
• The "Domain Distinction" (Meta-Tooling vs Application) is a project-specific addition. Per conductor/workflow.md §"Conductor Token Firewalling" §0: "This doc describes META-TOOLING — the AI agent orchestration layer used by Conductor agents to coordinate their own work. It is NOT the Application domain (the manual-slop GUI app being built)." This disambiguates the project's MMA from the application's MMA (in src/multi_agent_conductor.py), which is critical because they share a name but operate in different domains.
• The "Pre-Delegation Checkpoint" is a project-specific rule that's stricter than the skill's "stage or commit before delegating". The project's rule explicitly calls out the git restore failure mode ("git restore destroyed user in-progress src/* edits twice in one session 2026-06-07").
• The "Repeated failures → upgrade model" rule is explicitly named (--failure-count) and is a project-specific operationalization of the skill's BLOCKED handler.

7.4 Where the project doesn't follow the discipline

• "Two-stage review" — the project's tier-4 QA is for error analysis, not code-quality review. The skill's "code quality reviewer" subagent reviews the code itself (style, structure, naming); the project's tier-4 QA reviews errors (log summarization, failure root cause). This is ARCH-DIFF: the project uses tier-4 for a narrower purpose.
• "Continuous execution" — the project DOES pause for user review at phase boundaries. The skill says "execute all tasks from the plan without stopping"; the project's Phase Completion Verification and Checkpointing Protocol §5 says "PAUSE and await the user's response. Do not proceed without an explicit yes or confirmation from the user to proceed if tests pass." The project is more user-interactive than the skill.
• "Subagent-driven vs executing-plans: same session vs parallel session" — the project doesn't make this distinction explicitly. Tier 3 workers run in the same session as the orchestrator (via OpenCode Task tool); there is no parallel-session option.
• "If subagent asks questions: Answer clearly and completely" — partially followed. The project's tier-3 dispatch prompt is fully specified (WHERE/WHAT/HOW/SAFETY), but if the tier-3 worker asks a clarifying question during execution, the tier-2 may not have a structured response protocol (the project relies on the agent's conversational context).
• "Never accept 'close enough' on spec compliance" — partially followed. The project's tier-2 reviews the commit + git note but doesn't have a structured "spec compliance review" subagent.

7.5 Recommendations summary

The project follows the subagent-driven-development discipline with significant elaborations (4-tier MMA, Domain Distinction, Pre-Delegation Checkpoint, repeated-failure model escalation). The project's Tier 4 QA is narrower than the skill's "code quality reviewer" but the project compensates with per-task atomic commits + git notes that are reviewed by the user at phase boundaries. The deferred rebuild may want to:

• MEDIUM: Consider adding a tier-4b "code quality reviewer" subagent (the skill's two-stage review's second stage) to complement the tier-4 QA (first stage). This would close the ARCH-DIFF gap with the skill.
• LOW: Codify the "if subagent asks questions, answer clearly" rule as a tier-2 orchestrator prompt template. Currently this is implicit in the tier-2's behavior.
• LOW: Add a "parallel session execution" option for tracks where tasks are highly independent (e.g., research-style tracks like this one). The project has sequential dispatch; the skill offers a parallel option.

Verdict.

Field	Value
Primary	PARITY
Integration tag	INTEGRATED
Section size	deep-dive
Cross-refs	nagent_review_20260608 §5 (the durable-work thesis shapes how subagents are dispatched); fable_review_20260617 §3 (the cluster-sub-agent dispatch pattern); intent_dsl_survey_20260612 §6 (MMA is one of the project's "AI-agent properties")

Rationale. The project's 4-tier MMA is a faithful elaboration of subagent-driven-development. Tier 3 workers = fresh subagent per task (skill-compliant); Tier 4 QA = first-stage review (narrower than skill's two-stage); Tier 2 Tech Lead = persistent memory (project elaboration, not in skill); Tier 1 Orchestrator = strategic planning (project elaboration, not in skill). The Pre-Delegation Checkpoint + Domain Distinction + Repeated-failure model escalation are project-specific operationalizations.

Recommended change. Consider a tier-4b "code quality reviewer" subagent for the second-stage review; codify the "answer subagent questions" rule as a tier-2 template; consider parallel-session execution for highly independent tracks.

8. Executing Plans

8. Executing Plans

8.1 What the skill prescribes

The executing-plans skill is the simpler counterpart to subagent-driven-development for "separate session with review checkpoints" execution. The 3-step Process is:

1. Load and Review Plan — Read plan file; review critically (identify any questions or concerns); if concerns, raise them with the human partner before starting; if no concerns, create TodoWrite and proceed.
2. Execute Tasks — For each task: mark as in_progress; follow each step exactly (plan has bite-sized steps); run verifications as specified; mark as completed.
3. Complete Development — Announce "I'm using the finishing-a-development-branch skill to complete this work"; REQUIRED SUB-SKILL: use superpowers:finishing-a-development-branch; follow that skill to verify tests, present options, execute choice.

The "When to Stop and Ask for Help" list: hit a blocker (missing dependency, test fails, instruction unclear); plan has critical gaps preventing starting; don't understand an instruction; verification fails repeatedly. The skill says "Ask for clarification rather than guessing."

The "When to Revisit Earlier Steps" list: partner updates the plan based on your feedback; fundamental approach needs rethinking. The skill says "Don't force through blockers - stop and ask."

The skill's most important meta-rule: "Never start implementation on main/master branch without explicit user consent."

8.2 Mapping to the project's existing pattern

The project's tier-1 orchestrator uses this pattern when initializing a new track (per conductor/workflow.md §"Planning Session Workflow"). The skill is also implicitly used by tier-2 tech-leads when picking up an approved plan.

Skill rule	Project equivalent	Where
"Step 1: Load and Review Plan"	conductor/workflow.md §"Planning Session Workflow" steps 1-7 (Explore → Ask clarifying questions → Propose approaches → Write spec → User reviews spec → Write plan → User reviews plan)	conductor/workflow.md
"Review critically — identify any questions or concerns about the plan"	Tier-1 Track Initialization Rules §"Audit Before Specifying": "NEVER write a spec without first reading actual code using MCP tools"	conductor/workflow.md §"Tier 1 Track Initialization Rules"
"If concerns: Raise them with your human partner before starting"	Tier-1 spec is approved by the user before the plan is written (per the Planning Session Workflow)	conductor/workflow.md §"Planning Session Workflow"
"If no concerns: Create TodoWrite and proceed"	Every plan.md has the per-task structure that the implementing agent follows	conductor/workflow.md §"Task Workflow"
"Step 2: Execute Tasks — mark as in_progress"	"Mark In Progress: Before beginning work, edit plan.md and change the task from [ ] to [~]"	conductor/workflow.md §"Task Workflow" step 2
"Follow each step exactly (plan has bite-sized steps)"	Tier-1 Track Initialization Rules §1 "Spec format" + §4 "Plan format" — bite-sized steps are mandatory	conductor/workflow.md
"Run verifications as specified"	The Phase Completion Verification and Checkpointing Protocol: automated tests + API hooks + user confirmation	conductor/workflow.md
"Mark as completed"	"Step 10.1: Update Plan: Read plan.md, find the line for the completed task, update its status from [~] to [x], and append the first 7 characters of the just-completed commit's commit hash."	conductor/workflow.md §"Task Workflow" step 10
"Step 3: Complete Development — REQUIRED SUB-SKILL: use superpowers:finishing-a-development-branch"	The project's conductor/workflow.md doesn't have a finishing-a-development-branch equivalent; the closest is "10. Finalize" in the track's plan.md (Phase 10: register in tracks.md + update metadata.json with final statistics)	conductor/tracks/<id>/plan.md Phase 10
"When to Stop and Ask for Help" (4 stop conditions)	The project has the Per-Task Decision Protocol with 3 escalation levels: cosmetic → decide yourself; architectural → STOP and report to Tier 2; regression → STOP and report	conductor/workflow.md §"Per-Task Decision Protocol"
"When to Revisit Earlier Steps" (2 revisit conditions)	The "Inherited-Cruft Pattern (kill it)" rule: if the file is broken, ASK the user before fixing (revisit earlier steps in spirit)	AGENTS.md §"Process Anti-Patterns" §4
"Never start implementation on main/master branch without explicit user consent"	conductor/workflow.md does NOT have an explicit "don't start on master" rule; the user's session opens on master and tracks are committed to master. The "tier2-autonomous-sandbox" track has its own branch-protection rules (per conductor/tier2/opencode.json.fragment)	Partial

8.3 Where the project already follows the discipline

• The Planning Session Workflow is the tier-1 orchestrator's executing-plans process — load spec, review critically (Tier 1 audit), ask clarifying questions, propose 2-3 approaches, write spec, user reviews, write plan, user reviews, commit spec + plan in separate commits.
• The per-task workflow is the bite-sized execution pattern — mark in_progress, follow step exactly, run verification, mark completed. The "Mark In Progress → Follow each step exactly → Mark Completed" cycle is the workflow.md §"Task Workflow" steps 2, 4-5, 10.
• The Deduction Loop (per Section 6) is the project's "STOP and report" rule for the "When to Stop and Ask for Help" condition. The project goes beyond the skill: it doesn't just stop, it has a structured "5 things to do before surrendering" list.

8.4 Where the project doesn't follow the discipline

• No finishing-a-development-branch skill — the project's Phase 10 finalize is a simpler artifact (update state.toml + tracks.md + metadata.json) rather than the skill's "verify tests, present options, execute choice" pattern. The user's "review the work, decide merge/squash/PR" is implicit in the per-commit user-review workflow.
• "Never start implementation on main/master branch without explicit user consent" — the project DOES work on master directly; there's no worktree or branch creation required for normal tracks. This is ARCH-DIFF: the project treats master as the working branch; the skill's rule doesn't apply. (The tier2-autonomous sandbox is the exception, with explicit branch-protection rules.)
• No explicit "When to Revisit Earlier Steps" rule — the project relies on the Inherited-Cruft Pattern (per Section 6) to catch the "fundamentals need rethinking" condition. The skill's "discuss with the human partner before attempting more fixes" is partially covered.

8.5 Recommendations summary

The project follows the executing-plans discipline with three deviations: no finishing-a-development-branch skill (Phase 10 is simpler); works on master directly (no worktree rule); revisit-conditions are implicit (Inherited-Cruft Pattern). The deferred rebuild may want to:

• LOW: Consider codifying a "finishing-a-development-branch" check in conductor/workflow.md (after Phase 10): "verify all tests pass, present merge/review options to user, execute choice." Currently Phase 10 is "register in tracks.md + update metadata" only.
• LOW: Consider the master-vs-worktree question. The user's working pattern is master-direct; the skill's recommendation is worktree. This is a user-driven choice; deferring to the deferred rebuild is appropriate.

Verdict.

Field	Value
Primary	PARITY
Integration tag	INTEGRATED
Section size	medium
Cross-refs	nagent_review_20260608 §5 (the durable-work thesis shapes how plans are executed); fable_review_20260617 (the cluster-sub-agent dispatch pattern is one execution path); intent_dsl_survey_20260612 §6 (the project's execution discipline is one of its "AI-agent properties")

Rationale. The project's Planning Session Workflow + Task Workflow is a faithful re-encoding of executing-plans. The skill's "Mark In Progress → Follow each step → Mark Completed" cycle is the workflow steps 2, 4-5, 10. The "When to Stop" condition is the Deduction Loop + Per-Task Decision Protocol. The "finishing-a-development-branch" skill is partially covered by Phase 10.

Recommended change. Codify a "finishing-a-development-branch" check in conductor/workflow.md after Phase 10; consider the master-vs-worktree question in the deferred rebuild.

9. Dispatching Parallel Agents

9. Dispatching Parallel Agents

9.1 What the skill prescribes

The dispatching-parallel-agents skill is for "2+ independent tasks that can be worked on without shared state or sequential dependencies." Core principle: "Dispatch one agent per independent problem domain. Let them work concurrently." The skill's decision tree: Multiple failures? → Are they independent? → (yes → Can they work in parallel?) → (yes → Parallel dispatch; no → Sequential agents). Use when: 3+ test files failing with different root causes; multiple subsystems broken independently; each problem can be understood without context from others; no shared state between investigations. Don't use when: failures are related; need to understand full system state; agents would interfere.

The Pattern is 4 steps: (1) Identify Independent Domains — group failures by what's broken; (2) Create Focused Agent Tasks — specific scope + clear goal + constraints + expected output; (3) Dispatch in Parallel — multiple Task tool calls; (4) Review and Integrate — read each summary, verify no conflicts, run full suite, integrate.

Common Mistakes: Too broad ("Fix all the tests"); No context ("Fix the race condition"); No constraints (agent might refactor everything); Vague output ("Fix it"). The Skill emphasizes that "Agents don't inherit your session's context or history — you construct exactly what they need."

9.2 Mapping to the project's existing pattern

The project's MMA tier-3 worker dispatch is the closest equivalent, but it's sequential per track (not parallel per independent problem). The project's conductor/workflow.md §"Conductor Token Firewalling" specifies the "ConductorEngine execution loop" + "WorkerPool (concurrency 4)" pattern in src/multi_agent_conductor.py, which IS parallel — but this is the Application domain MMA, not the Meta-Tooling domain dispatch.

Skill rule	Project equivalent	Where
"Dispatch one agent per independent problem domain"	Tier-3 worker dispatch per task (per conductor/workflow.md §"Task Workflow" step 4 + step 5); but sequential per track, not parallel	conductor/workflow.md
"Use when: 3+ test files failing with different root causes"	The "fix_test_failures_20260624" track was a single-agent task with 3 surgical fixes (per chronology); parallel dispatch is not the project's default for fix tracks	conductor/tracks/fix_test_failures_20260624/
"Use when: multiple subsystems broken independently"	The MMA WorkerPool in src/multi_agent_conductor.py handles parallel ticket execution (4 concurrent workers), but this is Application-domain	src/multi_agent_conductor.py
"Create Focused Agent Tasks: specific scope + clear goal + constraints + expected output"	Tier-3 worker surgical prompt template (per conductor/workflow.md §"Task Workflow"): WHERE (file:line) + WHAT (test to create) + HOW (assertions/fixtures) + SAFETY (thread constraints)	conductor/workflow.md
"Dispatch in Parallel"	Application MMA WorkerPool does parallel execution; Meta-Tooling tier-3 dispatch is sequential per track	src/multi_agent_conductor.py
"Review and Integrate — read each summary, verify no conflicts"	Tier-2 tech-lead reviews each tier-3 worker's commit before proceeding to next task (per the per-task atomic commit + git note workflow)	conductor/workflow.md §"Task Workflow" step 9-10
"Don't use when: agents would interfere"	The project explicitly forbids "Never dispatch multiple implementation subagents in parallel (conflicts)" (per the subagent-driven-development skill analysis in Section 7)	conductor/workflow.md
"Agents don't inherit your session's context"	The Tier-3 worker is stateless per the MMA pattern: "Tier 3 Worker: Stateless Tier 3 Worker for surgical code implementation and TDD. Operates statelessly (Context Amnesia) but has access to file I/O tools."	conductor/workflow.md §"Conductor Token Firewalling"

9.3 Where the project already follows the discipline

• The Tier-3 worker stateless pattern is skill-compliant. "Context Amnesia" ensures each tier-3 dispatch is a fresh subagent without inherited session context.
• The "Focused Agent Tasks: WHERE/WHAT/HOW/SAFETY/COMMIT" surgical prompt template is the project's elaboratation of the skill's "specific scope + clear goal + constraints + expected output".
• The Application-domain MMA WorkerPool uses parallel execution (4 concurrent workers) which matches the skill's "dispatch in parallel" pattern. The Application MMA is in src/multi_agent_conductor.py (per docs/guide_multi_agent_conductor.md).
• The "Read each summary, verify no conflicts" pattern is enforced via per-task atomic commits + git notes; the tier-2 reviews each commit before proceeding.

9.4 Where the project doesn't follow the discipline

• Meta-Tooling tier-3 dispatch is sequential per track, not parallel per independent problem. The project's tier-2 tech-lead picks up one task at a time. The skill's "dispatch 3 parallel agents to fix 3 independent test failures" pattern is not used in Meta-Tooling.
• The Application MMA's WorkerPool (4 concurrent workers) is the closest equivalent, but it's an execution pattern for application tickets, not for meta-tooling track tasks.
• "Fix parallelization of independent meta-tooling tasks" would require a track-design change: the tier-2 would need to dispatch tier-3 workers in parallel and aggregate results. This is technically possible (OpenCode Task tool supports parallel dispatch) but not the project's current practice.

9.5 Recommendations summary

The project follows the skill's principles (stateless subagents, focused tasks, per-task verification) but applies them sequentially per track. The Application MMA uses parallel execution. The Meta-Tooling tier-3 dispatch is sequential because track tasks are usually sequential (each task depends on the previous one's commit). The deferred rebuild may want to:

• LOW: Document the Meta-Tooling sequential-dispatch pattern vs the Application parallel-dispatch pattern as a deliberate design choice. The skill applies to both; the project uses parallel for one and sequential for the other.

Verdict.

Field	Value
Primary	PARTIAL
Integration tag	INTEGRATED
Section size	brief
Cross-refs	nagent_review_20260608 §5 (durable work + disposable workers); fable_review_20260617 §3 (cluster-sub-agent dispatch uses the parallel pattern); intent_dsl_survey_20260612 §6 (the project's tier-3 + WorkerPool is documented as "AI-agent properties")

Rationale. The project's tier-3 worker pattern is skill-compliant (stateless, focused tasks, surgical prompts). The Application MMA's WorkerPool uses the skill's parallel dispatch pattern. The Meta-Tooling tier-3 dispatch is sequential per track (different from the skill's "dispatch 3 parallel agents" pattern). The project uses parallel dispatch where appropriate (Application tickets) and sequential where appropriate (Meta-Tooling track tasks).

Recommended change. (blank — no rebuild action. The project's deliberate sequential/parallel choice is defensible.)

10. Receiving Code Review

10. Receiving Code Review

10.1 What the skill prescribes

The receiving-code-review skill establishes that "Code review requires technical evaluation, not emotional performance." Core principle: "Verify before implementing. Ask before assuming. Technical correctness over social comfort." The Response Pattern is 6-step: READ (complete feedback without reacting) → UNDERSTAND (restate requirement in own words or ask) → VERIFY (check against codebase reality) → EVALUATE (technically sound for THIS codebase?) → RESPOND (technical acknowledgment or reasoned pushback) → IMPLEMENT (one item at a time, test each).

The Forbidden Responses are explicit: NEVER "You're absolutely right!" (explicit CLAUDE.md violation); NEVER "Great point!" / "Excellent feedback!" (performative); NEVER "Let me implement that now" (before verification). INSTEAD: restate the technical requirement; ask clarifying questions; push back with technical reasoning if wrong; just start working (actions > words).

The Handling Unclear Feedback rule: IF any item is unclear → STOP → ASK for clarification on unclear items. WHY: Items may be related. Partial understanding = wrong implementation. Example: Partner says "Fix 1-6" — you understand 1,2,3,6, unclear on 4,5. WRONG: Implement 1,2,3,6 now, ask about 4,5 later. RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."

The Source-Specific Handling distinguishes: From your human partner (Trusted — implement after understanding; still ask if scope unclear; no performative agreement; skip to action or technical acknowledgment) vs From External Reviewers (5-step pre-implementation check: technically correct for THIS codebase? breaks existing functionality? reason for current implementation? works on all platforms/versions? does reviewer understand full context?).

The YAGNI Check for "Professional" Features: IF reviewer suggests "implementing properly" → grep codebase for actual usage. IF unused: "This endpoint isn't called. Remove it (YAGNI)?" IF used: Then implement properly.

The Implementation Order is: Blocking issues (breaks, security) → Simple fixes (typos, imports) → Complex fixes (refactoring, logic) → Test each fix individually → Verify no regressions.

The Acknowledging Correct Feedback rule: "Actions speak. Just fix it. The code itself shows you heard the feedback." NEVER "Thanks" or gratitude expressions. State the fix instead.

The Gracefully Correcting Your Pushback rule: "You were right - I checked [X] and it does [Y]. Implementing now." / "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing." NEVER Long apology / defending why you pushed back / over-explaining.

10.2 Mapping to the project's existing pattern

The project doesn't have a dedicated "receiving code review" rule, but it has multiple patterns that map to the skill. The project is mostly self-directed (Tier 2 reviews Tier 3's commits via per-task git notes; the user reviews at phase boundaries), so the "receiving code review" pattern is invoked when the user gives feedback at phase checkpoints.

Skill rule	Project equivalent	Where
"Verify before implementing"	The Phase Completion Verification and Checkpointing Protocol: "PAUSE and await the user's response. Do not proceed without an explicit yes or confirmation from the user to proceed if tests pass."	conductor/workflow.md §"Phase Completion Verification"
"No performative agreement"	The project's communication style is neutral-technical; AGENTS.md uses imperative language; "Satisfaction before verification" red flag is the inverse	Project-wide
"Restate the technical requirement"	The Tier-1 orchestrator's "Ask clarifying questions, one at a time" pattern (per Section 2) is the inverse: restating is what the agent does after receiving feedback	conductor/workflow.md §"Planning Session Workflow"
"Just start working (actions > words)"	The project's per-task atomic commit + git note discipline: "Actions speak." The verb in every commit message is the action.	conductor/workflow.md §"Task Workflow" step 9
"NEVER 'Thanks' or gratitude expressions"	The project's commit message style is terse: "conductor(track): ...", "feat(...): ...", no "Thanks" / "Great!" / "Awesome!"	conductor/workflow.md
"Source-Specific Handling: from human partner"	The user (project owner) is the sole reviewer; the Tier-2 → user feedback loop is the closest equivalent to the skill's "from human partner" path	conductor/workflow.md §"Phase Completion Verification"
"YAGNI Check: grep codebase for actual usage"	The Tier-1 Track Initialization Rules §1 "Spec format" + §2 "Frame requirements as GAPS, not features" — the project's spec-first approach surfaces YAGNI before code, not after review	conductor/workflow.md §"Tier 1 Track Initialization Rules"
"Implementation Order: blocking → simple → complex"	The Per-Task Decision Protocol: "small decisions, decide yourself. Large decisions, escalate." Maps to skill's order.	conductor/workflow.md §"Per-Task Decision Protocol"
"Push back with technical reasoning if wrong"	The Report-Instead-of-Fix Pattern (kill it): "A status report is allowed only when: You have actually tried the fix and it failed with evidence, OR You are blocked on a decision the user must make."	AGENTS.md §"Process Anti-Patterns" §2
"Gracefully Correcting Your Pushback: State the correction factually and move on"	The Verbose-Commit-Message Pattern (kill it): "A commit message is a 1-3 sentence summary. The body is for non-obvious 'why' details, not for re-stating what the diff shows."	AGENTS.md §"Process Anti-Patterns" §7

10.3 Where the project already follows the discipline

• The neutral commit message style is skill-compliant. The project's commits are conductor(scope): <description> with terse descriptions; no "Thanks" / "Great!" / "Awesome!" patterns. The Verbose-Commit-Message rule enforces this.
• The Phase Completion Verification protocol's "PAUSE and await the user's response" is the project's "ask before assuming" pattern. The agent doesn't proceed without explicit user confirmation.
• The Report-Instead-of-Fix rule is the project's "push back with technical reasoning" rule. The agent is allowed to surface a concern to the user (status report) when blocked.
• The Tier-1 spec-first approach is the inverse of the skill's "review feedback may include 'implement this feature'": the project surfaces YAGNI before code via the spec, not after.

10.4 Where the project doesn't follow the discipline

• No explicit "no performative agreement" rule. The project implicitly has this via the neutral commit message style, but no AGENTS.md rule says "Never respond to feedback with 'Great point!' or 'Thanks!'". This is a soft gap.
• No explicit "restate the requirement before implementing" rule. The Tier-1 spec-first pattern is upstream of this; the Tier-3 worker is given a surgical prompt and implements. There's no "restate the WHOLE task before starting" step.
• "NEVER thanks" rule is implicit but not explicit. A new agent reading AGENTS.md might not know this discipline.
• No explicit "5-step pre-implementation check" for external reviewers. The project doesn't have external reviewers; the user is the sole reviewer. This rule doesn't apply.

10.5 Recommendations summary

The project follows the discipline implicitly via its neutral communication style and Phase Completion Verification protocol. The deferred rebuild may want to:

• LOW: Add an explicit "no performative agreement / no thanks" rule to AGENTS.md §"Communication Style" or a new "Communication Conventions" section. The implicit discipline is captured in commit messages but not codified.

Verdict.

Field	Value
Primary	PARITY
Integration tag	INTEGRATED
Section size	medium
Cross-refs	nagent_review_20260608 §3 ("durable work" thesis shapes review feedback); fable_review_20260617 §13 ("Genuinely Useful Patterns" includes neutral communication); intent_dsl_survey_20260612 §6 (the project's neutral style is documented)

Rationale. The project's neutral communication style + Phase Completion Verification protocol + Verbose-Commit-Message rule + Report-Instead-of-Fix pattern is a faithful (if implicit) re-encoding of the skill. The "no performative agreement" rule is captured in commit style but not codified.

Recommended change. Add explicit "no performative agreement / no thanks" rule to AGENTS.md or new "Communication Conventions" section.

11. Requesting Code Review

11. Requesting Code Review

11.1 What the skill prescribes

The requesting-code-review skill is the symmetric counterpart to receiving-code-review. Core principle: "Review early, review often." Mandatory review triggers: after each task in subagent-driven development; after completing major feature; before merge to main. Optional but valuable: when stuck (fresh perspective); before refactoring (baseline check); after fixing complex bug.

How to Request: (1) Get git SHAs (BASE_SHA=$(git rev-parse HEAD~1); HEAD_SHA=$(git rev-parse HEAD)); (2) Dispatch code reviewer subagent using Task tool with general-purpose type, fill template at code-reviewer.md. Placeholders: DESCRIPTION (brief summary of what was built); PLAN_OR_REQUIREMENTS (what it should do); BASE_SHA (starting commit); HEAD_SHA (ending commit). (3) Act on feedback: Fix Critical issues immediately; Fix Important issues before proceeding; Note Minor issues for later; Push back if reviewer is wrong (with reasoning).

Integration with Workflows: Subagent-Driven Development (review after EACH task; catch issues before they compound; fix before moving to next task); Executing Plans (review after each task or at natural checkpoints); Ad-Hoc Development (review before merge; review when stuck).

Red Flags: Never skip review because "it's simple"; never ignore Critical issues; never proceed with unfixed Important issues; never argue with valid technical feedback.

11.2 Mapping to the project's existing pattern

The project doesn't have a dedicated "requesting code review" pattern in the meta-tooling domain. The Application domain has the live_gui fixture for visual verification (per docs/guide_testing.md) and the Phase Completion Verification for automated checks. The "review" is implicit in the per-task git notes + phase checkpoints.

Skill rule	Project equivalent	Where
"Review after each task in subagent-driven development"	Per-task atomic commit + git note is the project's "review" artifact; the user can review at phase boundaries	conductor/workflow.md §"Task Workflow" step 9-10
"Get git SHAs (BASE_SHA + HEAD_SHA)"	The per-task commit + git note has the SHA recorded in state.toml (commit_sha field per task)	conductor/tracks/<id>/state.toml
"Dispatch code reviewer subagent"	No explicit code-reviewer subagent; the Tier-4 QA agent is for error analysis (not success claims). The user is the implicit reviewer.	conductor/workflow.md §"Conductor Token Firewalling"
"Fix Critical issues immediately"	The Phase Completion Verification §5: "If verification failed, the agent will halt the workflow, present the detailed failure logs to the user, and await further instructions for debugging or remediation."	conductor/workflow.md
"Fix Important issues before proceeding"	The Pause-and-await-user-response pattern (per Phase Completion Verification §5)	conductor/workflow.md
"Note Minor issues for later"	The "deferred_to_followup_tracks" field in metadata.json is the project's pattern for "note for later"	conductor/tracks/<id>/metadata.json
"Ad-Hoc Development: review before merge"	The project doesn't use merge workflow (works on master directly per Section 8); "review before merge" doesn't apply	—
"Review when stuck"	The Deduction Loop rule: "If you've tried 3 times and the test still fails, STOP and report to the user" — the user provides fresh perspective	AGENTS.md §"Process Anti-Patterns" §1
"Before refactoring (baseline check)"	The "feature_bleed_cleanup_20260302" track was a baseline check before refactoring; "before refactoring" is the project's pattern for cruft_elimination style tracks	conductor/archive/feature_bleed_cleanup_20260302/
"Never skip review because 'it's simple'"	The per-task atomic commit + git note rule applies even for "simple" changes; no skip rule	conductor/workflow.md

11.3 Where the project already follows the discipline

• The per-task atomic commit + git note discipline is the project's "review" artifact. The user can review at any time by reading the git log + git notes; the project's state.toml records each task's commit_sha.
• The deferred_to_followup_tracks field in metadata.json is the project's "Note Minor issues for later" pattern. The 5 sub-tracks of the result_migration campaign are noted this way.
• The Phase Completion Verification "PAUSE and await the user's response" rule is the project's "Fix Critical issues immediately + Fix Important issues before proceeding" pattern.
• The Tier-4 QA agent (per Section 7) is the project's closest equivalent to a code reviewer subagent, but it's for error analysis, not for success claims or style review.

11.4 Where the project doesn't follow the discipline

• No dedicated "code reviewer" subagent. The project uses tier-4 QA for error analysis and the user for review. A code-quality reviewer (style, naming, structure) doesn't exist as a tier-4b.
• No "Ad-Hoc Development: review before merge" because the project doesn't use merge workflow.
• No explicit "Minor issues for later" deferral mechanism beyond metadata.json's deferred_to_followup_tracks field. Other categories of "minor" (style nits, naming) aren't tracked.

11.5 Recommendations summary

The project has the discipline's core elements (per-task atomic commits, git notes, user-as-reviewer, phase checkpoints, deferred_to_followup_tracks). The deferred rebuild may want to:

• MEDIUM: Consider a tier-4b "code quality reviewer" subagent for style/naming review (per Section 7 recommendation).
• LOW: Add a conductor/style_nits.md (or similar) pattern for tracking minor style issues. Currently they're absorbed into the per-commit git history.

Verdict.

Field	Value
Primary	PARITY
Integration tag	INTEGRATED
Section size	brief
Cross-refs	nagent_review_20260608 §10 (project's deferred_to_followup pattern); fable_review_20260617 §13 (project's "Genuinely Useful Patterns"); intent_dsl_survey_20260612 §6

Rationale. The project's per-task atomic commit + git note + state.toml SHA + Phase Completion Verification + deferred_to_followup_tracks is a faithful re-encoding of the skill's review request discipline. The "code reviewer subagent" pattern is replaced by the user-as-reviewer model (per Section 7's MMA architecture).

Recommended change. (blank — no rebuild action. The project's user-as-reviewer model is intentional.)

12. Finishing a Development Branch

12. Finishing a Development Branch

12.1 What the skill prescribes

The finishing-a-development-branch skill is the post-implementation decision flow. Core principle: "Verify tests → Detect environment → Present options → Execute choice → Clean up." The 6-step Process:

1. Verify Tests — Before presenting options, verify tests pass. If tests fail, stop. Don't proceed to Step 2.
2. Detect Environment — Determine workspace state before presenting options. GIT_DIR == GIT_COMMON → normal repo; GIT_DIR != GIT_COMMON + named branch → worktree; GIT_DIR != GIT_COMMON + detached HEAD → externally managed.
3. Determine Base Branch — Try git merge-base HEAD main or git merge-base HEAD master.
4. Present Options — Normal repo and named-branch worktree: present exactly 4 options (Merge locally, Push and create PR, Keep as-is, Discard). Detached HEAD: present exactly 3 options (no merge option).
5. Execute Choice — Per the user's choice: Option 1 = merge to base + delete branch + cleanup worktree; Option 2 = push + create PR (no worktree cleanup); Option 3 = keep as-is (no worktree cleanup); Option 4 = require typed "discard" confirmation + force-delete + cleanup worktree.
6. Cleanup Workspace — Only for Options 1 and 4. Use git worktree remove + git worktree prune. Provenance check: only clean up worktrees under .worktrees/, worktrees/, or ~/.config/superpowers/worktrees/. Harness-owned worktrees are NOT cleaned up.

Common Mistakes: Skipping test verification; open-ended questions ("What should I do next?"); cleaning up worktree for Option 2; deleting branch before removing worktree; running git worktree remove from inside the worktree; cleaning up harness-owned worktrees; no confirmation for discard.

Red Flags: Never proceed with failing tests; never merge without verifying tests on result; never delete work without confirmation; never force-push without explicit request; never remove a worktree before confirming merge success; never clean up worktrees you didn't create (provenance check); never run git worktree remove from inside the worktree.

12.2 Mapping to the project's existing pattern

The project works on master directly (per Section 8). The skill's branch management doesn't apply. The closest equivalents are the Phase Completion Verification and the project's track archival flow.

Skill rule	Project equivalent	Where
"Verify Tests before presenting options"	Phase Completion Verification §3 "Execute Automated Tests in Batches"	conductor/workflow.md
"Detect Environment: GIT_DIR vs GIT_COMMON"	Project works on master directly (per Section 8's ARCH-DIFF); no worktree detection needed	conductor/workflow.md
"Determine Base Branch"	Master is the only base branch in the project; no merge-base question	conductor/workflow.md
"Present Options: Merge locally / Push and Create PR / Keep as-is / Discard"	The project's Phase 10 finalize is simpler: register in tracks.md + update metadata.json. No merge/PR/keep/discard options.	conductor/tracks/<id>/plan.md Phase 10
"Option 1: Merge Locally + cleanup worktree"	Project does not merge; commits go directly to master. Archival is via git mv to conductor/archive/.	conductor/tracks.md §"Notes" — Archiving a track (3 steps)
"Option 2: Push and Create PR"	Project does not use GitHub PR workflow; commits go to master via per-task atomic commits	Project-wide
"Option 3: Keep as-is"	Implicit — every track stays in conductor/tracks/ until the user archives it	Project-wide
"Option 4: Discard (with typed confirmation)"	The "Inherited-Cruft Pattern" + HARD BANs on git restore/reset/stash (per AGENTS.md)	AGENTS.md §"Critical Anti-Patterns"
"Cleanup Workspace: provenance check"	n/a — project doesn't use worktrees	—
"Never merge without verifying tests on result"	The project's per-task atomic commits enforce "tests pass before commit"; this is upstream of the merge question	conductor/workflow.md §"Task Workflow" step 9
"Require typed 'discard' confirmation"	The HARD BANs on git restore, git reset, git stash* (per AGENTS.md) effectively require explicit user permission for any destructive operation	AGENTS.md §"Critical Anti-Patterns"
"Skipping test verification"	The Isolated-Pass Verification Fallacy rule catches this upstream	conductor/workflow.md §"Isolated-Pass Verification Fallacy"

12.3 Where the project already follows the discipline

• The "Verify Tests before presenting options" rule is enforced via Phase Completion Verification §3.
• The "Require typed discard confirmation" rule is enforced via the HARD BANs on git restore/reset/stash + the Inherited-Cruft Pattern (ASK the user before doing destructive work).
• The "never merge without verifying tests" rule is upstream-enforced via per-task atomic commits (tests pass before commit, not before merge).
• The "Open-ended questions" anti-pattern is implicitly avoided: the Phase Completion Verification protocol uses specific failure reporting.

12.4 Where the project doesn't follow the discipline

• No 4-option menu because the project doesn't use branch management. Phase 10 is a simpler artifact.
• No worktree cleanup because no worktrees.
• No "Merge locally" option because project doesn't merge.
• No "Push and create PR" option because project doesn't use GitHub PRs.

12.5 Recommendations summary

The project's master-direct workflow is a deliberate ARCH-DIFF from the skill. The discipline elements (verify tests, no destructive operations without confirmation, no skipping) are present via other rules. The deferred rebuild may want to:

• LOW: Document the ARCH-DIFF explicitly in conductor/workflow.md §"Task Workflow" step 9: "The project works on master directly. The finishing-a-development-branch skill's 4-option menu (merge/PR/keep/discard) does not apply. Instead, the project's track archival flow (3 steps per conductor/tracks.md §Notes) handles track completion."

Verdict.

Field	Value
Primary	ARCH-DIFF
Integration tag	INTEGRATED
Section size	brief
Cross-refs	nagent_review_20260608 §5 (durable work + disposable workers); fable_review_20260617 §13 (project's archival flow as "genuinely useful"); intent_dsl_survey_20260612 §6

Rationale. The project's master-direct workflow is an architectural difference from the skill's branch-management workflow. The discipline elements (verify tests, no destructive ops without confirmation, no skipping) are present via other rules. The skill's 4-option menu doesn't apply.

Recommended change. Document the ARCH-DIFF explicitly in conductor/workflow.md §"Task Workflow" step 9; consider promoting the track archival flow to a conductor/workflow.md §"Track Archival" section.

13. Using Git Worktrees

14. Writing Skills

15. MMA Skills Cluster

16. Dual-Convention + Anything Else