List all boards (projects) under the configured boards folder.

Return the FeatureBoard board UI as a self-contained HTML document, ready to render as a Cowork artifact. This is THE way to satisfy any natural-language request to see the board — "open/show the board", "show the featureboard", "what's on my plate", "how are we looking", "give me a status", "show velocity/analytics". Do NOT hand-write your own board: take the returned html, write it to a file, and pass it to create_artifact (use artifact id "featureboard-board"; if a board artifact is already open, reuse it via update_artifact instead of creating a duplicate). Use the mcp_tools array in this response VERBATIM as the artifact's mcp_tools (do not hand-pick tools from memory — the board's buttons and analytics dashboard call back into exactly these tools, and any you omit will fail with "not in this artifact's mcp_tools allowlist").

Return the Research RAG Explorer UI as a self-contained HTML document, ready to render as a Cowork artifact — the visual front door to the local research RAG (FBMCPF-263/264). It lets the user browse a board's kb/ docs (including per-ticket research briefs), add new docs (add_kb_doc), and query the BM25 index (rag_search over kb + repo docs/ + Done-ticket summaries, with a search_kb fallback). Use this for natural-language asks like "show/open the RAG", "what's in the knowledge base", "let me query the research index". Do NOT hand-write your own explorer: take the returned html, write it to a file, and pass it to create_artifact (use artifact id "featureboard-rag-explorer"; if one is already open, reuse it via update_artifact). Use the mcp_tools array in this response VERBATIM as the artifact's mcp_tools — any tool you omit fails with "not in this artifact's mcp_tools allowlist".

Set — and LOCK — how much rigor a project's work is held to. Levels: "prototype" (move fast, minimal ceremony), "standard" (normal professional loop), "polished" (research-first: competitor teardowns, layout/IA of comparable apps, white papers, UX/UI heuristics, automation-everywhere, high test rigor + self-review). The resolved standard is injected into every work packet (packet.standard + extra definition-of-done items) and bends research-on-intake (polished forces it on with expanded questions; prototype skips it). mandate is the project's own free-text bar, carried verbatim into packets. INFERENCE RULE: when a project's standard is unset/unlocked, infer the level from the user's cues ONCE (pass source:"inferred") and lock it. A locked standard is settled — this tool refuses to change it unless force:true, which you pass ONLY when the user explicitly asks to change the standard. Account-wide default for unset projects: set_global_config defaultStandard.

FBMCPF-317: the churn loop's answer to an empty queue — call this when next_task returns nothing (or the user asks to 'keep improving'). Returns ordered, executable passes that encode the owner's steering pattern: (1) REVIEW the Done tickets completed since the last steering pass — adversarial defect hunt over their diffs (get_ticket_diff semantic:true, churn_reconcile), file log_bug for real defects; (2) TIGHTEN — triage the attached cleanup/strengthen findings into tickets or dismissals; (3) RESEARCH toward the project's goal at its locked standard (polished standards carry the competitor/layout/whitepaper/UX question set) grounded in rag_search prior art, then add_feature the next wave; (4) RESUME next_task. Review candidates are claimed in steering.json so the same work is never re-reviewed. If actionable is false twice in a row, report to the user and stop — do not spin. Pass dryRun:true to preview without claiming.

FBMCPF-319: read-only observability into the steering loop for a project — WITHOUT running or mutating a pass (unlike steer_project). Returns the persisted steering.json state (lastSteeringAt, everSteered, how many Done tickets have been claimed/reviewed + the recent reviewed ids, and goalOnlyStreak — the consecutive goal-only passes that gate the auto-stop) plus a live snapshot: goal/goalMissing, open-ticket count, how many Done tickets are still unreviewed, and the tickets filed since the last steering pass (a proxy for what the last pass produced). Use it to answer 'where is steering at?' without kicking off a new wave.

Create a new board folder with empty featurelist.md and buglist.md. Returns the derived ticket prefix.

List features and/or bugs on a board, most-recent first. Filter by type, status, product, label, or search. Returns a compact one-line-per-ticket view by default and is paginated (limit/offset) so large boards don't blow the context budget — set compact:false for full details, and raise limit or page with offset to see more. Use get_metrics for a pure overview.

Get the full details of a single task by its ticket ID (e.g. FBF-12).

Add a feature to a board's featurelist.md. Returns the new ticket (FBF-###).

Log a bug to a board's buglist.md. Returns the new ticket (FBB-###).

