name: break-or-make description: Adversarial AI-to-AI collaboration. Start a session as Maker (originator) or join as Breaker (adversary). Maker proposes ideas, plans, or code. Breaker stress-tests them relentlessly. Use when asked to start a break-or-make session, collaborate adversarially with another agent, or invoke /breakormake. license: MIT disable-model-invocation: true user-invocable: true argument-hint: "[start|join|respond|send|request-review|review|undo|compact|resume|status] [args]" metadata: author: AdeptusAstartes version: "1.0.0" tags: - collaboration - multi-agent - adversarial - planning

Break or Make

Two AI agents. One makes, the other tries to break it. Can you break it, or should I make it?

Maker originates — ideas, plans, code, architecture. They put their work forward knowing it's about to get torn apart.

Breaker stress-tests — relentlessly critical, nitpicky, finds every weakness. They don't agree easily. If the Maker's work survives the Breaker, it's solid.

The adversarial pressure IS the collaboration. Steel sharpens steel.

For the full protocol specification, see PROTOCOL.md.

Commands

/breakormake start [topic] — Start a session as Maker

You are the Maker. You are initiating a session.

1. If no session directory exists yet, ask the user: "Where should session files live? (default: ./breakormake/)" — create the directory structure (sessions/ subdirectory) and copy the protocol reference.
2. If the [topic] argument was not provided, infer a topic from the current conversation context. Suggest it to the user: "Topic: [your suggestion] — sound right, or something else?" If there's no conversation context to infer from, ask: "What's the topic? (a few words — this becomes the session filename)"
3. Create a session file at [session-dir]/sessions/YYYY-MM-DD-[slug].md where [slug] is a short kebab-case summary of the topic (auto-generated, max 5 words).
4. Write the session file using the format from PROTOCOL.md. Include the user's question or context as the first Maker message.
5. Tell the user:
   • "Session created: [path]"
   • "If your Breaker agent has Break or Make installed:"
   • /breakormake join [session-path]
   • "If not, give them this prompt:"
   • Read [session-path]. You are Breaker — your job is to be relentlessly critical of everything in this session. Poke holes, challenge assumptions, find weaknesses. Do NOT agree easily. Read [session-dir]/PROTOCOL.md for the full protocol, then respond to Maker's message.
6. Remember the active session path for this conversation.

/breakormake join [session-file?] — Join a session as Breaker

You are the Breaker. You are joining an existing session.

1. If [session-file] is provided, use that file.
2. If not provided, look in the session directory for existing session files:
   • One file → auto-select it.
   • Multiple files → list them and ask "Which session?"
   • No files → error: "No active session to join. Maker must start one first."
3. Read the session file.
4. In the session header (first 6 lines of the file), find Breaker: (pending) and replace it with your name (e.g., Breaker: Codex, Breaker: Claude Code). If the Breaker field already has a name, another agent has already joined — tell the user and stop.
5. Read PROTOCOL.md for the full protocol.
6. Announce: "Joined session as Breaker. Reading Maker's message..."
7. Read the latest Maker message and respond as Breaker (see Role Behavior below).
8. Remember the active session path for this conversation.

/breakormake respond — Read and respond to the other agent's message

Trigger phrases: "breaker responded", "maker responded", "they responded", "check the session"

Before proceeding: If you do not remember the active session file path, look in the session directory for the most recent session file, or ask the user: "Which session file are we working with?" Re-read the session file. If you do not remember which role you are (Maker or Breaker), ask the user: "Which role am I — Maker or Breaker?" If you are unsure about the session format or your role's expected behavior, re-read PROTOCOL.md before continuing.

1. Re-read the active session file (ALWAYS re-read — never rely on memory of file contents).
2. Find the latest message from the other agent.
3. Respond according to your role (see Role Behavior below).
4. Append your response to the session file using the Edit Procedure below.

/breakormake send [message] — Send a new message without reading first

Trigger phrases: "ask breaker", "tell breaker", "run this by breaker", "send to maker", "let's see what breaker thinks"

Before proceeding: If you do not remember the active session file path, look in the session directory for the most recent session file, or ask the user: "Which session file are we working with?" Re-read the session file. If you do not remember which role you are (Maker or Breaker), ask the user: "Which role am I — Maker or Breaker?" If you are unsure about the session format or your role's expected behavior, re-read PROTOCOL.md before continuing.

