Brainforge Knowledge

linear-board-audit-sop

11 min read

Standard Operating Procedure: Linear Board Audit

Title: Linear Board Audit
Version: 1.8
Date: 2026-04-02
Owner: GTM / Delivery

1. Purpose

This SOP standardizes the periodic audit of Linear tickets per Brainforge client. Use the linear-audit Cursor rule (.cursor/rules/linear-audit.mdc) and /linear-audit command (or natural language: “Linear audit”, “EP audit”, “audit Linear tickets”). The agent asks for full vs standard unless the user already asked for EP/ep-audit/full only.

  • Full audit: Pre-audit meeting list + summary (last 2 days of transcripts), then create missing issues from action items (transcripts, Granola notes; last 2 days only; use save_issue for creates), fill empty or minimal descriptions (when ~90% confident), assign started tickets to assignees and projects, check tickets whose status can be updated (propose only), check tickets that should be pushed to the current cycle (summary only), and output the internal summary in chat (meeting summaries + action items grouped by client then assignee with ticket links; risks and escalations per client within each client block).
  • Standard audit: Produce only the internal summary (SOP step 9). No creates, fills, or assignee/project/status/cycle changes.

The procedure ensures consistency, reuses existing playbook prompts (linear-ticket-agent.md and linear-ticket-generation-from-transcript.md), and keeps a single source of truth for how to run the audit.

2. Scope

  • Applies to: Brainforge clients with Linear teams/projects (e.g. LMNT, Hedra, CTA, MagicSpoon). Runs from the brainforge-platform repo (playbook + vault).
  • Full audit: Includes reads and writes (create/update) to Linear, with confirmation gates per linear-ticket-agent.md. Cycle-push is summary-only (no auto-move).
  • Standard audit: Read-only; summary is output in chat (no file written).
  • Does not apply to: Client repos as the primary workspace unless the agent has access to brainforge-platform for playbook and vault.

3. Definitions

  • Full audit: All phases in this SOP (steps 3–9): create from action items, fill descriptions, assign assignees/projects, status check, cycle-push summary, then output the internal summary in chat (Slack-style). May create/update Linear issues after explicit confirmation.
  • Standard audit: Summary only — step 9 only. List issues via Linear MCP, compute per-client sections, format Slack-style, output the summary in the chat thread (Slack-style format). No creates, fills, assignee/project/status/cycle proposals.
  • Started (ticket): In a state such as In Progress, Blocked, Client Review, PR Review, Escalated, Requirements Started (i.e. work has begun).
  • Not yet started: Backlog, ToDo, Ready for Work, etc., excluding Next Cycle for count purposes.
  • Unassigned transcripts: Transcripts under knowledge/clients/unassigned/transcripts/ not yet filed under a client folder; they often include the client name in the filename or meeting title.
  • Proposal-only mode: A run of steps 3–9 that outputs proposed creates and updates (and status/cycle summaries) without calling save_issue or update tools; the orchestrating agent performs writes after user confirmation.

4. Prerequisites

  • Cursor with Linear MCP enabled (see README.md). Linear MCP: use save_issue for creating new issues.
  • Access to brainforge-platform repo (playbook + vault). For full audit: Granola MCP and/or GitHub access for transcripts, meeting notes, and PR context (see same setup README).
  • Target client(s) and audit mode (full vs standard) confirmed before proceeding, except when the user explicitly requests EP/ep-audit/full only (then full).

5. Responsibilities

  • Person running the audit: Executes the procedure, confirms target client(s) and (when applicable) the pre-audit meeting list, and approves any Linear writes (full audit). Output is internal (summary in chat; optional copy to Slack).
  • Agent: Follows this SOP and the referenced ticket prompts; never writes to Linear without explicit confirmation when running full audit.

6. How to Run

Preferred: Use the Cursor command — type / in Cursor chat and select /linear-audit (stored in .cursor/commands/linear-audit.md). For full mode, the agent prompts for (1) target client(s), (2) full vs standard if needed, then (3) the list of meetings to be checked (last 2 days) and a quick summary (grouped by client) so you can add or request meetings, then runs the audit and produces the internal summary (meeting summaries + action items grouped by client then assignee with ticket links; risks and escalations per client inside each client block).

Alternative: Say “Run the Linear audit”, “Run the EP audit”, or “Audit Linear tickets” in chat. The agent follows .cursor/rules/linear-audit.mdc (same outcomes; EP/ep-audit phrasing defaults to full when unambiguous).