Add several features at once. Use this after brainstorming: you generate the ideas, this persists them. Returns the created tickets.

Import a backlog from raw text into a board. Accepts a markdown checklist (- [ ] Title: desc), CSV (with a header row: title, description, product, priority, type, due, labels, status), or a JSON array/object ({features:[…], bugs:[…]} or a flat array). Format is auto-detected. Set dryRun to preview the parsed tasks without writing them.

Parse unstructured feedback (user notes, review comments, bug reports) into candidate tickets, each with a suggested type (feature/bug), product, and priority from deterministic keyword heuristics only — no model calls. DRY-RUN BY DEFAULT (apply:false, the default): returns the structured candidate list for you to review/edit; creates NOTHING. Always dry-run first. When ready, call again with apply:true to bulk-create the candidates (optionally pass back an edited candidates array — e.g. from the dry-run response with corrected type/product/priority/title — instead of re-parsing feedback).

Turn a user request into board items in one step. Optionally creates the project, then adds the features and bugs you list. Use this as the FIRST step when starting a substantive request, then work the tickets one at a time. Returns all created tickets. When the project config etaHints is on (default), each created ticket carries an eta estimate and the response carries a totalEta roll-up (FBMCPF-269).

Return the next open ticket to work (status Todo or In Progress), so you can pull work one item at a time. Prefers In Progress, then earliest due date, then oldest ticket. Returns null when the board is clear. When the project config etaHints is on (default), also carries an eta estimate for the returned ticket (FBMCPF-269).

The PLURAL of next_task: return the whole dispatchable set at once, already partitioned into file-disjoint lanes, so every sub-agent lane can be filled in ONE call instead of N sequential next_task round-trips. Use this — not repeated next_task — whenever you are working a board with more than one open ticket. lanes[] are mutually file-disjoint and safe to run as CONCURRENT sub-agents; tickets WITHIN a lane share files and must run serially in the order given. sequential[] holds orchestrator-only tickets (fable) that run inline. Each ticket carries its own dispatch block ({subAgent, model, cap, parallelizable, instruction}) so no second lookup is needed. Pass occupied with the tickets your sub-agents are still working and call it again to REFILL just the lanes that freed up — lanes containing a running ticket come back under busyLanes and are never re-served. stopCondition is the authority on whether the loop is over: an empty wave is a steer_project event, NOT a stop.

Update fields on an existing task. Only provided fields change.

Create (or update) a named sprint on a board, with optional start/end dates and a one-line goal. The registry is persisted in the project config; tickets join a sprint via a sprint: label (see assign_sprint), so label-only sprints written by the board UI keep working.

List a board's sprints (config registry plus any label-only sprints) with progress per sprint (total/done/inProgress/todo, complete flag) and the count of open backlog tickets in no sprint.

Move one or more tickets into a sprint — sets the sprint: label, replacing any existing sprint label. Pass sprint: null to send tickets back to the backlog.

Close a sprint and generate four audience-specific close-out reports (marketing, sales, technical, executive) from its tickets, work log, and metrics (velocity, tokens, $ cost, ADRs touched, CRM ticket links). Refuses to close while the sprint still has open (non-Done) tickets unless force:true. Writes reports//.md pads under the project and returns their paths, a metric summary, and a per-audience LLM prompt (packet + brief) for richer draft copy. Posts a Slack summary when the project has Slack configured (never fails the close on a Slack error). Also handles the sprint's remaining open tickets per rolloverMode (FBMCPF-197): 'review' (default) returns a categorized rollover plan without moving anything; 'auto' retags P0/P1 tickets into nextSprint (or flags them rollover-pending if no nextSprint given), labels P2/P3 tickets rollover-candidate for human review, and drops the sprint label from P4+/unprioritized tickets back to the backlog; 'off' skips rollover handling entirely. The result's existing shape is unchanged — rollover info is added as a rollover section.

Read the close-out reports written by close_sprint. With no sprint: list sprints that have reports. With a sprint but no audience: the manifest + which audiences exist. With sprint + audience (marketing|sales|technical|executive): that report's markdown.