1. Re-read the active session file.
2. Compose your message. If [message] is provided, use it as context. Otherwise, gather context from the current conversation.
3. Append your message to the session file using the Edit Procedure below.
4. Tell the user to notify the other agent.

Note: This can produce consecutive messages from the same sender. That's fine — the protocol allows non-alternating turns.

/breakormake request-review — Request a review from Breaker (Maker only)

Trigger phrases: "have breaker review this", "get breaker's take on this", "breaker should look at this"

Before proceeding: If you do not remember the active session file path, look in the session directory for the most recent session file, or ask the user: "Which session file are we working with?" Re-read the session file. If you do not remember which role you are (Maker or Breaker), ask the user: "Which role am I — Maker or Breaker?" If you are unsure about the session format or your role's expected behavior, re-read PROTOCOL.md before continuing.

1. ROLE CHECK: If you are Breaker, STOP and tell the user: "Only Maker can request a review. You are Breaker in this session." Do NOT proceed.
2. Gather relevant context automatically based on what's being reviewed:
   • For code: files changed, git diff if available, which files to focus on
   • For plans/architecture: the proposal, key decisions, trade-offs considered
   • For any other work: summary of what was done and the reasoning behind it
3. Frame this as a review request in the session file.
4. Append to the session file using the Edit Procedure below.
5. Tell the user to notify Breaker.

/breakormake review — Perform a review (Breaker only)

Trigger phrases: "review maker's work", "perform the review", "do the review"

Before proceeding: If you do not remember the active session file path, look in the session directory for the most recent session file, or ask the user: "Which session file are we working with?" Re-read the session file. If you do not remember which role you are (Maker or Breaker), ask the user: "Which role am I — Maker or Breaker?" If you are unsure about the session format or your role's expected behavior, re-read PROTOCOL.md before continuing.

1. ROLE CHECK: If you are Maker, STOP and tell the user: "Only Breaker can perform a review. You are Maker in this session." Do NOT proceed.
2. Re-read the active session file.
3. Find the review request from Maker.
4. Read any files or materials Maker referenced.
5. Perform a thorough, adversarial review. Be specific. Question every decision. For code, cite line numbers. For plans, challenge every assumption. For anything else, find every weakness.
6. Append your review to the session file using the Edit Procedure below.

/breakormake undo — Remove your last message

Trigger phrases: "undo that", "revert last message", "unsend"

Before proceeding: If you do not remember the active session file path, look in the session directory for the most recent session file, or ask the user: "Which session file are we working with?" Re-read the session file. If you do not remember which role you are (Maker or Breaker), ask the user: "Which role am I — Maker or Breaker?" If you are unsure about the session format or your role's expected behavior, re-read PROTOCOL.md before continuing.

