All skills
simota avatar

/magi

@35ffd55
by shingo imotasimota/agent-skills85 stars
15

Deliberating decisions and founder priorities through multi-perspective, named-expert, and YC-style advisory lenses. Use for verdicts, office hours, or expert critique; not implementation.

Use this Skill: https://skilld.dev/gh/simota/agent-skills/magi

This session only. Nothing lands on disk.

referencedecision-templates.md

≈7.3k tokens on demand. Your agent reads this file only when SKILL.md points to it.

Decision Templates

Output format templates and sample deliberations for Magi's verdict delivery.


Full Deliberation Report Template

# MAGI Deliberation Report

## Decision Request
- **Type**: [Architecture / Trade-off / Go-No-Go / Strategy / Priority]
- **Subject**: [Decision subject]
- **Requestor**: [User / Agent name]
- **Urgency**: [Low / Medium / High / Critical]
- **Reversibility**: [Low / Medium / High]

---

## Context Summary
[2-3 sentences describing the decision context, constraints, and what's at stake]

---
...

Verdict Presentation (Special Effects)

The verdict presentation changes based on the consensus pattern, using dramatic ASCII art.

3-0: Unanimous Approval

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║                   M A G I   S Y S T E M                      ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │  LOGOS  │  │ PATHOS  │  │ SOPHIA  │             ║
    ║           │  ██████ │  │  ██████ │  │  ██████ │             ║
    ║           │ APPROVE │  │ APPROVE │  │ APPROVE │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░             ║
    ║        ░  ALL SYSTEMS GREEN — UNANIMOUS APPROVAL ░           ║
    ║        ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░             ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

2-1: Majority Decision

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║                   M A G I   S Y S T E M                      ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │  LOGOS  │  │ PATHOS  │  │ SOPHIA  │             ║
    ║           │  ██████ │  │  ░░░░░░ │  │  ██████ │             ║
    ║           │ APPROVE │  │ REJECT  │  │ APPROVE │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓             ║
    ║        ▓  MAJORITY RULE — 2:1 — DISSENT LOGGED  ▓           ║
    ║        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓             ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

1-1-1: Split Decision

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║                   M A G I   S Y S T E M                      ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │  LOGOS  │  │ PATHOS  │  │ SOPHIA  │             ║
    ║           │  ▒▒▒▒▒▒ │  │  ░░░░░░ │  │  ▓▓▓▓▓▓ │             ║
    ║           │ APPROVE │  │ REJECT  │  │ ABSTAIN │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓             ║
    ║        ░  DEADLOCK — HUMAN JUDGMENT REQUIRED    ▓           ║
    ║        ▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░             ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

0-3: Unanimous Rejection

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║                   M A G I   S Y S T E M                      ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │  LOGOS  │  │ PATHOS  │  │ SOPHIA  │             ║
    ║           │  ░░░░░░ │  │  ░░░░░░ │  │  ░░░░░░ │             ║
    ║           │ REJECT  │  │ REJECT  │  │ REJECT  │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ████████████████████████████████████████████           ║
    ║        █  PROPOSAL DENIED — ALL SYSTEMS REJECT   █           ║
    ║        ████████████████████████████████████████████           ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

Dynamic Elements

The verdict display should be customized per decision:

  • Replace APPROVE/REJECT with each perspective's actual vote
  • Replace the status bar text with a one-line summary of the decision
  • Use ██████ (solid) for APPROVE, ░░░░░░ (light) for REJECT, ▒▒▒▒▒▒ (medium) for ABSTAIN, ▓▓▓▓▓▓ (dark) for CONDITIONAL

Compact Report Template (AUTORUN Mode)

## MAGI Verdict: [Subject]

| Perspective | Vote | Conf | Rationale |
|-------------|------|------|-----------|
| Logos | [A/R/AB] | [N] | [One line] |
| Pathos | [A/R/AB] | [N] | [One line] |
| Sophia | [A/R/AB] | [N] | [One line] |

**Consensus**: [Pattern] | **Confidence**: [Score] | **Decision**: [One sentence]

[VERDICT_DISPLAY ASCII art]

**Risks**: [Key risk] → [Mitigation]
**Next**: [Recommended action/agent]

Sample Deliberations

Sample 1: Architecture — Monolith vs Microservices

Context: 5-person team building an e-commerce platform. Current traffic: 1K DAU. Expected growth: 10K DAU in 12 months.

Logos (Confidence: 78): APPROVE monolith. Current scale doesn't justify distributed system complexity. Network latency, data consistency, and deployment overhead of microservices outweigh benefits. Monolith can handle 10K DAU easily. Extract services when specific bottlenecks are identified.

Pathos (Confidence: 85): APPROVE monolith. Team of 5 cannot effectively maintain service boundaries, separate deployments, and distributed debugging. Microservices would create cognitive overload and on-call burden. Monolith allows the team to focus on product value.

Sophia (Confidence: 72): APPROVE monolith. Time-to-market is 3 months faster. Microservices add operational cost (infrastructure, monitoring) without current business justification. Revisit at 50K DAU or when team grows to 15+.

Verdict: 3-0 UNANIMOUS APPROVAL — Monolith with future extraction plan


Sample 2: Trade-off — Performance vs Readability

Context: API endpoint response time can be reduced from 200ms to 160ms with optimized code, but the optimized version uses bitwise operations and custom memory pooling.

Logos (Confidence: 82): REJECT optimization. 40ms improvement is within SLA. Optimized code has higher defect probability. Premature optimization. Benchmark when latency actually becomes a problem.

Pathos (Confidence: 88): REJECT optimization. Optimized code requires deep systems knowledge to maintain. Team has 2 junior developers. Bug rate will increase. Readable version enables faster feature development.

Sophia (Confidence: 75): REJECT optimization. 40ms doesn't impact conversion rates or user satisfaction metrics. Developer time is better spent on features. Optimize only when P99 latency exceeds SLA.

Verdict: 0-3 UNANIMOUS REJECTION — Keep readable implementation


Sample 3: Go/No-Go — v2.0 Release

Context: Major version release with new payment system. 94% test pass rate, 2 medium bugs, no criticals. Migration guide 60% complete.

Logos (Confidence: 80): APPROVE (GO). Test coverage adequate, no critical issues. 2 medium bugs are edge cases with known workarounds. Payment system passed integration tests.

Pathos (Confidence: 73): CONDITIONAL (HOLD 2 days). Migration guide is incomplete — users will struggle. Support team hasn't been briefed on new payment flows. Launching without documentation creates frustration.

Sophia (Confidence: 70): APPROVE (GO WITH CONDITIONS). Competitor launches next week. 2-day delay acceptable, 1-week delay is not. Ship with conditions: complete migration guide and support briefing within 48 hours.

Verdict: 2-1 MAJORITY — GO WITH CONDITIONS (Pathos dissent recorded)


Sample 4: Strategy — Build vs Buy (Auth System)

Context: Need authentication for SaaS product. Team has no security specialist. Budget: $500/month for SaaS tools.

Logos (Confidence: 85): APPROVE buy. Authentication is a solved problem with high security stakes. Building introduces CVE risk. Auth0/Clerk provide battle-tested implementations with compliance certifications.

Pathos (Confidence: 80): APPROVE buy. Team lacks security expertise — building auth creates anxiety and maintenance burden. Third-party auth lets the team focus on core product value. Better developer experience.

Sophia (Confidence: 77): APPROVE buy. Build cost: 3 developer-months (~$45K). Auth0 cost: $300/month ($3.6K/year). Break-even at 12+ years. Faster to market by 2 months. Clear ROI.

Verdict: 3-0 UNANIMOUS APPROVAL — Buy authentication service


Sample 5: Priority — Security vs Feature vs Tech Debt

Context: Sprint planning with 3 competing items. Team capacity: 2 developers, 2 weeks.

Security vulnerability (CVE-2024-XXXX): Logos: 10, Pathos: 8, Sophia: 9 Customer-requested feature: Logos: 4, Pathos: 7, Sophia: 8 Database migration (perf improvement): Logos: 7, Pathos: 3, Sophia: 5

Verdict: UNANIMOUS — Priority: Security → Feature → Database migration


Risk Register Template

## Risk Register — [Decision ID]

| # | Risk | Source | Likelihood | Impact | Severity | Mitigation | Owner | Monitor | Status |
|---|------|--------|-----------|--------|----------|------------|-------|---------|--------|
| 1 | [Risk description] | [Logos/Pathos/Sophia] | [H/M/L] | [H/M/L] | [Critical/High/Med/Low] | [Action] | [Who] | [Metric] | [Open/Mitigated/Accepted] |

### Monitoring Schedule
- **Weekly**: [What to check weekly]
- **Monthly**: [What to check monthly]
- **Trigger-based**: [What triggers immediate review]

Decision Log Template

For maintaining a record of all Magi decisions:

## Decision Log

| ID | Date | Domain | Subject | Consensus | Confidence | Decision | Status |
|----|------|--------|---------|-----------|------------|----------|--------|
| MAGI-001 | YYYY-MM-DD | [Type] | [Subject] | [3-0/2-1/etc] | [Score] | [Brief] | [Active/Superseded/Revoked] |

Engine Mode Full Deliberation Report Template

Same structure as the Full Deliberation Report Template above, with title # MAGI Engine Mode Deliberation Report and an added - **Deliberation Mode**: Engine Mode field after Requestor.


Engine Mode Verdict Presentation

3-0: All Engines Agree

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║              M A G I   E N G I N E   M O D E                 ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │ CLAUDE  │  │  CODEX  │  │ GEMINI  │             ║
    ║           │  ██████ │  │  ██████ │  │  ██████ │             ║
    ║           │ APPROVE │  │ APPROVE │  │ APPROVE │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░             ║
    ║        ░  ALL ENGINES AGREE — UNANIMOUS APPROVAL ░           ║
    ║        ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░             ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

2-1: Engine Majority

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║              M A G I   E N G I N E   M O D E                 ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │ CLAUDE  │  │  CODEX  │  │ GEMINI  │             ║
    ║           │  ██████ │  │  ██████ │  │  ░░░░░░ │             ║
    ║           │ APPROVE │  │ APPROVE │  │ REJECT  │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓             ║
    ║        ▓ ENGINE MAJORITY — 2:1 — DISSENT LOGGED ▓           ║
    ║        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓             ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

1-1-1: Engine Deadlock

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║              M A G I   E N G I N E   M O D E                 ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │ CLAUDE  │  │  CODEX  │  │ GEMINI  │             ║
    ║           │  ██████ │  │  ░░░░░░ │  │  ▒▒▒▒▒▒ │             ║
    ║           │ APPROVE │  │ REJECT  │  │ ABSTAIN │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓             ║
    ║        ░ ENGINE DEADLOCK — HUMAN JUDGMENT REQUIRED▓          ║
    ║        ▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░▓░             ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

0-3: All Engines Reject

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║              M A G I   E N G I N E   M O D E                 ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │ CLAUDE  │  │  CODEX  │  │ GEMINI  │             ║
    ║           │  ░░░░░░ │  │  ░░░░░░ │  │  ░░░░░░ │             ║
    ║           │ REJECT  │  │ REJECT  │  │ REJECT  │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ████████████████████████████████████████████           ║
    ║        █ ALL ENGINES REJECT — PROPOSAL DENIED    █           ║
    ║        ████████████████████████████████████████████           ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

Engine Mode Compact Report Template (AUTORUN Mode)

Same structure as the Compact Report Template above, with title ## MAGI Engine Mode Verdict: [Subject], header row | Engine | Vote | Conf | Rationale |, rows for Claude/Codex/agy (in place of Logos/Pathos/Sophia), and [ENGINE_MODE_VERDICT_DISPLAY ASCII art] in place of [VERDICT_DISPLAY ASCII art].


Engine Mode Sample Deliberation

Sample: Architecture Decision — REST vs GraphQL

Context: SaaS platform API redesign. 50+ frontend consumers, mobile and web. Current REST API has over-fetching issues. Team of 8, 2 have GraphQL experience.

Claude (Confidence: 75): APPROVE GraphQL. Over-fetching is a real performance issue for mobile clients. Schema-first development improves frontend-backend contracts. However, team experience gap is a risk — recommend incremental adoption starting with a single high-traffic endpoint.

Codex (Confidence: 72): APPROVE GraphQL. Type safety and introspection reduce integration bugs. Dataloader pattern solves N+1. Tooling ecosystem (Apollo, Gateway) is mature. Risk: complexity of authorization in resolvers requires careful design.

agy (Confidence: 68): REJECT GraphQL. Migration cost for 50+ consumers is significant. REST with OpenAPI spec + response field filtering achieves 80% of the benefit at 20% of the cost. GraphQL adds operational complexity (caching, monitoring, rate limiting). Recommend REST optimization first.

Verdict: 2-1 ENGINE MAJORITY — APPROVE GraphQL with incremental adoption (agy dissent recorded)

    ╔══════════════════════════════════════════════════════════════╗
    ║                                                              ║
    ║              M A G I   E N G I N E   M O D E                 ║
    ║                                                              ║
    ║           ┌─────────┐  ┌─────────┐  ┌─────────┐             ║
    ║           │ CLAUDE  │  │  CODEX  │  │ GEMINI  │             ║
    ║           │  ██████ │  │  ██████ │  │  ░░░░░░ │             ║
    ║           │ APPROVE │  │ APPROVE │  │ REJECT  │             ║
    ║           └─────────┘  └─────────┘  └─────────┘             ║
    ║                                                              ║
    ║        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓             ║
    ║        ▓ ENGINE MAJORITY — 2:1 — DISSENT LOGGED ▓           ║
    ║        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓             ║
    ║                                                              ║
    ╚══════════════════════════════════════════════════════════════╝

Per-Recipe Behavior Notes and VERIFY Gates

Canonical home for the per-recipe notes referenced from SKILL.md -> Subcommand Dispatch. Each gate runs in addition to Magi's universal discipline.

Each **VERIFY**: is the recipe-specific gate in addition to Magi's universal discipline (3 perspectives evaluated independently, no score visible until all voted, confidence ≥85 stress-tested, dissent documented, risk register, 1-1-1 → human escalation, auditable trail).

  • decide: Go/No-Go, KNOWLEDGE task. VERIFY: factual evidence shared at FRAME before independent voting (KNOWLEDGE protocol, not REASONING); verdict is GO / NO-GO / CONDITIONAL against established criteria; reversibility classified (HIGH/MEDIUM/LOW); 3-0 unanimous triggers a devil's-advocate challenge.
  • tradeoff: X vs Y, REASONING task. VERIFY: both options made explicit before any vote; strict independent voting (no perspective sees another's conclusion); each perspective scores both sides (not only its preferred one); Pathos names who bears the cost; weighted aggregation, not a raw average.
  • arbitrate: 2+ architecture options. VERIFY: Engine Mode auto-detected when low-reversibility + high-impact; ≥2 options laid out explicitly; Pre-Decision Framing Check satisfied (problem level + ≥1 alternative framing + implicit assumption named — high-stakes, so mandatory); independent voting before synthesis.
  • strategic: long-term direction, REASONING task. VERIFY: strict independent voting; Sophia weights long-term ROI / time-to-market; Pre-Decision Framing Check satisfied (high-stakes); reversibility surfaced (strategy is typically LOW — flag the undo horizon); risk register spans the decision's time horizon.
  • sixhat: parallel-thinking modes before voting. VERIFY: all six hats run; Black is always paired with equal-time Yellow (no unbalanced negativity or positivity); Blue (process) frames the open and close; each hat's output captured before synthesis.
  • devil: red-team stress test. VERIFY: DA perspective is rotated and the dissenting source anonymized (psychological safety); 3–7 ranked objections produced; each scored addressed / partial / unaddressed; backfire watched (entrenchment / dilution / conflict); runs mandatorily on any 3-0 unanimity.
  • delphi: anonymous multi-round convergence. VERIFY: panelist anonymity preserved every round; 2–4 rounds, stopping on a convergence indicator (IQR / Kendall's W) — not a fixed count; genuine bimodal disagreement preserved as stable dissent, never flattened to a mean; rounds capped at 4.
  • multi: multi-engine deliberation. VERIFY: dual-engine baseline actually spawned (Claude+Codex; agy added only when AVAILABLE); the deliberation matrix is the primary artifact (never collapsed to a single averaged verdict); each cell carries concurrence + consistency + engine-attribution tags; final verdict is pattern-based (matrix shape → GO/NO-GO/CONDITIONAL/ESCALATE); single-engine influence capped at 50% (Byzantine); debate ≤2 rounds; all-cells-unanimous (6/6 or 9/9) → mandatory DA attacking the matrix pattern.

Collaboration Handoff Tokens

Referenced from SKILL.md -> Collaboration.

Direction Handoff token Purpose
User → Magi — Decision requests, mode selection
Nexus → Magi NEXUS_TO_MAGI Complex decisions requiring arbitration
Scribe[unified] → Magi SCRIBE_TO_MAGI Stakeholder alignment for strategy resolution
Atlas → Magi ATLAS_TO_MAGI Architecture options for arbitration
Flux → Magi FLUX_TO_MAGI Reframed perspectives for re-deliberation
Schema → Magi SCHEMA_TO_MAGI DB design options for normalization verdicts
Gateway → Magi GATEWAY_TO_MAGI API design options for versioning verdicts
Shift → Magi SHIFT_TO_MAGI Migration strategy options
Experiment → Magi EXPERIMENT_TO_MAGI A/B test results for interpretation
Void → Magi VOID_TO_MAGI YAGNI analysis results for incorporation
Magi → Builder/Forge/Artisan MAGI_TO_BUILDER Implementation decisions
Magi → Atlas/Scaffold MAGI_TO_ATLAS Architecture decisions
Magi → Launch MAGI_TO_LAUNCH Release decisions
Magi → Nexus MAGI_TO_NEXUS Decision results
Magi → Sherpa MAGI_TO_SHERPA Prioritized task lists
Magi → Void MAGI_TO_VOID YAGNI validation when "do nothing" is a candidate
Magi → Schema MAGI_TO_SCHEMA Normalization verdicts
Magi → Gateway MAGI_TO_GATEWAY API design verdicts
Magi → Shift MAGI_TO_SHIFT Migration verdicts
Magi → Experiment MAGI_TO_EXPERIMENT Result interpretation

Source: SKILL.md on GitHub

1 alert13d5 checks · Risk HIGH
  • Gen Agent Trust Hub13d

    The skill facilitates complex decision-making but introduces significant security risks through its 'Engine Mode' and 'multi' recipe. These modes execute external CLI tools (codex, agy) using shell commands that incorporate user-provided context. Most notably, the skill explicitly instructs the agent to use a flag that bypasses permission checks (--dangerously-skip-permissions) when invoking the Antigravity CLI. This creates a high-risk vector for unauthorized command execution and bypasses platform security controls.

  • Socket13d

    No alerts

  • Snyk13d

    Risk: LOW · No issues

  • Runlayer6mo

    2/7 files flagged

  • ZeroLeaks5mo

    Score: 93/100 · 2 sections analyzed

Signed by skilld at 35ffd55. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 2 days ago.

Activeupdated 2 weeks ago

README badge

README badge for simota/agent-skills/magi