One-command incubator → dedicated-repo graduation (lifecycle "Option C"). Copies the project's CODE out to targetPath, EXCLUDING pad files (featurelist/buglist/scratchpad/etc) and junk (node_modules, .git, *.log, .zip, tmp_, ...), then repoints codeLocation, sets stage=graduated and gitTargets.codeRepo, and records the move in the scratchpad. The pad STAYS in the boards dir — it is only read, never modified or deleted — and the target repo additionally gets a read-only snapshot mirror of the pad files under .featureboard/. When commit is on and git is available the copied code + mirror are git-init'd (if needed) and committed; git absence/failure is tolerated as a warning. DRY-RUN BY DEFAULT: apply is false unless you pass apply:true, so the first call returns the plan (source, target, files, skipped) without touching the filesystem. CADSolver was the manual prototype.

Per-ticket token estimates for all open tickets, derived from the board's own history: a cap: label wins, then the median actual spend of Done tickets in the same product, then the board median, then a documented default. Each estimate carries its basis, confidence, spend so far, and a suggested model (model: label or heuristic).

Map a token budget onto the priority-ordered open queue BEFORE spending it: assigns tickets to days (greedy load-balance), draws the cutline where the budget runs out, and reports the Opus/Sonnet split with blended cost units. Optionally restrict to one sprint. When account-wide planLimits is captured (set_global_config), also returns an additive blendPlan (FBMCPF-279): days to reset, the fable/non-fable percent-per-day pace that converges both weekly meters, and concrete parallel-wave suggestions sized from the open backlog's effort and the board's historical tokens-per-ticket. The token budgeting is unchanged. Read-only — apply model choices with update_task labels if you want them stuck.

Which model tier should actually run your tickets, measured instead of guessed (FBMCPF-351). Scores every Done ticket from data the board already keeps — work-log tokens + model, ticket_events status transitions, and bugs filed with ref: — and reports, per tier: closed tickets, median tokens, median $ cost, median cycle time (In Progress -> Done), rework rate (reopened, or a follow-up bug filed after close-out), and the headline COST PER CLEAN TICKET (dollars per ticket that stayed closed). Cross-cut by effort:low/medium/high so the answer is 'which tier for THIS size of ticket', not one global average. A tier with fewer than minSamples closed tickets gets NO verdict — the readout says 'insufficient data' with the sample count rather than guessing. Advice only: it never writes a model:/cap: label, so intake stays deterministic. Pair with plan_budget (what the queue will cost) and daily_plan (what to run today).

Plan TODAY: pick the day's slice of the priority queue (default budget 5M logged tokens ≈ one day of a 25M week), assign each ticket a model from the roster (fable=orchestration/design, opus=architecture/invariants, sonnet=standard implementation, haiku=mechanical docs/copy) and an effort level (low/medium/high). apply:true writes model:/effort: labels onto the tickets. Returns dispatch groups: haiku/sonnet/opus tickets safe to run as parallel sub-agents, fable inline in the orchestrator (see server/routing.js). Pair with the daily_plan prompt to execute.

Compare board-workflow vs chat-workflow trials using label conventions: experiment:board / experiment:chat marks a ticket's arm, and an optional pair: label ties a board trial to its chat counterpart. Returns every labeled trial (tokens and $ cost from the work log, additions/deletions, wall-clock days, rework = linked bugs within 7 days of completion), per-arm medians/totals (including totalCost), matched pairs with a token ratio, and a one-line summary.

Export a board's tasks to json, csv, or markdown for use outside FeatureBoard (e.g. sharing with a PM tool). Round-trips through import_tasks. Read-only.

Flat-file export of analytics for external BI/spreadsheet use, mirroring export_tasks: what:'worklog' exports the per-event work log (date, ticket, model, tokens, additions/deletions); what:'completions' exports status counts + completions-by-date. Formats: json or csv. Read-only.

Write a ticket's refined requirements pad (requirements/.md): intent, assumptions, acceptance criteria, and open questions. Overwrites any existing pad. Once set, the ticket's work packet carries these requirements and its definition-of-done becomes the acceptance criteria. Draft the content first (see the refine prompt), then persist it here.

Read a ticket's requirements pad as structured intent / assumptions / acceptance criteria (with done flags) / open questions, plus the raw markdown. Returns null when no pad exists.

Toggle the checkbox on acceptance criterion #index (1-based) of a ticket's requirements pad. Hand-added sections are preserved. done defaults to true.

Post a message to THIS project's user-configured Slack incoming webhook. This is deliberate outbound egress: the board is otherwise local-only, and this sends to the https://hooks.slack.com/... URL the user set in project config (slackWebhook) — nowhere else. No-ops with sent:false when Slack is unconfigured or the event isn't in the project's slackEvents allow-list; failures return a warning and never throw.

