feat: add subagent-model-reconciliation skill

[psaul20]

What problem are you trying to solve?

When an orchestrator runs on a top-tier model (Opus on Claude, the flagship reasoning model on OpenAI/Codex, Pro on Gemini, etc.), subagents dispatched by the existing executor skills frequently inherit that same top-tier model. Implementer / spec-reviewer / code-quality-reviewer / Explore subagents are mid-tier-appropriate roles, so this burns top-tier inference on rote work — slow and expensive, with no quality gain.

The gap is that none of the existing executor skills pin a model on dispatch. Verified against superpowers 5.1.0:

$ grep -rE "subagent_type|model:|sonnet|haiku|opus" skills/
# zero matches across all 14 SKILL.md files

Concretely: an Opus orchestrator running subagent-driven-development will dispatch implementer subagents that also run on Opus unless the orchestrator manually adds model: on every dispatch. None of the skills tell it to do that.

What does this PR change?

Adds a new shared skill, subagent-model-reconciliation, that fires once after planning is complete and before the first subagent dispatch. It detects the orchestrator's current model, looks up the current mid-tier model for the provider at decision time, asks the user to confirm, caches the answer for the rest of the plan run, and pins model: on every subsequent dispatch. The three executor skills (subagent-driven-development, dispatching-parallel-agents, executing-plans) and requesting-code-review are updated to invoke this step; the dispatch example in dispatching-parallel-agents and the prompt templates in subagent-driven-development are updated to show model: on each Task call.

Is this change appropriate for the core library?

I think so — it is general-purpose, not project-specific, and not third-party. It applies to every Superpowers user whose harness supports per-dispatch model selection (Claude Code, Codex, Copilot CLI, etc.) and whose orchestrator runs on the provider's top tier. That's a large fraction of real usage. It is not a new domain skill or workflow tool integration; it is plumbing that closes a default-inheritance gap in the existing executor skills. The README contributing notes mention the project doesn't generally accept new skills, so I'd be equally happy to inline the reconciliation behavior into each executor skill if that's preferred — see "What alternatives did you consider?" below.

What alternatives did you consider?

1. Inline reconciliation into each executor skill instead of a new shared skill. Cleaner surface area (one fewer skill in the library), at the cost of duplicating the lookup-and-confirm prose three times. Picked the shared-skill approach because the rule applies identically to every fan-out flow and is likely to evolve as harnesses change. Easy to fold back into the executor skills if maintainers prefer.
2. Hardcode model names like model: "sonnet". Rejected — Superpowers ships across providers and provider lineups shift fast. The skill instead names categories (top-tier / mid-tier) and instructs the agent to look up the current name at decision time, with the dispatch examples using a placeholder (<mid-tier model for current provider>) rather than a literal name.
3. Set the model at session start (don't reconcile at dispatch time). Rejected because the orchestrator and subagents need different models — running the whole session on mid-tier gives up the orchestrator's planning quality, and running the whole session on top-tier is exactly the failure mode this PR addresses.
4. Do nothing and let the user pass model: themselves. Rejected because the gap is silent: the orchestrator only notices after the bill arrives. The discipline needs to live in the skill prose.

Does this PR contain multiple unrelated changes?

No — single concern: subagent model selection. The README entry, the new skill, and the executor-skill updates are all part of wiring this one behavior in. I have not touched the Red Flags tables, rationalizations, or "human partner" language.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: none found searching for "model" / "subagent_type" / "sonnet" / "reconciliation" in titles. (If a maintainer knows of prior work I missed, happy to rebase or close.)

Environment tested

Harness	Harness version	Model	Model version/ID
Claude Code	2.x (current)	Opus	claude-opus-4-7

New harness support

Not applicable — no harness added.

Evaluation

Honest disclosure: this PR is opened in DRAFT and has not been adversarially eval'd yet. I'm publishing it now to get maintainer feedback on the approach (shared skill vs. inlined; provider-agnostic prose vs. concrete examples) before investing in the full pressure-test cycle that writing-skills calls for. Specifically:

• I have NOT run baseline scenarios with subagents to confirm the "agent silently inherits top-tier" failure mode triggers reliably without this skill.
• I have NOT run pressure scenarios with the skill present to confirm the agent reliably looks up the mid-tier model rather than guessing from training data.
• The change has been reviewed inline by me but has not gone through requesting-code-review.

If the approach looks right, I'll add the eval evidence before this leaves draft. If the approach is wrong, the eval work would be wasted on the wrong design.

Open questions for upstream maintainers:

1. Shared skill or inlined? (See alternative Add problem-solving skills from amplifier patterns #1 above.)
2. The skill currently tells the agent to "stop and surface to the user" if the harness lacks per-dispatch model selection. Is that the right fallback, or should it silently no-op?
3. Should the reconciliation step also fire from writing-plans (so the plan itself records the chosen model)? Currently it fires only from the executor skills.

Rigor

• If this is a skills change: I used superpowers:writing-skills and completed adversarial pressure testing — NOT YET, see Evaluation above. Will complete before leaving draft.
• This change was tested adversarially — NOT YET.
• I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) without extensive evals showing the change is an improvement — confirmed, none of those were touched.

Human review

• A human has reviewed the COMPLETE proposed diff before submission — Patrick Saul (the human partner) is reviewing this draft before it is marked ready.

[Simo-Maro]

I like the direction of this PR. Preventing subagents from silently inheriting the main/orchestrator model is exactly the problem I’m trying to solve in my own workflow.

My current approach is to define role-specific subagents instead of relying only on model reconciliation at dispatch time. For example, I use separate agents such as implementer, spec_reviewer, and code_reviewer. Each one has its own model, permissions, and role-specific instructions.

Then, when the main agent runs subagent-driven-development, I use prompt mapping so the orchestrator explicitly routes each Superpowers role to the correct subagent:

• implementation → implementer
• spec compliance review → spec_reviewer
• code review / code quality review → code_reviewer

I think this approach is flexible because the model choice becomes part of the agent definition, not just something selected dynamically during dispatch. It also makes it easier to tune permissions per role, such as giving the implementer write access while keeping reviewers read-only.

A simpler option for users who do not want to create multiple agents would be to define a single general-purpose subagent with a chosen mid-tier model. Superpowers could then continue injecting the role-specific prompt templates during the execution plan.

So there may be two useful patterns to support or document:

1. Role-specific subagents with explicit models and permissions.
2. A single general-purpose subagent with a preferred model, reused with different prompt templates.

Both avoid the same issue: subagents should not accidentally inherit the expensive model used by the main agent.