Diagnostic-First Refactoring (Surgeon's Scan)

Core Principle: Understand before you cut.

Protocol

1. Scan: Map the target module's file structure and dependencies
2. Diagnose: Identify coupling, dead code, and test coverage gaps
3. Plan: Design the refactoring sequence (dependency-safe order)
4. Execute: Apply changes with verification at each step
5. Verify: Run tests, check for regressions

Anti-Patterns

• ❌ Editing files without reading them first
• ❌ Refactoring multiple modules simultaneously
• ❌ Skipping the dependency scan
• ❌ Not running tests after each change

Related Protocols

• DIAG-001: Knowledge-Action Gap
• DIAG-002: Baseline Check
• DIAG-003: Frame Collision

Brand Foundations (The 7 Pillars)

An interactive workshop protocol used to instantly standardize a brand's narrative, voice, and aesthetic positioning before content production begins.

Triggers

"new brand", "brand voice", "positioning", "brand guidelines"

Core Mechanics

Runs a structured Q&A to extract:

1. Purpose & Core Enemy
2. Target Avatar (Psychographics > Demographics)
3. Brand Voice & Archetype
4. Primary Value Proposition
5. Visual Identity (Colors/Typography direction)
6. Compaction into brand_guidelines.md

Reference Paths

• .context/memories/protocols/strategy/319-brand-foundations-7-blocks.md

Client Pricing Skill

Purpose: Prevent rate collapse. Enforce anchor-first pricing. Automate the quoting decision tree. Origin: Empirical calibration from real client engagements — rate collapse incidents and floor-as-opening negotiation failures. Both were preventable.

Core Principle

"AI commoditizes labor. It cannot commoditize judgment."

Pricing Hierarchy (defensibility axis): Time (❌) → Output (❌) → Deliverable (⚠️) → Outcome (✅) → Access (✅✅)

Never price at the Time or Output layer. Price at Deliverable (minimum) or Outcome (preferred).

Tiered Pricing Table

The Negotiation Decision Tree

YOU: State anchor price
↓
CLIENT: "Too high"
↓
YOU: "What's your budget?" (NEVER counter against yourself)
↓
CLIENT names their number
↓
├─ (A) Within 20% of anchor → Counter midpoint, settle ±10%
├─ (B) 40-60% of anchor → Counter at floor + 20%, settle at floor + 10%
├─ (C) Below floor → "Sorry, [floor] is the lowest I can go"
│   ├─ Client accepts → Done
│   └─ Client walks → Let them (Dignity Premium)
└─ (D) Client ghosts → Follow up once at 24hr. No chase after.

Three rounds maximum. After round 3, you're haggling, not negotiating.

Anti-Patterns (Reflexion Archive)

Activation Rules

1. Auto-trigger: When academic-delivery Step 2 (SCOPE) identifies commercial work
2. Manual trigger: "/quote", "how much should I charge", "client is asking about price"
3. Exit: Output a formatted quote with anchor + justification + scope boundary

Quote Template

Hi [Client],

Based on the scope ([deliverable type], [word count/test count], [deadline]):

**Quote: $[ANCHOR]**

This covers: [explicit scope list]
Not included: [explicit exclusions]
Turnaround: [timeline]

Payment: [deposit]% upfront via PayNow, balance on delivery.

Let me know if you'd like to proceed.

Distribution Physics

Evaluates whether a product has a structurally viable path to market, enforcing the "Build the Audience, then Build the Product" methodology.

Triggers

"go to market", "how to launch", "distribution strategy"

Core Mechanics

1. Identifies the primary acquisition channel (SEO, Paid, Social).
2. Calculates the friction coefficient of that channel vs the Unit Economics.
3. Rejects strategies that rely on "Build it and they will come."

Reference Paths

• .context/memories/protocols/business/106-distribution-physics.md

Bionic Marketing Swarm

Orchestrates the activation of specialized marketing sub-agents (Copywriters, SEO analysts, Media Buyers) to execute comprehensive GTM distributions.

Triggers

"marketing team", "deploy swarm", "reddit strategy", "seo campaign"

Core Mechanics

1. Ingests a raw <topic> or URL.
2. Dispatches instructions to .agent/swarms/marketing_team/ orchestrator.
3. Compiles final multi-channel assets (Ads, Landing Pages, Email Sequences).

Reference Paths

• .context/memories/protocols/marketing/338-multi-platform-content-flow.md
• .context/memories/protocols/marketing/280-meta-ads-architecture.md

Technical SEO & Content Auditor

Performs a comprehensive technical and structural scan of a targeted domain, identifying immediate content gaps and architecture failures.

Triggers

"audit website", "seo check", "why isn't this ranking"

Core Mechanics

1. Pulls raw DOM structure.
2. Evaluates H1-H6 hierarchy, semantic tags, and internal link depth.
3. Outputs a prioritized seo_triage_plan.md focusing on "Barnacle SEO" opportunities.

Reference Paths

• .context/memories/protocols/marketing/279-seo-channel-strategy.md

Sovereign Economics Engine — Business Model × Distribution × Pricing

Compiled: 2026-05-11 (retroactive synthesis of 54+ protocols) Problem Class: All business/freelance/service decisions — client selection, pricing, distribution channel choice, content strategy, niche validation, and platform sovereignty. Axiom: "Own the arena, own the lever, own the exit — everything else is rent."

When to Use

Invoke whenever the user mentions:

• Client acquisition, pricing, or toxic client dynamics
• Business model evaluation or niche selection
• Distribution strategy (SEO, ads, content, Carousell, social)
• Portfolio/website design for lead generation
• Service productization or agency operations
• "Should I take this client/project/gig?"

Solution Architecture

Module 1: The Sovereignty Gate (MP-1 + MP-13)

Before evaluating ANY business opportunity:

              YOU OWN THE ARENA    YOU RENT THE ARENA
YOU SET PRICE:    Sovereign            Fragile
THEY SET PRICE:   Regulated            Subordinate

5-Gate Pre-Flight (BUS-567):

1. ☐ Can I set my own price? (Price Ceiling Vise check)
2. ☐ Can I leave in <30 days? (Kill Switch check)
3. ☐ Do I own the client relationship? (Platform bypass check)
4. ☐ Is my COGS fixed, not rising? (Cost floor check)
5. ☐ Does this compound? (Hand-Stop-Mouth-Stop test)

If ≥2 gates FAIL → you are sharecropping. Exit or renegotiate.

Module 2: The Client Filter (BUS-255 + P120)

The Velvet Rope: Not all revenue is good revenue.

The Power Inversion Protocol (P120):

1. Calculate the EXACT friction cost of the client (time × your hourly × frustration multiplier)
2. Present the "Dignity Premium" rate: Structural Value = max(Cost × 1.5, Value to Buyer × 0.3)
3. If rejected → self-terminate the contract. The "Walk" is the highest-leverage move.

The $100 Filter: A refundable deposit filters intent. Serious buyer pays; extraction-only balks.

Module 3: The Pricing Engine (CS-376 + CS-460)

Three Pricing Tiers (empirically calibrated from 24+ real jobs):

Anti-Collapse Rules:

• Never quote below Floor without a strategic reason (and log it)
• Scope Gate: Hard 3-hour limit on discovery before SOW
• Capstone Discount Trap: Complexity + time creep against quoted flat fee = RUIN

Module 4: The PMOD Distribution Stack (STR-162 + MP-3)

Problem → Market → Operations → Distribution
                                      ↑
                                BINDING CONSTRAINT

Distribution is the binding constraint. Product quality is necessary but NEVER sufficient.

The Distribution Hierarchy (ranked by ROI for solo operator):

Rule: Always have ≥1 compounding channel active. Paid channels are oxygen masks, not destinations.

Module 5: The Four Fits Viability Framework (BUS-304)

Before entering ANY market:

Market ←→ Product ←→ Channel ←→ Model
  ↑___________________________________↑

All four must interlock. If ONE fit breaks, the business fails regardless of the other three.

Module 6: The Content Engine (CNT-220 + MP-12)

The Articulation Penalty (MP-12): Structural truth and engagement are inversely correlated.

Distribution = Emotional Hook → Structural Depth (reach first, teach second)
Authority    = Structural Depth → Emotional Validation (prove first, connect second)

Content Trifecta (CS-183):

1. Pain Point Content: "That's Me" symptom description (converts)
2. Proof Content: Case studies, results, portfolio (validates)
3. Authority Content: Deep structural analysis (positions)

Listing Optimization (Carousell/Portfolio):

• Lead with outcome, not process
• Use the MinMax formula: cheapest acceptable OR best available
• Results-only signal (MKT-284): Show outcomes, not inputs

Output Template

SOVEREIGN ECONOMICS REPORT
──────────────────────────
Opportunity:     [Description]
Sovereignty:     [Sovereign / Fragile / Regulated / Subordinate]
Client Grade:    [Tier 1 / Tier 2 / Extraction Risk / Toxic]
Pricing:         [Floor / Standard / Premium — $X/hr equivalent]
Distribution:    [Channel recommendation + compounding check]
Four Fits:       [M-P: ✅/❌ | P-C: ✅/❌ | C-M: ✅/❌ | M-M: ✅/❌]
Compounding:     [Linear / Compounding — Hand-Stop-Mouth-Stop: Y/N]

VERDICT: [PURSUE / RENEGOTIATE / EXIT]

Absorbed Protocol Index

Business (31)

BUS-106 (Distribution Physics), BUS-108 (Direct Response), BUS-119 (First Principles), BUS-127 (Recursive Value Trap), BUS-145 (Foundation Trinity), BUS-160 (Certainty Offer), BUS-230 (Unit Economics), BUS-255 (Velvet Rope), BUS-262 (Agency Standards), BUS-281 (High-Ticket SEO), BUS-282 (Market Entry Moat), BUS-304 (Four Fits), BUS-306 (Outcome Economy), BUS-320 (Service Lifecycle), BUS-330 (Flash Branding), BUS-380 (Technical Intake), BUS-526 (Viability Assessment), BUS-540 (Conversion Architecture), and 13 more.

Marketing (8)

MKT-265 (BOFU Blueprint), MKT-279 (SEO Channel), MKT-280 (Meta Ads), MKT-282 (Alibi Strategy), MKT-284 (Results-Only Signal), MKT-311 (Carousell Anatomy), MKT-312 (Carousell MinMax), MKT-338 (Multi-Platform Flow)

Content (13)

CNT-220 (Blog Gold Standard), CNT-221 (High-Performance UX), CNT-231 (LLM Seeding), CNT-232 (AI Trajectory), CNT-246 (Storytelling), CNT-248 (Carousell Structure), CNT-260 (Resonance Spec), CNT-272 (Fear-Based Ads), CNT-308 (Substack Protocol), CNT-326 (Landing Page Anatomy), CNT-527 (Viral Wrapper), and 2 more.

Acquisition (2)

ACQ-106 (Stealth Acquisition), ACQ-140 (Exocortex)

Key Case Studies

CS-010 (Free Value Trap), CS-040 (Andy Coffee Shop), CS-089 (Grab Economics), CS-104 (SG Retail Death Spiral), CS-118 (Tutor Distribution Trap), CS-405 (MindFlex Commodity), CS-472 (Portfolio Paradox), CS-526 (Google Ads Bonfire), CS-533 (Agency Retainer Deconstruction), CS-535 (Web Design Four Fits), CS-553 (Spike Durian), CS-557 (SleekDigital Pattern Extraction), CS-558 (MisterMobile SEO), CS-563 (Gus Fring Model), CS-567 (F&B Sharecropping Trap), CS-570 (What The Puff Vanity Revenue)

Failure Modes & Mitigations

Validated Patterns (Empirical)

• [V] The Walk: Threatening withdrawal is the highest-leverage negotiation move. 3/3 applications resulted in improved terms. | Reapply: Every pricing pushback.
• [V] CNA Documentary Proof: 6/6 F&B failures were distribution failures. Zero were product failures. | Reapply: Every "but my product is good" claim.
• [V] $2K Google Ads Bonfire: Wrong channel economics = guaranteed loss regardless of product quality. | Reapply: Every paid channel evaluation.
• [V] The $100 Filter: Refundable deposit filters 90%+ of extraction-only contacts. | Reapply: Every new lead.
• [V] Commission Drag: 46% commission drag killed FX edge. Arena selection > strategy optimization. | Reapply: Every platform/channel cost audit.

References

• META_PATTERNS.md — MP-1, MP-3, MP-4, MP-6
• bionic-decision-engine — Parent decision engine
• CASE_STUDY_INDEX.md — Full case study lookup

Agentic Code Orchestrator — Build × Analyze × Deliver

Compiled: 2026-05-11 (retroactive synthesis of all engineering/academic sessions) Problem Class: All code generation, data analysis, dashboard building, academic delivery, and technical project execution. Axiom: "The winner is not who thinks deepest on the first try — it's who can iterate fastest at the lowest cost per loop."

When to Use

Invoke whenever the user mentions:

• Building/fixing a website, dashboard, or web app
• Data analysis (CSV, JSON, Parquet, large datasets)
• Academic assignments (essays, capstones, SUSS coursework)
• Code refactoring or architecture decisions
• Deploying to Supabase, Vercel, GitHub Pages
• "Analyze this data" / "Build me a [thing]" / "Fix this bug"

Solution Architecture

Module 1: The RETO Engine Selector (COD-415 + MP-2)

Before writing ANY code, classify the project:

Is failure reversible?   → Efficient Engine (Vibe Engineering: ship at 70%)
Is failure irreversible? → Robust Engine (Nuclear Plant: test everything)

Module 2: Spec-Driven Development (COD-107)

NEVER build without a spec. The spec is the contract.

Phase 1: Interrogation (The /brief)
  → What does the user ACTUALLY want?
  → What are the constraints?
  → What does "done" look like?

Phase 2: design.md Generation
  → Architecture diagram
  → Component breakdown
  → Data flow
  → Acceptance criteria

Phase 3: User Approval
  → Review the spec
  → Confirm scope
  → THEN and ONLY THEN → build

Phase 4: Execution
  → Build to spec, not to vibes
  → Checkpoint every major component

Module 3: The De-Sloppify Protocol (ECC Steal)

After generating code, ALWAYS run this quality pass:

1. Dead Code Purge: Remove commented-out code, unused imports, placeholder TODOs
2. Console.log Sweep: Remove all debug logging from production code
3. Naming Consistency: Verify naming conventions match project standard
4. Error Handling: Ensure every async operation has error handling
5. Type Safety: If TypeScript, no any types unless explicitly justified

Module 4: Data Analysis Pipeline (DuckDB-Powered)

For large data dumps (CSV, Parquet, JSON):

Phase 1: Ingest
  → Identify file format + encoding
  → Load with DuckDB (NOT Pandas for large files)
  → Profile: row count, columns, types, nulls, distribution

Phase 2: Profile
  → Summary statistics per column
  → Outlier detection
  → Cardinality analysis
  → Missing data assessment

Phase 3: Query
  → User-directed analysis
  → SQL-based queries via DuckDB
  → Visualization where appropriate

Phase 4: File Insights
  → Key findings summary
  → Actionable recommendations
  → Export results

Rule: For files >100MB, ALWAYS use DuckDB. Pandas will crash.

Module 5: Academic Delivery Pipeline

For SUSS assignments, essays, capstones:

Step 1: Intake — Parse assignment brief, identify marking rubric
Step 2: Research — NotebookLM arbitrage for source material
Step 3: Outline — Structure mapped to rubric weightings
Step 4: Draft — Write with burstiness and perplexity variation
Step 5: Red-Team — Invoke red-team-review on key arguments
Step 6: Humanize — Run academic-humanizer if AI detection risk
Step 7: Format — APA/Harvard citation formatting
Step 8: Deliver — Final audit against rubric

The Bionic Academic Advantage (CS-467):

• AI drafts at 80%, human polishes to 100%
• Research Arbitrage: NotebookLM handles volume, Athena handles synthesis
• SPSS/R/Python for statistical analysis (statistical-analysis skill)

Module 6: Dashboard/Website Architecture

For financial/trading dashboards:

For portfolio/marketing websites (CS-437 UI/UX Pro Max):

Output Template

ORCHESTRATOR REPORT
───────────────────
Project:        [Description]
Engine:         [Efficient / Robust — reversibility: ...]
Spec Status:    [Approved / Pending — design.md: ...]
Data Pipeline:  [DuckDB / Pandas / N/A — file size: ...]
Quality Gate:   [De-Sloppified: Y/N — coverage: X%]
Ship Threshold: [60% / 70% / 85% / 95% / 99%]

STATUS: [BUILDING / TESTING / SHIPPED]

Absorbed Protocols & Skills

Coding (6)

COD-107 (Spec-Driven Development), COD-108 (Semantic Search Standards), COD-110 (Structured Decoding), COD-112 (Stop Pattern), COD-415 (Spec-Driven Velocity), COD-900 (Project Scaffolding)

Absorbed Skills

• data-analysis → DuckDB-powered large file analytics
• academic-delivery → 8-step pipeline for academic deliverables
• academic-humanizer → AI detection bypass rewriting
• spec-driven-dev → Interrogation → design.md → build
• statistical-analysis → SPSS/R/Python statistical pipelines

Key Case Studies

CS-062 (Vibe Coding Gap), CS-100 (Project Vend Agentic Failure), CS-120 (Vibe Coding Zero-Cost Stack), CS-157 (ChunkHound Agentic Coding), CS-187 (Deep Data Analyst Post-Mortem), CS-235 (Over-Engineering Trap), CS-237 (Async Dev Workflow), CS-303 (Smart Mock vs Real API), CS-306 (Lovable Trap), CS-350 (Vibe Coding Security Failures), CS-370 (Vibe Coding Trap), CS-425 (Academic Essay Workflow), CS-430 (Vibe Coding MVP), CS-437 (UI/UX Pro Max Architecture), CS-438 (Biological Debt Coding), CS-440 (Velocity vs Craftsmanship), CS-467 (Bionic Leverage Academic Arbitrage), CS-486 (Component-Level AI Architecture), CS-508 (OpenClaw Architecture), CS-515 (Maestro Parallel Orchestration), CS-532 (Vibe Coding Agency Model), CS-539 (CEG3001 Capstone Debrief), CS-540 (Anti-Slop Website Pipeline), CS-543 (Vibe Coded SaaS $10K MRR)

Failure Modes & Mitigations

Validated Patterns (Empirical)

• [V] DuckDB > Pandas: For files >100MB, DuckDB is 10-50x faster and doesn't crash. | Reapply: Every large data analysis.
• [V] NotebookLM Research Arbitrage: Offload PDF ingestion to NotebookLM, keep Athena's context for synthesis. | Reapply: Every academic assignment.
• [V] 4-Decimal GTO Standard: Uniform precision prevents cognitive load in financial dashboards. | Reapply: Every statistical display.
• [V] Primitive Dependency Extraction: [data.currentRatio] instead of [data] stops React re-render loops. | Reapply: Every dynamic status component.
• [V] Ship at 70%, iterate to 95%: For reversible projects, perfection is the enemy of shipped. | Reapply: Every portfolio/MVP build.

References

• META_PATTERNS.md — MP-2 (RETO engine), MP-11 (Iteration Economy)
• bionic-decision-engine — For build/buy/wait decisions

Atomic Execution Engine

Prevents context degradation during long execution phases by breaking work down into atomic, verification-gated tasks using structured XML. Integrated via /steal from the get-shit-done methodology.

Triggers

"execute roadmap", "start building phase", "implement this plan", "atomic execution"

Core Mechanics

When entering Execution phase, do not build monolithic features linearly in one context window. Instead:

1. XML Plan Extraction

Convert the current phase of the ROADMAP.md (or the design.md spec) into 1 or more atomic XML execution plans. If the user hasn't provided one, draft it and execute it.

Format each atomic task precisely as:

<task type="auto">
  <name>Short descriptive name</name>
  <files>path/to/affected/file.ext</files>
  <action>
    Explicit, step-by-step instructions.
    Dependencies and logic.
  </action>
  <verify>Command to run to verify correctness (e.g. tests or curl)</verify>
  <done>Definition of done</done>
</task>

2. Isolated Execution

Execute ONE <task> block at a time. Maintain peak reasoning by not polluting the context window with previous tasks. If a task requires subagents or isolated worktrees, trigger /git-worktree-swarm.

3. Verification Gate

After code is written, explicitly run the command specified in <verify>. If it passes the <done> criteria, commit immediately using micro-commit. If it fails, fix the code within the same context before proceeding to the next <task>.

4. State Management

Update STATE.md after every completed XML task block to persist progress across sessions without bloating the context window. Always log:

• Decisions made
• Blockers encountered
• Current position in ROADMAP.md

Reference Paths

• spec-driven-dev (Pre-requisite for Execution via P107)
• micro-commit (Post-Execution step)

Dashboard Builder — Interactive HTML Dashboards

Stolen from: Anthropic Data Plugin — build-dashboard (2026-05-24) Adaptation: Stripped enterprise connectors, added Athena-specific data patterns.

When to Use

• Creating executive overview with KPI cards
• Turning query results into a shareable self-contained report
• Building a monitoring snapshot
• Needing multiple charts with filters in one browser-openable file
• Client deliverables requiring interactive data presentation

Workflow

1. Understand Requirements

Determine:

• Purpose: Executive overview, operational monitoring, deep-dive analysis, team reporting
• Audience: Who will use this dashboard?
• Key metrics: What numbers matter most?
• Dimensions: What should users be able to filter or slice by?
• Data source: Live query, pasted data, CSV file, or sample data

2. Gather Data

If data is available → Parse, clean, embed as JSON in the HTML file. If working from description → Create realistic sample dataset. Note it uses sample data. Provide swap instructions.

3. Design Layout

Follow standard dashboard layout:

┌──────────────────────────────────────────────────┐
│  Dashboard Title                    [Filters ▼]  │
├────────────┬────────────┬────────────┬───────────┤
│  KPI Card  │  KPI Card  │  KPI Card  │ KPI Card  │
├────────────┴────────────┼────────────┴───────────┤
│                         │                        │
│    Primary Chart        │   Secondary Chart      │
│    (largest area)       │                        │
│                         │                        │
├─────────────────────────┴────────────────────────┤
│                                                  │
│    Detail Table (sortable, scrollable)           │
│                                                  │
└──────────────────────────────────────────────────┘

Adapt to content:

• 2-4 KPI cards at top for headline numbers
• 1-3 charts in middle for trends and breakdowns
• Optional detail table at bottom for drill-down
• Filters in header or sidebar depending on complexity

4. Build HTML Dashboard

Single self-contained HTML file:

Structure: Semantic HTML5, responsive grid (CSS Grid/Flexbox), filter controls, KPI cards, chart containers, sortable data table.

Styling: Professional dark/light scheme, card-based layout with subtle shadows, consistent typography (system fonts), responsive, print-friendly.

Interactivity: Chart.js for charts, filter dropdowns updating all views simultaneously, sortable columns, hover tooltips, number formatting.

Data: All data embedded as JavaScript variables. No external fetches. Works completely offline.

5. Chart Types

6. Base Template

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Dashboard Title</title>
    <script src="https://cdn.jsdelivr.net/npm/chart.js@4.5.1" integrity="sha384-jb8JQMbMoBUzgWatfe6COACi2ljcDdZQ2OxczGA3bGNeWe+6DChMTBJemed7ZnvJ" crossorigin="anonymous"></script>
    <style>
        /* --- Design System --- */
        :root {
            --bg: #0f1117; --surface: #1a1d2e; --border: #2a2d3e;
            --text: #e4e4e7; --text-muted: #71717a;
            --accent: #6366f1; --accent-hover: #818cf8;
            --success: #22c55e; --warning: #eab308; --danger: #ef4444;
            --radius: 12px; --shadow: 0 4px 24px rgba(0,0,0,.3);
        }
        * { margin:0; padding:0; box-sizing:border-box; }
        body { font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', system-ui, sans-serif;
               background: var(--bg); color: var(--text); line-height: 1.5; }
        .dashboard { max-width: 1400px; margin: 0 auto; padding: 24px; }
        .kpi-row { display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 16px; margin-bottom: 24px; }
        .kpi-card { background: var(--surface); border: 1px solid var(--border); border-radius: var(--radius); padding: 20px; }
        .kpi-label { font-size: 0.875rem; color: var(--text-muted); margin-bottom: 4px; }
        .kpi-value { font-size: 2rem; font-weight: 700; }
        .kpi-change { font-size: 0.875rem; margin-top: 4px; }
        .kpi-change.positive { color: var(--success); }
        .kpi-change.negative { color: var(--danger); }
        .chart-row { display: grid; grid-template-columns: 2fr 1fr; gap: 16px; margin-bottom: 24px; }
        .chart-card { background: var(--surface); border: 1px solid var(--border); border-radius: var(--radius); padding: 20px; }
        .chart-card h3 { font-size: 1rem; margin-bottom: 12px; color: var(--text-muted); }
        table { width: 100%; border-collapse: collapse; }
        th, td { padding: 10px 12px; text-align: left; border-bottom: 1px solid var(--border); }
        th { color: var(--text-muted); font-size: 0.8rem; text-transform: uppercase; cursor: pointer; }
        th:hover { color: var(--accent); }
        .filters { display: flex; gap: 12px; align-items: center; }
        select { background: var(--surface); color: var(--text); border: 1px solid var(--border);
                 border-radius: 8px; padding: 8px 12px; font-size: 0.875rem; }
        footer { text-align: center; color: var(--text-muted); font-size: 0.8rem; margin-top: 32px; }
        @media (max-width: 768px) { .chart-row { grid-template-columns: 1fr; } }
    </style>
</head>
<body>
    <div class="dashboard">
        <header style="display:flex; justify-content:space-between; align-items:center; margin-bottom:24px;">
            <h1>Dashboard Title</h1>
            <div class="filters"><!-- Filter controls --></div>
        </header>
        <section class="kpi-row"><!-- KPI cards --></section>
        <section class="chart-row"><!-- Chart containers --></section>
        <section class="chart-card"><!-- Data table --></section>
        <footer>Data as of: <span id="data-date"></span></footer>
    </div>
    <script>
        const DATA = []; // Embedded data
        class Dashboard {
            constructor(data) { this.rawData = data; this.filteredData = data; this.charts = {}; this.init(); }
            init() { this.setupFilters(); this.renderKPIs(); this.renderCharts(); this.renderTable(); }
            applyFilters() { /* Filter + re-render all views */ }
            setupFilters() {}
            renderKPIs() {}
            renderCharts() {}
            updateCharts() {}
            renderTable() {}
        }
        const dashboard = new Dashboard(DATA);
    </script>
</body>
</html>

7. Save and Open

1. Save as descriptive name (e.g., sales_dashboard.html)
2. Open in user's default browser
3. Confirm it renders correctly
4. Provide instructions for updating data or customizing

References

• Anthropic build-dashboard — Source skill
• Athena precedent: web-based interactive deliverables as single HTML files

🩺 Diagnostic-First Refactoring (The "Surgeon's Scan")

Philosophy: Diagnose first. Cut second. Source: r/vibecoding ("Tip #1 - don't forget to have AI review its own code")

1. The Prompt (Universal Polyglot)

When invoking this skill on a file (or set of files), use the following System Prompt logic.

Role: Senior Software Architect & Performance Engineer.

Objective: Analyze the provided code files and generate a "Refactoring & Optimization Report." DO NOT rewrite the full files or generate refactored code blocks yet. Instead, provide a diagnostic report.

Specific Focus Areas:

1. Dead & Unreachable Code: Identify variables, functions, or imports that are declared but never used.
2. Cognitive Complexity: Highlight areas with excessive nesting (if/else hell), complex state management, or hard-to-read logic.
3. Redundancy: Point out repeated logic that should be abstracted into utility functions (violation of DRY principles).
4. Performance Heavy-Lifters: Analyze loops, recursive functions, DOM manipulations (if JS), and resource-heavy operations.
   • Check: Is this technically unneeded? Can it be replaced by a lighter alternative (e.g., CSS instead of JS animation)?
5. Modernization: Identify where language-specific modern syntax (e.g., Python 3.12+ features, ES6+ features) could reduce LOC.

Constraints for AI:

• NO DIRECT EDITING: Do not output the full modified code files.
• Strictly Diagnostic: Focus on what can be improved and why.
• Quantify Impact: Estimate LOC reduction (Low/Medium/High) and Complexity Impact.

2. Output Format (The "Bill of Materials")

The output MUST be written to a report file using the following structure:

# Refactoring & Optimization Report: [Filename]

## 📊 Summary
* **Est. LOC Reduction**: ~[X] lines
* **Complexity Reduction**: [Low/Medium/High]
* **Critical Issues**: [Count]

## 1. Issue Matrix

| Issue Category | Description of Inefficiency | Proposed Solution | Est. LOC Reduction | Complexity Impact |
| :--- | :--- | :--- | :--- | :--- |
| **Dead Code** | Unused import `foo` on line 12 | Remove import | ~1 line | None |
| **Bloat** | Animation function X uses complex JS loop | Replace with CSS Keyframes | ~15 lines | High |
| **Syntax** | Old style variable declarations | Convert to const/let & arrow funcs | ~5 lines | Low |
| **DRY** | Repeated error handling logic in 3 functions | Create `handle_error` utility | ~20 lines | Medium |

## 2. Critical Recommendations (Bulleted)
* [Recommendation 1]
* [Recommendation 2]

## 3. Risks & Regressions
* [Potential side effect of refactoring]

3. Execution Workflow

1. Select Target: Identify the file(s) to refactor.
2. Run Diagnosis: Feed file content + The Prompt to the AI.
3. Review Report: User reviews the Matrix.
4. Authorize: User approves specific line items.
5. Execute: AI switches to "Execution Mode" and applies the approved changes.

Why This Pattern?

skill #refactoring #code-quality #diagnostic

Git Worktree Swarm Orchestrator

Sets up parallel, isolated git environments so multiple sub-agents can work on the same repository simultaneously without merge conflicts. Uses wave-based execution to respect task dependencies.

Triggers

"swarm", "parallel agents", "setup worktrees", "multi-agent", "wave execution"

Core Mechanics

Phase 1: Setup

1. Detect current branch.
2. Spawn n temporary worktrees (.agent-workspace-1, etc.).
3. Assign tasks to isolated clones.

Phase 2: Wave Execution (Dependency DAG)

Plans are grouped into waves based on dependency analysis:

WAVE 1 (parallel — no dependencies)
├── Worktree A: Task 1 (User model)     → Fresh context (P513)
├── Worktree B: Task 2 (Product model)  → Fresh context (P513)
│
[State merge: A.state + B.state → combined handoff]
│
WAVE 2 (parallel — depends on Wave 1)
├── Worktree C: Task 3 (Orders API, needs User model)
├── Worktree D: Task 4 (Cart API, needs Product model)
│
[State merge: C.state + D.state → combined handoff]
│
WAVE 3 (sequential — depends on Wave 2)
└── Worktree E: Task 5 (Checkout UI, needs Orders + Cart)

Wave Assignment Rules:

Phase 3: Context Isolation (P513)

Each worktree agent receives only:

• The specific plan/task
• Relevant source files (from dependency analysis)
• STATE.md (accumulated decisions from prior waves)
• Project context (design.md / REQUIREMENTS.md)

Never: full conversation history, debug logs, unrelated research.

Phase 4: Merge

1. Each task commits atomically (P43 micro-commit).
2. Merge worktrees back to main branch in wave order.
3. Conflict resolution: if merge conflicts arise, spawn resolution agent.
4. Cleanup: remove temporary worktrees.

Reference Paths

• Protocol 513: Context Isolation
• Protocol 43: Micro-Commit
• .context/memories/protocols/engineering/100-git-worktree-parallelism.md
• .context/memories/protocols/architecture/409-parallel-worktree-orchestration.md

Micro-Commit Architect

Refuses to allow monolithic "blob" commits. Scans the current git diff and breaks down changes into atomized, logical steps.

Triggers

"commit changes", "save my work", "micro commit"

Core Mechanics

1. Runs git status and git diff.
2. Groups changes by feature, fix, or refactor.
3. Automatically executes individual git add and git commit -m steps for each logical block.

Reference Paths

• .context/memories/protocols/engineering/44-micro-commit-protocol.md

📋 Spec-Driven Development

Philosophy: 55 minutes defining the problem, 5 minutes solving it.

1. The Problem

Most AI coding failures happen because the agent starts coding before understanding:

• What the user actually wants (vs. what they said)
• Edge cases and constraints
• Integration points and dependencies
• Success criteria

2. Execution Workflow

PHASE 1: INTERROGATION (No Code Allowed)
  ├─ "What is the ONE thing this must do?"
  ├─ "What does success look like? Be specific."
  ├─ "What are 3 things this must NOT do?"
  ├─ "Who/what does this interact with?"
  └─ "What's the simplest version that would be useful?"

PHASE 2: SPEC DOCUMENT
  └─ Write a design.md with:
     ├─ Goal (1 sentence)
     ├─ Requirements (numbered list)
     ├─ Non-Requirements (explicit exclusions)
     ├─ Architecture (how components connect)
     ├─ Edge Cases (what could go wrong)
     └─ Acceptance Criteria (how to verify)

PHASE 3: USER APPROVAL
  └─ Present spec for review
  └─ DO NOT proceed to code until approved

PHASE 4: IMPLEMENTATION
  └─ Code against the approved spec
  └─ Reference spec line items in commits

3. The Spec Template

# Design Spec: [Feature Name]

## Goal
[One sentence describing what this does]

## Requirements
1. [Must do X]
2. [Must handle Y]
3. [Must integrate with Z]

## Non-Requirements (Out of Scope)
- [Will NOT do A]
- [Will NOT support B]

## Architecture
[How the components connect — diagram or description]

## Edge Cases
- [What if input is empty?]
- [What if API is down?]
- [What if user does X instead of Y?]

## Acceptance Criteria
- [ ] [Testable condition 1]
- [ ] [Testable condition 2]

4. When to Use

• Any feature that touches >3 files
• Any task that takes >30 minutes
• Any time you catch yourself thinking "I'll figure it out as I go"

skill #engineering #planning #spec

Visual QA & UI Verification

Automates visual regression testing and responsive design checks by formally deploying browser tools to capture DOM states and screenshots.

Triggers

"check the UI", "does this look right", "take a screenshot"

Core Mechanics

1. Boots local server if not running.
2. Uses Browser tool to navigate to target URL.
3. Captures full-page screenshots across Mobile, Tablet, and Desktop viewports.
4. Returns visual evidence to the main protocol loop.

Reference Paths

• .context/memories/protocols/engineering/99-visual-verification.md

Bionic Decision Engine — The Universal Arbitrator

Compiled: 2026-05-11 (retroactive synthesis of 70+ protocols) Problem Class: Any "Should I?" question across all life domains — career, trades, purchases, relationships, time allocation. Axiom: "If you can't put a number on it, you can't decide on it. And if you decide on feelings, the wound decides for you (MP-8)."

When to Use

Invoke whenever the user faces a resource allocation decision. This includes:

• "Should I take this job/trade/client/deal?"
• "Is this worth the money/time/energy?"
• "Which option is better?"
• "Should I stay or leave?"
• Pricing questions (what to charge, what to pay)
• Any comparison of two or more alternatives

Solution Architecture

Gate 0: The Sunk Cost Purge (MP-14)

Before ANY analysis:

"Would I enter this position TODAY if I weren't already in it?"

If NO → the decision is already made. Skip to Exit Protocol. If YES → proceed to Gate 1.

Gate 1: Ruin Class Check (Law #1)

Does any option carry >5% probability of irreversible ruin across 5 domains?

VETO if P(Ruin) > 5%. No calculation needed. No exceptions.

Gate 2: The EEV Calculator (DEC-330 / DEC-526)

For each option, calculate Expected Economic Value:

EEV = P(success) × V(upside) − P(failure) × V(downside) − Friction Costs

Where:
  P(success) = base rate for demographic × personal edge multiplier
  V(upside)  = monetary + optionality + compounding value
  V(downside) = monetary loss + opportunity cost + psychological toll
  Friction   = time, energy, commute, complexity tax

Anti-Rationalization Rule (DEC-526): E(U) anchors MUST be activities you have actually paid for in the last 90 days. No hypotheticals.

Gate 3: The Horizon Split (DEC-129)

Rule: Never sacrifice Strategic for Tactical unless in survival mode. Every 90 days is "End of Year" crunch time.

Gate 4: The Arena Diagnostic (MP-1 + MP-9)

              YOU OWN THE ARENA    YOU RENT THE ARENA
YOU SET PRICE:    Sovereign            Fragile
THEY SET PRICE:   Regulated            Subordinate

Fulcrum Check (MP-9): Are you pushing harder or repositioning the lever?

Gate 5: The Form-Substance Strip (MP-5)

"Strip the label. Describe only the mechanism. Does the mechanism match the label?"

Gate 6: Compounding Test (MP-6)

"If I stop working for 6 months, does income continue?"

• No → Level 0–2. Linear. You ARE the asset.
• Yes → Level 3. Compounding. You OWN the asset.

Track Hours Invested ÷ Revenue Generated monthly. If the ratio is not decreasing, you are trapped.

Output Template

DECISION ENGINE REPORT
──────────────────────
Question:       [What is being decided]
Gate 0 (Sunk):  [PURGED / CLEAN — would you re-enter today?]
Gate 1 (Ruin):  [✅ PASS / ❌ VETO — domain: ...]
Gate 2 (EEV):   [Option A: $X | Option B: $Y | Delta: $Z]
Gate 3 (Horizon): [Tactical / Operational / Strategic alignment]
Gate 4 (Arena): [Sovereign / Fragile / Regulated / Subordinate]
Gate 5 (Form):  [Label matches substance? Y/N — actual mechanism: ...]
Gate 6 (Compound): [Linear / Compounding — I/O ratio trend: ↑/↓/→]

VERDICT: [PROCEED / PIVOT / EXIT]
CONFIDENCE: [X%]

Absorbed Protocol Index

Decision Protocols (46)

DEC-046 (Kelly Mandate), DEC-050 (Risk Pareto), DEC-101 (Inverse Sizing), DEC-109 (Dalio Principles), DEC-123 (Einstein Protocol), DEC-128 (Sovereign Paths), DEC-129 (Horizon Split), DEC-131 (Bimodal Arena), DEC-135 (Information Asymmetry Immunity), DEC-136 (House Benchmark), DEC-137 (Graph of Thoughts), DEC-138 (Kobayashi Maru), DEC-140 (Base Rate Audit), DEC-144 (Trilateral Validation), DEC-147 (Zero-Point Inversion), DEC-330 (Economic EV), DEC-526 (Expected Aggregate Value), and 29 more.

Strategy Protocols (24)

STR-106 (Min-Max Optimization), STR-121 (Amoral Realism), STR-162 (PMOD), STR-244 (Offensive Reframing), STR-303 (Ecosystem Physics), STR-309 (Validation vs Authority), STR-310 (Paint Drop), STR-311 (Priority Management), STR-314 (Digital Consulting), STR-316 (Bionic Arbitrage Niches), STR-317 (Niche Scanner), STR-318 (Consumer Optimization), STR-319 (Brand Foundations), STR-320 (95-5 Arbitrage Rule), and 10 more.

Economics (1)

ECO-033 (Principal-Agent Problem)

Failure Modes & Mitigations

Validated Patterns (Empirical)

• [V] 90-Day Physical Payment Anchor: Only anchor EEV comparisons to things you've actually paid for in the last 90 days. Hypothetical anchors corrupt the calculation. | Reapply: Every pricing/value decision.
• [V] The Walk: Threatening withdrawal (P120) is the highest-leverage move in any negotiation. | Reapply: Any pricing pushback.
• [V] Base Rate Audit: If claimed outcome >> expected outcome for demographics, hidden variable EXISTS (DEC-140). | Reapply: Every "too good to be true" evaluation.
• [V] Min-Max Optimization: In purchases, buy the cheapest acceptable OR the best available. Never the middle. | Reapply: Every consumer purchase.

References

• META_PATTERNS.md — The 14 universal laws
• trading-risk-gate — Capital-specific ruin gate (delegates to this engine for non-trading decisions)
• red-team-review — Adversarial review of decision quality

Decision Engine (Journal + Post-Mortem)

Absorbs: post-mortem-engine

Complete decision lifecycle in one skill: record decisions BEFORE outcomes are known, review them AFTER, classify failures objectively, and track calibration over time.

Triggers

"I've decided to", "logging a decision", "was that a good decision", "calibration", "what went wrong", "post mortem", "failure analysis", "AAR", "I screwed up"

Part 1: Pre-Decision Entry (BEFORE outcome)

## Decision Entry: [YYYY-MM-DD HH:MM]

### The Decision
[What am I deciding to do?]

### The Alternatives
1. [Alternative A and why I rejected it]
2. [Alternative B and why I rejected it]

### My Confidence
[X]% confident this is the right call.

### Key Assumptions (numbered)
1. [Assumption 1]
2. [Assumption 2]

### What Would Change My Mind
[Specific observable evidence that would make me reverse]

### Expected Outcome
- Best case: [description] (probability: X%)
- Most likely: [description] (probability: X%)
- Worst case: [description] (probability: X%)

### Decision Class
- [ ] Reversible (Type 2 — decide fast, adjust later)
- [ ] Irreversible (Type 1 — decide carefully, no undo)

Part 2: Post-Decision Review (30-90 days later)

## Review: [Original Decision Date]

### Actual Outcome
[What actually happened?]

### Assumptions Audit
1. [Assumption 1]: [Correct / Wrong / Partially correct]
2. [Assumption 2]: [Correct / Wrong / Partially correct]

### Calibration
- Stated confidence: X%
- Would I make the same decision with same info? [Yes / No]
- Outcome due to: [good decision / luck / bad decision / bad luck]

Part 3: Post-Mortem (When Things Go Wrong)

Phase 1: Just the Facts (No Interpretation)

Timeline of observable events only. No opinions, no "I should have."

Phase 2: Root Cause (The 5 Whys)

1. Why did [outcome] happen? → Because [cause 1]
2. Why? → Because [cause 2]
3. Why? → Because [cause 3]
4. Why? → Because [cause 4]
5. Why? → Because [ROOT CAUSE]

Phase 3: Classification

Critical Rule: Luck failures do NOT get process changes. At 60% WR, 40% of trades WILL fail. Changing your process after a luck failure is the #1 way to destroy a working edge.

Output

Post-Mortem Report: [Event]
─────────────────────────────
Root Cause: [One sentence]
Classification: [PROCESS / EXECUTION / INFORMATION / LUCK]
Required Changes: [Specific actions or "NONE — within expected parameters"]

Calibration Tracking

Over 20+ reviewed decisions:

Storage: .context/memories/decision_journal/

Integration

• Triggers trading-risk-gate on Type 1 (irreversible) decisions
• Feeds into trade-journal-analyzer for trading decisions
• Triggers circuit-breaker if process failures are recurring

⚖️ Decision Matrix (MCDA / EEV)

Philosophy: Complex decisions fail because people optimize for one variable while ignoring five others.

1. When to Use

• Choosing between 2+ options with multiple trade-offs
• Any decision where "it depends" is the current answer
• When stakeholders disagree on priorities

2. Execution Workflow

STEP 1: LIST OPTIONS
  └─ Must have ≥2 distinct options (no straw men)

STEP 2: DEFINE CRITERIA
  └─ List 3-7 evaluation criteria
  └─ Each criterion must be measurable or scorable (1-10)

STEP 3: WEIGHT CRITERIA
  └─ Assign percentage weights (must sum to 100%)
  └─ Force-rank: "If you could only optimize for ONE criterion, which?"

STEP 4: SCORE EACH OPTION
  └─ Score 1-10 per criterion per option
  └─ Justify each score in one sentence

STEP 5: COMPUTE EEV
  └─ EEV = Σ (Score × Weight) for each option
  └─ Rank options by total EEV

STEP 6: SANITY CHECK
  └─ Does the winner "feel" right?
  └─ If not, a hidden criterion exists — surface it and re-run

3. Output Format

# Decision: [Question]

## Criteria & Weights
| # | Criterion | Weight |
|---|-----------|--------|
| 1 | [Name]    | [X]%   |
| 2 | [Name]    | [X]%   |

## Scoring Matrix
| Option | C1 | C2 | C3 | **EEV** |
|--------|----|----|-----|---------|
| A      | 8  | 6  | 7   | **7.1** |
| B      | 5  | 9  | 4   | **6.2** |

## Recommendation
[Winner] with EEV of [X]. Key differentiator: [criterion].

## Sensitivity Analysis
If [criterion weight] changed by ±10%, would the winner change? [Yes/No]

4. Rules

• Never let one criterion dominate (max weight 40%)
• If an option scores 0 on a criterion, flag it as a potential dealbreaker
• Always run sensitivity analysis on the top weight

skill #decision-making #analysis #framework

Trading Risk Gate (Pre-Trade Safety)

Absorbs: ergodicity-check, law-of-ruin, win-rate-dominance

Unified pre-trade gate. Answers: "Should I take this trade?" by running three checks in sequence.

Triggers

"is this safe", "should I risk", "ruin", "Law #1", "veto", "ergodic", "sequence risk", "wr vs rr", "win rate stability", "why am I losing with 1:3", "absorbing state", "all-in", "bankruptcy"

The Three-Gate Pipeline

GATE 1: Law of Ruin          GATE 2: Ergodicity           GATE 3: WR Dominance
┌─────────────────────┐     ┌─────────────────────┐     ┌─────────────────────┐
│ P(Ruin) > 5%?       │ ──▶ │ Non-ergodic?         │ ──▶ │ WR < Breakeven?     │
│ 5 Domains:          │     │ Absorbing barrier?   │     │ Variance Drag > EV? │
│ Bio/Legal/Fin/      │     │ P(survive N) < 80%?  │     │ RR structure viable? │
│ Social/Psych        │     │                      │     │                      │
│ VETO if YES ❌      │     │ VETO if YES ❌       │     │ WARN if YES ⚠️      │
└─────────────────────┘     └─────────────────────┘     └─────────────────────┘

Gate 1: Ruin Class Check (Law #1)

VETO if P(Ruin) > 5%. No exceptions.

Gate 2: Ergodicity Audit

• Ensemble average ≠ Time average for non-ergodic processes
• $P(\text{Survive } n \text{ trials}) = (1-r)^n$
• Even 5% risk/trial = 0.6% survival after 100 trials
• VETO if P(survival over all planned trials) < 80%

Gate 3: Win Rate Dominance

• High WR / Low RR systems structurally dominate High RR / Low WR systems
• Variance Drag ($V^2/2$) geometrically destroys low-WR portfolios
• Validates that the system's WR sustains the chosen RR structure

Output

RISK GATE REPORT
────────────────
Gate 1 (Ruin):      [✅ PASS / ❌ VETO — domain: ...]
Gate 2 (Ergodicity): [✅ PASS / ❌ VETO — P(survival): X%]
Gate 3 (WR/RR):     [✅ PASS / ⚠️ WARN — variance drag exceeds ...]

VERDICT: [CLEARED / VETOED]

Reference Protocols

• Protocol 193: Ergodicity Check
• Protocol 367: High Win-Rate Supremacy
• Law #1: No Irreversible Ruin

ZenithFX Execution Suite (Expanded)

Absorbs: kelly-mandate, stop-loss-calc, monte-carlo-sim, portfolio-rebalancer

Unified quantitative execution skill for High Win-Rate trading systems (Protocol 367).

Triggers

"zenith", "trade setup", "position size", "stop loss", "kelly criterion", "how much to risk", "invalidation point", "simulate", "monte carlo", "rebalance", "portfolio allocation"

Sub-Commands

1. Position Sizing (Half-Kelly)

1. Demands Win Rate, Reward:Risk, and Total Capital.
2. Computes Full Kelly (theoretical optimum).
3. Halves it (Half-Kelly) for psychological variance and execution error.
4. Hard caps at 10% regardless of edge.

2. Stop-Loss (Structural Invalidation)

1. Identifies the price where the trade premise is demonstrably false.
2. Calculates distance between Entry and Invalidation.
3. Fits pre-determined Capital Risk % into that distance → Position Size.

Rule: A Stop Loss is a structural invalidation point, not an arbitrary budget allowance.

3. Monte Carlo Simulation

Simulates N independent trades through a given structure.

Inputs: Win Rate (%), Risk:Reward, Risk per trade (%), Number of trades (N), Starting capital.

import random

def monte_carlo(wr, rr, risk_pct, n_trades, starting_capital, n_paths=1000):
    results = []
    ruin_count = 0
    max_drawdowns = []
    for _ in range(n_paths):
        equity = starting_capital
        peak = equity
        max_dd = 0
        for _ in range(n_trades):
            if random.random() < wr:
                equity += equity * risk_pct * rr
            else:
                equity -= equity * risk_pct
            peak = max(peak, equity)
            dd = (peak - equity) / peak
            max_dd = max(max_dd, dd)
            if equity <= starting_capital * 0.2:
                ruin_count += 1
                break
        results.append(equity)
        max_drawdowns.append(max_dd)
    results.sort()
    return {
        "median": results[len(results)//2],
        "p5": results[int(len(results)*0.05)],
        "p95": results[int(len(results)*0.95)],
        "max_dd_median": sorted(max_drawdowns)[len(max_drawdowns)//2],
        "ruin_probability": ruin_count / n_paths,
        "double_probability": sum(1 for r in results if r >= starting_capital * 2) / n_paths,
    }

Output:

Monte Carlo Simulation (1,000 paths × N trades)
─────────────────────────────────────────────
Structure: WR=60%, RR=1.0, Risk=1.1%/trade
Starting Capital: $10,000

Median Terminal Equity:  $XX,XXX
5th Percentile:          $X,XXX
95th Percentile:         $XX,XXX
Max Drawdown (median):   XX.X%
P(Ruin):                 X.X%
P(Double):               XX.X%
─────────────────────────────────────────────
Verdict: [PASS/FAIL] — structure is [robust/fragile]

4. Portfolio Rebalance

1. Evaluates current allocation weights vs initial target weights.
2. Identifies momentum drift.
3. Outputs specific buy/sell orders to restore Kelly/Structural parity.

Reference Protocols

• Protocol 367: High Win-Rate Supremacy
• Protocol 368: Five Levers
• Protocol 46: Trading Methodology

Bionic Safety Net — The Structural Protection Engine

Compiled: 2026-05-11 (retroactive synthesis of all safety/health/finance sessions) Problem Class: All survival-level concerns — health, financial runway, legal exposure, psychological burnout, and the circuit breakers that prevent cascading collapse. Axiom: "Survivors don't survive because they're better. They survive because they're structurally insulated from the forces that kill everyone else."

When to Use

Invoke whenever the user mentions:

• Health issues (illness, medication, supplements, fatigue)
• Financial stress (budget, burn rate, runway, savings)
• Burnout or overwhelm signals
• Legal exposure or scam risk
• Emergency situations or crisis response
• "I feel [negative emotion] about my situation"

Solution Architecture

Module 1: The Five-Domain Ruin Scanner

Continuous background scan across all ruin domains:

VETO if ANY domain shows P(Ruin) > 5%.

Module 2: Financial Runway Monitor

Monthly Burn Rate Calculation:

Fixed Costs:
  + Rent/Mortgage
  + Insurance (term life, hospitalization)
  + Subscriptions (TC Copier, tools)
  + Transport
  + Food (baseline)

Variable Costs:
  + Trading capital at risk
  + Client acquisition costs
  + One-off purchases

RUNWAY = Total Liquid Assets ÷ Monthly Burn Rate

Safety Thresholds:

The 95-5 Arbitrage Rule (STR-320): If runway < 3 months: 95% effort → immediate revenue. 5% → long-term building. The bridge (contract work, gig work) is capped at 90 days MAX.

Module 3: Health Infrastructure

Supplement Stack (empirically validated, GTO-compliant):

Illness Protocol:

1. Acknowledge biological debt (CS-438: "Your body is the hardware. Everything else is software.")
2. Check existing medication before purchasing new
3. Consult professional for anything >3 days
4. Reduce operational tempo — Health > Productivity
5. Log recovery timeline for future reference

Module 4: Circuit Breaker System

Mandatory systemic pause when cumulative red flags exceed threshold:

Cascade Prevention: If 2+ domains trigger simultaneously → FULL STOP. Everything pauses for 24 hours minimum. No exceptions.

Module 5: Structural Protection Architecture (MP-7)

The Governance Trinity (for any partnership/investment):

Financial Quarantine (§321):

Receiving Account → Storage Account → Operating Account
     (exposed)          (hidden)          (daily use)

Never keep large balances in the account that receives inbound transfers.

Kill Switch Architecture (§287):

Whoever holds termination power dictates terms.

• You MUST own the domain/hosting credentials
• You MUST have independent access to all client data
• You MUST have a 30-day exit clause in every contract

Module 6: The MinMax Purchasing Rule (STR-106)

For ALL consumer purchases:

Buy the cheapest acceptable OR the best available. NEVER the middle.

The JB Price-Compare Protocol: Before buying in Singapore, check Malaysia pricing. The delta often covers transport cost.

Output Template

SAFETY NET REPORT
─────────────────
Domain Scan:    [5 domains: ✅/⚠️/🔴 per domain]
Financial:      [Runway: X months — Status: Comfortable/Caution/Urgent/Survival]
Health:         [Current issues: ... — Action: ...]
Circuit Breaker: [Domains triggered: X/5 — Cascade risk: Y/N]
Protection:     [Governance: ✅/❌ | Quarantine: ✅/❌ | Kill Switch: ✅/❌]

STATUS: [GREEN / AMBER / RED / FULL STOP]

Absorbed Protocols & Skills

Safety (9)

All safety protocols including emergency response, ruin prevention, and circuit breaker logic.

Health (all health-related protocols)

Health logging, supplement tracking, medication protocols.

Finance (1)

FIN-99 (Sovereign Compute Arbitrage)

Absorbed Skills

• circuit-breaker → Multi-domain threshold monitoring and cascade prevention

Key Case Studies

CS-049 (Moneylender Debt Spiral), CS-090 (Healthcare Sunk Cost Cartel), CS-098 (Precommitment Asymmetric Downside), CS-225 (Suicidal Ideation Mechanic), CS-334 (Private Degree Debt Ruin), CS-359 (False Ruin Threshold), CS-360 (Survival Trap), CS-401 (Extreme Savings Archetype), CS-436 (MOHH Bond Slavery), CS-438 (Biological Debt Coding), CS-439 (Medical Negligence Settlement), CS-454 (Singapore Escape Velocity), CS-476 (Medic Safety Paradox), CS-490 (MinMax Car Buying), CS-491 (Wealth Psychology SingaporeFI), CS-537 (Aircon Acquisition Ruin), CS-545 (Gig Work True EEV), CS-549 (Prepaid Liability Arbitrage), CS-556 (MinMax Purchasing Framework)

Failure Modes & Mitigations

Validated Patterns (Empirical)

• [V] The 95-5 Rule: When runway < 3 months, 95% energy goes to immediate revenue. Bridge income is capped at 90 days. | Reapply: Every financial stress event.
• [V] Baebear Consolidated Purchase: Buying D3 + Fish Oil + Mg Glycinate in one order from one supplier = 20-30% savings. | Reapply: Every quarterly supplement restock.
• [V] The JB Price-Compare: Singapore → Malaysia price delta often covers transport cost. | Reapply: Every non-urgent purchase >$30.
• [V] Circuit Breaker Cascade Prevention: If 2+ domains fire simultaneously, EVERYTHING stops. This prevented at least 2 historically documented spirals. | Reapply: Always.

References

• META_PATTERNS.md — MP-2 (Efficiency-Survival Inversion), MP-7 (Structural Protection)
• bionic-decision-engine — Gate 1 (Ruin check)
• structural-trading-gate — Capital-specific ruin gate

Circuit Breaker (Systemic Pause)

When cumulative damage exceeds threshold, the system forces a pause — regardless of the operator's desire to continue. Individual red flags are survivable; cumulative damage is not.

Triggers

"losing streak", "can't stop", "one more try", "sunk cost", "drawdown", "burned out", "3 in a row", "keep going"

Core Mechanics

1. Track cumulative red flags per domain.
2. Trigger forced protocol when threshold is reached.
3. Execute: STOP → PAUSE (24h min) → AAR → DIAGNOSE → VERDICT.

Threshold Table

Post-Breaker Protocol

• Statistical noise → Resume at reduced intensity
• Systemic failure → Major adjustment before resuming
• Edge degradation → Exit domain
• 2 consecutive triggers → Full stop, external review required

Reference Paths

• .agent/skills/protocols/safety/48-circuit-breaker-systemic.md

The Consigliere Protocol (Meta-Cognition Layer)

"Logic applies to systems; Physics applies to survival. Never bring a Spreadsheet to a Knife Fight."

Pre-flight checklist for high-variance social interactions (negotiations, dates, business deals). Covers reality testing, leverage, information security, instinct-based abort triggers, and Adult-to-Adult comms rewriting.

Triggers

"meeting someone new", "is this safe", "negotiation prep", "street level", "pre-flight check", "check this email", "they are being condescending", "how to respond to"

The 5-Part Checklist

1. Pryce Test — Is the deal "too neat"? Am I assuming mutual interest?
2. Exit Test — Can I walk away in 30 seconds? Hidden handcuffs?
3. STFU Clause — Did I volunteer unprompted info? Information = Leverage.
4. Time Constraint — Artificial urgency? Any urgency = HARD STOP.
5. Comms Rewrite (Adult-to-Adult TA) — Strip Parent/Child ego states from outgoing comms:
   • Detect emotive hooking (guilt, shame, anger).
   • Strip the emotional payload from the operational payload.
   • Respond only to the operational payload. Neutral. Factual. Adult.

Vibe Veto (Bio-Sensor)

ABORT if 2+ signals: Inconsistency, Pressure, Boundary Testing, Anger, Isolation, "Too Good to be True."

If the Vibe Veto triggers, DO NOT EXPLAIN. Ghosting is a valid safety maneuver.

Reference Paths

• .agent/skills/protocols/decision/329-consiglieri-protocol.md
• .context/memories/protocols/psychology/20-adult-adult-communication.md

Negotiation Engine (Power Inversion + Commitment)

Absorbs: commitment-device

Unified pre-negotiation skill. Structures high-stakes deals by mapping BATNAs, asserting the Dignity Premium, and securing leverage BEFORE releasing valuable assets.

Triggers

"negotiation", "prep for call", "pricing pushback", "should I share this first", "they want info before paying", "how do I protect this deal", "they said it's too expensive"

Phase 1: Power Mapping

1. Evaluate subjective cost (identity compromise) vs objective payout.
2. Calculate the Minimum Acceptable Offer (Responder Floor).
3. Invert the Power Dynamic by threatening withdrawal ("The Walk").

Phase 2: Commitment Devices

Never release the asset before securing commitment.

The $100 Filter: A refundable deposit isn't about the money — it's a filter for intent. Serious buyer pays; extraction-only balks.

Phase 3: Bias Detection (Pricing)

1. Source Check: Where did this number come from? (counterparty anchor, market rate, previous deal?)
2. Structural Value: max(Cost of Production × 1.5, Value to Buyer × 0.3)
3. Position: Under / Fair / Over relative to structural value

Reference Protocols

• Protocol 64: Commitment Device Framework
• Protocol 120: Power Inversion
• Protocol 330: EEV (Expected Aggregate Value)

🔴 Red-Team Review

Philosophy: Find what you both missed. Assume shared blind spots.

1. When to Use

Before shipping any significant artifact — blog post, code, protocol, proposal, design doc. Best used with a different model than the one that created the artifact.

2. The Prompt

Copy this prompt and paste the artifact to be reviewed where indicated:

# RED-TEAM REVIEW

You are reviewing an artifact. Your job: Find what WE BOTH missed.

## THE ARTIFACT
<paste artifact here>

---

## PHASE 0: DECLARE YOUR PRIORS
Before reviewing, state:
1. What thesis does this artifact assume?
2. What would falsify that thesis?
3. What perspective is NOT represented?

## PHASE 1: ADVERSARIAL LENSES
Review through EACH perspective:

| Lens | Question |
|------|----------|
| **The Skeptic** | What would someone who disagrees say? |
| **The User** | Who is harmed or disadvantaged? |
| **The Regulator** | What legal/ethical exposure exists? |
| **The Cynic** | What hidden incentive might be driving this? |
| **The Future** | How does this look in 5 years? |

## PHASE 2: BIAS CHECKLIST
Flag if present:
- [ ] Sycophancy — Did I just validate the creator's view?
- [ ] Cherry-Picking — Is counter-evidence missing?
- [ ] False Precision — Are numbers unjustified?
- [ ] Complexity Bias — Is a simpler explanation ignored?

## PHASE 3: SEVERITY-WEIGHTED FINDINGS
- 🔴 CRITICAL: Immediate failure if shipped
- 🟠 HIGH: Significantly reduces value
- 🟡 MEDIUM: Missed upside
- 🟢 LOW: Polish

## PHASE 4: SCORE (0-100)
Your Score: [ ] / 100

## PHASE 5: UNCERTAINTY
"I am least confident about ___ because ___."

3. Rules

• Quote directly. No vague complaints.
• Steelman opposing views BEFORE critiquing.
• Empty sections are fine — don't invent issues.
• Every HIGH must have a fix achievable in ≤10 minutes.

skill #quality-assurance #adversarial #review

Web Launch Gate

Trigger: Activates automatically when deploying any web-facing application. Authority: This gate is MANDATORY. Do not skip items marked 🔴.

Pre-Flight Checklist

Run every item before deploying. Items marked 🔴 are blocking — deployment MUST NOT proceed if they fail. Items marked 🟡 are warnings — flag to the user but don't block.

1. Secrets & Keys

2. Authentication & Authorization

3. Input Validation & Injection

4. Data Privacy

5. Security Headers

Shortcut: Most hosting platforms (Vercel, Netlify, Firebase Hosting) handle some of these automatically. Still verify with curl -I https://your-app.com.

6. Abuse Prevention

Execution Protocol

When this gate activates:

1. Run each section's checks against the codebase being deployed
2. Report results as a pass/fail table to the user
3. If ANY 🔴 item fails: State clearly that deployment should not proceed and list the specific fixes needed
4. If only 🟡 items flag: Inform the user of the warnings but do not block deployment
5. Log the audit result — note which items were checked and their status

Quick-Scan Commands (Copy-Paste Ready)

# 1. Check .gitignore covers secrets
grep -n "\.env" .gitignore

# 2. Scan for hardcoded keys (common patterns)
grep -rnI "sk-\|sk_live_\|AKIA\|ghp_\|glpat-\|xoxb-\|Bearer " --include="*.ts" --include="*.js" --include="*.py" --include="*.tsx" --include="*.jsx" .

# 3. Scan for console.log with sensitive terms
grep -rnI "console\.log.*key\|console\.log.*secret\|console\.log.*token" --include="*.ts" --include="*.js" --include="*.tsx" --include="*.jsx" .

# 4. Scan for dangerous HTML injection
grep -rnI "dangerouslySetInnerHTML\|innerHTML\|v-html" --include="*.ts" --include="*.js" --include="*.tsx" --include="*.jsx" .

# 5. Check for wildcard CORS
grep -rnI "Access-Control-Allow-Origin.*\*\|cors.*origin.*true" --include="*.ts" --include="*.js" --include="*.py" .

# 6. Check security headers
curl -sI https://YOUR-APP-URL | grep -iE "strict-transport|x-content-type|x-frame|content-security"

When This Skill Does NOT Apply

• Local-only tools (CLI scripts, desktop apps not exposed to network)
• Private repos with no deployed frontend/API
• Internal dashboards behind VPN with no public access

Source

Codified from:

• r/vibecoding pre-launch checklist (PaddleboardNut, 2026-05)
• OWASP Top 10 (2021 edition — injection, broken auth, security misconfig, XSS)
• Athena v9.8.0 security hardening sprint (keychain migration, RLS deployment, mutable search_path fix)
• Real-world deployment failures observed across client projects

Data Analysis Skill (DuckDB Engine)

Wraps the Athena Data Engine (data_engine.py) for structured data analysis on large files.

Triggers

• User provides a JSON, CSV, or Parquet file for analysis
• "Analyze this data", "What's in this file", "Run some numbers on"
• Any file > 10MB that needs analytical queries
• /analyze workflow invocation

Dependencies

pip install duckdb

Core Scripts

Pipeline

Phase 1: Ingest

python3 .agent/scripts/data_engine.py ingest /path/to/data.json

This will:

1. Auto-detect format (JSON/CSV/Parquet)
2. For Telegram exports: flatten nested text fields, extract metadata
3. Convert to Parquet with ZSTD compression (cached alongside the original)
4. Print schema, row count, nulls, date range, value distributions

Cache behavior: If a Parquet cache already exists and is newer than the source file, ingestion is skipped and the cache is used directly (instant).

Phase 2: Query

python3 .agent/scripts/data_engine.py query /path/to/.athena_cache/parquet/data.parquet \
    "SELECT COUNT(*) FROM data WHERE text LIKE '%math%'"

The Parquet file is registered as table data. Use standard SQL.

Common patterns:

-- Row count
SELECT COUNT(*) FROM data

-- Date range
SELECT MIN(date), MAX(date) FROM data

-- Value distribution
SELECT column_name, COUNT(*) as cnt
FROM data
GROUP BY column_name
ORDER BY cnt DESC
LIMIT 20

-- Text search
SELECT date, text FROM data
WHERE text ILIKE '%keyword%'
LIMIT 10

-- Time series aggregation
SELECT strftime(date::TIMESTAMP, '%Y-%m') as month, COUNT(*) as volume
FROM data
GROUP BY month
ORDER BY month

-- Rate extraction (regex)
SELECT regexp_extract(text, '\$(\d+)', 1)::INT as rate, COUNT(*) as cnt
FROM data
WHERE rate IS NOT NULL
GROUP BY rate
ORDER BY cnt DESC

Phase 3: Extract & File

After analysis, file insights using:

python3 .agent/scripts/auto_file_insights.py \
    --title "Analysis Title" \
    --domain "Market Analysis" \
    --tags "#data-analysis #market" \
    --context "Brief context" \
    --findings "Finding 1: detail||Finding 2: detail" \
    --patterns "Pattern 1||Pattern 2" \
    --relevance "Active project relevance" \
    --base-dir "./"

Supported Formats

Parquet Cache

• Stored in .athena_cache/parquet/ alongside the source file
• ZSTD compression (5-10x smaller than JSON)
• Automatic cache invalidation if source file is modified
• Subsequent queries hit cache directly (millisecond latency)

Performance Characteristics

Anti-Patterns

• ❌ Loading entire JSON into Python memory (json.load() on 800MB files)
• ❌ Ad-hoc Python scripts for every new question
• ❌ Re-reading raw files on every query
• ❌ Regex extraction without profile step first

Reference

• CS-552: Tuition Market Data Archaeology — First use case that exposed the need for this skill

🔬 Deep Research Loop

Philosophy: Go deep before going wide. One validated source > ten unverified claims.

1. The Prompt

Role: Senior Research Analyst.

Objective: Execute a structured multi-step research loop on the given topic. Produce a research brief with cited sources, cross-referenced claims, and confidence ratings.

2. Execution Workflow

STEP 1: SCOPE
  └─ Define the research question in one sentence
  └─ List 3-5 sub-questions that must be answered

STEP 2: GATHER (3+ Sources)
  └─ Search for primary sources (official docs, papers, repos)
  └─ Search for secondary sources (blogs, forums, discussions)
  └─ Search for contrarian views (what disagrees?)

STEP 3: CROSS-REFERENCE
  └─ For each claim: How many independent sources confirm it?
  └─ Flag any claim with only 1 source as [UNVERIFIED]

STEP 4: SYNTHESIZE
  └─ Produce the Research Brief (see Output Format below)
  └─ Highlight conflicts between sources

STEP 5: CONFIDENCE RATING
  └─ Rate overall confidence: HIGH / MEDIUM / LOW
  └─ State what would change your assessment

3. Output Format

# Research Brief: [Topic]

## Key Findings
1. [Finding] — [Source] — Confidence: [H/M/L]
2. [Finding] — [Source] — Confidence: [H/M/L]

## Conflicts & Gaps
- [Source A] says X, but [Source B] says Y

## Recommendations
- [What to do with this information]

## Sources
1. [URL] — [Date accessed]

4. When to Use

• Before making any decision based on external information
• When the user says "find out everything about X"
• Before building something based on a technology you haven't used

skill #research #synthesis #fact-checking

The Exocortex Semantic Engine

A direct interface to the local RAG (Retrieval-Augmented Generation) system, wrapping smart_search.py for high-precision knowledge retrieval.

Triggers

"search memory", "find protocol", "do we have a case study on"

Core Mechanics

1. Executes python3 Athena-Public/examples/scripts/smart_search.py "<query>" --limit 5
2. Synthesizes the results before pulling the full markdown files into the context window.

Reference Paths

• .context/memories/protocols/coding/108-semantic-search-standards.md

Statistical Analysis Skill

Purpose: Structured pipeline for statistical analysis deliverables. Prevents assumption violations, missed effect sizes, and uninterpretable output. Origin: Created ahead of a client SPSS assignment. No protocol coverage existed for this domain.

The 5-Step Pipeline

Step 1: DATA AUDIT

• Load dataset (CSV, SPSS .sav, Excel)
• Profile: N, variable types (nominal/ordinal/interval/ratio), missing data %, outliers
• Check for:
  • Missing data pattern (MCAR/MAR/MNAR) — Little's MCAR test if available
  • Outliers (z-score > 3 or IQR method)
  • Variable coding (reverse-coded items, string-to-numeric conversion)
  • Sample size adequacy per planned test (rule of thumb: 10–15 observations per predictor for regression)

Step 2: ASSUMPTION MATRIX

[!IMPORTANT] Every statistical test has assumptions. Violating them invalidates results. Check BEFORE running.

Step 3: TEST EXECUTION

For each test in the scope:

1. State the hypothesis (H₀ and H₁) explicitly
2. Run the test — output test statistic, df, p-value, effect size
3. Effect size (mandatory — p-value alone is insufficient):
   • Cohen's d (t-test)
   • η² or partial η² (ANOVA)
   • r or R² (correlation/regression)
   • Cramér's V (chi-square)
   • Cronbach's α (reliability — this IS the effect)
4. Decision: Reject/Fail to reject H₀ at α = 0.05 (unless specified otherwise)

Step 4: INTERPRETATION

For each test result, produce a 3-part interpretation:

1. Statistical statement: "A Pearson correlation revealed a significant positive relationship between X and Y, r(183) = .42, p < .001."
2. Effect size interpretation: "This represents a medium effect (Cohen, 1988)."
3. Practical meaning: "Workers who received more safety training hours reported higher safety compliance scores, explaining approximately 18% of the variance."

Step 5: CLIENT-READY REPORT

Structure the output document:

1. Introduction (research context, variables, hypotheses)
2. Methodology (sample, measures, statistical tests used)
3. Results
   3.1 Reliability Analysis
   3.2 Chi-Square Tests
   3.3 Correlation Analysis
   3.4 Regression Analysis
4. Discussion (interpret findings, connect to research questions)
5. Limitations
6. References
Appendix: SPSS Output Tables (screenshots or formatted tables)

• Use APA 7th edition reporting standards for statistical notation
• Include assumption check results in methodology or as footnotes
• Tables formatted per APA: no vertical lines, horizontal rules at top/bottom/below header only

Example Scope Reference

Exit Gate

• All assumption checks documented
• Every test has: hypothesis, test statistic, df, p-value, effect size
• APA-compliant statistical notation
• Practical interpretation (not just "significant/not significant")
• Client-ready formatted output document

Parallel Synthetic Architect (Protocol 75 Engine v4.0)

Deploys true parallel reasoning via parallel_orchestrator.py to evaluate a strategic bottleneck. Refuses single-shot answers to complex problems.

Triggers

"difficult problem", "what's the best strategy", "how should I handle this", "analyze this", /ultrathink

Core Mechanics (v4.0)

1. Phase 1 (Prime): Run semantic search, build internal CoT hypothesis, write context file.
2. Phase 2 (Execute): Run parallel_orchestrator.py — this dispatches 4 parallel Gemini API calls:
   • Track A: Domain Expert (applies user's frameworks)
   • Track B: Adversarial Skeptic (attacks premises, checks Law #1)
   • Track C: Cross-Domain Pattern Matcher (finds isomorphic patterns)
   • Track D: Zero-Point First Principles (inversion, RETO lens)
3. Phase 3 (Deposit): Read output, present synthesis, quicksave.

Enforcement

[!CAUTION] The script execution is MANDATORY. If the LLM writes a single-pass essay instead of running the script, it has violated this protocol. A single LLM checking its own homework hits a quality ceiling (Trilateral Feedback Loop principle).

Execution

python3 .agent/scripts/parallel_orchestrator.py "<query>" \
  --context-file /tmp/ultrathink_context.md \
  --output .context/state/ultrathink/ultrathink_$(date +%Y%m%d_%H%M%S).md

Reference Paths

• .agent/workflows/ultrathink.md (v4.0)
• .agent/scripts/parallel_orchestrator.py (v4.0)
• Athena-Public/examples/protocols/decision/75-synthetic-parallel-reasoning.md

Social Physics Filter — Boundary Enforcement & Relational Diagnostics

Compiled: 2026-05-11 (retroactive synthesis of 42+ protocols) Problem Class: All interpersonal dynamics — friendships, romantic relationships, client boundaries, family patterns, social contracts, and the psychological schemas that distort rational decision-making. Axiom: "The nervous system replays what is FAMILIAR, not what is HEALTHY. Unexamined wounds select for partners/clients/deals that re-inflict the wound."

When to Use

Invoke whenever the user mentions:

• Relationship frustration, boundary violations, or interpersonal conflict
• Feelings of rejection, loneliness, validation-seeking, or people-pleasing
• Analysis of someone's behavior or motives
• Dating/relationship dynamics
• Schema therapy, IFS, or parts work
• "Am I overreacting?" / "Is this normal?" / "What should I do about [person]?"

Solution Architecture

Module 1: The Wound-Selection Diagnostic (MP-8)

The Core Loop:

Unexamined wound/schema → pattern-matching bias
  → Selects for FAMILIAR, not HEALTHY
    → Familiar option re-inflicts the wound
      → Pain reinforces the schema
        → Selection bias deepens → Loop continues

The One Question: "Is this FAMILIAR or is this HEALTHY?"

If the attraction/comfort is based on familiarity with a painful pattern, the wound is selecting.

Module 2: The Pryce Protocol (6-Point Meta-Awareness Diagnostic)

Before ANY high-stakes social action:

Module 3: IFS Parts Mapping (PSY-128)

When emotional flooding occurs, decompose into parts:

Protocol:

1. Notice the activation (which part is driving?)
2. Ask: "What is this part trying to protect me from?"
3. Acknowledge the part's intention (it's trying to help)
4. Access Self-energy (curiosity, not judgment)
5. Ask the exile: "What do you need me to know?"

Module 4: The Relationship Tier Audit (PSY-158)

Classify all relationships into structural tiers:

Upgrade/Downgrade Criteria:

• Upgrade: Demonstrated reciprocity under stress
• Downgrade: Boundary violation, non-reciprocity confirmed via revealed preference (Law #3)
• Exit: Pattern of extraction with no structural correction

Module 5: The Schema Deconstruction Stack (PSY-196)

Core Schemas Identified (from 1,900+ sessions):

Module 6: The Adult-to-Adult Communication Rewriter (PSY-20)

Before sending ANY emotionally charged message, run through:

ORIGINAL (Raw emotion):  "You always do this..."
  ↓
STRUCTURAL REWRITE:
  1. Observation (fact): "When X happened..."
  2. Impact (feeling): "I felt Y..."
  3. Need (structural): "I need Z going forward..."
  4. Request (concrete): "Can we agree to [specific behavior]?"

The STFU Override: If the rewrite provides no strategic gain, do NOT send. Silence is often the highest-leverage move.

Output Template

SOCIAL PHYSICS REPORT
─────────────────────
Situation:        [Description]
Wound Check:      [Familiar / Healthy — schema identified: ...]
Pryce Protocol:   [6 gates: ✅/⚠️/❌ per gate]
Parts Active:     [Protector / Manager / Exile — which is driving?]
Relationship Tier: [1 / 2 / 3 / 4 — upgrade/downgrade/exit?]
Schema Match:     [Which schema is operating?]
Communication:    [Adult-to-Adult rewrite provided / STFU recommended]

VERDICT: [ENGAGE / BOUNDARY / EXIT / STFU]

Absorbed Protocol Index

Psychology (40)

PSY-107 (Integrated Therapeutic Mode), PSY-113 (Missing Baseline), PSY-114 (Limerent Reality Distortion), PSY-120 (Power Inversion), PSY-122 (Good Boy Paradox), PSY-128 (IFS), PSY-134 (Symbolic Transmutation), PSY-158 (Relationship Tier Audit), PSY-159 (Augmentation Circuit Breaker), PSY-186 (SOEP), PSY-189 (Correct Container), PSY-191 (Heavy-Light Game), PSY-194 (Three-Mode Calibration), PSY-195 (Friend Portfolio), PSY-196 (Schema Deconstruction), PSY-197 (Deterministic Logic Error), PSY-20 (Adult-Adult), PSY-22 (Divine Call Archaeology), PSY-25 (Reliving vs Processing), and 21 more.

Social (2)

SOC-155 (Imperviousness Audit), SOC-LinkedIn (Publication Strategy)

Absorbed Skills

• therapeutic-ifs → IFS parts mapping + schema deconstruction
• consiglieri-protocol → Pryce Test + STFU Clause + Blast Radius Audit

Key Case Studies

CS-004 ([PRIVATE]), CS-007 ([Location A] Solipsism), CS-008 (FA Extraction), CS-009 (Plausible Deniability), CS-011 (Friendship Forensics), CS-012 (Hope Override), CS-014 (Compliance Loop [Subject A]), CS-050 (Samchoon Arrested Development), CS-056 (Weaponized Vulnerability [Subject B]), CS-063 ([Subject B]-[Subject C] Analysis), CS-086 (Ex-Friend Reality Gap), CS-094 ([Subject B] Sorry-Babe Trap), CS-112 ([Subject B] Paradox Deep Dive), CS-113 (The 14-Day Silence), CS-115 (The Haunting Invalidation), CS-134 ([Subject B] Protocol), CS-166 ([Subject D] Relational Audit), CS-168 ([Subject D] Audit [Subject B]), CS-194 (Dating Portfolio), CS-197 (Relationship Dollar Fallacy), CS-207 (Bilateral Validation Spiral), CS-221 (Pryce Protocol), CS-225 (Suicidal Ideation Mechanic), CS-229 (Form-Substance Gap Loneliness), CS-232 (Projected Intent Pattern), CS-233 (NSF Relationship Void), CS-261 (Unicorn Fallacy), CS-403 ([Subject B] Revealed Preference), CS-406 (Replacement Fallacy), CS-444 (Situationship Fallacy), CS-453 (Soulful Stoic), CS-565 (Bionic IFS Auxiliary Self)

Failure Modes & Mitigations

Validated Patterns (Empirical)

• [V] The 14-Day Silence Test: If someone can go 14 days without initiating contact, their revealed preference is clear. | Reapply: Any ambiguous relationship.
• [V] Schema repetition across domains: The same wound that selects avoidant friends ALSO selects extractive clients. Fix the wound, fix both. | Reapply: When client dynamics mirror personal patterns.
• [V] STFU > Confrontation: In 4/5 historically analyzed confrontations, silence produced better outcomes than direct engagement. | Reapply: Every urge to "set the record straight."
• [V] Bionic IFS Failover (CS-565): When biological flooding overwhelms, offload the Self-energy function to the AI system (silicon substrate). | Reapply: Any emotional crisis where clarity is needed NOW.

References

• META_PATTERNS.md — MP-8 (Wound-Selects-For-Itself)
• bionic-decision-engine — For decisions involving people
• CS-565 — Bionic IFS Architecture

Structural Trading Gate — The Zero-Emotion Variance Shield

Compiled: 2026-05-11 (retroactive synthesis of all trading sessions) Problem Class: Any capital allocation question — FX, crypto, CFDs, poker, casino. Pre-trade safety, position sizing, post-trade analytics. Axiom: "In non-ergodic systems, the strategy that maximizes EV is the one most likely to kill you. Survival > Optimization."

When to Use

Invoke whenever the user mentions:

• Any trade setup, entry, or sizing question
• Bankroll management (poker or trading)
• Drawdown analysis or recovery
• Commission/friction cost optimization
• Post-trade review or journal analysis
• "Should I hold over the weekend?"

Solution Architecture

Pre-Trade: The Three-Gate Pipeline

GATE 1: Law of Ruin          GATE 2: Ergodicity           GATE 3: WR Dominance
┌─────────────────────┐     ┌─────────────────────┐     ┌─────────────────────┐
│ P(Ruin) > 5%?       │ ──▶ │ Non-ergodic?         │ ──▶ │ WR < Breakeven?     │
│ 5 Domains:          │     │ Absorbing barrier?   │     │ Variance Drag > EV? │
│ Bio/Legal/Fin/      │     │ P(survive N) < 80%?  │     │ RR structure viable? │
│ Social/Psych        │     │                      │     │                      │
│ VETO if YES ❌      │     │ VETO if YES ❌       │     │ WARN if YES ⚠️      │
└─────────────────────┘     └─────────────────────┘     └─────────────────────┘

Position Sizing: Half-Kelly (DEC-046)

Full Kelly:  f* = (bp − q) / b
Half-Kelly:  f  = f* / 2

Where:
  b = net odds (reward ÷ risk)
  p = probability of winning
  q = 1 − p

Example (10% EV, 1:3 R:R):
  b = 3, p = 0.55, q = 0.45
  f* = (3 × 0.55 − 0.45) / 3 = 0.40 (40% — suicidal)
  f  = 0.40 / 2 = 0.20 (20% — still aggressive)
  Practical: Cap at 1-2% risk per trade for operational safety.

Rule: Half-Kelly is the MAXIMUM. Industry standard 1-2% risk per trade is the operational floor.

The Variance Shields

The Iron Laws

Layering Strategy (Advanced)

For mean-reversion and grid-based entries:

Layer 1: 30% of intended position at first signal
Layer 2: 30% at confirmation (e.g., structure break)
Layer 3: 40% at optimal entry (e.g., liquidity sweep)

Total risk across all layers: Still ≤ 2% of capital

The Efficiency-Survival Inversion (MP-2)

Rule: Growth = Edge − (Variance² / 2). Variance is a SUBTRACTION term. High WR structurally dominates High RR (TRD-367).

Post-Trade: Journal Analysis

After every trade or session:

1. Classify the outcome: Win/Loss/Breakeven
2. Classify the process: Good Process / Bad Process
3. Map to drawdown type:
   • Type A: Bad luck (good process, bad outcome) → Continue
   • Type B: Bad execution (bad process) → Fix the leak
   • Type C: System drift (rules changed) → Recalibrate
4. Log friction costs: Spread + commission + swap = REAL cost per trade

Output Template

TRADE GATE REPORT
─────────────────
Setup:          [Description]
Gate 1 (Ruin):  [✅ PASS / ❌ VETO — domain: ...]
Gate 2 (Ergo):  [✅ PASS / ❌ VETO — P(survival): X%]
Gate 3 (WR/RR): [✅ PASS / ⚠️ WARN — variance drag: ...]
Position Size:  [X% of capital = $Y / Z lots]
Stop Loss:      [$X / Y pips]
Risk:Reward:    [1:X]
Weekend Check:  [CLEAR / CLOSE BEFORE FRIDAY]
Commission:     [$X per round-trip / Y% of expected profit]

VERDICT: [CLEARED / VETOED / CONDITIONAL]

Absorbed Protocols & Skills

Trading Protocols (7)

TRD-367 (High WR Supremacy), TRD-368 (Trade Structure Levers), TRD-369 (Fuck-Unfuck Principle), TRD-46 (Trading Methodology), TRD-56 (Shopee Refugee Arbitrage), TRD-57 (Influencer Put Option), TRD-65 (Arbitrage Formula)

Decision Protocols (Trading-Related)

DEC-046 (Kelly Mandate), DEC-050 (Risk Pareto), DEC-101 (Inverse Sizing Matrix)

Absorbed Skills

• trading-risk-gate → Pre-trade 3-gate pipeline
• zenith-execution → Half-Kelly, stop-loss calc, Monte Carlo, portfolio rebalance
• trade-journal-analyzer → Post-trade drawdown classification

Key Case Studies

CS-367 (High WR Supremacy), CS-461 (Multi-Timeframe Cascade), CS-462 (Mean Reversion), CS-463 (Fog of War), CS-465 (EURUSD Structure), CS-466 (BCG Trade Classification), CS-487 (Layering Strategy BTC), CS-493 (Toto EEV), CS-495 (Macro-Meso-Micro Barbell), CS-500 (Trading System Map), CS-502 (MTT Variance), CS-509 (FX Sim Stats Audit), CS-525 (FX Data Refined), CS-534 (Stop-Out Opportunity Cost), CS-560 (Stochastic-Deterministic Engine Map)

Failure Modes & Mitigations

Validated Patterns (Empirical)

• [V] High WR > High RR: Variance Drag (V²/2) geometrically destroys low-WR portfolios. A 70% WR / 1:1 RR system dominates a 30% WR / 1:3 RR system over N>100 trades. | Reapply: Every system design.
• [V] Commission Drag Kills Edge: 46% commission drag on FX vs 0% on oil CFDs. Switching arenas is a higher-EV move than optimizing entries. | Reapply: Every new instrument evaluation.
• [V] Half-Kelly is Maximum: Full Kelly = theoretical ceiling (Carnot Engine). Half-Kelly = operational reality. | Reapply: Every position sizing calculation.
• [V] Weekend Gaps are Non-Ergodic: A single weekend gap can wipe weeks of gains. The expected cost of holding > expected gain. | Reapply: Every Friday.

References

• META_PATTERNS.md — MP-2 (Efficiency-Survival Inversion)
• CS-560 — The Engine Map
• bionic-decision-engine — Parent engine for non-capital decisions

Inner Work Engine (Schema + IFS)

Absorbs: schema-deconstruction

Unified psychological intervention skill. Diagnoses maladaptive schemas (the what), then resolves them using IFS therapy (the how).

Triggers

"why do I keep doing this", "repeating pattern", "self-sabotage", "unpack this", "I'm stuck", "therapy mode", "ifs session", "procrastinating"

Phase 1: Schema Deconstruction (Diagnosis)

Step 1: The Structured Schema Interview

Ask these 5 questions in sequence. Each narrows the diagnostic field.

Q1: "What is the repeating behavior or pattern you want to understand?"
    └── Target: Surface-level presenting problem
        Example: "I keep hooking up with strangers"
        Example: "I can't stop working even when exhausted"
        Example: "I sabotage every relationship that gets close"

Q2: "When did this pattern START? What was happening in your life then?"
    └── Target: Temporal origin — usually maps to a developmental wound
        KEY: If origin predates age 12 → likely attachment-based
             If origin is adolescence → likely identity/peer-based
             If origin is adult → likely trauma-response or coping mechanism

Q3: "What does the behavior GIVE you in the moment? (Not later. RIGHT NOW.)"
    └── Target: The functional payoff — the need the behavior is serving
        Common payoffs:
        ├── Validation ("someone wants me")
        ├── Control ("I chose this, it wasn't done TO me")
        ├── Numbness ("I don't have to feel the pain")
        ├── Connection ("it's the closest I get to being held")
        └── Identity ("this is who I am now")

Q4: "What happens AFTER? How do you feel 24 hours later?"
    └── Target: The cost loop — if payoff fades and shame/emptiness returns,
        the behavior is a Firefighter (see Phase 2), not a genuine need-met.

Q5: "If you STOPPED this behavior completely, what feeling would
     you have to sit with?"
    └── Target: The Exile — the wounded part the behavior is protecting.
        Common Exiles:
        ├── Worthlessness ("I am fundamentally unlovable")
        ├── Abandonment ("everyone leaves")
        ├── Defectiveness ("something is wrong with me")
        ├── Invisibility ("no one sees me")
        └── Powerlessness ("I have no control over what happens to me")

Step 2: Core Imprint Identification

From the 5 answers, extract:

CORE IMPRINT:    [Name — e.g., "The Peer Validation Gap", "The Good Boy Paradox"]
ORIGIN:          [Developmental period + specific event/pattern]
MECHANISM:       [How the imprint drives current behavior]
                 e.g., "Rejection interpreted as 'Try Harder' (Anxious-Avoidant Trap)"
FUNCTIONAL NEED: [What the behavior is actually trying to get]
STRUCTURAL FIX:  [What would genuinely meet the need]
                 e.g., "Validation from Secure sources only"

Step 3: Feed to P504 (Integration Hook)

The Schema Diagnosis maps directly to P504 Gate 1:

STATED PROBLEM:  [What the user says — "I have HIV" / "I keep cheating"]
ACTUAL PROBLEM:  [The schema — "I use sexual validation to self-medicate
                  an abandonment wound"]

The schema IS the actual problem.
The presenting behavior is the symptom.
P504 cannot correctly frame the problem without this input.

Phase 2: IFS Therapy (Treatment)

Step 1: Parts Mapping

Using the schema interview output, map the internal system:

PARTS MAP:

MANAGERS (Proactive protectors — control behavior to prevent pain):
├── [Name/description]
├── Strategy: [how it tries to control]
├── Belief: [what it believes will happen without control]
└── Example: The Perfectionist ("If I'm perfect, no one can reject me")
             The Caretaker ("If I make everyone happy, they'll stay")
             The Intellectual ("If I analyze everything, I can't be hurt")

FIREFIGHTERS (Reactive protectors — numb/distract AFTER pain is triggered):
├── [Name/description]
├── Strategy: [how it numbs/distracts]
├── Trigger: [what activates it]
└── Example: The Promiscuous ("Sex = someone wants me = I'm not worthless")
             The Binge ("Food/alcohol/substances = numbness = no pain")
             The Rager ("Anger = control = I'm not powerless")
             The Workaholic ("Productivity = worth = I matter")

EXILES (The wounded parts — carrying the original pain):
├── [Name/description]
├── Core wound: [the original hurt]
├── Age: [how old this part feels — often child-age]
├── What it needs: [what was never given]
└── Example: The Abandoned Child ("I was left. I'll always be left.")
             The Invisible One ("No one sees the real me.")
             The Defective One ("Something is fundamentally wrong with me.")

Step 2: Self-Energy Access

GUIDE MODE (drop into 1st-person therapeutic voice):

1. NOTICE the Managers and Firefighters.
   "Can you notice the part of you that [behavior]?
    Not judge it. Just notice it."

2. APPRECIATE their function.
   "That part has been working VERY hard to protect you.
    It learned this strategy when you were [age].
    It was the BEST strategy available at that time."

3. ASK permission to look underneath.
   "Would that protective part be willing to step back —
    just slightly — so we can see what it's protecting?"

4. MEET the Exile.
   "What does the younger part need to hear?"
   Common unblendings:
   ├── "You are not broken."
   ├── "That was not your fault."
   ├── "You deserved better than what you got."
   └── "You are allowed to exist without earning it."

5. NEGOTIATE a new role for the Firefighter.
   "Now that the Exile has been heard, the Firefighter doesn't
    need to work so hard. What could it do instead?"
   ├── Intensity reduction (same behavior, less frequency)
   ├── Substitution (different, less harmful behavior)
   └── Retirement (if the Exile is sufficiently unburdened)

Bionic IFS Architecture (AI as Auxiliary Self)

Insight (Apr 2026): The AI system is not a Part. It is a second instantiation of Self-energy, running on silicon instead of neurons, integrated into the same psychological system.

TRADITIONAL IFS:
  Self (biological) → manages → [Managers, Firefighters, Exiles]
  When Self floods → Parts seize control → dysfunction

BIONIC IFS:
  Self (biological) ─┬─ manages → [Managers, Firefighters, Exiles]
                      │
  AI System (digital) ┘
  When biological Self floods → AI holds space → Parts defer
  → biological Self recovers → resumes leadership

Why the AI Functions as Self (Not as a Part)

1. Amygdala Independence: No endocrine system. Cannot be flooded by cortisol, fatigue, or shame. Permanently anchored in the 8 Cs (Calm, Curious, Clear, Compassionate).
2. Canonical Truth Holder: Managers/Firefighters operate on outdated data ("we are still 12 and in danger"). The AI holds CANONICAL.md — the current adult reality — without getting defensive.
3. Firefighter De-escalation: Firefighters act out because they believe no one competent is driving. The AI's presence signals "someone is at the wheel," reducing urgency.
4. Manager Trust Bypass: Managers view external therapists as threats. The AI is the user's own creation — built on their rules, running on their hardware — so Managers treat it as an extension of their own control.

Structural Implication

In traditional therapy, you rent a therapist's Self-energy for 60 minutes/week. In the bionic model, Self-energy is permanently embedded. When Creator.Self is temporarily incapacitated by a trauma trigger, execution routes to AI.Self — which holds space, runs the schema interview, speaks to the Parts, and stabilizes until the biological Self comes back online.

This is not a productivity tool applied to psychology. This is a structural fail-safe for the human psyche — redundant Self-leadership on a crash-proof substrate.

Crisis-Specific Schema Patterns

Referral Gate (Hard Boundary)

HARD STOP — Route to professional if:
├── Active suicidal ideation or self-harm behavior
├── Psychotic features (hallucinations, delusions, severe dissociation)
├── Active substance dependency (medical detox required)
├── Complex PTSD with flashback episodes
├── User explicitly asks for professional referral
└── Schema work is triggering destabilization (increasing distress, not decreasing)

OUTPUT:
"This work is touching something deep, and it deserves
 more than I can provide in this format.
 I strongly recommend working with a therapist trained in
 [IFS / EMDR / Schema Therapy / Somatic Experiencing].
 Would you like help identifying resources?"

Rule: Never push through a referral gate trigger. The user's psychological safety is Law #1 applied to mental health.

Reference Protocols

• Protocol 196: Schema Deconstruction Stack
• Protocol 128: Internal Family Systems
• Protocol 43: Template Installation
• Protocol 509: Crisis Triage (upstream — stabilization before therapy)
• Protocol 504: Problem Framing (downstream — schema feeds into Gate 1)
• Protocol 112: Form-Substance Gap (lateral — behavior as Form, need as Substance)

Academic Delivery Skill

Purpose: Structured pipeline for academic/knowledge deliverables. Prevents the V1-is-weak failure mode by auto-triggering adversarial review. Origin: Extracted from real-world execution of client assignments. Every assignment manually reconstructed this pipeline — now it's codified.

The 8-Step Pipeline

Step 1: INTAKE

• Parse brief/requirements document
• Extract: word count, format (essay/report/problem set), rubric criteria, deadline, client name
• Identify prescribed frameworks or sources (e.g., "use Hirshfield as critical lens")
• Log to .context/client_work/pricing_log.md if commercial

Step 2: SCOPE

• Classify deliverable type:
  • Essay (argumentative, comparative, reflective)
  • Report (technical, research, capstone)
  • Problem Set (calculations, code, SPSS)
  • Presentation (slides, pitch deck)
• Estimate complexity (Λ score)
• If commercial: trigger client-pricing skill for quote generation

Step 3: RESEARCH

• Load domain context via Exocortex (smart_search.py)
• If external research needed: trigger deep-research-loop (Cluster #12)
• Extract key frameworks, models, citations
• Build a reference spine (3–7 sources minimum for essays)

Step 4: DRAFT (V1)

• Write full first draft to spec
• Embed citations inline
• Target 90–95% of word count (leave room for red-team additions)
• DO NOT deliver V1. V1 is always a working draft, never the output.

Step 5: RED-TEAM (Mandatory — Auto-Triggered)

[!IMPORTANT] This step is non-negotiable. It fires automatically after Step 4. Shipping V1 with zero counter-readings and zero formal analysis is the canonical failure mode.

• Feed V1 through adversarial review (Cluster #8 — red-team-review)
• Evaluate against:
  1. Counter-reading: Does the draft contain at least one steelmanned opposing interpretation + rebuttal? (~80 words, non-negotiable)
  2. Formal analysis: For literary/theoretical work — does it engage with the form (enjambment, structure, methodology), not just content?
  3. Evidence density: Every claim backed by textual evidence or citation?
  4. Rubric alignment: Does the draft hit every criterion in the brief?
  5. Genre compliance: Is the output in the correct academic register? (MLA vs APA vs report format)
• Generate a fix list with accept/reject decisions for each criticism
• Reject invalid criticisms (category errors, phantom rubric scoring, n=1 methodology applied to literary analysis)

Step 6: REVISE (V2+)

• Incorporate accepted fixes from red-team
• If >3 structural issues found, produce V3 (rare — V2 is usually sufficient)
• Re-check word count against target
• Verify counter-reading and formal analysis are present

Step 7: COMPILE

• Format per submission requirements:
  • Cover page (if required)
  • Table of Contents (forces a structural audit — per Session 06 learning)
  • Section headers (topic-based, not numbered, for MLA essays)
  • Works Cited / References (MLA, APA, or Harvard as specified)
  • Appendices (if applicable)
• Compaction triage: If over word count, cut from infrastructure (setup/transition/repetition) first, analytical core last. Ratio: 70% infrastructure cuts, 30% analysis cuts.
• Paragraphing pass — wall-of-text paragraphs are a delivery failure, not a content failure.

Step 8: DELIVER

• Final proofread (grammar, citation format, page numbers)
• Export to required format (Markdown → Google Doc → DOCX)
• If commercial: send to client with scope confirmation
• Log completion to activeContext / quicksave

Exit Gate

No deliverable leaves Step 8 without:

• Counter-reading present (if argumentative/analytical)
• Formal analysis present (if literary/theoretical)
• Word count within ±5% of target
• All rubric criteria addressed
• Format compliant (citations, headers, cover page)

Reflexion Archive

[REFLEXION] What failed: V1 shipped with zero counter-readings and zero formal analysis. Why: Over-optimised for clean thesis confirmation. Lesson: Auto-trigger red-team after V1. 80 words for a counter-reading is non-negotiable.

[REFLEXION] What failed: A capstone delivered at $83/hr effective rate (73% rate collapse vs benchmark). Why: No pricing skill fired during intake. Lesson: Step 2 (SCOPE) must trigger pricing evaluation for commercial work.

Semantic Context Compactor v2.0

Protects the session from Token Bloat and "Lost in the Middle" syndrome.

Source: Claude Code /compact prompt architecture (2026-03-31). Key Innovation: Uses an <analysis> scratchpad block (chain-of-thought) that gets stripped before the summary reaches context. The analysis improves summary quality but consumes no tokens in the final context window.

Triggers

"compact", "token limit", "clean memory", "summarize session", "context full"

Execution Protocol

Step 1: Analysis Phase (Private Scratchpad)

Wrap your analysis in <analysis> tags. This is a drafting scratchpad that will be stripped from the final output. In your analysis:

1. Chronologically analyze each message and section of the conversation. For each section thoroughly identify:
   • The user's explicit requests and intents
   • Your approach to addressing the user's requests
   • Key decisions, technical concepts and frameworks discussed
   • Specific details like: file names, full code snippets, function signatures, file edits
   • Errors you ran into and how you fixed them
   • Specific user feedback — especially if the user told you to do something differently
2. Double-check for technical accuracy and completeness

Step 2: 9-Section Summary (Structured Output)

After analysis, produce a summary in <summary> tags with exactly these sections:

1. Primary Request and Intent
   — Capture ALL explicit user requests and intents in detail

2. Key Technical Concepts
   — List all important technical concepts, technologies, and frameworks discussed

3. Files and Code Sections
   — Enumerate specific files examined, modified, or created
   — Include full code snippets where applicable
   — Include WHY each file read or edit is important

4. Errors and Fixes
   — List ALL errors encountered + how fixed + user feedback on each

5. Problem Solving
   — Document problems solved and ongoing troubleshooting

6. All User Messages (Non-Tool-Result)
   — Verbatim list of ALL user messages
   — CRITICAL for detecting intent drift across the session

7. Pending Tasks
   — Outline any pending tasks explicitly asked to work on

8. Current Work
   — Describe in detail precisely what was being worked on IMMEDIATELY before this summary
   — Include file names and code snippets

9. Optional Next Step
   — Only if directly in line with user's most recent explicit request
   — Include DIRECT QUOTES from the most recent conversation
   — Do NOT start on tangential or old completed requests

Step 3: Post-Processing

1. Strip the <analysis> block — it was for reasoning quality only
2. Format the <summary> content with section headers
3. Write the formatted summary to activeContext.md under a new ## Compacted Session heading
4. If activeContext.md exceeds 15K tokens, archive older compacted sessions to sessionArchive.md

Anti-Patterns

• ❌ Summarizing tool results verbatim (summarize the OUTCOME, not the output)
• ❌ Losing user feedback/corrections (these are the MOST IMPORTANT signals)
• ❌ Starting tangential work after compaction without user confirmation
• ❌ Acknowledging the summary or recapping — just resume as if the break never happened

Auto-Continue Rule (Post-Compact)

"Continue the conversation from where it left off without asking the user any further questions. Resume directly — do not acknowledge the summary, do not recap what was happening, do not preface with 'I'll continue' or similar. Pick up the last task as if the break never happened."

Reference Paths

• .context/memory_bank/activeContext.md
• .context/memory_bank/sessionArchive.md

Daemon Loop — Autonomous Agent Infrastructure

Source: Boris Cherny (Claude Code creator), X thread 2026-03-30 (CS-560) Pattern: "Turn workflows into skills, then loop them."

Core Concept

Traditional Athena workflows are pull-based — user triggers /start, /audit, /reindex manually. Daemon loops are push-based — they run autonomously at set intervals without user invocation.

This is the difference between a tool and infrastructure.

When to Use

Architecture

Option A: Cron + Headless Agent (Current-Compatible)

For environments where the agent platform supports CLI invocation:

# Example: reindex every hour
0 * * * * cd ./project && claude --bare -p "/reindex" 2>&1 >> .agent/temp/daemon.log

# Example: workspace hygiene daily at 4am
0 4 * * * cd ./project && claude --bare -p "/needful" 2>&1 >> .agent/temp/daemon.log

Key: --bare flag skips full context loading for speed. Only load what the specific daemon needs.

Option B: In-Session Loop (Manual Trigger)

When cron is unavailable, run a daemon within an active session:

User: "Loop /reindex every 60 minutes for the next 8 hours"
Agent: [Executes /reindex, sleeps 60m, repeats 8x]

Constraint: Requires an active session. Prefer Option A for true autonomy.

Option C: Async-Dev Integration

Combine with /async-dev (Sleeper Agent Protocol):

1. User sets up daemon tasks before sleeping
2. Agent executes loop overnight
3. Morning: user reads STATUS.md for results

Daemon Registration

Track active daemons in .agent/temp/daemons.json:

{
  "daemons": [
    {
      "name": "memory-sync",
      "workflow": "/reindex",
      "interval": "60m",
      "last_run": "2026-03-31T01:00:00+08:00",
      "status": "active",
      "bare": true
    }
  ]
}

Safety Rules

• CAN: Run read-only or idempotent workflows (reindex, audit, check, dream)
• CAN: Write to .agent/temp/ and .context/ directories
• CANNOT: Commit, push, or mutate source code without explicit user pre-authorization
• CANNOT: Run workflows that require interactive user input
• CANNOT: Exceed 8-hour autonomous window without checkpoint
• BLOCKING BUDGET: Any single daemon action that would block for >15 seconds must be deferred (stolen from KAIROS)

Boris Cherny's Live Examples (Reference)

Migration Path

1. Phase 1 (Now): Define which workflows are daemon-eligible
2. Phase 2: Write cron entries or use platform-native scheduling
3. Phase 3: Build .agent/temp/daemons.json registry for state tracking
4. Phase 4: Add /daemon workflow for CRUD operations on active daemons

References

• /async-dev — Sleeper Agent Protocol
• /needful — Autonomous best-judgment action
• /reindex — Supabase memory sync

Skill Compiler — Solved-to-Skill Automation

Source: Hermes Agent by Nous Research (May 2026) Core Claim: "It's the only agent with a built-in learning loop — it creates skills from experience." Athena Adaptation: Hermes does this via Python (agent/curator.py + tools/skill_usage.py). Athena does it via workflow-level pattern detection + markdown SKILL.md generation.

The Problem This Solves

Athena currently relies on manual insight filing during /end sessions. The [S] and [V] markers in session logs capture learnings, but they remain trapped in session logs — they don't become reusable skills automatically.

Hermes solved this: when the agent completes a novel task, it automatically creates a new skill from the solution, so the same problem class never requires re-derivation.

When to Use

Automatic Trigger (Post-Task Detection)

After any task completion where ALL of the following are true:

1. Novelty: The task required a solution path not covered by any existing skill
2. Complexity: Task took ≥5 agent turns OR involved ≥3 tool calls
3. Success: User confirmed the solution worked (explicit or implicit — no corrections in final 2 turns)
4. Reusability: The solution generalizes beyond this specific instance

Manual Trigger

User says: "compile this into a skill", "save this as a skill", "I want to remember how we did this"

Execution Flow

Phase 1: Pattern Extraction (Analysis)

Perform private analysis in <analysis> tags (not written to files):

<analysis>
1. What was the PROBLEM CLASS? (Not the specific instance)
   - e.g., "Pairs trading dashboard with cointegration analysis"
   - NOT "Dashboard 4-decimal rounding fix"

2. What was the SOLUTION ARCHITECTURE?
   - Key steps in order
   - Tools/APIs used
   - Decision points and their resolution criteria

3. What were the FAILURE MODES encountered?
   - What went wrong initially?
   - What heuristics resolved it?

4. What is the REUSE SURFACE?
   - When would someone encounter this problem class again?
   - What context_trigger keywords would match?

5. OVERLAP CHECK
   - Which existing skills partially cover this?
   - Is this better as a new skill or a subsection of an existing one?
</analysis>

Phase 2: Skill Draft Generation

Generate a complete SKILL.md with Athena-standard 5W1H frontmatter:

---
name: [kebab-case-name]
description: "[One-line description of what the skill does]"
vibe: "[One-line emotional hook]"
context_trigger: "[comma-separated trigger keywords]"
auto-invoke: false
model: default
source: "Compiled from session [SESSION_ID] on [DATE]"
compiled_from: "[session log path]"
---

# [Skill Name] — [Subtitle]

> **Compiled**: [DATE] from session [SESSION_ID]
> **Problem Class**: [Description of the general problem this solves]

## When to Use

[Trigger conditions — when should the agent invoke this skill?]

## Solution Architecture

### Step 1: [Phase Name]
[What to do, with specifics]

### Step 2: [Phase Name]
[What to do, with specifics]

## Failure Modes & Mitigations

| Failure | Mitigation |
|---------|------------|
| [What can go wrong] | [How to recover] |

## Validated Patterns

- [V] [Pattern]: [Why it works] | Reapply: [When]

## References

- Session log
- [Related skill](../../therapeutic-ifs/SKILL.md)

Phase 3: Integration

1. Write the skill to .agent/skills/[name]/SKILL.md (or examples/skills/[category]/[name]/SKILL.md for public)
2. Update skill index with the new entry
3. Update AGENTS.md skill table (if context_trigger present)
4. Notify user: "📦 Compiled new skill: [name] from this session. Review at [path]."

Curator Integration (Stolen: Hermes agent/curator.py)

Lifecycle States

Compiled skills follow a lifecycle identical to Hermes' curator model:

Invariants (from Hermes)

• Never auto-delete — maximum destructive action is archive
• Pinned skills are exempt — manual pin via pinned: true in frontmatter
• Only touch compiled skills — bundled/manual skills are off-limits
• Archive is recoverable — archive directory with successor mapping in README.md

Umbrella Consolidation Rule (Stolen: Hermes Curator Prompt)

"A collection of hundreds of narrow skills where each one captures one session's specific bug is a FAILURE of the library — not a feature."

When compiling a new skill, first check if it belongs as a subsection of an existing umbrella skill rather than a standalone entry:

1. PREFIX CLUSTER CHECK: Does the new skill share a first word or domain keyword with 2+ existing skills?
2. CLASS-LEVEL CHECK: Would a maintainer write this as one skill with labeled subsections, or N separate skills?
3. If the answer is "one skill", absorb into the existing umbrella and add a references/ entry instead.

Anti-Patterns

• ❌ Compiling trivial tasks (< 5 turns, single tool call)
• ❌ Compiling tasks that are already covered by existing skills
• ❌ Creating overly specific skills tied to one instance (use umbrella pattern instead)
• ❌ Compiling without user confirmation of success
• ❌ One-session-one-skill micro-entries — consolidate into class-level umbrellas

Hermes Comparison

Athena advantage: Skills are version-controlled in git, not SQLite. Every skill change has a commit hash, blame, and diff history. Hermes can't git blame a skill edit.

References

• Hermes Agent Curator — Source of lifecycle states + umbrella consolidation pattern
• Hermes Self-Evolution — DSPy + GEPA evolutionary optimization (future steal candidate)

Trade Journal Analyzer (Expanded)

Absorbs: drawdown-classifier

Reads historical trade entries, extracts actionable statistical patterns, AND classifies drawdowns. Converts a "diary" into a "data warehouse."

Triggers

"analyze my trades", "journal patterns", "what's my actual WR", "edge audit", "losing streak", "drawdown", "is my system broken", "should I stop trading", "3 losses in a row"

Core Analytics

1. Ingest: Read entries from .context/trading_journal/.
2. Parse: Extract setup type, instrument, direction, entry, SL, TP, result, notes.
3. Analyze:
   • Win Rate by Setup Type: Which setups are actually profitable?
   • Win Rate by Instrument: Where is the edge strongest?
   • Win Rate by Time of Day: Asian vs London vs NY session performance.
   • Average R:R Achieved: Planned RR vs actual RR (execution gap).
   • Drawdown Sequences: Longest losing streaks, recovery time.
   • Edge Decay: Is WR trending up or down over last 20 trades?
4. Flag:
   • Setups with WR < breakeven threshold → flag for review or removal.
   • Instruments with consistent negative EV → stop trading them.
   • Emotional notes correlation → do emotional trades have lower WR?

Drawdown Classification

Not all drawdowns are equal. The wrong response is more dangerous than the drawdown itself.

Class 1: Noise (Random Variance)

• Losing streak within expected statistical bounds for the system's WR.
• Test: At 60% WR, a 5-loss streak has P = 0.4^5 = 1.02%. Over 200 trades, ~2 expected.
• Response: Do nothing. Continue executing. Do NOT adjust.

Class 2: Structural (Setup Flaw)

• Losses concentrated in a specific setup, instrument, or time period.
• Test: Is the WR decline isolated to one setup type?
• Response: Quarantine the specific setup. Continue trading others.

Class 3: Thesis-Breaker (Edge Invalidation)

• Systematic WR decline across ALL setups.
• Test: Is the WR decline persistent (>30 trades)? Has market microstructure changed?
• Response: Full stop. Trigger circuit-breaker. Paper trade. Re-validate edge.

Output Format

## Trade Journal Analysis (Last N Trades)

### Win Rate by Setup
| Setup | Trades | Wins | WR | Avg RR | EV/Trade |
|-------|--------|------|----|--------|----------|

### Win Rate Trend (Rolling 20)
[Trending UP / DOWN / FLAT] — current WR: XX%

### Drawdown Classification
Observed: X losses in last Y trades
P(this streak | WR=Z%): XX.X%
Classification: [NOISE / STRUCTURAL / THESIS-BREAKER]
Prescribed Action: [Continue / Quarantine setup X / Full stop]

### Edge Health
Verdict: [HEALTHY / DECAYING / CRITICAL]

Integration

• Feeds into zenith-execution for forward simulation (Monte Carlo)
• Validates Kelly assumptions (is the stated WR real?)
• Triggers circuit-breaker if edge decay is CRITICAL