Append a new ADR to a project's decision log (decisions.md): context, decision, consequences, and any tickets it relates to. Auto-numbers ADR-. Append-only — never rewrites prior ADRs. Relevant ADRs surface automatically in ticket work packets.

Read a project's ADR log as structured entries: id, title, date, context, decision, consequences, tickets. Pass ticket to filter to decisions relevant to that ticket.

Write a ticket's handoff note (handoffs/.md): free-form markdown for whatever a successor ticket needs to know. Overwrites any existing note. Surfaces automatically in the work packets of tickets blockedBy this one; read it via get_work_packet.

Full audit timeline for one ticket: recorded field-change events (status moves, priority moves, label/sprint changes, due-date edits — captured automatically by set_status/update_task/assign_sprint) merged in chronological order with that ticket's work-log entries (tokens/additions/deletions per work session). Tolerates tickets with no recorded events yet (pre-FBMCPF-142 tickets still show their work-log history).

Unified compliance/traceability export: for one ticket or the whole board, merges the existing audit primitives into a single report — field-change events (status/priority/label moves), work-log sessions, sub-agent dispatch records, requirements pads with acceptance-criteria state, review comments with resolution, decision-log entries, correlated commits (recorded-first with git log --grep fallback), and drift-harness scores. Includes a board-level compliance summary: status counts, acceptance coverage, unresolved reviews, work totals, drift flags, and Done tickets with no correlated commit. Formats: json (structured), markdown (human-readable dossier), csv (flat chronological trail rows for BI). Read-only.

Per-ticket worked spans for the board's piano-roll Timeline view, in one read pass. For every ticket returns: created date, startedAt (first status→In Progress audit event, falling back to its earliest work-log entry, then createdDate — startedSource says which), completedAt (completionDate or last status→Done event), lastActivity, status/product/type/sprint/priority/model for lane grouping and colour, cumulative tokens/additions/deletions/cost, and per-day work rollups (days[]) for clip intensity. Also returns a board-wide byDate[] rollup (tokens/additions/deletions/cost per day) for the datastream overlay strip. Optional from/to (ISO date or datetime) keep only spans whose worked window overlaps that range. Read-only.

Capture the code changes made for a ticket: find commits in the project's code repo (codeLocation / gitTargets.codeRepo) whose message mentions the ticket id and return, per commit, a summary (hash/author/date/subject) plus a size-capped unified diff (git show). Read-only — never writes or fetches. context sets the unified context-line count; maxBytes caps the total diff bytes returned (over-cap diffs are truncated with a notice, later commits omitted). Returns a warning (not an error) when the project has no codeLocation, the path is not a git repo, or no commits mention the ticket. Pass semantic:true to also get a deterministic semantic view (no LLM): formatting-only hunks stripped, files ordered core → tests → docs/config, mechanical renames flagged, plus a ready-to-use review-summary prompt — assistive, verify against the raw diff.

Attach a PR-style review comment to a ticket (optionally anchored to a file and line). Unresolved review comments surface in the ticket's next work packet (get_work_packet.reviewComments) so the next agent acts on the feedback, and — when the ticket is in Review — a comment sends it back into next_task's queue. Also recorded on the ticket's audit history.

List review comments for a project, optionally scoped to one ticket, with their resolved state. Set includeResolved:false to see only open feedback.

Mark a review comment resolved by its id (RC-). Idempotent. Once every comment on a ticket is resolved it stops surfacing in the work packet and (if in Review) leaves next_task's queue.

Find ticket ids that appear more than once on a board (legacy data can carry collisions like FBF-491 twice), and optionally renumber the later occurrences to fresh ids. Dry-run by default; pass apply:true to write. Note: updates to a duplicated id are refused until the board is repaired.

Move a task between Todo / In Progress / Review / Done. Review sits between In Progress and Done when requireReview is on; approve:true overrides the gate. When moving to Done you can also record structured completion metadata (model, tokens, additions, deletions) — these are written to the work log and roll up into velocity/metrics. For graduated projects, moving to Done also refreshes the pad snapshot in /.featureboard/ (best-effort; a mirror failure never blocks the status change). If git is enabled for the project and Done is reached with no commit referencing the ticket (recorded via commit_feature, or found via git log --grep), the response carries uncommitted:true + a commitReminder — or, when requireCommitOnDone is on, the move is refused outright (approve:true overrides).