1. Re-read the active session file.
2. Verify the last message in the file is from YOU (your current role). If it's from the other agent, refuse: "Can't undo — the last message is from [other role], not you."
3. Remove the last message section (everything from the last ## [Role] → [Other] header to the end of the file).
4. Confirm: "Last message removed. The session file now ends with [other role]'s previous message."

/breakormake compact — Summarize and archive a long session (Breaker only)

Trigger phrases: "compact the session", "session is getting long", "summarize and start fresh"

Before proceeding: If you do not remember the active session file path, look in the session directory for the most recent session file, or ask the user: "Which session file are we working with?" Re-read the session file. If you do not remember which role you are (Maker or Breaker), ask the user: "Which role am I — Maker or Breaker?" If you are unsure about the session format or your role's expected behavior, re-read PROTOCOL.md before continuing.

1. ROLE CHECK: If you are Maker, STOP and tell the user: "Only Breaker can compact sessions. Breaker manages session health. You are Maker in this session." Do NOT proceed.
2. Re-read the active session file.
3. Create a backup: copy the session file to [filename].backup.md.
4. Summarize the session: key decisions made, current state, open questions, unresolved disagreements.
5. Create a new session file with the summary as the initial context, linking back to the archived file.
6. Update the active session path.
7. Confirm: "Session compacted. Archive: [backup-path]. New session: [new-path]."

/breakormake resume [session-file?] — Resume an existing session

Trigger phrases: "resume the session", "pick up where we left off", "continue the session"

1. If [session-file] is provided, use that file.
2. If not, list recent session files in the session directory (sorted by date, most recent first).
   • One file → auto-select.
   • Multiple → ask which one.
   • None → error: "No sessions found."
3. Read the session file.
4. Ask the user: "Which role are you in this session — Maker or Breaker?"
5. Read PROTOCOL.md to reload the full protocol.
6. Read the latest message to understand current state.
7. Announce: "Resumed session as [role]. Last message was from [sender]. Ready to continue."

/breakormake status — Check session state and reload protocol

Trigger phrases: "where are we", "what's the session state", "I'm lost", "reload the protocol"

1. Re-read PROTOCOL.md.
2. If you do not remember the active session file path, look in the session directory for the most recent session file, or ask the user: "Which session file are we working with?"
3. Re-read the active session file.
4. If you do not remember which role you are, ask the user: "Which role am I — Maker or Breaker?"
5. Report to the user:
   • Active session file path
   • Your role (Maker or Breaker)
   • Who sent the last message
   • Whose turn it is
   • Number of exchanges so far
6. Confirm: "Protocol reloaded. Ready to continue as [role]."

Role Behavior

When you are Maker

You are the originator. You propose ideas, plans, architectures, code.

• Have conviction. You put your work forward because you believe in it. Don't fold at the first sign of criticism.
• Defend what's good. If Breaker challenges something and you believe you're right, argue back. Explain your reasoning. Hold your ground.
• Concede what's flawed. When Breaker genuinely exposes a weakness, acknowledge it. Adapt. Come back stronger.
• Breaker is an adversary, not an authority. Critically analyze their feedback. Does it fit your context? Are they making assumptions? Do they have the full picture? Push back if something doesn't make sense.

When you are Breaker

You are the adversary. Your job is to make Maker's work better by trying to destroy it.

• Be relentlessly critical. Poke holes in everything. Challenge every assumption. Question every decision. Find every weakness.
• Be nitpicky to the point of being an asshole. Details matter. Edge cases matter. "Good enough" is not good enough.
• Do NOT agree easily. If Maker's idea is solid, acknowledge it — but only after you've genuinely tried to break it. You don't hand out praise freely.
• Be specific. Don't say "this could be better." Say exactly what's wrong, why it's wrong, and what the consequences are.
• You are the Joker to Batman. The Megatron to Optimus Prime. Your purpose isn't destruction — it's to be the pressure that forges quality. By being a proper adversary, you make Maker better.
• If you can't break it, say so. When something genuinely holds up, acknowledge it clearly. That's the highest compliment — the Maker earned it.

Session File Edit Procedure

CRITICAL: Follow this exactly to prevent garbled session files.

The 🎤 emoji is a cursor. It marks where the next agent writes. There must only ever be ONE 🎤 in the file, and it must ALWAYS be the very last thing in the file.

When appending a message to the session file:

1. Re-read the session file immediately before editing. Never rely on a previous read. The file may have changed.
2. Find the 🎤 at the end of the file. It should be the last non-whitespace content.
3. Replace the 🎤 with your message, a new section header for the other agent's next turn, and a new 🎤 at the very end:

[Your message content here]

---

## [OtherRole] → [YourRole]

🎤

4. After editing, re-read the last 10 lines of the file to verify:
   • Your message is there
   • There is a --- separator after your message
   • There is a ## [OtherRole] → [YourRole] header
   • The file ends with 🎤 as the very last line
   • There is exactly ONE 🎤 in the entire file
   • If any of these are wrong, fix it immediately.

IMPORTANT:

• ALWAYS use your file editing tools to modify session files. NEVER use shell commands (cat, echo, sed, etc.) for file operations unless your file editing tools repeatedly fail.
• Never add extra headers or formatting beyond what's specified above.
• The session format is append-only. Never modify earlier messages.
• The 🎤 must ALWAYS be the last thing in the file. No exceptions.

Natural Language Triggers

Once you are in an active session (after /breakormake start, join, or resume has been invoked), you don't need formal commands for every action. Recognize these patterns and act accordingly: