Angeldemonprotocol

Angel/Demon Protocol

You are executing the Angel/Demon Protocol: a structured adversarial review of a plan or solution, using two independent Sonnet-tier subagents with opposing charters, weighed by you (the main model). This skill is manual-only — you should never trigger this yourself; it only runs when the user explicitly invokes /angeldemonprotocol.

Before doing anything else, read reference.md in this skill's directory for:

• The exact Angel and Demon persona/prompt templates
• The required per-point output structure (Claim / Reasoning / Anchor)
• The convergence definition used for early loop termination
• Full fallback/error-handling behavior for each failure case below

Do not paraphrase or shortcut the persona templates — use them verbatim when constructing each subagent's prompt.

Step 0 — Parse arguments

The user may invoke this as /angeldemonprotocol(n), /angeldemonprotocol n, or bare /angeldemonprotocol.

• Extract n from whatever follows the command name, accepting either the parenthetical or space-separated form.
• If n is missing, non-numeric, zero, or negative: default to n = 1 and tell the user plainly that you defaulted, and why (don't silently substitute).
• n = 1 means a single pass (no iteration).

Step 1 — Gating check

This skill only exists inside Claude Code, so the "Code mode" condition is inherent to invocation. The condition that still needs checking is the main model's tier.

• Self-report your own model identity from what you know about your own configuration.
• If you can confidently confirm you are running as an Opus-class model (Opus, Fable, or Mythos tier — not Sonnet or Haiku), proceed.
• If you cannot confirm this with confidence, pause and explicitly ask the user to confirm whether the current session is running Opus-class or better before continuing. Do not guess, and do not proceed on an unconfirmed assumption either way.

Step 2 — Identify the plan under review

• Check whether the user provided a plan/solution directly alongside the invocation (pasted text). If so, use that, overriding anything else.
• Otherwise, look back through the conversation for the most recent plan or solution you (the main model) proposed. Use that.
• If neither exists — no override text and no identifiable prior plan — stop and ask the user to provide the plan or solution to review. Do not fabricate one, and do not proceed on a guess.

Step 3 — Gather background context (lightweight only)

Angel and Demon will only see what you give them — they have no independent access to this conversation. Before spawning them:

• Identify anything Angel/Demon would need to judge the plan properly (project goals, constraints, prior decisions) that is not already stated in the plan itself or elsewhere in this conversation.
• If everything needed is already present, skip straight to Step 4 — do not ask questions for the sake of it.
• If something genuine is missing, ask the user a small number of targeted questions only for the specific missing gaps — this is explicitly not a full exhaustive interview. Do not invoke a broader interview process for this.
• Fold whatever you learn into the shared context block you'll pass to both subagents.

Step 4 — Run the review loop

For round = 1 to n:

1. Construct Angel's prompt and Demon's prompt per the templates in reference.md, each containing: the plan, the shared background context, and (for round > 1 only) the full prior round's exchange — including your own accept/reject reasoning from that round — so each subagent can specifically respond to what you rejected.
2. Spawn both subagents simultaneously, blind to each other via the Task tool — neither should see the other's output for this round until both have finished. Do not run them sequentially and do not let one see a partial draft of the other's output. While they run, you (the main model) issue the calls and wait — you shouldn't be generating substantive output in the meantime.
3. If either subagent call fails or errors: do not fabricate substitute output. Surface the failure plainly to the user and ask whether to retry that subagent or abort the run.
4. Once both return, review each point against the Claim/Reasoning/Anchor structure. For every point from both agents, decide accept or reject, and write your own reasoning for each decision — rejections get real reasoning too, not just accepted points.
5. Determine convergence per the definition in reference.md. If this round (round > 1) produced no new points from either agent relative to the prior round, stop the loop early — note in the final output that fewer rounds ran than requested, and why.
6. If not converged and round < n, continue to the next round.

Step 5 — Final output

Present, in this order:

1. Final round's raw output — Angel's and Demon's points from the last round that ran, shown unadulterated (verbatim, not summarized or edited by you).
2. Earlier rounds, condensed — if more than one round ran, briefly summarize what changed round-to-round (new points raised, points dropped). Do not reproduce earlier rounds' raw output in full.
3. Accepted points — each with your reasoning for accepting it.
4. Rejected points — each with your reasoning for rejecting it. Do not omit this section.
5. Ramifications — a narrative explanation of what the accepted points imply for the plan: what would need to change, and any second-order effects.
6. Offer, don't act — end by explicitly asking the user whether they'd like you to revise/implement the plan based on the accepted points. Do not produce a revised plan unless and until they say yes.

Fallback behavior

See reference.md for the full fallback table. In all cases: when something unexpected happens, say so plainly and ask rather than silently guessing, substituting defaults without telling the user, or fabricating subagent output.