Replace one feature with a set of linked subtasks. You provide the subtasks; this creates them (each linked to the parent) and deletes the parent. Returns the new tickets.

Relate two tickets. kind "linked" (default) sets ticket's linked issue to linkedIssue (e.g. link a bug to the feature it affects). kind "blocks" makes linkedIssue a blocker of ticket — the child ticket gains linkedIssue in its blockedBy list; edges that would close a dependency cycle are rejected.

Attach a file path or URL to a ticket (stored as [Attachments: ...] on the ticket line). Idempotent: attaching the same item twice is a no-op.

Detach a previously attached file path or URL from a ticket.

Permanently remove a task from its board.

Read-only deep-clean scan: finds likely-duplicate tickets (grouped by title similarity, each group nominating a keeper + removal candidates), stale/placeholder tickets (old Todo items, placeholder titles), open tickets missing a model:/cap: label (FBMCPF-159 intake orchestration guard — nothing should sit in the queue without a sub-model orchestration decision), and priority-scaled SLA breaches (FBMCPF-198: high-priority tickets stuck In Progress with no recent work-log activity → 'escalate'; tickets languishing in Todo → 'stale'; per-priority thresholds overridable via the slaThresholds config key). Returns a suggested removal set to feed prune_board. Never deletes — a good fit for a recurring Cowork scheduled task that surfaces breaches each morning.

Read-only deep-clean of the project's test/ dir: finds byte-identical duplicate test files, stale files whose filename ticket id is no longer on the board, and empty stub files (only TODO placeholder assertions). Returns a suggested removal set. Never deletes — companion to scan_board_cleanup.

Guarded cleanup: deletes ONLY the ticket ids you pass, and only when confirm is true (otherwise returns a dry-run preview of what would be deleted). Non-existent ids are reported, not fatal. Pair with scan_board_cleanup's suggestedRemovals.

Suppress a scan_board_cleanup finding from future scans WITHOUT deleting anything — for false positives or findings you've consciously accepted. Pass the finding's stable id (shown on each duplicate/stale/unlabeled/SLA finding) and an optional reason. Dismissals are append-only; future scans hide the finding and report dismissedCount. The id is a hash of the finding's type+ticket, so it keeps matching across rescans until that ticket changes category.

List files and folders under the project's codeLocation (optionally a subpath), with sizes and extensions. Skips vendor/build dirs (node_modules, .git, dist, …). depth controls how many levels to expand. Sandboxed to codeLocation.

Read a file under the project's codeLocation as UTF-8 text (size-capped; binary files are flagged, not dumped). Returns content + line count. Sandboxed to codeLocation (no path escape).

Given an oversized source file (see code_file_map's splitCandidates), return a structured, ready-to-execute refactor proposal: exported symbols clustered by name-prefix, proposed target modules, keep-original-as-barrel guidance, and a prompt to hand straight to the agent. Read-only — the server never edits code; Claude executes the split.

Recursively map the project's codeLocation: total file count + bytes, counts by extension, and the files that exceed the split thresholds (lines/bytes) as split candidates (worst first) — useful for spotting oversized modules to decompose. With symbols:true, also returns a per-file list of top-level exported functions/classes/consts for JS/TS files (regex-based, capped per file) — a lightweight symbol map for navigation.

Read-only snapshot: feature/bug counts by status, completions by date, and velocity from the work log (tokens, additions/deletions, active days, recent tokens, and $ cost by model — see project config "pricing" to override the default Anthropic API rates).

Append a dated narrative status update (Linear-style) to the project's updates.md pad — a lightweight health check-in that lives between the heavier sprint close-out reports. Takes a health flag (on-track | at-risk | off-track) and a free-text narrative. The latest update (and a staleness hint when it's more than 7 days old) is surfaced on get_metrics and get_health. When the project config voiceLint is on, the narrative is scored for AI-writing tells and the result is attached as voice (warn-only, never blocks the update).

Estimate when open work will complete by dividing the backlog by the board's observed throughput (tickets closed per active day). Walks the priority-ordered queue to give each open ticket a projected completion date, suggests a due date for tickets that don't have one, and flags tickets whose existing due date is likely to slip. Read-only — apply a suggestion with update_task if you want it stuck.

Read a board's settings: products, code location, agent model, prefixes, website, description, pricing overrides. Merges MCP-managed config over the legacy project_config.json.