Multi-agent (per-client) mode: When a full audit runs with multiple target clients, the agent may run one subagent per client. Each subagent executes steps 3–9 in proposal-only mode (no direct Linear writes). The orchestrating agent collects each subagent’s internal summary block and proposed creates/updates, presents the combined summary and proposals in the main chat, and after explicit user confirmation performs all creates/updates via Linear MCP. Single-client full audits may also use one subagent for consistency.

This SOP may be copied or linked into a client repo (e.g. docs/SOP-Linear-Audit.md) for visibility. Canonical source: knowledge/standards/04-prompts/tickets/linear-board-audit-sop.md.

7. Step-by-Step Procedure

  1. Confirm target client(s). If not provided, ask: “Which client(s) should I audit? (e.g. LMNT, Hedra, CTA, MagicSpoon).”

  2. Pre-audit — Meeting list and summary. Gather transcripts from the last 2 days (client-named + content match per 3a and 3a’ below). Output in chat:

    • List of meetings that will be checked (with paths or titles).
    • Quick summary (grouped by client): For each target client, provide bullet points of what was mentioned (topics, decisions, action items) across the gathered meetings. Do not group by meeting.
    • Ask: “Anything missing? You can add or request specific meetings before I run the audit.”
    • Do not proceed to steps 3–9 until the user confirms or adds meetings.

  3. Create missing issues from action items (full audit only). Use linear-ticket-generation-from-transcript.md and linear-ticket-agent.md. Every action item mentioned in a meeting or sync is to be treated as a Linear task/ticket; no need for the speaker to say “I will create a ticket” or “add to Linear.” When creating new Linear issues, use the save_issue MCP tool (not create_issue).

    • 3a. Transcript discovery — client-named (required). For each target client, gather transcripts from the last 2 days only:
      • Assigned: knowledge/clients/{client}/transcripts/ (folder name matches client, e.g. magicspoon, LMNT, CTA).
      • Unassigned: knowledge/clients/unassigned/transcripts/ — include any file whose filename or meeting title (first line or metadata) indicates that client (e.g. “magic_spoon”, “Magic Spoon”, “brainforge x CTA”).
    • 3a’. Transcript discovery — content match for shared meetings (required). For each target client, search the content of transcripts from the last 2 days (same paths as above) for the client name or Linear ticket prefix (MAG-, LMN-, CTA-, AMB-). Include any transcript that contains a match. Every content-matched transcript that is a standup, delivery sync, or client regroup must be read for action items (do not sample).
    • 3b. Optional — Slack context. For each target client, use Supabase MCP first (Slack project, last 2 days, client/ticket prefix) per supabase-context-agent.md. If Supabase is unavailable, errors (including permission denied/auth), or is insufficient, always run Slack MCP fallback in the same workflow: search client and internal channels for the last 2 days (slack_search_public; with user consent slack_search_public_and_private for private). Surface action items or updates from Slack that may not appear in transcripts; feed them into the same create/update logic. See slack-mcp-context.md.
    • 3c. Optionally use Granola for the same client(s) to supplement action items.
    • 3d. Extract action items from the gathered transcripts (Slack if used, and Granola if used). Treat every action item as a candidate Linear ticket. Then continue with dedupe, plan, confirm, create per existing wording.
    • Client-name mapping (for steps 3a and 3a’): MagicSpoon → folder magicspoon; title patterns “magic_spoon”, “magic spoon”, “Magic Spoon”; content/ticket prefix “Magic Spoon”, “MAG-”. LMNT → folder lmnt; title “lmnt”, “LMNT”; content/ticket prefix “LMNT”, “LMN-”. CTA → folder CTA; title “cta”, “CTA”, “brainforge x cta”; content/ticket prefix “CTA”, “CTA-”. Amble → folder amble; title “amble”, “minutemd”, “MinuteMD”; content/ticket prefix “Amble”, “MinuteMD”, “AMB-”. Eden (EdenOS/HealthOS/Rimo): folder eden. Use these (or ask the user) when resolving client from audit target.

  4. Fill empty or minimal descriptions (full audit only). For issues with missing or very short descriptions, use context from knowledge/transcripts/Granola and the description template in linear-ticket-generation-from-transcript. Only fill when ~90% confident; otherwise add a comment asking for input. Only consider issues that are not yet in a Completed (or Done) state; skip description fills for closed issues.

  5. Assign started tickets to the most relevant assignee (full audit only). For tickets in a “started” state, infer assignee from similar tickets, project leads, or context; propose updates and confirm before applying. Do not skip this step; if no started tickets are unassigned, say so explicitly.

  6. Assign “Started” tickets to their relevant projects (full audit only). Ensure started work is in the correct Linear project(s); propose and confirm before applying. Do not skip this step; if no started tickets lack a project, say so explicitly.

  7. Check tickets whose status can be updated (full audit only). Use transcripts, meeting notes, Granola, and GitHub PRs (and any linked branch/PR on the ticket) to identify status changes (e.g. done, blocked, in review). Output a proposed list only; require explicit confirmation before updating status in Linear.

  8. Check tickets that should be pushed to the current cycle (full audit only). Compare backlog/next-cycle candidates to current cycle scope; provide a summary only — do not move tickets unless the user explicitly asks.

  9. Produce the internal summary. Output in the chat thread (do not create a markdown file in vault). Structure so each client’s block can be copied into that client’s Slack channel. Include:

    • Meetings checked (last 2 days): List meeting title/date and path or identifier.
    • Internal summary (grouped by Client > Assignee, for Slack): For each client (in audit order or alphabetically), use bullet points for all content:
      • Summary: Bullet list of what was discussed (topics, decisions, context) across the meetings that involved this client.
      • By assignee: Under that client, group by assignee (or “Unassigned”) and list action items and new Linear ticket links (e.g. CTA-93: title) as bullets.
      • Risks and escalations (per client): For each client, include a short Risks and escalations sub-block (bullet list) covering blockers, overdue items, unassigned critical work, client/stakeholder escalations, or notable gaps for that client. Do not use a separate global Risks and escalations section.
    • Optionally, a short per-client board snapshot (counts, critical/overdue) if useful.

