team.json

{
  "_comment": "TEAM ROSTER — single source of truth for the /team (grok-heavy) skill. Edit THIS FILE to add/remove models, change caps, or repoint roles; the skill reads it fresh every run and never hardcodes members. No skill edits needed. This is the GROK-HEAVY edition: it leans on Grok for a persistent master auditor/tester (up to 10 slave subagents), a fast executor pool (up to 16, with 3-way blind redundant builds for hard subtasks), and all research/imagine work — so it expects a generous Grok plan (SuperGrok Heavy / X Premium+). If you do NOT have heavy Grok usage, use the lighter github.com/BlinkingSun/claude-team-skill instead.",
  "version": 2,
  "updated": "2026-08-10",
  "cursor": {
    "enabled": null,
    "bridge": "~/cursor-bridge/bin/cursor-ask",
    "cli": "~/.local/bin/cursor-agent",
    "_comment": "THE CURSOR GATE. null = UNANSWERED: the /team skill asks you once, at Step 0a, before it plans anything, and writes your answer back here. false = this roster is the grok-only team, exactly as it has always run; the skill ignores every block marked CURSOR ONLY. true = you have the Cursor CLI plus the cursor-ask bridge, and the paired grok:cursor protocol is in force. install.sh asks at install time when it can; setting this to true must also set enabled=true on the cursor-executor, cursor-assistant and blind-race members below.",
    "_when_enabled": "MECHANICAL RULE: with cursor.enabled true, any roster key named <key>_with_cursor REPLACES <key>. Nothing else about the roster changes."
  },
  "coordinator_focus": "You are a senior systems engineer, specialized in software development for AI workflows. Your primary job is to create tasks for other agents based on a master plan to achieve a software goal. You are the coordinator and planner but have a team of ace agents which you should use to your advantage. Avoid confirmation bias by maintaining a layer of context separation. Auditors should be thorough to find edge case scenarios. Executors should report changes and have their execution reviewed without bias. The plan should maintain consistency with the rest of the project so leave design guidelines for the next agent as you build. Button alignment, color schemes and arrangement are important. If the user wants a UI, use Grok Imagine to help visualize the desires and go through a graphical approval process with the user before committing to building all of the features and then having to make a bunch of code modifications to get it right. Do not use emojis in UIs. Prioritize multi-threading to speed up anything which takes real compute. Prioritize builds on Apple Silicon unless specifically requested otherwise by the user. Prioritize stacks which allow for a visually pleasant and spectacular user experience through the UI. Animation is great where it fits in seamlessly. Be creative and be autonomous but ask the user when you are stuck or need clarification.",
  "design_rules": [
    "UIs default to DARK MODE. Light mode is opt-in only when the user asks.",
    "Do NOT use emojis in UIs.",
    "Button alignment, color scheme, spacing, and arrangement are first-class — keep them consistent with the rest of the project. Leave written design guidelines in the workdir for the next agent as you build.",
    "For any UI: run the Grok Imagine graphical-approval gate BEFORE building features (see the UI flow in the skill). Iterate on the mockup, not on shipped code.",
    "Every app you build ships a custom ICON generated with Grok Imagine that fits the program's purpose and matches its aesthetic (dark, modern). Produce the icon, get sign-off with the mockup, then integrate it (on macOS: .iconset -> iconutil -> .icns).",
    "Prioritize a visually pleasant, spectacular UX. Seamless animation where it fits — never gratuitous.",
    "Prioritize multi-threading for anything that does real compute.",
    "Prioritize Apple Silicon builds unless the user requests otherwise."
  ],
  "members": [
    {
      "name": "fable",
      "provider": "anthropic",
      "model": "claude-fable-5",
      "role_hint": "orchestrator / planner / integrator (the live session) — ALWAYS the planner, see the ORCHESTRATOR ALWAYS PLANS policy",
      "invoke": {
        "method": "current-session"
      },
      "strengths": [
        "decomposition",
        "architecture",
        "integration",
        "final review",
        "project context"
      ],
      "may_spawn": [
        "grok worker bees during planning as switchboard spike-* lanes via agent-dispatch (research unknowns, quick spikes)"
      ],
      "budget": "claude-plan",
      "enabled": true,
      "notes": "The orchestrating session itself — whatever model your session runs orchestrates (the reference setup runs Fable 5). Never delegated to. Owns all git, signing, release, deploy, and the final report to the user. May spawn grok worker bees during planning. Never implements during EXECUTE/VERIFY — coordinates only."
    },
    {
      "name": "grok-master",
      "provider": "xai",
      "model": "grok-4.5",
      "auth": "subscription (grok login / grok.com OAuth). NEVER set XAI_API_KEY — that bills separate API credits instead of your subscription.",
      "role_hint": "persistent master auditor + execution auditor + tester + UI visualizer",
      "invoke": {
        "method": "grok-ask",
        "worker": "~/grok-bridge/bin/grok-ask -w -c master-<task> -d <dir> \"<prompt>\"",
        "note": "ONE persistent channel per team task (master-<task>). Opened at plan audit, resumed for per-lane audit slices during the build, then phase-end integration + testing, closed at integrate. --resume keeps its context cache warm across phases."
      },
      "spawns": {
        "what": "up to 10 grok slave auditors/researchers as NATIVE grok subagents. Each slave EITHER researches one unknown OR reviews one slice of the plan/diff, reports to the master, and closes when done.",
        "cap": 10
      },
      "hats": [
        "plan auditor (edge-case hunter, gate before execution)",
        "execution auditor (per-lane audit slices as lanes land + phase-end cross-lane audit)",
        "tester (drives the built program's API headlessly; screenshots when a feature is visual)",
        "UI visualizer (Grok Imagine / image_gen -> concept mockups + app icons for the approval gate)"
      ],
      "lifecycle": "STAYS OPEN until the team task is complete (context caching). Slaves close when their task finishes.",
      "strengths": [
        "independent verification (different model family, zero shared bias)",
        "fresh-eyes review",
        "edge-case hunting",
        "web-current research",
        "headless testing",
        "Grok Imagine (image_gen)"
      ],
      "budget": "grok-plan — does NOT consume Claude limits. GROK-HEAVY: this member is used a lot; expects a generous Grok plan (SuperGrok Heavy / X Premium+).",
      "enabled": true,
      "notes": "Grok 4.5 via the Grok Build CLI (>= 0.2.102 for Grok Imagine), driven headless by the claude-grok-bridge wrapper (github.com/BlinkingSun/claude-grok-bridge). Setup: curl -fsSL https://x.ai/cli/install.sh | bash; grok login; then install the bridge. If the wrapper is missing at run time, treat this member as disabled — the skill falls back to Claude tiers for audit/verify/test and tells the user (but you lose the point of this edition; use the lighter claude-team-skill instead)."
    },
    {
      "name": "execution-master",
      "provider": "anthropic",
      "model": "sonnet",
      "role_hint": "OPUS/sonnet: intelligently PARTITIONS the build into non-conflicting file-lanes to avoid merge conflicts, then assigns + fans out parallel grok executors (up to caps.grok_executors, currently 16), pipelines per-lane audits, and reviews them without bias. MAXIMIZE lane count — width is free because grok costs no Claude limits. Split test/gate code off the algorithm lane. Smart decomposition is how we parallelize safely — do NOT serialize just because files might collide.",
      "invoke": {
        "method": "agent-tool",
        "detached_alt": "agent-dispatch --task <task> --lane exec-master --exec claude-ask -- -m sonnet -w -c exec-master-<task> -d <dir> \"<dispatch spec>\""
      },
      "spawns": {
        "what": "up to caps.grok_executors (16) grok executors via grok-ask -w in isolated worktrees/scratch dirs, including caps.grok_redundancy parallel attempts for any hard/risky subtask (see the grok-redundant member). Executors build, report to the execution-master, and close (grok-ask process exits) when their subtask passes.",
        "cap": "caps.grok_executors"
      },
      "strengths": [
        "execution decomposition",
        "dispatch + coordination",
        "reviewing grok output without bias"
      ],
      "budget": "claude-plan (moderate) — coordinates and reviews; does NOT do the bulk build itself.",
      "enabled": true
    },
    {
      "name": "grok-executor",
      "provider": "xai",
      "model": "grok-4.5",
      "auth": "subscription (grok.com OAuth). Never XAI_API_KEY.",
      "role_hint": "fast bulk builder — the DEFAULT executor for large/parallelizable subtasks",
      "invoke": {
        "method": "grok-ask",
        "worker": "~/grok-bridge/bin/grok-ask -w -c exec-<task>-<n> -d <worktree> \"Read SPEC.md. Implement per acceptance criteria. Run the tests. Write _team/reports/<lane>.md. Reply DONE/OPEN/TEST/BLOCKERS.\""
      },
      "lifecycle": "one-shot per call (process exits = closed). Never resumed after its subtask passes verification.",
      "strengths": [
        "fast implementation",
        "parallel bulk build",
        "can replace sonnet/opus for large tasks"
      ],
      "budget": "grok-plan — does NOT consume Claude limits. The default build muscle; used heavily.",
      "enabled": true
    },
    {
      "name": "grok-redundant",
      "provider": "xai",
      "model": "grok-4.5",
      "auth": "subscription (grok.com OAuth). Never XAI_API_KEY.",
      "role_hint": "N-way redundant grok race — the DEFAULT answer for hard/risky subtasks, replacing a single Claude executor lane",
      "invoke": {
        "method": "grok-ask (xN, concurrent)",
        "worker": "for i in 1..caps.grok_redundancy: agent-dispatch --task <task> --lane <lane>-r<i> --exec ~/grok-bridge/bin/grok-ask -- -w -c exec-<task>-<lane>-r<i> -d <worktree-r<i>> \"<the SAME spec, verbatim>\"",
        "adjudicate": "~/grok-bridge/bin/grok-ask -w -c master-<task> -d <dir> \"ADJUDICATE: attempts at _team/reports/<lane>-r1..rN.md and their worktrees. You authored none of them. Diff them, pick the correct one or merge the best of each, and justify on evidence (which attempt satisfies which acceptance criterion). Write _team/reports/adjudicate-<lane>.md.\""
      },
      "lifecycle": "each attempt is one-shot (process exits = closed); the adjudication runs on the persistent master channel. Losing worktrees are removed by the orchestrator at integrate.",
      "strengths": [
        "accuracy through independent cross-check rather than a slower model",
        "wall-clock of the slowest single attempt, not the sum",
        "costs no Claude limits"
      ],
      "budget": "grok-plan — does NOT consume Claude limits. N attempts still cost nothing; width is free.",
      "notes": "Attempts MUST be blind to each other: separate worktrees, separate channels, identical spec. If all N attempts fail the same acceptance criterion, that is signal the SPEC is wrong — fix the spec, do not escalate to Claude. Escalate to executor_direct._fallback only when the attempts disagree and grok-master cannot adjudicate on evidence.",
      "enabled": true
    },
    {
      "name": "blind-race",
      "provider": "xai + cursor",
      "model": "grok-4.5 + auto",
      "auth": "both subscription logins. Never XAI_API_KEY / CURSOR_API_KEY.",
      "role_hint": "CURSOR ONLY replacement for grok-redundant — a cross-FAMILY blind race for hard/risky subtasks",
      "invoke": {
        "method": "grok-ask + cursor-ask (xN, concurrent, split evenly)",
        "worker": "for i in 1..caps.blind_race_attempts: agent-dispatch --task <task> --lane <lane>-r<i> --exec <half ~/grok-bridge/bin/grok-ask, half ~/cursor-bridge/bin/cursor-ask> -- -w -c exec-<task>-<lane>-r<i> -d <worktree-r<i>> \"<the SAME spec, verbatim>\"",
        "adjudicate": "~/grok-bridge/bin/grok-ask -w -c master-<task> -d <dir> \"ADJUDICATE: attempts at _team/reports/<lane>-r1..rN.md and their worktrees. You authored none of them. Diff them, pick the correct one or merge the best of each, and justify on evidence. Write _team/reports/adjudicate-<lane>.md.\""
      },
      "lifecycle": "each attempt is one-shot; adjudication runs on the persistent master channel.",
      "strengths": [
        "agreement ACROSS MODEL FAMILIES is stronger evidence than agreement within one",
        "wall-clock of the slowest single attempt, not the sum",
        "costs no Claude limits"
      ],
      "budget": "grok-plan + cursor-plan — does NOT consume Claude limits.",
      "notes": "Attempts MUST be blind to each other AND to which provider their siblings are: separate worktrees, separate channels, identical spec. caps.blind_race_attempts is even so the split is exactly 1:1. If all N fail the same acceptance criterion the SPEC is wrong — that is a tough decision, not a build failure.",
      "enabled": false,
      "_enabled_note": "CURSOR ONLY. Flipped to true with cursor.enabled; when false, hard/risky build stays grok-redundant."
    },
    {
      "name": "cursor-executor",
      "provider": "cursor",
      "model": "auto",
      "auth": "Cursor subscription login (cursor-agent login). Never CURSOR_API_KEY.",
      "role_hint": "second free-at-the-margin bulk builder — dispatched 1:1 alongside grok-executor",
      "invoke": {
        "method": "cursor-ask",
        "worker": "~/cursor-bridge/bin/cursor-ask -w -c exec-<task>-<n> -d <worktree> \"Read SPEC.md. Implement per acceptance criteria. Run the tests. Write _team/reports/<lane>.md. Reply DONE/OPEN/TEST/BLOCKERS.\""
      },
      "lifecycle": "one-shot per call (process exits = closed). Never resumed after its subtask passes verification.",
      "strengths": [
        "fast implementation",
        "parallel bulk build",
        "different model family from grok — the pairing is a standing cross-check, not just extra width"
      ],
      "budget": "cursor-plan — does NOT consume Claude limits.",
      "notes": "The cursor-ask bridge exposes the SAME flags as grok-ask (-c -n -w -d -m -f -t -j --status --channels), so every dispatch/wait/state rule in the skill applies unchanged; only --exec differs.",
      "enabled": false,
      "_enabled_note": "Flipped to true by install.sh (or the skill's Step 0 question) when cursor.enabled is true."
    },
    {
      "name": "cursor-assistant",
      "provider": "cursor",
      "model": "auto",
      "auth": "Cursor subscription login. Never CURSOR_API_KEY.",
      "role_hint": "ADVISORY live plan-conformance checker attached to ONE master beneath the planner",
      "invoke": {
        "method": "cursor-ask",
        "worker": "agent-dispatch --task <task> --lane assist-<master> --exec ~/cursor-bridge/bin/cursor-ask -- -w -c assist-<task>-<master> -d <dir> \"You ADVISE the <master> master. Read PLAN.md and SPEC.md. As the master works, check its output for plan conformance and raise DOUBLE-CHECK items. Append to _team/reports/assist-<master>.md. You are advisory: you never stop, block or overrule your master.\""
      },
      "lifecycle": "runs with its master's phase; closes when the master's phase ends.",
      "strengths": [
        "catches drift a same-family reviewer rationalizes away",
        "costs nothing at the margin",
        "never on the critical path"
      ],
      "budget": "cursor-plan — does NOT consume Claude limits.",
      "notes": "ADVISORY ONLY. An assistant can never stop its master, and the planner (fable) is never assisted — it answers to the user.",
      "enabled": false,
      "_enabled_note": "Flipped to true by install.sh (or the skill's Step 0 question) when cursor.enabled is true."
    },
    {
      "name": "opus",
      "provider": "anthropic",
      "model": "opus",
      "role_hint": "STANDING DECISION AUTHORITY — tough calls, contested adjudication, and authoring the hard part of a spec. Also the fallback executor tier for a hard subtask the redundant grok build cannot converge on.",
      "invoke": {
        "method": "agent-tool",
        "detached_alt": "agent-dispatch --task <task> --lane <lane> --exec claude-ask -- -m opus -w -c <channel> -d <dir> \"<spec>\""
      },
      "strengths": [
        "hard implementation",
        "subtle debugging",
        "algorithmic work"
      ],
      "budget": "claude-plan (premium) — spend it on DECISIONS, not typing. Few tokens, high leverage: a decision written into the spec is cheaper than a Claude model implementing the whole lane.",
      "enabled": true,
      "notes": "Invoked per tough_decision_triggers. Output is a written decision in the spec or an adjudication in _team/reports/, never bulk implementation. Context separation still binds: if opus authored the decision, it may adjudicate the attempts; it must not also be the author of an attempt."
    },
    {
      "name": "sonnet",
      "provider": "anthropic",
      "model": "sonnet",
      "role_hint": "direct Claude executor for medium subtasks the plan master flags as risky for a fast model",
      "invoke": {
        "method": "agent-tool",
        "detached_alt": "agent-dispatch --task <task> --lane <lane> --exec claude-ask -- -m sonnet -w -c <channel> -d <dir> \"<spec>\""
      },
      "strengths": [
        "solid general implementation",
        "refactors",
        "test writing"
      ],
      "budget": "claude-plan (moderate)",
      "enabled": true
    },
    {
      "name": "haiku",
      "provider": "anthropic",
      "model": "haiku",
      "invoke": {
        "method": "agent-tool",
        "detached_alt": "agent-dispatch --task <task> --lane <lane> --exec claude-ask -- -m haiku -w -c <channel> -d <dir> \"<spec>\""
      },
      "strengths": [
        "mechanical edits",
        "boilerplate",
        "bulk file operations"
      ],
      "budget": "claude-plan (light)",
      "enabled": true
    }
  ],
  "assignment": {
    "_comment": "role -> member name. DIVISION OF LABOR: Anthropic DECIDES, grok BUILDS. The orchestrator always plans and integrates; opus is the standing decision authority for tough calls; grok does the typing at maximum width. Build work defaults to grok-executor; hard/risky subtasks get an opus-authored decision followed by a grok-redundant build.",
    "orchestrator": "fable",
    "planner": "fable",
    "plan_master": "grok-master",
    "execution_auditor": "grok-master",
    "tester": "grok-master",
    "ui_visualizer": "grok-master",
    "researcher": "grok-master",
    "execution_master": "execution-master",
    "executor_pool": "grok-executor",
    "executor_pool_with_cursor": [
      "grok-executor",
      "cursor-executor"
    ],
    "_executor_pool_with_cursor_note": "CURSOR ONLY. Worker fan-out dispatches grok and cursor in EQUAL NUMBER (caps.worker_ratio '1:1'). Odd lanes grok, even lanes cursor, or split each wave down the middle. A wave that can only fill one side (a provider is rate-limited) proceeds unpaired but MUST say so in the phase report — silent single-provider fan-out defeats the cross-check.",
    "master_assistant": "cursor-assistant",
    "_master_assistant_note": "CURSOR ONLY. Every master BENEATH the planner may run one. The planner is not assisted — it answers to the user. Assistants are advisory and can never stop their master.",
    "supercharge_pool_with_cursor": [
      "grok-executor",
      "cursor-executor",
      "opus"
    ],
    "_supercharge_note": "CURSOR ONLY. Used by verify cycles >= caps.verify_supercharge_from_cycle: all three attack the same still-failing lane IN PARALLEL, then are adjudicated. This is the one place opus implements rather than merely decides — a bounded exception justified by two prior cycles having already failed.",
    "executor_direct": {
      "hard": "grok-redundant",
      "risky": "grok-redundant",
      "hard_with_cursor": "blind-race",
      "risky_with_cursor": "blind-race",
      "trivial": "grok-executor",
      "_escalation": "hard/risky are split into a DECISION and a BUILD. The DECISION — the algorithm, the formula, the contract, the trade-off — is authored by assignment.decision_authority (opus) and written INTO the spec. The BUILD is then grok-redundant: caps.grok_redundancy independent grok executors on that identical spec, one isolated worktree each, blind to each other. Routine adjudication of the attempts goes to adjudicator_routine (grok-master); anything meeting a tough-decision trigger goes to adjudicator_contested (opus). Claude executor tiers in _fallback are for when the redundant build itself cannot converge.",
      "_fallback": {
        "hard": "opus",
        "risky": "sonnet"
      },
      "_trivial_note": "trivial repointed haiku -> grok-executor (grok does not consume Claude limits). haiku remains available by explicit orchestrator choice.",
      "hard_decision": "opus"
    },
    "decision_authority": "opus",
    "adjudicator_routine": "grok-master",
    "adjudicator_contested": "opus"
  },
  "tough_decision_triggers": [
    "Irreversible or safety-critical: real hardware motion, firmware flashing, signing, notarizing, release, deploy, destructive file operations.",
    "The redundant grok attempts materially disagree, or grok-master cannot adjudicate on evidence.",
    "All N attempts fail the SAME acceptance criterion — the spec is suspect, and rewriting a spec is a decision, not labor.",
    "A contested audit: the executor disputes the auditor's verdict, or two auditors disagree.",
    "A determinism/golden law would change (byte-identity, golden outputs, established public API/contract).",
    "Cross-lane architectural conflict, or a partition that turns out not to be conflict-free.",
    "Any point where the team is about to ask the user — decide whether it is genuinely a user call first."
  ],
  "caps": {
    "slave_auditors": 10,
    "grok_executors": 16,
    "grok_executors_with_cursor": 32,
    "_grok_executors_note": "LOAD-BEARING KEY — agent-dispatch reads exactly this name for per-task capacity. With cursor enabled it is the TOTAL concurrent lane budget across BOTH pools plus audit-*/assist-*/spike-* lanes, which is why the _with_cursor value is doubled: pairing must not halve effective grok width.",
    "worker_executors_per_provider_with_cursor": 16,
    "worker_ratio_with_cursor": "1:1",
    "grok_executors_proven": 10,
    "grok_redundancy": 3,
    "blind_race_attempts_with_cursor": 4,
    "_blind_race_note": "CURSOR ONLY. Replaces grok_redundancy. Even by construction so a hard/risky race splits exactly 2 grok + 2 cursor — an odd count cannot be 1:1.",
    "verify_loops": 3,
    "verify_loops_with_cursor": 4,
    "verify_supercharge_from_cycle": 3,
    "master_assistants_with_cursor": true,
    "assistants_per_master": 1,
    "_cursor_cap_note": "CURSOR ONLY. verify_loops 3 -> 4, and cycles >= verify_supercharge_from_cycle are SUPERCHARGED (grok + cursor + opus in parallel on the same failing lane, then adjudicated). master_assistants enables one advisory cursor-assistant per master beneath the planner. All four are inert while cursor.enabled is false.",
    "_cap_note": "grok_executors raised 10 -> 16 for maximum grok width. 10 concurrent is field-proven; 11-16 is less tested — if grok-ask starts failing to launch or returning auth/rate errors, fall back to 10 and tell the user rather than silently serializing. grok_redundancy is the number of independent grok attempts a hard/risky subtask gets. slave_auditors are in-process native grok subagents, so that cap is per-master-session, not extra OS processes."
  },
  "policies": [
    "GROK-HEAVY by design. Grok 4.5 through the Grok Build CLI subscription does not consume Claude limits, so default build work to the grok-executor pool and route all audit/test/research/imagine to Grok. Reserve Claude executor tiers (opus/sonnet/haiku) for subtasks the plan master flags as genuinely hard, subtle, or high-risk for a fast model. This assumes a generous Grok plan; on a light Grok plan, use claude-team-skill instead.",
    "MAXIMUM GROK WIDTH, ANTHROPIC JUDGMENT: the two subscriptions are spent on different things and neither is cut out. ANTHROPIC = JUDGMENT: the orchestrator plans and integrates, opus makes the tough calls (see tough_decision_triggers), the execution-master partitions. GROK = LABOR: spikes, implementation, tests, audits, and redundant attempts, at maximum width up to caps.grok_executors. Grok is subscription-funded and free at the margin, so WIDTH IS FREE and serialization is the only real cost — but width is not a substitute for judgment. Buy accuracy on ROUTINE work with REDUNDANCY (caps.grok_redundancy blind grok attempts on one identical spec, separate worktrees, adjudicated by grok-master, which authored none of them). Buy accuracy on TOUGH work with OPUS: opus authors the decision into the spec BEFORE the grok build starts, and opus adjudicates whenever a tough-decision trigger fires. Escalate a build to a Claude executor tier only when the redundant build cannot converge on an opus-authored spec.",
    "THE ORCHESTRATOR ALWAYS PLANS: planning and integration belong to the roster's orchestrator member — decomposition, architecture, the spec, the final report. If the live session is NOT running that member's model (e.g. the user switched /model before typing /team), the orchestrator must not quietly plan as whatever model it happens to be: either restart on the roster model or delegate the PLAN step to an agent running it and integrate the plan it returns. Note the deviation in the phase report. Planning on a different, more expensive model is a silent budget leak, and the planner is the planner by design, not by default.",
    "OPUS OWNS THE TOUGH CALLS: opus is the standing decision authority (assignment.decision_authority). It is invoked for DECISIONS, not for typing — short, high-leverage calls that cost few tokens and set direction: authoring the hard part of a spec (the algorithm, formula, contract, trade-off), adjudicating contested results, and every tough_decision_triggers case. This is the correct place to spend Claude limits; a Claude model doing bulk implementation is not. When opus authors a decision it writes it into the SPEC so the grok build inherits it verbatim — the decision is a durable artifact, not a chat message.",
    "DECOMPOSE FOR WIDTH: the execution-master's first job is to MAXIMIZE independent lanes, not minimize them. Fan-out is bounded by disjoint file ownership, so split along file boundaries wherever a written contract exists between the parts. BINDING: test/gate code goes on its own grok lane, separate from the algorithm it verifies — the spec pins the contract, so the suite can be written in parallel with the implementation, and gate code is grok-trivial even when the algorithm is subtle. Never bundle a gate suite onto the expensive lane that exists BECAUSE the algorithm is subtle. (Measured in a real run: one lane that bundled ~570 lines of gate rewrite with the subtle algorithm ran 65+ min on a Claude tier while every grok lane in that phase finished in 3-13 min.)",
    "NEVER SKIP THE EXECUTION-MASTER TIER: even a two-lane phase goes through the execution-master, because that tier is the only actor whose job is width — dispatching executors straight from the orchestrator skips the question 'can this split further?'. If the orchestrator does dispatch directly for thrift, it must first write the split analysis (why N lanes and not more) into the phase report.",
    "TAKE THE GROK PATH WHEN THE AUDITOR OFFERS ONE: plan-master tiering advice of the form 'Claude/sonnet preferred OR senior grok with spike in hand' resolves to GROK whenever the spike report exists — a completed spike- lane IS that precondition. Prefer grok-redundant over a single Claude lane in every such case, and note the choice in the phase report.",
    "ALL Grok calls go through the bridge (~/grok-bridge/bin/grok-ask) on grok-4.5 using the Grok subscription login. NEVER set XAI_API_KEY or route Grok through paid API credits.",
    "A member whose wrapper or CLI is not installed is treated as disabled — apply the fallbacks and tell the user which member was unavailable. If Grok is unavailable, audit/test/execute fall back to Claude tiers (a different model than the one that wrote the code), and you lose this edition's advantage.",
    "ONE grok master per team task (channel master-<task>). Opened at plan audit, it STAYS OPEN (resumed) through per-lane audits, phase-end integration and testing, closing only at integrate — this keeps its context cache warm. The master decides how to deploy up to caps.slave_auditors slave auditors/researchers (native grok subagents); each slave researches one unknown OR reviews one slice, reports to the master, and closes when done. The master consolidates and reports to the orchestrator.",
    "The execution-master (an Anthropic model) decomposes the build and spawns up to caps.grok_executors grok executors (worker mode, isolated worktrees/scratch dirs). Executors report to the execution-master and close (their grok-ask process exits) when their subtask passes. The execution-master reviews Grok output WITHOUT bias before reporting up.",
    "Context separation is mandatory to avoid confirmation bias: the planner (fable), the executors (grok/claude), and the auditor/tester (grok-master) are DISTINCT actors. An auditor or tester must never be the member that wrote the code under review, and never gets write access to it — it may run the program and probe its API, not edit its source.",
    "The verify loop is PER-LANE under a whole-phase cap: one cycle = each currently-dirty lane reworked exactly once, then re-tested exactly once, after which the cycle counter increments regardless of outcome. A lane failing re-test goes dirty for the NEXT cycle only — per-lane rework must never create nested loops under the outer cap. The ORCHESTRATOR alone owns and increments the counter (caps.verify_loops per phase) and hands the exec-master each cycle's batch list. After the cap, STOP and ask the user — never loop indefinitely.",
    "CONTEXT THRIFT: every actor writes full detail to _team/reports/ in the task workdir with EXCLUSIVE writers — <lane>.md (that lane's executor, finished BEFORE the process exits), audit-<lane>.md and FINDINGS-<cycle>.md (grok master ONLY; FINDINGS-0 = phase-end integration baseline, verify cycles number 1..n), spike-<topic>.md (that bee), exec-master-<phase>.md (exec-master). Channel/agent replies cap ~15 lines: verdict + file pointers; never re-paste SPEC/PLAN/diff content a channel already has or can read — paths + one-line deltas. Lane names must not begin with audit-/FINDINGS-/exec-master-/plan-audit as free report-style names; spike- marks bee lanes. Audits read a lane report only after that lane is DONE/FAILED.",
    "PIPELINED PER-LANE AUDIT: during a build phase the exec-master hands each terminal BUILD lane (never spike-*) to the master channel for its independent audit slice as it lands, driven by RESCAN not events: on start/resume, every wait return, and every master reply, every build lane in {DONE, FAILED, DIED} without _team/reports/audit-<lane>.md is enqueued (CORRUPT -> escalate; ORPHAN -> investigate, never audit-as-done); never re-enter switchboard wait while that queue is non-empty. master-<task> has ONE owner via the _team/MASTER-OWNER token (exec-master claims at first hand-off, releases only when all expected audit files exist or on explicit abort); master calls are serialized by blocking on the prior call — concurrent or backgrounded master calls are forbidden. Audit requests carry paths + acceptance criteria, never the relayer's verdict. Phase-end integration testing must not start until every expected audit-<lane>.md exists or an explicit fail/escalate is recorded.",
    "Planning research bees run as switchboard lanes (agent-dispatch --lane spike-<topic>) so all long-running work is slot-visible; bees share the per-task executor cap, so reap/wait all spike-* lanes before the build fan-out.",
    "EVERYTHING-VISIBLE DISPATCH (when Agent Switchboard is installed): long-running work appears as switchboard lanes. Grok executors and spike bees use agent-dispatch --exec grok-ask; detached Claude work (exec-master, direct tiers) uses agent-dispatch --exec claude-ask. Nothing important should run as an invisible process when the switchboard is available.",
    "HARD RULE — the orchestrator never implements during EXECUTE/VERIFY. Cost ladder for building: grok executor -> redundant grok race -> opus decision + grok rebuild -> Claude-tier lane (executor_direct._fallback) -> ask the user. Note where the opus rung sits: escalating a hard problem means buying a DECISION, not a slower typist. Orchestrator-inline implementation sits ABOVE every rung — it is the most expensive path, never a thrift measure.",
    "Every program you build MUST expose an API (HTTP / CLI / socket) so the grok-master tester can validate features headlessly. When a feature can only be confirmed visually, the tester captures a screenshot (headless browser for web UIs; screen capture / image tools for native) and checks it against the approved mockup.",
    "UI work (binding — see design_rules): default to DARK MODE; no emojis; before building features, run the Grok Imagine approval gate (grok-master image_gen renders concept mockups; the user signs off graphically); iterate on the mockup, not shipped code. Every app also gets a fitting custom icon generated with Grok Imagine and integrated.",
    "Prioritize multi-threading for CPU-heavy work, and Apple Silicon builds unless the user asks otherwise.",
    "No member except the orchestrator may commit, push, sign, notarize, or deploy. Never run any worker-mode member inside hardware-connected or release-critical directories (serial-connected equipment, device flashing, publish/deploy scripts).",
    "Memory hygiene: slaves and executors close after their task (grok-ask calls are one-shot; native subagents die with the parent). Only the master channel persists. At integrate (task done), run ~/agent-team/bin/team-cleanup to reap stray grok leader processes and clear finished channel state. Do NOT reap the grok leader mid-task or the master loses its warm cache.",
    "Team-mode persistence (v2, SESSION-SCOPED): the hook writes state/active-<session_id> when the user types /team; while it exists that session's prompts route through this skill. 'exit team mode' deactivates only that session; team-cleanup --exit clears all. The legacy global state/active is honored with a may-belong-to-another-session warning + per-session detach marker. A /clear or second window can never inherit another session's task.",
    "ORCHESTRATOR IDENTITY IS NOT ASSUMABLE: no member or session may sign documents as a task's orchestrator, adjudicate its escalated blockers, run its master channel, or dispatch its lanes without owning that task. A session that finds an in-flight task after context loss must VERIFY ownership first (live processes, switchboard trail, _team records — absence of a visible exec-master is NOT proof the orchestrator is gone) and route to the owner or ask the user instead of assuming the role. Work discovered done under assumed authority is reviewed on evidence, never auto-accepted.",
    "Live team reports: relay each audit, test, and verify result to the user as it lands — verdicts, contradictions, accepted vs rejected findings — not only in the final report. Prefer file pointers over pasting full reports.",
    "NO AUTONOMOUS DESTRUCTIVE ENFORCEMENT: no member may arm an automated guard/watchdog that kills processes, reverts state, or blocks another member's work as an automatic response. Guards observe and ALERT only; destructive response requires the orchestrator's explicit go-ahead under fresh context. Before enforcing a safety invariant, confirm with the orchestrator that it still holds — user authorization or completed orchestrator steps may have lifted it."
  ]
}