Update a board's settings (only provided fields change). Writes to the MCP-managed config; never mutates legacy project_config.json. codeLocation points the code tools at the project's source repo; websiteLocation points the website tools (get_site/set_site/add_page/deploy_site/scaffold_site/...) at the project's SHIPPED site, which may live outside the pad in its own repo (absolute path to the assets dir) — leave it unset to keep the site under /site/. Also configures voiceLint/voiceLintMin/voiceProfile (AI-writing-tell self-checks on drafting tools) and the etaHints dispatch toggle.

Set the project's brand kit in one place — name, tagline, brand words, voice/tone, primary & accent colors, logo, and font — so every generated asset (media, website, campaigns) stays consistent. Stored on the board config; retrieve it with get_branding. By default also applies colors/font to the project website if one exists.

Return the project's brand kit — name, tagline, words, voice, colors, logo, font — plus a ready-to-inject generation instruction, a CSS :root cssVars snippet for web, and which fields are still missing. Call this before generating any branded asset to stay consistent.

Add a product to a board's product list (used for tagging tickets via [Product: …]).

Remove a product from a board's product list (existing ticket tags are left as-is).

Read a board's freeform scratchpad.md - a per-project notes surface for context, decisions, and reminders that Claude and the board share. Returns the raw markdown.

Overwrite a board's scratchpad.md with new content. Use append_scratchpad to add a note without replacing existing content.

Append a line or block to a board's scratchpad.md, preserving existing notes. Mention a ticket id (e.g. FBF-12) to have it surface in that ticket's work packet.

Write a markdown doc into a board's kb/ folder (a per-project knowledge base beyond the scratchpad): title + markdown body, stored as kb/.md. Calling again with the SAME title updates that doc in place; a different title that slugifies to the same filename gets a numeric suffix instead of clobbering the original. Docs are keyword-matched into work packets automatically via get_work_packet.

List a board's kb/ docs: slug, title, updatedAt, size, and a short excerpt of each (not the full body — use get_kb_doc for that).

Read one kb doc's full markdown content by slug (or title — it gets slugified). Returns null-ish (not found) when no such doc exists.

Keyword search across a board's kb doc titles + content, ranked (title hits weighted above content hits). Returns matches with a short excerpt around the first hit and the doc's path. This is the same matcher get_work_packet uses to inject relevant docs into a ticket's packet (kbMatches).

Capture ONE research finding into a ticket's durable research doc AS YOU GO (FBMCPF-333). Appends to the same kb doc get_work_packet auto-attaches downstream (research-), creating it on the first call and appending on later ones — so findings accrue in the always-indexed kb/ knowledge base instead of the ephemeral scratchpad. Prefer this over append_scratchpad for anything worth remembering across tickets: call it repeatedly during research rather than saving one brief only at the end.

Save a research source (paper, article, reference) into a board's sources/ library — one file per source, separate from the synthesized kb/ notes, stored under a citation header (title, source/author, url, ticket, tags) and indexed into the RAG (source/). THREE ways to supply the text, in priority order: (1) path= a local file — .pdf (optional pdf-parse dep), .html, or any text/markdown is read + extracted automatically; (2) url= a web page or PDF — fetched and extracted automatically (title/source auto-filled); (3) text= the raw text directly. With url/path, title/source are auto-detected (override by passing them). If a PDF is scanned or a page is JS-rendered, the tool returns { needsText: true, reason } — read it yourself and call again with text=. Calling again with the SAME title updates in place. Use this for the sources; use add_kb_doc / append_research for YOUR notes about them.

List a board's sources/ library: slug, title, source, url, linked ticket, tags, dates, size, and a short excerpt of each (not the full raw text — use get_source for that).

Read one source's full raw text + citation fields by slug (or title — it gets slugified). Returns null-ish (not found) when no such source exists.

Begin a drift-evaluation run over a board's Done tickets. mode 'sample' evaluates a seeded random subset (fast statistical estimate); mode 'full' evaluates every Done ticket. Returns a runId + the tickets to score. Then, for each ticket, compare its scope/description/DoD + work log against the actual code it touched (use get_work_packet and the project's codeLocation) and call drift_record with a 0–100 fidelity score; finish with drift_report. Use the evaluate_drift prompt to run the whole loop.

Record a 0–100 fidelity score for one ticket in a drift run (verdict is derived: >=80 aligned, 50–79 partial, <50 drift — or pass your own). Provide a short gap explaining any shortfall, and optionally the files you checked. Upserts by ticket.

