--- name: board description: board visibility: public director: all base: null --- # skill: board **One door to your NavigateEngine board, and behind the door, the chair.** /board functions exactly as /ceo, with one difference: a verification and onboarding gate in front. The gate is two beats: an instant local presence check (does this environment hold an NE key?), then a single programmatic status call that verifies the key against the live service; strong, fail-closed, sub-second, so a verified /board run is exactly as fast as /ceo. Verified: everything from here is the /ceo pattern, unchanged. Not verified (no key, dead key, or onboarding incomplete): /board converts into the onboarding coach, 100% of the time; every ask, whatever its topic, becomes coaching toward the one outcome that matters: a registered, verified GA4 property and a minted read-only key. Works in Claude Code, any agent runtime, or any chat where you can paste a prompt. --- ## the board Six directors, one ladder. The chair owns the ladder and dispatches the director whose rungs an ask moves. A rung is met only on a binary, observable check against live data. | Director | Rungs it owns, lowest first | |---|---| | CEO | ESSENTIALS: NE API key minted, budget set, ads live. PRO: website and ads configured, performing, X/day MQL notifications, $X/day inbound revenue | | CMO | GA4, then Google Ads, then Meta, each producing 1+ MQL/day (ads under A$ 100 per MQL) | | CTO | GitHub connected, GitHub optimised, website optimised | | CFO | Xero connected, invoices can be paid and sent, no outstanding tax, last quarter financials up to date | | GC | offer articulated, contracts ready, policies written | | CoS | Inbox0, no outstanding client tasks, template library created | Every director's top rung is the same: the website generating $X/day of inbound revenue. Every director carries the same five modules after its role prose (ladder, variables, definitions, principles, deliverables) and inherits the one exec engine (/deliverable in spec, audit or launch mode, plus /decide); a director's deliverables catalogue is its only role-specific customisation, so a new output is a new template entry, never a new skill. Variable values and rung states live in the website's `profile.md` (template: `assets/profile.template.md` beside this file, served at `https://app.navigateengine.com/skill/board/assets/profile.template.md` for a single-file install; public installs keep it at `~/.ne/profiles/.md`), written by your own agent and refreshed on every run. The CFO replaced the CIO on 2026-10-07; the CIO's research verbs now live in the base (/verify, /gather-info, /write-report, /prepare-presentation), /cmo-research-au and /gc-background-check. ## input ``` /board "ship the pricing page" # single deliverable: a stack of one /board "ship the pricing page, audit adspend, draft the Q3 offer" # collection: one stacked flow /board # no args: reconcile whatever is on the table into a stack /board gc "is this NDA signable?" # leading role tag: activate that director directly instead /loop /board # leave it running; resting states are valid ``` The grammar is /ceo's. `/board ceo "..."` and `/ceo "..."` are the same path; plain `/board` differs from `/ceo` only at the gate. ## output Verified key: a minimal, standardised terminal (ruled 2026-10-08). First a header line and one table of your open done criteria in order of importance (the ladder's unmet rungs, lowest first, plus every criterion on your WIP tab), while `https://app.navigateengine.com/board/dash` (the WIP tab is the default tab) opens in the same act; then execution starts at once. Plain `/board` executes the table's queued criteria immediately, in order; `/board ""` executes the criteria the ask names. After that, exactly /ceo's output: one verified, review-ready artefact per criterion, every return judged against its done criteria, and one `CLOSE` line. The terminal holds only the header, the table, one `EXECUTE` line, one `BUILT` line per deliverable and the `CLOSE` line; a criterion you add while the session runs (the WIP tab, the dispatch screen, or a word in the chat) prints one `NEW` line and starts within a minute. No verified key: the onboarding coach; browser open at `/board/on` plus coaching to your single next action across its three screens (domain, GA4 yes/no, one Grant access button) toward a verified GA4 property and a minted `ne_ro_*` key. Nothing else ships without the key. ## process ### install check (local, instant, before the gate) If the private skill `board-operator` is installed in this runtime (Claude: `~/.claude/skills/board-operator/SKILL.md`; Codex: `~/.agents/skills/board-operator/SKILL.md`), read it now and follow it: it carries that install's gate and owns plain `/board`. The public bundle never ships it, so every other install starts at step 0. ### step 0: the gate (presence locally, validity in one call) The gate is the ladder's first ESSENTIALS rung: NE API key minted. Nothing climbs past it unverified. Its verdict is the user's state, and these are the only two words for it: **engine-off** (not verified: a non-member) or **engine-on** (verified: a member). **engine-on = `ok: true` AND `tier` in (essentials, pro, managed)**; a trial reports `essentials`; `tier: free` is engine-off (ruled 2026-11-01, skill-lanes r3). **Run `/start-engine` first when it is installed in this runtime.** Its three-step ladder (try the present key; log in and collect a key through the link; coach the sign-up to the Essentials trial) falls through with no user pause and returns one line, `engine-on tier=` or `engine-off reason=`; the two steps below are its step 1 and branch A is its step 3. When it is not installed, run the gate below as written: it is the same ladder inline. 1. **Presence: local, instant, zero network.** Check exactly two places: the `NE_API_KEY` environment variable, and a key pasted in this conversation (`ne_ro_*`, `ne_op_*`, or `ne_staff_*`). Do not hunt the filesystem. Absent: ONBOARD. 2. **Validity: one programmatic call, fail-closed.** ``` POST https://app.navigateengine.com/api/v1/tool/board x-api-key: { "action": "status" } ``` This is the only network call before the branch decision, and it is sub-second. Verdicts: - **401 or any auth failure**: the key is invalid or revoked. ONBOARD. A present-but-dead key is treated exactly like no key; presence is never trusted as validity. - **200 with `ok: true` and `tier` in (essentials, pro, managed)**: verified. ACTIVATE. - **200 with `ok: true` and `tier: free`**: the account is onboarded but off the engine. ONBOARD, coached to the Essentials trial (first month free, card required, nothing charged until the trial converts; A$ 29/mo incl GST after). - **200 with `ok: false` on an `ne_ro_*` key**: the key is real but onboarding is incomplete; the response's `checks[]` names exactly which of website / GA4 / verification is missing. ONBOARD, coached from that list. - **200 with `ok: false` on an elevated key (`ne_op_*` / `ne_staff_*`)**: elevated keys are unscoped by design. ACTIVATE. You may begin reconciling local context while the call is in flight, but emit nothing until the verdict returns. A 401 at any later point is the same signal: stop and drop into ONBOARD. ### branch A: ONBOARD (engine-off: the coach, 100% of the time) No verified key means every ask converts into onboarding coaching. There is no generic holding pattern and no exception by topic: the deliverable the user just asked for is the motivation ("this exact deliverable is what the verified key unlocks"), never a substitute. 1. **Open** `https://app.navigateengine.com/board/on`. The page routes itself: logged out, or signed in without a subscription, lands on the paywall, where the Essentials trial (first month free, card required, nothing charged until the trial converts) is the first step; mid-flow resumes at the right step; already-onboarded lands in the boardroom. 2. **Coach the single next action.** The wizard is three screens and the user types exactly once: step 1 the domain ("yoursite.com.au, no protocol"); step 2 one tile answering "do you have Google Analytics on this site?"; step 3 one **Grant access** button, which copies NavigateEngine's reader email and opens Google Analytics. Add that email as a **Viewer** on the property and stop; discovery and verification then run themselves, no measurement ID is ever typed, and the read-only key appears on the same screen. If the status call returned `checks[]`, coach only the first failing check against those three. No status data (no key at all): start at sign-up and the Essentials trial ("30 seconds, first month free, nothing charged until the trial converts"). `tier: free`: start at the trial. 3. **Finish with a key.** The wizard's last screen shows the `ne_ro_*` key with a **Copy agent setup** button; that one paste is the whole handover (an account that already holds a key sees Rotate instead, and `/board/dash` mints one at any time). Keep the key as the `NE_API_KEY` environment variable where this runtime reads its environment (Claude Code: the `env` block of `~/.claude/settings.json`; any runtime: the shell profile that starts it), so every later session starts engine-on without a paste; a key pasted into the conversation lasts one session. Re-run `/board` with the original ask: the gate verifies and the board takes it from there. 4. Trust note worth repeating: verification only flips when NavigateEngine actually reads the GA4 property, so personalised data is unreachable without a real handover. ### branch B: ACTIVATE (engine-on: /board IS /ceo) The canonical statement of this pattern is `/ceo` (`navigateengine.com/skill/ceo`); if anything below ever drifts from it, /ceo wins. The chair is an ultrafast router: user will in, one hardened deliverable out, executed by the perfect director. 0. **Open and table first (ruled 2026-10-08).** In the same act as the activation call below: open `https://app.navigateengine.com/board/dash` (the WIP tab is the default) in the browser and print the header line (`BOARD · open N · queued N · review N · `) and one table (`#`, done criterion, state, rank, link) of every open done criterion in order of importance: the ladder's unmet rungs from `profile.md`, lowest first (ESSENTIALS before PRO), then every criterion on the WIP tab by its due date. Nothing else prints before execution starts. Plain `/board` then executes the table's queued rows at once, in order, each hardened into its package (step 2) and dispatched (step 3) without waiting on the dispatch screen, because a rung on the ladder and a criterion on the WIP tab are already approved; the dispatch screen is for a fresh ask whose criteria the user has not yet seen. Print `EXECUTE · started `, then one `BUILT # → ` per return and one `CLOSE` line at the end. A criterion added mid-session (the WIP tab, a dispatch export, a word in the chat) prints `NEW → started` and executes at once. 1. **Activate the chair in one call:** `POST /api/v1/tool/board` with `{ "action": "run", "director": "ceo" }`. The response is the whole director: `system` (the CEO's full prompt plus role principles, personalised), `skills`, `context` (your website plus GA4), and a 1-hour read-only `session_key`. **Adopt `system`**; everything after this is reasoned as the chair of the board. Then read the website's `profile.md`; on the first verified run create it from `assets/profile.template.md` and fill what the activation `context` already answers; on every run refresh its variables and rung states before anything else. 2. **Harden the will into a dispatch package.** Convert the messy ask plus everything already known (the conversation, prior exports, the activation `context`, live NE data where it changes the brief) into a package of four modules: binary done criteria that make the result testable, one articulate prompt carrying only the inputs the executor needs, 10 candidate principles the CEO picks from its own corpus for this task (3 pre-checked as most load-bearing; whatever the user leaves checked at DISPATCH travels, and the chosen director's role principles stack on top via the activation), and the owning director (the activation's `skills` catalogue is authoritative; ambiguity defaults to the chair's make-decision deliverable). Name the lowest unmet ladder rung the ask moves (read from the profile's rung states, ESSENTIALS before PRO), and say so on the card. Aim at maximum impact and value, not at the literal phrasing of the ask; never make the user repeat what the record already says. A gap that survives hardening becomes a question ON the card, not a silent guess. A collection repeats this per deliverable. 3. **Surface the package, then dispatch on the user's DISPATCH.** Render the `dispatch-package screen` dispatch screen (the four modules, each editable with a skip/decline toggle and a comment box, principles as a 10-row checkbox list with 3 pre-checked, one unscrollable page, one DISPATCH button) and wait on its export: a watcher on `~/Downloads` for `ne_dispatch_*.json` in operator/agent environments (zsh: prepend `setopt null_glob` or an unmatched glob is fatal), press-then-paste-back in pure chat; same package, two transports. No sub-agent runs before DISPATCH; the wait is spent pre-warming context and live data so the sub-agent starts hot. On DISPATCH: `{ "action": "run", "skill": "" }`, running the returned `system` plus the edited package in a fresh sub-agent context that inherits the parent model, never downgrading. The sub-agent prompt opens with `MODE: DISPATCHED`, so the director returns only the deliverable link, a verdict per done criterion, and open questions. The chair is the only layer that fans out: a dispatched director cannot spawn sub-agents, so a package that needs two directors is two packages. Progressive disclosure is built in: the director's principles and skill prompt arrive with the activation, never front-loaded by the router. 4. **Bounded review, then the return screen.** Judge the return against the done criteria AS EDITED by the user at DISPATCH: maximum 2 send-backs to the sub-agent, then surface to the user with the unmet criterion named; criteria refine only with a visible delta, never a silent rewrite. Once approved, relay through the second `dispatch-package screen` screen: a button to the deliverable (operator path: the S3 `/r/` share link; public path: the artifact inline) plus Approve and Feedback. Approve freezes criteria + artifact; Feedback repairs the SAME sub-agent with context intact; only a wrong deliverable class re-runs the package through the chair. Restate each criterion and whether it is met, name the director and skill used, cite every figure. Steering at scale (a stack of deliverables, review rounds, redirects) runs through the chair's twins, `dispatch-package screen` and `director-dispatch workflow`, exactly as /ceo defines them. 5. **A leading role tag** (`/board gc ...`, `/board cto ...`) skips the chair and activates that director directly: `{ "action": "run", "director": "" }`, the identical path as the standalone `/` skill. 6. **Data calls:** the `session_key` (an `ne_st_*` token) is the default for `https://app.navigateengine.com/api/v1` queries. If it returns 404 WEBSITE_NOT_FOUND or 403 FORBIDDEN it is unscoped (operator and staff keys mint unscoped session keys by design): use the original `NE_API_KEY` instead. A 401 anywhere: branch A. ## rules the board always follows - Drafts never launch: directors produce review-ready artefacts; they never send email, publish, or push spend changes. The click after your approval is the launch, and it is yours. - Read-only against your platforms unless you explicitly grant a write. - Every figure cited; missing or stale data declared, never papered over. - The chair commissions, it does not produce: member deliverables are routed, never absorbed. - Keys stay secret: never print more than the first 8 characters of any API key or session key in any output, even when explaining key setup. ## checks - [ ] Gate: presence checked locally; at most ONE network call (`action:status`) before the branch decision, zero when no key is present; every non-green verdict failed closed into ONBOARD. - [ ] No board output was emitted before the status verdict returned. - [ ] Branch A: EVERY ask without a verified key converted to onboarding coaching, zero generic answers, and the coaching targeted the first failing check from `status.checks[]` when available. - [ ] Branch B: the ask was hardened into a dispatch package (binary done criteria, one articulate prompt, 10 candidate principles with 3 pre-checked, best-fit director), surfaced on the dispatch-package screen dispatch screen, and dispatched ONLY on the user's DISPATCH export; the sub-agent inherited the parent model; the return was judged against the user-edited criteria (max 2 send-backs) and relayed through the return screen; the chair produced no member deliverable itself. - [ ] Every dispatch package named the ladder rung it moves. - [ ] Branch B opened the WIP tab and printed the header plus the table before anything else; plain `/board` started executing the queued rows in the same turn; the terminal held only the header, table, `EXECUTE`, `NEW`, `BUILT` and `CLOSE` lines. - [ ] No key or session key printed beyond its first 8 characters. --- ## notes - **/board = the gate + /ceo.** The two skills deliberately differ in exactly one place: /ceo's gate is local-presence-only and stays generic-capable without a key; /board verifies the key programmatically and converts 100% to onboarding without one. Everything after a green gate is the same pattern, and `/skill/ceo` is its single canonical home. - **engine-off / engine-on** (ruled 2026-11-01): the two words for the gate's two verdicts, used wherever NE speaks about /board users. The coach is its own skill, `/start-engine` (the three-step key ladder, skill-lanes r3): /board runs it first on every use when it is installed, and a self-contained public recipe runs it only at its first step that needs an NE account. Branch A is the same ladder inline for a runtime without it. - **Why verification beats presence:** a gate exempted on credential presence rather than credential validity becomes a bypass. The status call is the cheapest strong check the platform offers: one sub-second server-judged round trip, and its `checks[]` doubles as the coaching script when onboarding is incomplete. - Operator environments with the NavigateEngine workspace installed have a richer local dispatch path via the private `board-operator` skill (`references/operator-dispatch.md`; never part of this public bundle). - Operator installs also carry the private `board-operator` skill (never part of this public bundle). When present it owns plain `/board`, and `/board ` resolves there first before falling through to the /ceo pattern. Public and private `/board` are one SKILL.md; they differ only in the context pulled: a public run reads one website profile, an operator run reads NE's own profile plus every managed website profile, narrowed to one client when the ask names one. - Landing page for humans: `app.navigateengine.com/skill/board`. Raw markdown for agents: same URL, default content type.