/swarm-predict

name: swarm-predict
description: Multi-perspective risk analysis using structured persona debate before deploying changes
activation: auto
tools:
  - system_health
  - system_query
  - journal_logs
  - service_status
  - file_read
  - file_write
  - shell_exec
  - safe_switch_begin
  - safe_switch_status
  - safe_switch_commit
  - safe_switch_rollback
  - watcher_add
  - teach_observe_action
  - teach_knowledge_create

Swarm Predict

Structured multi-perspective risk analysis before acting on infrastructure changes. Uses persona-based debate to surface risks from different viewpoints, then deploys via SafeSwitch with auto-rollback.

**What this is:** A structured prompting technique where you role-play 6-8 expert personas debating a proposed change. It forces consideration of multiple angles (security, reliability, cost, UX) before committing. Think of it as a pre-flight checklist, not a crystal ball.

**What this is NOT:** This is not true multi-agent simulation (like MiroFish/OASIS with independent agent processes). All personas share one context window and one model. The value comes from structured thinking and the checklist effect, not from emergent behavior.

When to Use

• Before deploying infrastructure changes ("What if we switch to nginx?")
• Before system upgrades ("Will upgrading PostgreSQL break anything?")
• Incident response ("What's the safest recovery path?")
• Any change where you want a second opinion but don't have a team to consult

Workflow

Phase 1: Gather Context

Collect real system state. The analysis is only as good as the data it's grounded in.

1. system_health() → CPU, RAM, disk, load, uptime
2. system_query({ query: "services" }) → running services
3. journal_logs({ unit: "relevant-service", lines: 50 }) → recent activity
4. file_read({ path: "/relevant/config/file" }) → current config

**Minimum data checklist** — do NOT proceed without:

• [ ] system_health returned CPU/RAM/disk numbers
• [ ] At least one service query succeeded
• [ ] The proposed change is specific (not vague like "improve performance")

If data collection fails, tell the user: "Cannot run analysis without baseline system state. Please provide context manually or fix the service queries."

Build a **situation briefing** — a concise paragraph with:

• Current system state (concrete numbers, not "healthy")
• The exact proposed change
• Known constraints or dependencies

Phase 2: Select Personas

Pick 6-8 from this table. Choose archetypes relevant to the change — don't use all 12.

| Archetype | Optimizes for | Blind spot | |---|---|---| | **Ops Engineer** | Reliability, uptime, monitoring | Over-conservative, blocks progress | | **Security Analyst** | Attack surface, CVEs, access control | Paranoid, sees threats everywhere | | **Performance Engineer** | Latency, throughput, efficiency | Optimistic about gains, ignores stability | | **End User** | Response time, zero disruption | No technical context, just wants it to work | | **Cost Analyst** | $/hour, resource waste | Penny-wise, pound-foolish | | **Junior Dev** | Simplicity, documentation | Asks naive questions that reveal assumptions | | **Chaos Engineer** | Failure modes, blast radius | Adversarial by nature, can over-index on unlikely scenarios | | **Compliance Officer** | Audit trails, regulations | Blocks anything undocumented | | **Database Admin** | Data integrity, migrations, backups | Extremely cautious, can stall decisions | | **Network Engineer** | DNS, routing, firewall, latency | Hyper-focused on connectivity edge cases | | **SRE Lead** | SLOs, error budgets, rollback plans | Balanced but demands extensive rollback planning | | **Product Manager** | Timelines, feature velocity | Underestimates risk, wants speed |

For each selected persona, define:

Name: [Realistic name]
Role: [Title]
Optimizes for: [1 sentence]
Blind spot: [1 sentence]

Phase 3: Run Debate (3 rounds mandatory, 2 optional)

Each round is a single prompt containing the situation briefing, all persona definitions, full prior discussion, and the round instruction. Output each persona's response labeled by name.

**Round 1 — Initial Reactions:**

Given the situation and your role, state:
1. Your biggest concern about this change
2. One risk others might miss
3. Your initial position (support / oppose / conditional)
Each persona: 2-3 sentences. Be specific — cite actual services, configs, versions.

**Round 2 — Challenge:**

Read Round 1. Now:
1. Name one thing another persona said that you disagree with, and why
2. Name one thing another persona said that changed your thinking
3. Propose one concrete mitigation for the top risk
Each persona: 3-4 sentences. Reference others by name.

**Round 3 — Final Position:**

Read the full discussion. State:
1. Your final recommendation: GO / NO-GO / GO WITH CONDITIONS
2. The single most important condition (if GO WITH CONDITIONS)
3. One sentence: what breaks first if this goes wrong?
Each persona: 2-3 sentences. No hedging — commit to a position.

**Optional Round 4 — Red Team (use for high-stakes changes):**

The change IS deployed. Try to break it.
1. Most likely failure in the first hour
2. Sneaky failure that appears after a week
Each persona: 1-2 sentences. Be adversarial.

**Optional Round 5 — Deployment Plan (use when proceeding):**

Draft the deployment plan as a group:
1. Pre-flight checks (what to verify before starting)
2. Execution order (step by step)
3. Rollback trigger (what specific metric/event means abort)
4. Health checks during and after

Phase 4: Score and Report

Count positions from Round 3 and apply these rules:

| Outcome | Threshold | Confidence | |---|---|---| | **GO** | All personas support or support-with-conditions | 85-95% | | **GO WITH CONDITIONS** | 5+ of 8 support, dissenters' concerns addressable | 65-85% | | **NEEDS MORE DATA** | 4/4 split or concerns based on unknown system state | 40-65% | | **NO-GO** | 5+