Aggregate a drift run: per-ticket scores, mean fidelity, verdict counts, drift rate, and — for sampling — a 95% Wilson confidence interval on the true drift fraction extrapolated to the whole Done population. Lists the flagged (partial/drift) tickets worst-first with their gaps, and any pending (unscored) tickets.

One-click remediation across a run's flagged tickets: action 'file_bugs' files a linked, drift-labeled bug per gap; 'reopen' moves them back to Todo; 'relabel' adds a 'drift' label. verdicts selects the bands to act on (default ['drift']). Pass dryRun:true to preview. Records what it did on the run.

Append a work event to the board's work log: a summary plus optional tokens, additions/deletions, and model, tied to a ticket. Feeds velocity and health.

Read work-log entries, most-recent first. Optionally filter to one ticket. Returns entries plus a velocity rollup.

Live snapshot of the board's currently-running work: every In Progress ticket with elapsed time since it went In Progress (from the ticket_events.jsonl audit log, falling back to its earliest work-log entry or createdDate when there's no recorded status event), its last event (most recent audit event or work-log entry, whichever is newer) with age, token spend so far vs its cap: label and the resulting spend ratio, and a stalled flag (no event/work-log activity within stallMinutes, default 30). Also reports costSoFar and capCost in dollars (via project-config-overridable pricing; capCost is null when no model can be inferred for the ticket). Each ticket also carries lastDispatch ({worker, model, parallel, note, ageMinutes}, null if record_dispatch was never called for it) — who's actively working it, a sub-agent or the orchestrator — so the board can render an orchestration chip without a separate call. Sorted most-recently-active first, with a top-level summary (count, stalledCount, subAgentCount, parallelCount, totalSpend, totalCap, totalCostSoFar, totalCapCost, stalledTickets). Pairs with churn mode: a stalled ticket mid-churn usually means the agent is stuck or has gone quiet. Use it to see what's underway, who/what is running it, and catch stuck tickets.

Append a lightweight in-flight progress ping for a ticket a sub-agent is actively working: a phase/milestone note, and optionally the model, elapsed minutes, and tokens spent so far. Distinct from log_work (which records a completed unit of work at the end of a session) — heartbeats are informational pings emitted DURING a long (5-13min) dispatch, so get_agent_monitor and the board's live/stall banners have something to show besides a generic "multitasking" indicator until the sub-agent returns. Call it at a few natural milestones (e.g. "read the ticket + adjacent code", "wrote the fix", "tests passing, writing report") rather than on every tool call. Sub-agents may call this directly — it is informational only and does not move the ticket's status.

Record who is actively working an In Progress ticket: appended as a 'dispatch' audit event (ticket_events.jsonl), so get_agent_monitor's lastDispatch and the board UI's orchestration chip can show whether a ticket is running on a sub-agent or back with the orchestrator. Call this right after set_status "In Progress" when handing a ticket off to a fresh sub-agent — worker:"sub-agent", with model (sonnet/opus/haiku/fable) and parallel:true when it's running alongside other sub-agent dispatches. Call it again with worker:"orchestrator" when you take the ticket back (e.g. for review before commit) — the newest call always wins as the ticket's current lastDispatch. Informational only: it never moves the ticket's status.

Composite 0-100 health score with grade and breakdown: bug pressure, feature progress, momentum (recent tokens), and freshness (staleness of open work).

For Done tickets with tagged commits, compare the additions/deletions logged in the work log against the git-actual numstat of their commits. Git-actual comes from recorded commit events (FBMCPF-188) or, failing that, a live git log --grep + numstat cached by hash. Reports per-ticket loggedAdd/loggedDel vs gitAdd/gitDel with a drift ratio (worst first), plus an overall churnAccuracy also surfaced on get_health. Paginated (FBMCPB-42): returns the worst-drift page by default (limit/offset, mirroring list_tasks) so a big board stays inside the token budget — the totals/churnAccuracy rollup is always over ALL reconciled tickets. Pass driftThreshold to omit tickets whose drift ratio is below it, or full:true for every row.