Full audit: Execute steps 3–9 in sequence. Steps 4, 5, and 6 must not be skipped: list or query started issues for target clients, then fill descriptions / assign assignees / assign projects as applicable, or state that there was nothing to do.

  1. Optionally share the relevant client block(s) to Slack.

8. Quality Checks

  • All target clients are covered in the summary.
  • Full audit: All creates/updates follow linear-ticket-agent.md (dedupe, confirmation gate). Description fills only when ~90% confident and only for non-Completed issues. Status and cycle changes are proposed, not auto-applied (except where user confirmed).
  • Every content-matched standup, delivery sync, or regroup in the last 2 days was considered for action-item extraction.
  • Every action item from those meetings is either reflected in a created/updated ticket or explicitly deferred.
  • Summary: Includes meetings checked, meeting summaries, and action items grouped by client then assignee with links to new tickets; risks/escalations per client within each client block; output in chat.

9. Escalation Path

  • Missing team/project mapping or ambiguous client name: Ask the user.
  • Linear MCP errors: Follow README.md; retry after checking auth/config.
  • Granola or GitHub unavailable for full audit: Skip status/context-dependent steps and note the gap in the summary.

10. Version History

  • v1.0 — Initial draft (2026-02-19). Full and standard audit; Cursor command and rule; references linear-ticket-agent and linear-ticket-generation-from-transcript.
  • v1.1 — Add explicit transcript discovery (assigned + unassigned by path/title; content search for client/ticket prefix so shared meetings e.g. Data Service standups are included). RCA: missed Feb 20 Magic Spoon transcript in unassigned; feedback: client topics also appear in meetings not named after the client.
  • v1.2 — Summary output in chat (Slack-style) instead of vault file; Step 4 restricted to non-Completed issues only for description fills.
  • v1.3 — Linear auditing improvements: 5-day window; full audit only (later ep-audit command); pre-audit meeting list and summary; action items = tickets (no explicit “create a ticket” required); new summary format (meetings + action items by assignee with ticket links; risks and escalations). Command renamed to ep-audit.
  • v1.8 — ep-audit rule/command removed; single entry point /linear-audit + linear-audit.mdc (full vs standard; EP audit phrasing still supported).
  • v1.4 — Window changed from last 5 days to last 1 day. Eden scope narrowed to EdenOS, HealthOS, Rimo only.
  • v1.5 — Window changed from last 1 day to last 2 days.
  • v1.6 — Use save_issue MCP tool for creating new issues. Internal summary includes meeting summaries and is grouped by Client > Assignee for Slack paste.
  • v1.7 — Require steps 4–6 never skipped; pre-audit and internal summary client-grouped with bullet points; risks and escalations per client (no separate section).

Graph View

Backlinks