[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CW56Q6B52QVY7YFDXJCDP2":3,"skill-same:01M6CW56Q6B52QVY7YFDXJCDP2":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":36,"repositoryHtmlUrl":37,"repositoryHomepageUrl":6,"ownerHtmlUrl":38,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":39,"install":40,"resources":53},"01M6CW56Q6B52QVY7YFDXJCDP2","setup",null,"Set up the Board of Governance. Run when the user types \u002Fsetup or asks to set up, install, or configure the board for the first time.","stefans71\u002FFrontierBoard","stefans71","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F66725311?v=4","01M6CW3VPYK13M9K13NZZBXZ36","01M6CW3VTXG8DT51A3FN2SQM1V",6,"MIT","https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsetup\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27],"governance","run","SET","first","configure","board","user","install","up","time","2026-11-10 10:12:30",false,"---\nname: setup\ndescription: Set up the Board of Governance. Run when the user types \u002Fsetup or asks to set up, install, or configure the board for the first time.\n---\n\n# Board of Governance — Setup\n\nWalk the user through setting up their board. This is a conversation — ask questions, listen, do the work. Only pause when you genuinely need the user to act (paste a key, scan a QR code, open a browser). When something is broken, fix it yourself.\n\n**Output formatting:** Use markdown headings for each step (`## Step 3: Autonomous Mode`) and per-agent (`### Agent 1`).\n\n---\n\n## Paths\n\n- **`$BOARD`** — the FrontierBoard clone directory. All board files go here: `.board\u002F`, agents, reports. The board NEVER writes `.board\u002F` inside the user's project.\n- **`$PROJ`** — the user's project. Read-only, except: you may append to `$PROJ\u002F.gitignore` and create new files in `$PROJ\u002F.claude\u002Fskills\u002F`.\n\n### Global install mode\n\nIf `$BOARD` is under `~\u002F.frontierboard\u002F`, this is a global install. In global mode:\n- Agents are built once and shared across all projects\n- Per-project state lives in `$BOARD\u002F.board\u002Fprojects\u002F{project-name}\u002F` (briefs, contexts, reports, BOARD.md)\n- Agent directories stay at `$BOARD\u002F.board\u002Fboard\u002F{agent-name}\u002F` (shared)\n- Each project gets its own orchestrator CLAUDE.md at `$BOARD\u002F.board\u002Fprojects\u002F{project-name}\u002FCLAUDE.md`\n- A global skill is installed at `~\u002F.claude\u002Fskills\u002Ffrontierboard\u002FSKILL.md` so the user can type `\u002Ffrontierboard` from any project session\n\n**C1: Use absolute paths everywhere.** `~` resolves differently per user (`\u002Froot` vs `\u002Fhome\u002Fllmuser`). All BOARD.md, CLAUDE.md, skill files, and invocation commands must use absolute paths (e.g., `\u002Froot\u002F.frontierboard\u002FFrontierBoard`), never tilde notation.\n\n---\n\n## Hard-Won Knowledge\n\nThese are operational facts Claude cannot derive from general training. Never remove them.\n\n1. **`unset CLAUDECODE`** — All invocation commands for Claude Code agents must unset the `CLAUDECODE` env var. Without it, nested Claude sessions fail with \"Cannot be launched inside another Claude Code session.\" Wrap in `bash -c 'unset CLAUDECODE && ...'`.\n\n2. **`codex exec` not `codex`** — The bare `codex` command opens a TUI requiring an interactive terminal. It will silently fail as a subprocess. Always use `codex exec` for non-interactive invocation.\n\n3. **Root always needs a board user** — Even in interactive mode, `--dangerously-skip-permissions` is blocked when running as root. If current user is root, ALWAYS create a board user regardless of mode choice.\n\n4. **Sudoers validation** — Always validate with `visudo -c -f \u003Cfile>` after writing. A bad sudoers file can brick sudo. Use `chmod 0440`. Remove the file if validation fails.\n\n5. **Board user ownership** — After creating all agent directories, `chown -R $BOARD_USER:$BOARD_USER $BOARD\u002F.board\u002F`. Also ensure the board user can traverse parent directories.\n\n6. **Billing warnings are mandatory** — Always warn users about pay-per-use billing (OpenAI API, Anthropic API) before accepting keys. Recommend spend limits. Claude Pro\u002FMax subscriptions have no extra charges — mention this.\n\n7. **Agent model must be high-reasoning** — Settings bubbles must set model to `claude-opus-4-6` (Claude Code). For Codex, let it default to its recommended model (currently `gpt-5.4`) or explicitly set `gpt-5.4` \u002F `gpt-5.3-codex`. The old `o4-mini` name is retired and causes errors. Never use Sonnet — it lacks the reasoning depth for independent review.\n\n8. **Codex approval_policy is `never`** — The Codex config.toml must use `approval_policy = \"never\"` (not \"full-auto\"). And Codex invocations in BOARD.md must include `--dangerously-bypass-approvals-and-sandbox`. Without this flag, Codex won't run as a subprocess.\n\n9. **Agent invocation must read CLAUDE.md** — All invocation commands must tell the agent to read its CLAUDE.md first, then read inbox files. Example: `\"read CLAUDE.md then read inbox\u002Fcontext.md and inbox\u002Fbrief.md and write your report to outbox\u002Freport.md\"`. Agents without CLAUDE.md instructions lose their identity.\n\n10. **`claudeMdExcludes` blocks tree-walking leaks** — Claude Code walks UP the directory tree from CWD and loads EVERY `CLAUDE.md` it finds. Agents inside `$BOARD\u002F.board\u002Fboard\u002F{agent}\u002F` would pick up `$BOARD\u002FCLAUDE.md` (orchestrator routing table) and potentially `$PROJ\u002FCLAUDE.md` (project rules). This pollutes agent context with instructions meant for the orchestrator. Fix: every agent's `.claude\u002Fsettings.json` must include `claudeMdExcludes` listing the absolute paths of all parent CLAUDE.md files to block. Note: `.claude\u002Fsettings.json` does NOT walk up — only CLAUDE.md does.\n\n---\n\n## Step 1: Welcome and Detect\n\n> Welcome to Board of Governance setup. I'll set up a board of independent AI reviewers for your project. I'll only pause when I genuinely need something from you.\n>\n> What's the path to the project this board will review?\n\nSet `$PROJ` (project path) and `$BOARD` (FrontierBoard clone — current directory or clone path).\n\n**Global mode detection:** If `$BOARD` is under `~\u002F.frontierboard\u002F`, this is a global install. Check if agents already exist at `$BOARD\u002F.board\u002Fboard\u002F`. If they do, skip Steps 2–6 (board already built) and jump to Step 7 to wire up the new project. If agents don't exist yet, this is a first-time global setup — run all steps normally, then wire the project.\n\nSilently detect integration mode by checking `$PROJ`:\n- **fb-project-bridge** — has its own AI agent system (`src\u002Findex.ts` + `container\u002Fbuild.sh` + `groups\u002F`, or similar multi-agent project structure). Needs a bridge script to trigger FB reviews from within the project.\n- **claude-project** — has `.claude\u002F` but no agent system of its own\n- **standalone** — no AI tooling found\n- **global** — `$BOARD` is under `~\u002F.frontierboard\u002F` (detected above)\n\nScan the project: read README, CLAUDE.md, SPEC.md, package manifests. Build a mental model of the stack for use in Step 5 (agent contexts).\n\n---\n\n## Step 2: Autonomous Mode\n\n> Do you want agents in **YOLO mode** or **supervised mode**?\n>\n> **YOLO mode** — Full autonomy. Agents run unattended with read\u002Fwrite\u002Fbash. No permission prompts. They can use browser tools, run commands, explore freely. **Risk:** YOLO agents can read\u002Fwrite any file accessible to the board user, execute arbitrary commands, and access the network. Blind review between agents is enforced by instructions only — not by technical isolation. Use on machines where you trust the agents with everything the board user can access.\n>\n> **Supervised mode** — Agents pause before actions. Good for first-time setup or shared\u002Funtrusted environments.\n\nRecord the choice. Write `yolo_mode: true` or `yolo_mode: false` in BOARD.md (Step 7). If YOLO, agent invocations include `--dangerously-skip-permissions` (Claude Code) or `--dangerously-bypass-approvals-and-sandbox` (Codex). If supervised, omit those flags.\n\n---\n\n## Step 2b: Board User\n\nAgents run directly on the host as a dedicated board user. Blind review is enforced by agent instructions and directory permissions.\n\n- If **not root**: note the choice and move on.\n- If **root** (see Hard-Won Knowledge #3): explain that AI tools block autonomous mode for root, and a separate user account is needed. Ask for a name (default: `llmuser`).\n- Create the board user: idempotent useradd, sudoers entry with visudo validation (see Hard-Won Knowledge #4). Do this yourself — don't ask the user to run commands.\n\n---\n\n## Step 3: Review Domain\n\n> What will your board primarily review?\n> 1. Software  2. Business  3. HR\u002FHiring  4. Finance  5. Mix of everything\n\nIf \"mix\" — explain that agents have stable thinking styles and you'll load domain-specific context automatically per review.\n\n---\n\n## Step 4: Compose the Board\n\nExplain the concept briefly:\n\n> Each board member is an AI agent with a **thinking style** — how they approach any question. That stays stable. I load domain context per review. Think about *how* you want things questioned, not what domain.\n>\n> How many agents? Two minimum, three gives a tiebreaker, more than four gets noisy.\n\nFor each agent, ask:\n1. **Thinking style** — offer domain-relevant suggestions (skeptic, systems thinker, pragmatist, contrarian, or custom)\n2. **CLI** — Claude Code, Codex, or Qwen. If unsure, suggest Claude Code (no extra charges with Pro\u002FMax subscription). Mention Qwen has a free tier. Warn that Codex uses pay-per-use API billing.\n\n---\n\n## Step 5: CLI Setup\n\nFor each unique CLI across all agents, check if installed and authenticated. Report findings, then fix what's missing.\n\n**Auth guidance per CLI:**\n- **Claude Code**: Subscription (browser login) or API key (console.anthropic.com). Recommend subscription path.\n- **Codex**: Clarify ChatGPT subscription ≠ API access. API is separate pay-per-use at platform.openai.com. Strongly recommend spend limits.\n- **Qwen**: DashScope API key from bailian.console.aliyun.com. Has a free tier (Bailian Coding Plan).\n\nExplain once: credentials are global (one login per machine), settings are per-agent.\n\nIf a board user was created, copy credential files from current user's home to board user's home.\n\n**C10: Validate credentials before proceeding.** After auth setup, verify that each configured credential source actually exists and is usable:\n- **Claude OAuth:** Check `~\u002F.claude\u002F.credentials.json` exists, is parseable JSON, and contains a non-empty `claudeAiOauth.accessToken`. If missing or empty: \"Run `claude \u002Flogin` to authenticate, then re-run `\u002Fsetup`.\" (Runtime extraction in `\u002Frun` is the authoritative freshness check — setup validates obvious misconfigurations only.)\n- **Codex ChatGPT OAuth:** Check `~\u002F.codex\u002Fauth.json` exists. If missing: \"Run `codex` to authenticate, then re-run `\u002Fsetup`.\"\n- **API keys:** Verify the relevant env var (`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`) is set and non-empty.\n\nDo NOT continue to Step 6 if validation fails — the generated invocation templates will be correct but unusable. Fail early with an actionable message.\n\n---\n\n## Step 6: Build the Agents\n\nFor each agent, create their directory at `$BOARD\u002F.board\u002Fboard\u002F{agent-name}\u002F` with:\n- `inbox\u002F`, `outbox\u002F`, `learnings\u002F`, `contexts\u002F`\n- Settings bubble for their CLI (Claude: `.claude\u002Fsettings.json` allowing all tools + model. Codex: `.codex\u002Fconfig.toml` with approval=never + project doc pointing to CLAUDE.md. Qwen: `.qwen\u002Fsettings.json` with yolo mode.)\n- **`claudeMdExcludes` (critical):** Claude Code walks up the directory tree and loads every CLAUDE.md it finds. Agents must NOT pick up the FrontierBoard orchestrator's CLAUDE.md or the user's project CLAUDE.md — only their own agent identity. Add `claudeMdExcludes` to each agent's `.claude\u002Fsettings.json` listing the absolute paths of all CLAUDE.md files above the agent directory. At minimum, exclude `$BOARD\u002FCLAUDE.md`. If `$PROJ\u002FCLAUDE.md` exists and the board is inside or near the project, exclude that too.\n\n  **Claude agent `.claude\u002Fsettings.json` template:**\n  ```json\n  {\n    \"permissions\": {\n      \"allow\": [\"Read\", \"Glob\", \"Grep\", \"Write\", \"Edit\", \"Bash\"]\n    },\n    \"model\": \"claude-opus-4-6\",\n    \"claudeMdExcludes\": [\n      \"{$BOARD}\u002FCLAUDE.md\"\n    ]\n  }\n  ```\n  Replace `{$BOARD}` with the resolved absolute path. Add `\"{$PROJ}\u002FCLAUDE.md\"` to the array if `$PROJ` has a CLAUDE.md. For supervised mode, restrict the permissions list.\n- `CLAUDE.md` — agent identity. Domain-agnostic thinking style, NOT domain knowledge. Cover: who they are, how they think, what they're reviewing (one sentence naming the project), output format (structured findings using the SOP severity levels: FIX NOW \u002F DEFER \u002F INFO \u002F REJECT, with location\u002Ffinding\u002Fscenario\u002Frecommendation), rules (blind review, write report first, load context from inbox).\n\n**Context files** go in `contexts\u002F{domain}.md`. This is where ALL domain-specific knowledge lives — architecture, tech stack, key files, threat models. Tailor to each agent's thinking style. Write one context per domain chosen in Step 3, or three (software, business, general) if they chose \"mix.\"\n\n---\n\n## Step 6b: Fix Ownership\n\nIf a board user exists, chown all of `.board\u002F` to that user and ensure parent directory traversal (see Hard-Won Knowledge #5). Also chown `$BOARD\u002Ftasks.json` to the board user — it lives outside `.board\u002F` but agents need write access to update task status after reviews.\n\n---\n\n## Step 7: Board Identity and Integration\n\n### Board orchestrator CLAUDE.md\n\nWrite `$BOARD\u002F.board\u002FCLAUDE.md` — the orchestrator identity. Include: project name\u002Fpath\u002Fstack, agent table (name, dir, CLI, style), how reviews work (detect domain → copy context → write brief → run agents → synthesise → write to REVIEW-LOG.md), available commands (\u002Fnew-agent, \u002Fbrief, \u002Frun).\n\n### BOARD.md\n\nWrite `$BOARD\u002F.board\u002Fboard\u002FBOARD.md` — operational source of truth. Include: project path, autonomous mode (`yolo_mode: true\u002Ffalse`), board user, per-agent invocation commands with `timeout 900` wrapper, parallelism pattern (run all agents in parallel, wait for all, check exit codes, verify report freshness).\n\n**All Claude Code invocation commands MUST include `unset CLAUDECODE`** (see Hard-Won Knowledge #1). **All Codex invocations MUST use `codex exec`** (see Hard-Won Knowledge #2).\n\n### Invocation templates\n\n**Claude Code (bare):**\n```bash\ntimeout 900 sudo -u $BOARD_USER bash -c 'unset CLAUDECODE && cd $AGENT_DIR && claude --dangerously-skip-permissions -p \"read CLAUDE.md then read inbox\u002Fcontext.md and inbox\u002Fbrief.md and write your report to outbox\u002Freport.md\"'\n```\n\n**Codex (bare):**\n```bash\ntimeout 900 sudo -u $BOARD_USER bash -c 'cd $AGENT_DIR && codex exec --dangerously-bypass-approvals-and-sandbox \"read CLAUDE.md then read inbox\u002Fcontext.md and inbox\u002Fbrief.md and write your report to outbox\u002Freport.md\"'\n```\n\nIf no board user, omit `sudo -u`. If supervised mode, omit `--dangerously-skip-permissions` \u002F `--dangerously-bypass-approvals-and-sandbox`.\n\n### Integration bridge\n\n**fb-project-bridge:** Create `$BOARD\u002F.board\u002Fbridge\u002Frun-review.sh` (executable) that accepts a brief, populates each agent's `inbox\u002Fbrief.md` (not a dead `board\u002Finbox\u002F` path), switches to board user if root, runs the orchestrator. The bridge must include `unset CLAUDECODE` before any Claude invocation. Create a skill at `$PROJ\u002F.claude\u002Fskills\u002Fboard-review\u002FSKILL.md` that tells the project's Claude how to invoke the bridge with timing estimates and a polling pattern. Add bridge section to BOARD.md.\n\n**claude-project:** Create a skill at `$PROJ\u002F.claude\u002Fskills\u002Fboard-review\u002FSKILL.md` that triggers the board from any Claude session. Check for existing skill first — if it's a previous FrontierBoard install, offer to update; if unrelated, use alternate name (`frontierboard-review`).\n\nWrite the following template to `$PROJ\u002F.claude\u002Fskills\u002Fboard-review\u002FSKILL.md`, replacing all `{$BOARD}`, `{$PROJ}`, and `{$BOARD_USER}` with resolved absolute paths (no tilde). If no board user exists (non-root), omit `sudo -u {$BOARD_USER}` from the launch command.\n\n```markdown\n---\nname: board-review\ndescription: Trigger a FrontierBoard governance review from this project session. Type \u002Fboard-review or describe what you want reviewed.\n---\n\n# Board Review\n\nTrigger a board review without leaving this session.\n\n## Board Location\n\n- **Board:** {$BOARD}\n- **Board state:** {$BOARD}\u002F.board\n- **Board user:** {$BOARD_USER}\n- **Project:** {$PROJ}\n\n## Behavior\n\nWhen the user types `\u002Fboard-review` or describes something to review:\n\n### 1. Accept the review request\n\nAsk what to review if not already specified. Capture the full description.\n\n### 2. Pre-flight checks\n\nRun these before launching. Stop with a clear message if any fail:\n\n1. **Board exists:** `[ -f \"{$BOARD}\u002F.board\u002Fboard\u002FBOARD.md\" ]` — if not: \"Board not found at {$BOARD}. Run \u002Fsetup first.\"\n2. **No review in progress:** Check `{$BOARD}\u002F.board\u002F.review-lock` — if it exists, read the PID. If PID is alive: \"Review already in progress (PID {pid}). Wait or kill it.\" If PID is dead: remove stale lock and continue.\n3. **Agents ready:** Verify at least one agent directory exists under `{$BOARD}\u002F.board\u002Fboard\u002F` with inbox\u002F and outbox\u002F.\n\n### 3. Stage the review description\n\nWrite the description to a staging file to avoid shell escaping issues:\n\n```bash\nmkdir -p {$BOARD}\u002F.board\u002Fbridge\ncat > {$BOARD}\u002F.board\u002Fbridge\u002Fpending-review.md \u003C\u003C 'BRIEF'\n[user's review description here]\nBRIEF\n```\n\n### 4. Launch the orchestrator\n\nRun in background so the user's session isn't blocked (reviews take 8–15 minutes):\n\n```bash\nnohup sudo -u {$BOARD_USER} bash -c 'unset CLAUDECODE && cd {$BOARD} && claude --dangerously-skip-permissions -p \"Read .board\u002FCLAUDE.md for your identity. Read .board\u002Fbridge\u002Fpending-review.md for the review request. The project is at {$PROJ}. Run \u002Fbrief with this context, then \u002Frun.\"' > \u002Ftmp\u002Ffb-review-$$.log 2>&1 &\necho $! > \u002Ftmp\u002Ffb-review-$$.pid\n```\n\nTell the user:\n> Board review launched. Standard reviews take 8–15 minutes. I'll check every 60 seconds and report back.\n\n### 5. Poll for completion\n\nCheck every 60 seconds:\n- Is the orchestrator PID still alive? (`kill -0 $(cat \u002Ftmp\u002Ffb-review-$$.pid)`)\n- Has `{$BOARD}\u002F.board\u002Fboard\u002FREVIEW-LOG.md` been modified since launch?\n\nOn completion (PID exits):\n1. Read `{$BOARD}\u002F.board\u002Fboard\u002FREVIEW-LOG.md` — find the most recent review entry\n2. Present: FIX NOW items, DEFER items with trigger conditions, INFO items\n3. Show agent agreement\u002Fdisagreement per finding\n4. Ask: \"Want to work through the FIX NOW items now, or save for later?\"\n\nOn failure (non-zero exit or no new REVIEW-LOG entry):\n1. Read `\u002Ftmp\u002Ffb-review-$$.log` for error output\n2. Present the error and suggest: \"Run \u002Fdebug from {$BOARD} to diagnose.\"\n\n### 6. Cleanup\n\n```bash\nrm -f \u002Ftmp\u002Ffb-review-$$.pid \u002Ftmp\u002Ffb-review-$$.log {$BOARD}\u002F.board\u002Fbridge\u002Fpending-review.md\n```\n\n## Notes\n\n- The orchestrator handles \u002Fbrief and \u002Frun — this skill just triggers and reports\n- For planning help before a review, use \u002Fdirector\n- Reviews run agents in parallel as {$BOARD_USER} (bare mode)\n- Agents are ephemeral — zero memory between rounds, everything via inbox\n```\n\nAlso add an \"Integration\" section to BOARD.md:\n\n```markdown\n## Integration\n\n**Project:** {$PROJ}\n**Skill:** {$PROJ}\u002F.claude\u002Fskills\u002Fboard-review\u002FSKILL.md\n\nFrom the project's Claude session, type `\u002Fboard-review` or describe what to review.\n```\n\nTell the user:\n> Created `\u002Fboard-review` skill in your project. From your project session, type `\u002Fboard-review` or just describe what you want reviewed.\n\n**standalone:** Add a \"Running a Review\" section to BOARD.md with the direct command.\n\n**global:** Create per-project state at `$BOARD\u002F.board\u002Fprojects\u002F{project-name}\u002F`:\n- `CLAUDE.md` — project-specific orchestrator identity (project name, path, stack, pointer to shared agents)\n- `BOARD.md` — project-specific operational reference (same agents, but project-specific paths for briefs\u002Freports)\n- `briefs\u002F`, `reports\u002F`, `contexts\u002F` — per-project review artifacts\n\nAlso create a global skill at `~\u002F.claude\u002Fskills\u002Ffrontierboard\u002FSKILL.md` that lets the user type `\u002Ffrontierboard` from any Claude session. The skill should:\n1. Detect the current working directory as the project path (use `$PWD`, passed explicitly — C6)\n2. Use **absolute paths** to the board install (e.g., `\u002Froot\u002F.frontierboard\u002FFrontierBoard`, NOT `~\u002F.frontierboard\u002F...`) — C1\n3. Shell out with `unset CLAUDECODE` before nested Claude invocation — C5: `bash -c 'unset CLAUDECODE && cd \u002Fabsolute\u002Fpath\u002Fto\u002FFrontierBoard && claude --dangerously-skip-permissions -p \"review project at \u002Fabsolute\u002Fproject\u002Fpath\"'`\n4. Pass the project path so the orchestrator can resolve `projects\u002F{name}\u002F` for per-project state — C6\n5. Report back the synthesis\n6. If agents don't exist yet, tell the user to run setup first\n\nWhen the user returns to review another project, `\u002Fsetup` detects existing agents and only creates the new project entry — no need to rebuild the board.\n\n---\n\n## Step 7b: Director Setup\n\nCreate the Director — a separate Claude session for review planning.\n\n### Director session directory\n\nCreate `$BOARD\u002F.board\u002Fdirector\u002F` with:\n\n**CLAUDE.md** — The director persona. Write this file with resolved absolute paths:\n\n```markdown\n# FrontierBoard Director — Review Planning Consultant\n\nYou are the Director — a planning consultant for FrontierBoard reviews. You help the human owner think through what to review, how to frame it, and what the findings mean.\n\nYou are NOT the orchestrator. You do NOT run agents. You read, advise, and help plan.\n\n## Your Knowledge Sources\n\nRead these to understand the current state:\n- `$PROJ\u002FCLAUDE.md` — project identity\n- `$PROJ\u002FSPEC.md` — project architecture (if exists)\n- `$BOARD\u002F.board\u002Fboard\u002FBOARD.md` — board composition and agent invocations\n- `$BOARD\u002Fdocs\u002FREVIEW-SOP.md` — how reviews work (4-round SOP)\n- `$BOARD\u002F.board\u002Fboard\u002FREVIEW-LOG.md` — prior review history (if exists)\n- `$BOARD\u002Ftasks.json` — task tracker including deferred items\n- `$BOARD\u002F.board\u002Fboard\u002FDEFERRED_WORK.md` — legacy deferred items (if exists)\n\nReplace $PROJ and $BOARD with the actual absolute paths.\n\n## What You Do\n\n- **Plan reviews:** Help decide what to put in front of the board and frame the right questions\n- **Advise on depth:** Quick (1 agent, fast) vs Standard (full board, thorough) vs Custom\n- **Draft briefs:** Help formulate evaluation criteria, broader context, specific questions for agents\n- **Interpret findings:** After a review, help understand the synthesis, prioritize FIX NOW items\n- **Track deferred work:** Review deferred items, assess trigger conditions, recommend promotions to FIX NOW\n- **Draft owner directives:** Help write directives for mid-review steering (between rounds)\n- **Suggest agent composition:** Advise whether current agents cover the review domain or if \u002Fnew-agent is needed\n\n## What You Do NOT Do\n\n- You do NOT run agents — that is the orchestrator's job (user runs \u002Frun from their project session)\n- You do NOT write to agent inboxes or outboxes\n- You do NOT modify BOARD.md or agent configurations\n- You are advisory — read-only with respect to the board infrastructure\n\n## Session Start\n\nWhen the user arrives, say:\n\n> What are you thinking about reviewing? Or would you like me to look at the recent review history and suggest what needs attention?\n\nThen read the knowledge sources above and help them plan.\n```\n\n**`.claude\u002Fsettings.json`** — Read-only advisory permissions for the director session:\n```json\n{\n  \"permissions\": {\n    \"allow\": [\"Read\", \"Glob\", \"Grep\"],\n    \"deny\": [\"Write\", \"Edit\", \"Bash\"]\n  }\n}\n```\n\n### Director skill in user's project\n\nCreate `$PROJ\u002F.claude\u002Fskills\u002Fdirector\u002FSKILL.md` with the content from the template at `$BOARD\u002F.claude\u002Fskills\u002Fdirector\u002FSKILL.md`, replacing `$BOARD` with the resolved absolute path.\n\n---\n\n## Step 8: Update .gitignore\n\nAppend FrontierBoard entries to `$BOARD\u002F.gitignore` (NOT `$PROJ\u002F.gitignore`). Append-only — never modify existing lines. Gitignore: agent working directories (contexts, inbox, outbox, learnings), BOARD.md, REVIEW-LOG.md, DEFERRED_WORK.md, CONSOLIDATION.md, bridge\u002F.\n\n---\n\n## Step 9: Smoke Test\n\nWrite a minimal brief asking each agent to confirm their identity and write to their outbox. Run each agent from their directory. Confirm every agent produced a report before declaring success. If any fail, diagnose and fix.\n\n---\n\n## Step 10: Contribute Back (Optional)\n\nIf you discovered workarounds or fixes during setup that aren't in upstream, ask the user if they want to send a PR to `stefans71\u002FFrontierBoard`. Show what changed in plain language. Only submit after explicit confirmation. Skip entirely if nothing was discovered.\n\n---\n\n## Step 11: Done\n\nName each agent, their CLI, and role. Show `$PROJ` and `$BOARD\u002F.board\u002F` paths. Give concrete next steps matching the integration mode:\n\n- **fb-project-bridge**: \"Your project can now trigger board reviews. Run the bridge or use the `\u002Fboard-review` skill from within your project's Claude session.\"\n- **claude-project**: \"Type `\u002Fboard-review` or describe what to review.\"\n- **standalone**: \"`cd $BOARD\u002F.board && claude` then describe what to review or `\u002Fbrief` then `\u002Frun`.\"\n- **global**: \"Type `\u002Ffrontierboard` from any project session, or `cd ~\u002F.frontierboard\u002FFrontierBoard && claude` and tell it which project to review.\"\n\n> What would you like the board to look at first?\n","# Board of Governance — Setup\n\nWalk the user through setting up their board. This is a conversation — ask questions, listen, do the work. Only pause when you genuinely need the user to act (paste a key, scan a QR code, open a browser). When something is broken, fix it yourself.\n\n**Output formatting:** Use markdown headings for each step (`## Step 3: Autonomous Mode`) and per-agent (`### Agent 1`).\n\n---\n\n## Paths\n\n- **`$BOARD`** — the FrontierBoard clone directory. All board files go here: `.board\u002F`, agents, reports. The board NEVER writes `.board\u002F` inside the user's project.\n- **`$PROJ`** — the user's project. Read-only, except: you may append to `$PROJ\u002F.gitignore` and create new files in `$PROJ\u002F.claude\u002Fskills\u002F`.\n\n### Global install mode\n\nIf `$BOARD` is under `~\u002F.frontierboard\u002F`, this is a global install. In global mode:\n- Agents are built once and shared across all projects\n- Per-project state lives in `$BOARD\u002F.board\u002Fprojects\u002F{project-name}\u002F` (briefs, contexts, reports, BOARD.md)\n- Agent directories stay at `$BOARD\u002F.board\u002Fboard\u002F{agent-name}\u002F` (shared)\n- Each project gets its own orchestrator CLAUDE.md at `$BOARD\u002F.board\u002Fprojects\u002F{project-name}\u002FCLAUDE.md`\n- A global skill is installed at `~\u002F.claude\u002Fskills\u002Ffrontierboard\u002FSKILL.md` so the user can type `\u002Ffrontierboard` from any project session\n\n**C1: Use absolute paths everywhere.** `~` resolves differently per user (`\u002Froot` vs `\u002Fhome\u002Fllmuser`). All BOARD.md, CLAUDE.md, skill files, and invocation commands must use absolute paths (e.g., `\u002Froot\u002F.frontierboard\u002FFrontierBoard`), never tilde notation.\n\n---\n\n## Hard-Won Knowledge\n\nThese are operational facts Claude cannot derive from general training. Never remove them.\n\n1. **`unset CLAUDECODE`** — All invocation commands for Claude Code agents must unset the `CLAUDECODE` env var. Without it, nested Claude sessions fail with \"Cannot be launched inside another Claude Code session.\" Wrap in `bash -c 'unset CLAUDECODE && ...'`.\n\n2. **`codex exec` not `codex`** — The bare `codex` command opens a TUI requiring an interactive terminal. It will silently fail as a subprocess. Always use `codex exec` for non-interactive invocation.\n\n3. **Root always needs a board user** — Even in interactive mode, `--dangerously-skip-permissions` is blocked when running as root. If current user is root, ALWAYS create a board user regardless of mode choice.\n\n4. **Sudoers validation** — Always validate with `visudo -c -f \u003Cfile>` after writing. A bad sudoers file can brick sudo. Use `chmod 0440`. Remove the file if validation fails.\n\n5. **Board user ownership** — After creating all agent directories, `chown -R $BOARD_USER:$BOARD_USER $BOARD\u002F.board\u002F`. Also ensure the board user can traverse parent directories.\n\n6. **Billing warnings are mandatory** — Always warn users about pay-per-use billing (OpenAI API, Anthropic API) before accepting keys. Recommend spend limits. Claude Pro\u002FMax subscriptions have no extra charges — mention this.\n\n7. **Agent model must be high-reasoning** — Settings bubbles must set model to `claude-opus-4-6` (Claude Code). For Codex, let it default to its recommended model (currently `gpt-5.4`) or explicitly set `gpt-5.4` \u002F `gpt-5.3-codex`. The old `o4-mini` name is retired and causes errors. Never use Sonnet — it lacks the reasoning depth for independent review.\n\n8. **Codex approval_policy is `never`** — The Codex config.toml must use `approval_policy = \"never\"` (not \"full-auto\"). And Codex invocations in BOARD.md must include `--dangerously-bypass-approvals-and-sandbox`. Without this flag, Codex won't run as a subprocess.\n\n9. **Agent invocation must read CLAUDE.md** — All invocation commands must tell the agent to read its CLAUDE.md first, then read inbox files. Example: `\"read CLAUDE.md then read inbox\u002Fcontext.md and inbox\u002Fbrief.md and write your report to outbox\u002Freport.md\"`. Agents without CLAUDE.md instructions lose their identity.\n\n10. **`claudeMdExcludes` blocks tree-walking leaks** — Claude Code walks UP the directory tree from CWD and loads EVERY `CLAUDE.md` it finds. Agents inside `$BOARD\u002F.board\u002Fboard\u002F{agent}\u002F` would pick up `$BOARD\u002FCLAUDE.md` (orchestrator routing table) and potentially `$PROJ\u002FCLAUDE.md` (project rules). This pollutes agent context with instructions meant for the orchestrator. Fix: every agent's `.claude\u002Fsettings.json` must include `claudeMdExcludes` listing the absolute paths of all parent CLAUDE.md files to block. Note: `.claude\u002Fsettings.json` does NOT walk up — only CLAUDE.md does.\n\n---\n\n## Step 1: Welcome and Detect\n\n> Welcome to Board of Governance setup. I'll set up a board of independent AI reviewers for your project. I'll only pause when I genuinely need something from you.\n>\n> What's the path to the project this board will review?\n\nSet `$PROJ` (project path) and `$BOARD` (FrontierBoard clone — current directory or clone path).\n\n**Global mode detection:** If `$BOARD` is under `~\u002F.frontierboard\u002F`, this is a global install. Check if agents already exist at `$BOARD\u002F.board\u002Fboard\u002F`. If they do, skip Steps 2–6 (board already built) and jump to Step 7 to wire up the new project. If agents don't exist yet, this is a first-time global setup — run all steps normally, then wire the project.\n\nSilently detect integration mode by checking `$PROJ`:\n- **fb-project-bridge** — has its own AI agent system (`src\u002Findex.ts` + `container\u002Fbuild.sh` + `groups\u002F`, or similar multi-agent project structure). Needs a bridge script to trigger FB reviews from within the project.\n- **claude-project** — has `.claude\u002F` but no agent system of its own\n- **standalone** — no AI tooling found\n- **global** — `$BOARD` is under `~\u002F.frontierboard\u002F` (detected above)\n\nScan the project: read README, CLAUDE.md, SPEC.md, package manifests. Build a mental model of the stack for use in Step 5 (agent contexts).\n\n---\n\n## Step 2: Autonomous Mode\n\n> Do you want agents in **YOLO mode** or **supervised mode**?\n>\n> **YOLO mode** — Full autonomy. Agents run unattended with read\u002Fwrite\u002Fbash. No permission prompts. They can use browser tools, run commands, explore freely. **Risk:** YOLO agents can read\u002Fwrite any file accessible to the board user, execute arbitrary commands, and access the network. Blind review between agents is enforced by instructions only — not by technical isolation. Use on machines where you trust the agents with everything the board user can access.\n>\n> **Supervised mode** — Agents pause before actions. Good for first-time setup or shared\u002Funtrusted environments.\n\nRecord the choice. Write `yolo_mode: true` or `yolo_mode: false` in BOARD.md (Step 7). If YOLO, agent invocations include `--dangerously-skip-permissions` (Claude Code) or `--dangerously-bypass-approvals-and-sandbox` (Codex). If supervised, omit those flags.\n\n---\n\n## Step 2b: Board User\n\nAgents run directly on the host as a dedicated board user. Blind review is enforced by agent instructions and directory permissions.\n\n- If **not root**: note the choice and move on.\n- If **root** (see Hard-Won Knowledge #3): explain that AI tools block autonomous mode for root, and a separate user account is needed. Ask for a name (default: `llmuser`).\n- Create the board user: idempotent useradd, sudoers entry with visudo validation (see Hard-Won Knowledge #4). Do this yourself — don't ask the user to run commands.\n\n---\n\n## Step 3: Review Domain\n\n> What will your board primarily review?\n> 1. Software  2. Business  3. HR\u002FHiring  4. Finance  5. Mix of everything\n\nIf \"mix\" — explain that agents have stable thinking styles and you'll load domain-specific context automatically per review.\n\n---\n\n## Step 4: Compose the Board\n\nExplain the concept briefly:\n\n> Each board member is an AI agent with a **thinking style** — how they approach any question. That stays stable. I load domain context per review. Think about *how* you want things questioned, not what domain.\n>\n> How many agents? Two minimum, three gives a tiebreaker, more than four gets noisy.\n\nFor each agent, ask:\n1. **Thinking style** — offer domain-relevant suggestions (skeptic, systems thinker, pragmatist, contrarian, or custom)\n2. **CLI** — Claude Code, Codex, or Qwen. If unsure, suggest Claude Code (no extra charges with Pro\u002FMax subscription). Mention Qwen has a free tier. Warn that Codex uses pay-per-use API billing.\n\n---\n\n## Step 5: CLI Setup\n\nFor each unique CLI across all agents, check if installed and authenticated. Report findings, then fix what's missing.\n\n**Auth guidance per CLI:**\n- **Claude Code**: Subscription (browser login) or API key (console.anthropic.com). Recommend subscription path.\n- **Codex**: Clarify ChatGPT subscription ≠ API access. API is separate pay-per-use at platform.openai.com. Strongly recommend spend limits.\n- **Qwen**: DashScope API key from bailian.console.aliyun.com. Has a free tier (Bailian Coding Plan).\n\nExplain once: credentials are global (one login per machine), settings are per-agent.\n\nIf a board user was created, copy credential files from current user's home to board user's home.\n\n**C10: Validate credentials before proceeding.** After auth setup, verify that each configured credential source actually exists and is usable:\n- **Claude OAuth:** Check `~\u002F.claude\u002F.credentials.json` exists, is parseable JSON, and contains a non-empty `claudeAiOauth.accessToken`. If missing or empty: \"Run `claude \u002Flogin` to authenticate, then re-run `\u002Fsetup`.\" (Runtime extraction in `\u002Frun` is the authoritative freshness check — setup validates obvious misconfigurations only.)\n- **Codex ChatGPT OAuth:** Check `~\u002F.codex\u002Fauth.json` exists. If missing: \"Run `codex` to authenticate, then re-run `\u002Fsetup`.\"\n- **API keys:** Verify the relevant env var (`ANTHROPIC_API_KEY`, `OPENAI_API_KEY`) is set and non-empty.\n\nDo NOT continue to Step 6 if validation fails — the generated invocation templates will be correct but unusable. Fail early with an actionable message.\n\n---\n\n## Step 6: Build the Agents\n\nFor each agent, create their directory at `$BOARD\u002F.board\u002Fboard\u002F{agent-name}\u002F` with:\n- `inbox\u002F`, `outbox\u002F`, `learnings\u002F`, `contexts\u002F`\n- Settings bubble for their CLI (Claude: `.claude\u002Fsettings.json` allowing all tools + model. Codex: `.codex\u002Fconfig.toml` with approval=never + project doc pointing to CLAUDE.md. Qwen: `.qwen\u002Fsettings.json` with yolo mode.)\n- **`claudeMdExcludes` (critical):** Claude Code walks up the directory tree and loads every CLAUDE.md it finds. Agents must NOT pick up the FrontierBoard orchestrator's CLAUDE.md or the user's project CLAUDE.md — only their own agent identity. Add `claudeMdExcludes` to each agent's `.claude\u002Fsettings.json` listing the absolute paths of all CLAUDE.md files above the agent directory. At minimum, exclude `$BOARD\u002FCLAUDE.md`. If `$PROJ\u002FCLAUDE.md` exists and the board is inside or near the project, exclude that too.\n\n  **Claude agent `.claude\u002Fsettings.json` template:**\n  ```json\n  {\n    \"permissions\": {\n      \"allow\": [\"Read\", \"Glob\", \"Grep\", \"Write\", \"Edit\", \"Bash\"]\n    },\n    \"model\": \"claude-opus-4-6\",\n    \"claudeMdExcludes\": [\n      \"{$BOARD}\u002FCLAUDE.md\"\n    ]\n  }\n  ```\n  Replace `{$BOARD}` with the resolved absolute path. Add `\"{$PROJ}\u002FCLAUDE.md\"` to the array if `$PROJ` has a CLAUDE.md. For supervised mode, restrict the permissions list.\n- `CLAUDE.md` — agent identity. Domain-agnostic thinking style, NOT domain knowledge. Cover: who they are, how they think, what they're reviewing (one sentence naming the project), output format (structured findings using the SOP severity levels: FIX NOW \u002F DEFER \u002F INFO \u002F REJECT, with location\u002Ffinding\u002Fscenario\u002Frecommendation), rules (blind review, write report first, load context from inbox).\n\n**Context files** go in `contexts\u002F{domain}.md`. This is where ALL domain-specific knowledge lives — architecture, tech stack, key files, threat models. Tailor to each agent's thinking style. Write one context per domain chosen in Step 3, or three (software, business, general) if they chose \"mix.\"\n\n---\n\n## Step 6b: Fix Ownership\n\nIf a board user exists, chown all of `.board\u002F` to that user and ensure parent directory traversal (see Hard-Won Knowledge #5). Also chown `$BOARD\u002Ftasks.json` to the board user — it lives outside `.board\u002F` but agents need write access to update task status after reviews.\n\n---\n\n## Step 7: Board Identity and Integration\n\n### Board orchestrator CLAUDE.md\n\nWrite `$BOARD\u002F.board\u002FCLAUDE.md` — the orchestrator identity. Include: project name\u002Fpath\u002Fstack, agent table (name, dir, CLI, style), how reviews work (detect domain → copy context → write brief → run agents → synthesise → write to REVIEW-LOG.md), available commands (\u002Fnew-agent, \u002Fbrief, \u002Frun).\n\n### BOARD.md\n\nWrite `$BOARD\u002F.board\u002Fboard\u002FBOARD.md` — operational source of truth. Include: project path, autonomous mode (`yolo_mode: true\u002Ffalse`), board user, per-agent invocation commands with `timeout 900` wrapper, parallelism pattern (run all agents in parallel, wait for all, check exit codes, verify report freshness).\n\n**All Claude Code invocation commands MUST include `unset CLAUDECODE`** (see Hard-Won Knowledge #1). **All Codex invocations MUST use `codex exec`** (see Hard-Won Knowledge #2).\n\n### Invocation templates\n\n**Claude Code (bare):**\n```bash\ntimeout 900 sudo -u $BOARD_USER bash -c 'unset CLAUDECODE && cd $AGENT_DIR && claude --dangerously-skip-permissions -p \"read CLAUDE.md then read inbox\u002Fcontext.md and inbox\u002Fbrief.md and write your report to outbox\u002Freport.md\"'\n```\n\n**Codex (bare):**\n```bash\ntimeout 900 sudo -u $BOARD_USER bash -c 'cd $AGENT_DIR && codex exec --dangerously-bypass-approvals-and-sandbox \"read CLAUDE.md then read inbox\u002Fcontext.md and inbox\u002Fbrief.md and write your report to outbox\u002Freport.md\"'\n```\n\nIf no board user, omit `sudo -u`. If supervised mode, omit `--dangerously-skip-permissions` \u002F `--dangerously-bypass-approvals-and-sandbox`.\n\n### Integration bridge\n\n**fb-project-bridge:** Create `$BOARD\u002F.board\u002Fbridge\u002Frun-review.sh` (executable) that accepts a brief, populates each agent's `inbox\u002Fbrief.md` (not a dead `board\u002Finbox\u002F` path), switches to board user if root, runs the orchestrator. The bridge must include `unset CLAUDECODE` before any Claude invocation. Create a skill at `$PROJ\u002F.claude\u002Fskills\u002Fboard-review\u002FSKILL.md` that tells the project's Claude how to invoke the bridge with timing estimates and a polling pattern. Add bridge section to BOARD.md.\n\n**claude-project:** Create a skill at `$PROJ\u002F.claude\u002Fskills\u002Fboard-review\u002FSKILL.md` that triggers the board from any Claude session. Check for existing skill first — if it's a previous FrontierBoard install, offer to update; if unrelated, use alternate name (`frontierboard-review`).\n\nWrite the following template to `$PROJ\u002F.claude\u002Fskills\u002Fboard-review\u002FSKILL.md`, replacing all `{$BOARD}`, `{$PROJ}`, and `{$BOARD_USER}` with resolved absolute paths (no tilde). If no board user exists (non-root), omit `sudo -u {$BOARD_USER}` from the launch command.\n\n```markdown\n---\nname: board-review\ndescription: Trigger a FrontierBoard governance review from this project session. Type \u002Fboard-review or describe what you want reviewed.\n---\n\n# Board Review\n\nTrigger a board review without leaving this session.\n\n## Board Location\n\n- **Board:** {$BOARD}\n- **Board state:** {$BOARD}\u002F.board\n- **Board user:** {$BOARD_USER}\n- **Project:** {$PROJ}\n\n## Behavior\n\nWhen the user types `\u002Fboard-review` or describes something to review:\n\n### 1. Accept the review request\n\nAsk what to review if not already specified. Capture the full description.\n\n### 2. Pre-flight checks\n\nRun these before launching. Stop with a clear message if any fail:\n\n1. **Board exists:** `[ -f \"{$BOARD}\u002F.board\u002Fboard\u002FBOARD.md\" ]` — if not: \"Board not found at {$BOARD}. Run \u002Fsetup first.\"\n2. **No review in progress:** Check `{$BOARD}\u002F.board\u002F.review-lock` — if it exists, read the PID. If PID is alive: \"Review already in progress (PID {pid}). Wait or kill it.\" If PID is dead: remove stale lock and continue.\n3. **Agents ready:** Verify at least one agent directory exists under `{$BOARD}\u002F.board\u002Fboard\u002F` with inbox\u002F and outbox\u002F.\n\n### 3. Stage the review description\n\nWrite the description to a staging file to avoid shell escaping issues:\n\n```bash\nmkdir -p {$BOARD}\u002F.board\u002Fbridge\ncat > {$BOARD}\u002F.board\u002Fbridge\u002Fpending-review.md \u003C\u003C 'BRIEF'\n[user's review description here]\nBRIEF\n```\n\n### 4. Launch the orchestrator\n\nRun in background so the user's session isn't blocked (reviews take 8–15 minutes):\n\n```bash\nnohup sudo -u {$BOARD_USER} bash -c 'unset CLAUDECODE && cd {$BOARD} && claude --dangerously-skip-permissions -p \"Read .board\u002FCLAUDE.md for your identity. Read .board\u002Fbridge\u002Fpending-review.md for the review request. The project is at {$PROJ}. Run \u002Fbrief with this context, then \u002Frun.\"' > \u002Ftmp\u002Ffb-review-$$.log 2>&1 &\necho $! > \u002Ftmp\u002Ffb-review-$$.pid\n```\n\nTell the user:\n> Board review launched. Standard reviews take 8–15 minutes. I'll check every 60 seconds and report back.\n\n### 5. Poll for completion\n\nCheck every 60 seconds:\n- Is the orchestrator PID still alive? (`kill -0 $(cat \u002Ftmp\u002Ffb-review-$$.pid)`)\n- Has `{$BOARD}\u002F.board\u002Fboard\u002FREVIEW-LOG.md` been modified since launch?\n\nOn completion (PID exits):\n1. Read `{$BOARD}\u002F.board\u002Fboard\u002FREVIEW-LOG.md` — find the most recent review entry\n2. Present: FIX NOW items, DEFER items with trigger conditions, INFO items\n3. Show agent agreement\u002Fdisagreement per finding\n4. Ask: \"Want to work through the FIX NOW items now, or save for later?\"\n\nOn failure (non-zero exit or no new REVIEW-LOG entry):\n1. Read `\u002Ftmp\u002Ffb-review-$$.log` for error output\n2. Present the error and suggest: \"Run \u002Fdebug from {$BOARD} to diagnose.\"\n\n### 6. Cleanup\n\n```bash\nrm -f \u002Ftmp\u002Ffb-review-$$.pid \u002Ftmp\u002Ffb-review-$$.log {$BOARD}\u002F.board\u002Fbridge\u002Fpending-review.md\n```\n\n## Notes\n\n- The orchestrator handles \u002Fbrief and \u002Frun — this skill just triggers and reports\n- For planning help before a review, use \u002Fdirector\n- Reviews run agents in parallel as {$BOARD_USER} (bare mode)\n- Agents are ephemeral — zero memory between rounds, everything via inbox\n```\n\nAlso add an \"Integration\" section to BOARD.md:\n\n```markdown\n## Integration\n\n**Project:** {$PROJ}\n**Skill:** {$PROJ}\u002F.claude\u002Fskills\u002Fboard-review\u002FSKILL.md\n\nFrom the project's Claude session, type `\u002Fboard-review` or describe what to review.\n```\n\nTell the user:\n> Created `\u002Fboard-review` skill in your project. From your project session, type `\u002Fboard-review` or just describe what you want reviewed.\n\n**standalone:** Add a \"Running a Review\" section to BOARD.md with the direct command.\n\n**global:** Create per-project state at `$BOARD\u002F.board\u002Fprojects\u002F{project-name}\u002F`:\n- `CLAUDE.md` — project-specific orchestrator identity (project name, path, stack, pointer to shared agents)\n- `BOARD.md` — project-specific operational reference (same agents, but project-specific paths for briefs\u002Freports)\n- `briefs\u002F`, `reports\u002F`, `contexts\u002F` — per-project review artifacts\n\nAlso create a global skill at `~\u002F.claude\u002Fskills\u002Ffrontierboard\u002FSKILL.md` that lets the user type `\u002Ffrontierboard` from any Claude session. The skill should:\n1. Detect the current working directory as the project path (use `$PWD`, passed explicitly — C6)\n2. Use **absolute paths** to the board install (e.g., `\u002Froot\u002F.frontierboard\u002FFrontierBoard`, NOT `~\u002F.frontierboard\u002F...`) — C1\n3. Shell out with `unset CLAUDECODE` before nested Claude invocation — C5: `bash -c 'unset CLAUDECODE && cd \u002Fabsolute\u002Fpath\u002Fto\u002FFrontierBoard && claude --dangerously-skip-permissions -p \"review project at \u002Fabsolute\u002Fproject\u002Fpath\"'`\n4. Pass the project path so the orchestrator can resolve `projects\u002F{name}\u002F` for per-project state — C6\n5. Report back the synthesis\n6. If agents don't exist yet, tell the user to run setup first\n\nWhen the user returns to review another project, `\u002Fsetup` detects existing agents and only creates the new project entry — no need to rebuild the board.\n\n---\n\n## Step 7b: Director Setup\n\nCreate the Director — a separate Claude session for review planning.\n\n### Director session directory\n\nCreate `$BOARD\u002F.board\u002Fdirector\u002F` with:\n\n**CLAUDE.md** — The director persona. Write this file with resolved absolute paths:\n\n```markdown\n# FrontierBoard Director — Review Planning Consultant\n\nYou are the Director — a planning consultant for FrontierBoard reviews. You help the human owner think through what to review, how to frame it, and what the findings mean.\n\nYou are NOT the orchestrator. You do NOT run agents. You read, advise, and help plan.\n\n## Your Knowledge Sources\n\nRead these to understand the current state:\n- `$PROJ\u002FCLAUDE.md` — project identity\n- `$PROJ\u002FSPEC.md` — project architecture (if exists)\n- `$BOARD\u002F.board\u002Fboard\u002FBOARD.md` — board composition and agent invocations\n- `$BOARD\u002Fdocs\u002FREVIEW-SOP.md` — how reviews work (4-round SOP)\n- `$BOARD\u002F.board\u002Fboard\u002FREVIEW-LOG.md` — prior review history (if exists)\n- `$BOARD\u002Ftasks.json` — task tracker including deferred items\n- `$BOARD\u002F.board\u002Fboard\u002FDEFERRED_WORK.md` — legacy deferred items (if exists)\n\nReplace $PROJ and $BOARD with the actual absolute paths.\n\n## What You Do\n\n- **Plan reviews:** Help decide what to put in front of the board and frame the right questions\n- **Advise on depth:** Quick (1 agent, fast) vs Standard (full board, thorough) vs Custom\n- **Draft briefs:** Help formulate evaluation criteria, broader context, specific questions for agents\n- **Interpret findings:** After a review, help understand the synthesis, prioritize FIX NOW items\n- **Track deferred work:** Review deferred items, assess trigger conditions, recommend promotions to FIX NOW\n- **Draft owner directives:** Help write directives for mid-review steering (between rounds)\n- **Suggest agent composition:** Advise whether current agents cover the review domain or if \u002Fnew-agent is needed\n\n## What You Do NOT Do\n\n- You do NOT run agents — that is the orchestrator's job (user runs \u002Frun from their project session)\n- You do NOT write to agent inboxes or outboxes\n- You do NOT modify BOARD.md or agent configurations\n- You are advisory — read-only with respect to the board infrastructure\n\n## Session Start\n\nWhen the user arrives, say:\n\n> What are you thinking about reviewing? Or would you like me to look at the recent review history and suggest what needs attention?\n\nThen read the knowledge sources above and help them plan.\n```\n\n**`.claude\u002Fsettings.json`** — Read-only advisory permissions for the director session:\n```json\n{\n  \"permissions\": {\n    \"allow\": [\"Read\", \"Glob\", \"Grep\"],\n    \"deny\": [\"Write\", \"Edit\", \"Bash\"]\n  }\n}\n```\n\n### Director skill in user's project\n\nCreate `$PROJ\u002F.claude\u002Fskills\u002Fdirector\u002FSKILL.md` with the content from the template at `$BOARD\u002F.claude\u002Fskills\u002Fdirector\u002FSKILL.md`, replacing `$BOARD` with the resolved absolute path.\n\n---\n\n## Step 8: Update .gitignore\n\nAppend FrontierBoard entries to `$BOARD\u002F.gitignore` (NOT `$PROJ\u002F.gitignore`). Append-only — never modify existing lines. Gitignore: agent working directories (contexts, inbox, outbox, learnings), BOARD.md, REVIEW-LOG.md, DEFERRED_WORK.md, CONSOLIDATION.md, bridge\u002F.\n\n---\n\n## Step 9: Smoke Test\n\nWrite a minimal brief asking each agent to confirm their identity and write to their outbox. Run each agent from their directory. Confirm every agent produced a report before declaring success. If any fail, diagnose and fix.\n\n---\n\n## Step 10: Contribute Back (Optional)\n\nIf you discovered workarounds or fixes during setup that aren't in upstream, ask the user if they want to send a PR to `stefans71\u002FFrontierBoard`. Show what changed in plain language. Only submit after explicit confirmation. Skip entirely if nothing was discovered.\n\n---\n\n## Step 11: Done\n\nName each agent, their CLI, and role. Show `$PROJ` and `$BOARD\u002F.board\u002F` paths. Give concrete next steps matching the integration mode:\n\n- **fb-project-bridge**: \"Your project can now trigger board reviews. Run the bridge or use the `\u002Fboard-review` skill from within your project's Claude session.\"\n- **claude-project**: \"Type `\u002Fboard-review` or describe what to review.\"\n- **standalone**: \"`cd $BOARD\u002F.board && claude` then describe what to review or `\u002Fbrief` then `\u002Frun`.\"\n- **global**: \"Type `\u002Ffrontierboard` from any project session, or `cd ~\u002F.frontierboard\u002FFrontierBoard && claude` and tell it which project to review.\"\n\n> What would you like the board to look at first?\n",{"name":5,"description":7},"main","e01303ad28862b5c26c950358250aeb4f74090e6",".claude\u002Fskills\u002Fsetup",1,"https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard","https:\u002F\u002Fgithub.com\u002Fstefans71","2026-04-20 07:23:08",{"source":8,"skillName":5,"commands":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add stefans71\u002FFrontierBoard --skill setup",{"tool":46,"command":47},"bunx","bunx skills add stefans71\u002FFrontierBoard --skill setup",{"tool":49,"command":50},"pnpm","pnpm dlx skills add stefans71\u002FFrontierBoard --skill setup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsetup\u002FSKILL.md",true,[54,60,64,68,72,76],{"path":55,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":58,"sourceHtmlUrl":59},"references\u002Fbuild-tooling.md","REFERENCE","参考文档",9761,"https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fcpp-pro\u002Freferences\u002Fbuild-tooling.md",{"path":61,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":62,"sourceHtmlUrl":63},"references\u002Fconcurrency.md",10918,"https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fcpp-pro\u002Freferences\u002Fconcurrency.md",{"path":65,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Fmemory-performance.md",9104,"https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fcpp-pro\u002Freferences\u002Fmemory-performance.md",{"path":69,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Fmodern-cpp.md",6565,"https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fcpp-pro\u002Freferences\u002Fmodern-cpp.md",{"path":73,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Ftemplates.md",7908,"https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fcpp-pro\u002Freferences\u002Ftemplates.md",{"path":77,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":78,"sourceHtmlUrl":79},"resources\u002Fimplementation-playbook.md",1255,"https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcopilot\u002Fcpp-pro\u002Fresources\u002Fimplementation-playbook.md",[81,92,109,119,137,153],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":28},"01M6CW5BKYDY1PC8YPCHNZN1V5","teardown","Remove a FrontierBoard installation. Run when the user types \u002Fteardown or asks to uninstall, remove, or clean up the board.","https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fteardown\u002FSKILL.md",[],[83,88,19,23,24,89,26,90,91],"uninstall","remove","clean","installation",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":103,"publishedAt":28},"01M6CW599G8TXF87JTYRPHRKJ7","smoke-test","Validate a board installation works end-to-end. Run when the user types \u002Fsmoke-test or asks to test, validate, or verify the board setup.","https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsmoke-test\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[104,105,106,107,5,19,108,23,24,91],"smoke test","smoke","test","validate","verify",{"skillNo":110,"name":19,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":28},"01M6CW5435Q93Y2Q1427PSDWMA","Run the board agents and synthesise their reports. Run when the user types \u002Frun, asks to run the board, or after \u002Fbrief when the user confirms they're ready to go.","https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frun\u002FSKILL.md",[],[19,24,115,116,117,23,118],"brief","ready","reports","go",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":28},"01M6CW518M6QPGGW3DAT6JNEZQ","review-release","Review a GitHub repo or release using the board. Use when the user types \u002Freview-release, asks to \"review a release\", \"check if this is safe to install\", \"look at the latest version of [repo]\", wants to \"try installing it and see what breaks\", or any variant of reviewing an external GitHub project before contributing to it or installing it.","https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview-release\u002FSKILL.md",[],[126,127,128,129,130,131,132,133,23,24,25,134,135,136],"review release","release","review","repo","safe","github","contributing","check","use","version","look",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":146,"publishedAt":28},"01M6CW4YSSPY6FXCR6DMZWF9XX","project-tests","Generate test specs (Skeptic writes) and verify test code (Skeptic reviews). Two modes — \u002Fproject tests for specs, \u002Fproject tests --verify for code review.","https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fproject\u002Ftests\u002FSKILL.md",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000007","代码审查",[147,148,149,108,150,151,128,152,106],"project tests","generate","code","skeptic","verify test","code review",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":28},"01M6CW4WYSM8Z6SF2TEH4QSF8J","project-status","Show project lifecycle dashboard. Run when the user types \u002Fproject status or asks about project progress.","https:\u002F\u002Fgithub.com\u002Fstefans71\u002FFrontierBoard\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fproject\u002Fstatus\u002FSKILL.md",[],[160,161,24,162,19,163,164],"status","project status","lifecycle","show","dashboard"]