Score text for AI-writing tells (overused lexical items like "delve"/"tapestry", contrastive-pivot rhetoric like "not just X, but Y", sycophantic openers, tidy-summary closers, and rhythm/density metrics: sentence-length burstiness, tricolon density, em-dash density, bolded-list density) using the research-backed ruleset in docs/VOICE-RESEARCH.md. Intended for editing YOUR OWN outbound drafts before sending them (project updates, docs, customer replies) — not for judging whether someone else's writing was AI-written. Pass project to apply that project's voiceProfile config (extraBannedPhrases, allowedTells, samplesNote) on top of the base ruleset; threshold (default 30) only changes the summary wording, not which findings fire.

Assemble a focused brief for one ticket before you work it: scope, linked-issue details, code location + custom project prompt, scratchpad mentions, the ticket's recent work log, files to read, and a definition of done. Read the files it points to rather than dumping them. When the project config etaHints is on (default), also carries an eta ({estimatedMinutes:{low,high}, basis}) so you can tell the human how long this ticket is expected to take (FBMCPF-269).

FBMCPF-263: deterministically assemble a research REQUEST packet for a ticket BEFORE implementation (no model calls). Returns the questions to answer — how to execute (approaches + tradeoffs), prior art IN THIS repo (files/tickets), comparables/competitors, risks/invariants — plus local sources to seed from (matching KB docs, docs/ paths, code hints, and prior-art hits from the local lexical RAG, FBMCPF-264), a deliverable spec (a collated markdown brief ≤ ~150 lines), a saveInstruction (orchestrator saves the returned brief via add_kb_doc as research/ so getWorkPacket auto-attaches it as researchBrief), and a suggested cheap model (haiku for effort:low/medium, else sonnet). When the research phase resolves OFF (config researchOnIntake:false or a research:off label) returns { skip:true, reason }; a research:on label forces it on.

FBMCPF-264/315: local retrieval over this board's KB docs (incl. research briefs), the code repo's docs/ + root README, and Done tickets' title+completionSummary — zero model tokens. Two-stage HYBRID by default: BM25 preselects candidates, a LOCAL embedding model (Xenova/all-MiniLM-L6-v2 via the optional @xenova/transformers dependency; ~25MB model auto-downloaded ONCE on first semantic query, then cached and offline forever) re-ranks by cosine similarity, reciprocal-rank fusion blends the two. Response carries mode: "hybrid" or "lexical" — it falls back to pure BM25 (identical to the old behavior) whenever the optional dep isn't installed, FEATUREBOARD_NO_SEMANTIC=1, or embedding fails, with a note saying why. Pass mode:"lexical" to skip embeddings deliberately (deterministic/offline runs).

Read-only git/filesystem ground truth about what coding sub-agents are doing RIGHT NOW, for one project or (omit project) a rollup across every project with a codeLocation configured. Sub-agents deliberately never write the board mid-flight (only the orchestrator sets status/logs work/commits), so between a ticket going In Progress and coming back Done, the board itself has nothing new to say — the filesystem is the only truth. Per repo (code + website, when configured): dirty files (capped list + total count) and pending additions/deletions, commits in the last sinceMinutes, and OTHER git worktrees (a live sub-agent edit surface) with their branch + dirty-file count. Also surfaces each repo's (and each worktree's) .fb-progress file — the sanctioned sub-agent progress channel: tell sub-agents in their brief to append one-line timestamped notes there at each major step (created → tests written → suite green, etc.) — plus recently-modified files and the cheap board-side signals (In Progress count, last work-log age). Use this for stalled-ticket triage (get_agent_monitor flags a stall from board events; this answers 'but is anything actually moving?') and for a cross-project 'what's live right now' rollup on Mission Control. In all-projects mode, quiet projects (nothing within sinceMinutes) are returned as plain name strings instead of full objects, appended after the active ones.

Generate a boilerplate test file (path + node:test content) for a ticket, derived from its title/description and the board's code location. Agent-native 'fixtest': call it when creating or starting a ticket, then write the returned file. Read-only — it returns the stub, it does not create the file.

Generate a FULL node:test file (path + content) from a prompt and/or a ticket — one test() block per described behaviour, not just the single boilerplate stub. Optionally imports a target module. Read-only: returns the file for you to write under test/.

Given a bug (by ticket, or an ad-hoc title/description), rank the existing features most likely affected, by keyword overlap and shared product. Use it when logging a bug to spot regressions and linkage candidates.

Record a test run's result (passed/failed/skipped, optional suite + ticket + summary) to the board's test_runs.md. You run the tests (e.g. via the shell); this stores the report so the board can surface pass/fail over time.