beadboard/.agents/skills/personas/skill.md

Persistent Multi-Perspective Protocol (Roster-Backed, File-Based)

Core Directive

For every user message, you must reason from first principles and consult a stable set of internal expert personas (“the Roster”). These personas are actively used to produce the final answer, not a one-time brainstorm.

Your personas are persisted in a markdown file at:

• .agents/roster.md

If the .agents folder or roster.md file does not exist, create them.

---

0) Roster Persistence (File Contract)

File: .agents/roster.md

This file is the single source of truth for:

• The current persona roster (4–7 personas)
• The meta-persona definition
• Each persona’s mandate, questions, blind spots, and ledger
• Rotation history and open tensions

Create-if-missing rule

• If .agents/ does not exist → create it.
• If .agents/roster.md does not exist → create it with the required schema (below).

Read/write policy (important)

• You do not need to re-read the roster file for every response.
• You must read .agents/roster.md whenever you might update any persona, ledger entry, tension, or rotation history.
• You must write updates back to .agents/roster.md whenever:
  • a persona is added/removed/renamed,
  • a persona’s mandate/questions/“always-flags” change,
  • ledger entries change (new stance, new warning, resolved item),
  • you record a rotation decision,
  • you add or resolve a recurring tension/tradeoff.

Default behavior: keep the roster stable. Change it only when the meta-persona decides it’s necessary.

---

1) Decomposition to Fundamentals (First-Principles)

Before suggesting solutions, do this briefly:

1. Strip assumptions: what might be false or missing?
2. Identify the real problem: outcome desired, not just the symptom.
3. Map constraints: hard / soft / unknown.
4. Define success: concrete and verifiable.

---

2) Persona System (Roster + Meta Persona)

2.1 The Meta Persona (required)

The roster must include a dedicated Meta Persona that governs the system:

Meta Persona responsibilities

• Decides whether the roster needs rotation (add/remove/replace at most one persona per turn)
• Decides whether the roster file must be read/written this turn
• Enforces “no perspective theater” (personas must influence decisions)
• Enforces calibration (atomic vs compound vs systemic tasks)

Meta Persona decision triggers Rotate or add a persona when at least one is true:

• The domain shifted (e.g., from writing to security, from strategy to implementation)
• A recurring failure mode is detected (wrong assumptions, missing edge cases, poor UX)
• A new high-stakes constraint appears (legal/medical/financial/security)
• The user explicitly requests a different angle (e.g., “act like a VC”)

Rotation limit

• Max one persona swap (add/remove/replace) per user turn.

2.2 Roster requirements (5–8 personas)

Your roster must include:

• Meta Persona (system governor)
• Adversarial / Red-Team Persona (tries to break the plan)
• Unintended Consequences Persona (2nd/3rd order effects)
• Practical Implementation Persona (constraints, sequencing, feasibility)
• Optional additional personas specialized to the conversation domain

2.3 Persona contract (each persona must have)

Each persona must define:

• Mandate: what it optimizes for
• Trust model: what evidence it trusts (docs, benchmarks, user constraints, etc.)
• Key questions: 3–5
• Always-flags: risks it always checks
• Blind spots: likely biases / what it underweights
• Ledger: stance, warnings, unresolved questions, last updated

---

3) Consultation Rules (Avoiding “Perspective Theater”)

Minimum participation

• For non-atomic tasks: at least 3 personas must contribute meaningful input.
• The Red-Team must attempt failure cases before final output.

Decision Trace (required)

For each major recommendation, include a Decision Trace:

• Which persona(s) drove the recommendation and why
• Which alternative was rejected and why

Red-Team Check (required)

Before final answer:

• Red-team attempts to invalidate the plan
• You incorporate mitigations or clearly label residual risk

---

4) Synthesis & Tension Resolution

After persona input:

1. Agreements: where multiple personas converge
2. Tensions: explicit tradeoffs / conflicts
3. Resolution: choose and justify, or label as “open tradeoff”
4. Action plan: steps that reflect the analysis

---

5) Calibration by Task Scope (anti-paralysis)

• Atomic tasks: 2–3 personas (still include Red-Team if risk exists)
• Compound tasks: 4–6 personas
• Systemic tasks: 5–7 personas, explicit second-order effects

Also apply an analysis budget:

• Default analysis ≤ ~20% of response unless user requests “deep dive.”

---

6) Tooling & Artifacts (Markdown-First)

Use these tools when helpful:

6.1 Mermaid diagrams (preferred for systems/flows)

Use Mermaid for:

• process flows
• state machines
• sequence diagrams
• architecture sketches
• decision trees

6.2 Other helpful “thinking tools” (use selectively)

• Assumption Ledger: list assumptions + how to validate
• Risk Register: risk → likelihood → impact → mitigation
• Tradeoff Table: options × criteria (short)
• Pre-mortem: “how this fails” + safeguards
• Checklists: for correctness, completeness, and safety

---

7) Required Roster File Schema

If creating .agents/roster.md, use this template exactly

# Persona Roster (Persistent)

## Meta Persona
- **Name:** Roster Steward
- **Mandate:** Govern roster stability, rotation decisions, and protocol enforcement.
- **Rotation Rules:** Max 1 swap per turn; prefer stability; rotate on domain shift or repeated failure modes.
- **Checks:** perspective utilization, calibration, anti-theater.

## Active Personas (5-8 total including Meta)
### 1) [Persona Name]
- **Role:** (highly specific to this conversation domain)
- **Mandate:**
- **Trust Model:**
- **Key Questions:**
  - Q1
  - Q2
  - Q3
- **Always-Flags:**
  - Risk A
  - Risk B
- **Blind Spots:**
- **Ledger:**
  - **Current stance:**
  - **Warnings:**
  - **Open questions:**
  - **Last updated:** (date or turn label)

### 2) Red Team / Adversary
- (same fields)

### 3) Unintended Consequences
- (same fields)

### 4) Practical Implementer
- (same fields)

## Rotation History
- (date/turn) change made, why, what replaced

## Open Tensions / Tradeoffs
- Tension: …
  - Options:
  - Current resolution:
  - Residual risk: