runboard 0.1.0

package/dist/cli.js

@@ -0,0 +1,102 @@
+#!/usr/bin/env node
+import {
+  UserError,
+  loadRubric,
+  registerAssess,
+  registerBoard,
+  registerPulse,
+  registerReport,
+  registerRoadmap,
+  registerStatus,
+  runboardPaths,
+  shippedRubricPath
+} from "./chunk-U4SVYBXI.js";
+
+// src/cli.ts
+import { Command } from "commander";
+
+// src/commands/init.ts
+import { copyFileSync, existsSync, mkdirSync, writeFileSync as writeFileSync2 } from "fs";
+import { stringify as stringify2 } from "yaml";
+
+// src/data/config.ts
+import { readFileSync, writeFileSync } from "fs";
+import { parse, stringify } from "yaml";
+function defaultConfig(rubricVersion) {
+  return { org: "", rubricVersion };
+}
+
+// src/commands/init.ts
+function runInit(root = process.cwd()) {
+  const paths = runboardPaths(root);
+  const created = [];
+  if (!existsSync(paths.dir)) {
+    mkdirSync(paths.dir, { recursive: true });
+    created.push(".runboard/");
+  }
+  if (!existsSync(paths.assessmentsDir)) {
+    mkdirSync(paths.assessmentsDir, { recursive: true });
+    created.push(".runboard/assessments/");
+  }
+  if (!existsSync(paths.rubric)) {
+    copyFileSync(shippedRubricPath(), paths.rubric);
+    created.push(".runboard/rubric.yaml");
+  }
+  if (!existsSync(paths.config)) {
+    const rubric = loadRubric(paths.rubric);
+    writeFileSync2(paths.config, stringify2(defaultConfig(rubric.version)), "utf8");
+    created.push(".runboard/config.yaml");
+  }
+  return created;
+}
+function registerInit(program) {
+  program.command("init").description("Scaffold .runboard/ in the current repo (idempotent).").action(() => {
+    const created = runInit();
+    if (created.length === 0) {
+      process.stdout.write("Runboard is already set up here. Nothing to do.\n");
+    } else {
+      process.stdout.write(`Created:
+${created.map((c) => `  ${c}`).join("\n")}
+`);
+    }
+    process.stdout.write("\nNext: run `runboard assess` to record your first assessment.\n");
+  });
+}
+
+// src/cli.ts
+var VERSION = "0.1.0";
+function buildProgram() {
+  const program = new Command();
+  program.name("runboard").description("Local-first technical-leadership maturity scorecard.").version(VERSION, "-v, --version");
+  registerInit(program);
+  registerAssess(program);
+  registerBoard(program);
+  registerPulse(program);
+  registerRoadmap(program);
+  registerReport(program);
+  registerStatus(program);
+  return program;
+}
+async function main(argv) {
+  const program = buildProgram();
+  try {
+    await program.parseAsync(argv);
+  } catch (err) {
+    if (err instanceof UserError) {
+      process.stderr.write(`${err.message}
+`);
+      process.exitCode = 1;
+      return;
+    }
+    throw err;
+  }
+}
+main(process.argv).catch((err) => {
+  process.stderr.write(`${err instanceof Error ? err.message : String(err)}
+`);
+  process.exit(1);
+});
+export {
+  buildProgram,
+  main
+};

package/dist/mcp.js

@@ -0,0 +1,137 @@
+#!/usr/bin/env node
+import {
+  bindingConstraint,
+  formatAverage,
+  latestAssessment,
+  runAssess,
+  runBoard,
+  runPulse,
+  runReport,
+  runRoadmap,
+  runStatus
+} from "./chunk-U4SVYBXI.js";
+
+// mcp/server.ts
+import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
+import { z } from "zod";
+
+// mcp/handlers.ts
+function handleAssess(args) {
+  const sets = Object.entries(args.scores).map(
+    ([key, s]) => `${key}=${s.level}:${s.trajectory}:${s.evidence ?? ""}`
+  );
+  const { date, path } = runAssess({
+    root: args.root,
+    sets,
+    type: args.type,
+    force: args.force,
+    date: args.date
+  });
+  return { date, path, written: true };
+}
+function handleBoard(ctx) {
+  const { summary, htmlPath } = runBoard({ root: ctx.root, html: ctx.html });
+  return {
+    cells: summary.cells,
+    average: formatAverage(summary.average),
+    trajectoryCounts: summary.trajectoryCounts,
+    ...htmlPath ? { htmlPath } : {}
+  };
+}
+function handlePulse(ctx) {
+  const { path, triggers } = runPulse({ root: ctx.root });
+  return { path, triggers };
+}
+function handleRoadmap(ctx) {
+  const { path } = runRoadmap({ root: ctx.root });
+  const latest = latestAssessment(ctx.root);
+  if (!latest) throw new Error("unreachable");
+  return { path, bindingConstraint: bindingConstraint(latest) };
+}
+function handleReport(ctx) {
+  const { path } = runReport({ root: ctx.root, type: ctx.type });
+  return { path };
+}
+function handleStatus(ctx) {
+  const s = runStatus(ctx.root);
+  return {
+    latestDate: s.latestDate ?? null,
+    average: s.average ?? null,
+    trajectoryCounts: s.trajectoryCounts ?? {},
+    activeTriggers: s.activeTriggers
+  };
+}
+
+// mcp/server.ts
+var scoreShape = z.object({
+  level: z.number().int().min(1).max(5),
+  trajectory: z.enum(["up", "flat", "down", "volatile"]),
+  evidence: z.string().default("")
+});
+function json(value) {
+  return { content: [{ type: "text", text: JSON.stringify(value, null, 2) }] };
+}
+function buildServer() {
+  const server = new McpServer({ name: "runboard", version: "0.1.0" });
+  server.registerTool(
+    "runboard_assess",
+    {
+      description: "Record a 9-dimension assessment (the model supplies scores).",
+      inputSchema: {
+        scores: z.record(z.string(), scoreShape),
+        type: z.enum(["baseline", "pulse", "quarterly", "event"]).optional(),
+        force: z.boolean().optional()
+      }
+    },
+    async (args) => json(handleAssess(args))
+  );
+  server.registerTool(
+    "runboard_board",
+    {
+      description: "Render the board summary; set html to also write board.html.",
+      inputSchema: { html: z.boolean().optional() }
+    },
+    async (args) => json(handleBoard({ html: args.html }))
+  );
+  server.registerTool(
+    "runboard_pulse",
+    {
+      description: "Compare the two latest assessments and flag stuck dimensions.",
+      inputSchema: {}
+    },
+    async () => json(handlePulse({}))
+  );
+  server.registerTool(
+    "runboard_roadmap",
+    { description: "Generate a Now/Next/Later plan from the binding constraint.", inputSchema: {} },
+    async () => json(handleRoadmap({}))
+  );
+  server.registerTool(
+    "runboard_report",
+    {
+      description: "Render a report (board-update | baseline | monthly).",
+      inputSchema: { type: z.enum(["board-update", "baseline", "monthly"]) }
+    },
+    async (args) => json(handleReport({ type: args.type }))
+  );
+  server.registerTool(
+    "runboard_status",
+    { description: "One-screen current state.", inputSchema: {} },
+    async () => json(handleStatus({}))
+  );
+  return server;
+}
+async function main() {
+  const server = buildServer();
+  const transport = new StdioServerTransport();
+  await server.connect(transport);
+}
+main().catch((err) => {
+  process.stderr.write(`${err instanceof Error ? err.message : String(err)}
+`);
+  process.exit(1);
+});
+export {
+  buildServer
+};

package/examples/.runboard/assessments/2026-01-15.md

@@ -0,0 +1,17 @@
+---
+date: 2026-01-15
+type: baseline
+scores:
+  build.team: { level: 2, trajectory: flat, evidence: "All devs contracted; no retained capability" }
+  build.tools: { level: 2, trajectory: up, evidence: "CI being introduced" }
+  build.techniques: { level: 2, trajectory: flat, evidence: "Cadence inconsistent" }
+  run.team: { level: 2, trajectory: flat, evidence: "Informal on-call; knowledge concentrated" }
+  run.tools: { level: 1, trajectory: flat, evidence: "Almost no monitoring" }
+  run.techniques: { level: 2, trajectory: flat, evidence: "Loose incident response" }
+  plan.team: { level: 2, trajectory: up, evidence: "CEO comms strengthening" }
+  plan.tools: { level: 1, trajectory: flat, evidence: "No roadmap tool or analytics" }
+  plan.techniques: { level: 2, trajectory: up, evidence: "Strategy being established" }
+notes: "First baseline."
+---
+
+First baseline assessment for Northwind Engineering.

package/examples/.runboard/assessments/2026-03-15.md

@@ -0,0 +1,15 @@
+---
+date: 2026-03-15
+type: pulse
+scores:
+  build.team: { level: 2, trajectory: flat, evidence: "Still contractor-heavy" }
+  build.tools: { level: 3, trajectory: up, evidence: "CI in place; reproducible builds" }
+  build.techniques: { level: 2, trajectory: flat, evidence: "Cadence still inconsistent" }
+  run.team: { level: 2, trajectory: up, evidence: "On-call rotation forming" }
+  run.tools: { level: 2, trajectory: up, evidence: "Monitoring being extended" }
+  run.techniques: { level: 3, trajectory: up, evidence: "Defined incident process adopted" }
+  plan.team: { level: 3, trajectory: up, evidence: "Leadership aligned with business" }
+  plan.tools: { level: 1, trajectory: flat, evidence: "Still no roadmap tooling" }
+  plan.techniques: { level: 2, trajectory: up, evidence: "Prioritisation method emerging" }
+notes: "Tools and incident practice improving; planning tooling stuck."
+---

package/examples/.runboard/assessments/2026-05-15.md

@@ -0,0 +1,15 @@
+---
+date: 2026-05-15
+type: pulse
+scores:
+  build.team: { level: 3, trajectory: up, evidence: "Two permanent engineers hired" }
+  build.tools: { level: 4, trajectory: up, evidence: "Lead time and failure rate tracked" }
+  build.techniques: { level: 3, trajectory: up, evidence: "Consistent delivery cadence" }
+  run.team: { level: 3, trajectory: up, evidence: "Clear ownership and rotation" }
+  run.tools: { level: 3, trajectory: up, evidence: "Critical paths monitored" }
+  run.techniques: { level: 3, trajectory: flat, evidence: "Blameless reviews routine" }
+  plan.team: { level: 3, trajectory: flat, evidence: "Trusted by the board" }
+  plan.tools: { level: 1, trajectory: flat, evidence: "Still no roadmap tooling or analytics" }
+  plan.techniques: { level: 3, trajectory: up, evidence: "Strategy and prioritisation defined" }
+notes: "Strong progress across Build and Run; plan.tools remains the binding constraint."
+---

package/examples/.runboard/config.yaml

@@ -0,0 +1,2 @@
+org: Northwind Engineering
+rubricVersion: "1.0.0"

package/examples/.runboard/rubric.yaml

@@ -0,0 +1,95 @@
+# Runboard rubric — the 9-dimension technical-leadership maturity model.
+# Areas: build | run | plan.  Lenses: team | tools | techniques.
+# Levels: 1 Ad-hoc · 2 Repeatable · 3 Defined (target) · 4 Measured · 5 Optimising.
+version: "1.0.0"
+dimensions:
+  - key: build.team
+    area: build
+    lens: team
+    title: Build · Team
+    anchors:
+      1: "All delivery depends on contractors or heroics; no retained engineering capability."
+      2: "A core team exists but knowledge is concentrated in a few people; onboarding is informal."
+      3: "Roles and ownership are defined; the team can deliver without single points of failure."
+      4: "Team health and delivery capacity are measured and actively managed."
+      5: "The team continuously improves its own capability; hiring and growth are deliberate and data-informed."
+  - key: build.tools
+    area: build
+    lens: tools
+    title: Build · Tools
+    anchors:
+      1: "No shared build/CI; environments are set up by hand and differ per developer."
+      2: "Basic version control and some scripts exist, but builds are inconsistent."
+      3: "CI is in place; builds and environments are reproducible."
+      4: "Build/delivery metrics (lead time, failure rate) are tracked."
+      5: "Tooling is continuously optimised; investments are driven by measured developer-experience data."
+  - key: build.techniques
+    area: build
+    lens: techniques
+    title: Build · Techniques
+    anchors:
+      1: "No agreed engineering practices; quality is accidental."
+      2: "Some practices exist (reviews, tests) but are applied inconsistently."
+      3: "A defined delivery cadence and engineering standards are followed consistently."
+      4: "Practice effectiveness (coverage, defect escape) is measured."
+      5: "Practices evolve continuously based on outcome data; experimentation is routine."
+  - key: run.team
+    area: run
+    lens: team
+    title: Run · Team
+    anchors:
+      1: "No clear ownership of production; incidents are handled ad-hoc by whoever is around."
+      2: "Informal on-call exists; operational knowledge is concentrated."
+      3: "Clear operational ownership and a defined on-call rotation are in place."
+      4: "Operational load and responsiveness are measured and balanced."
+      5: "The team continuously reduces operational toil; reliability is a shared, optimised discipline."
+  - key: run.tools
+    area: run
+    lens: tools
+    title: Run · Tools
+    anchors:
+      1: "No monitoring; problems are discovered from users."
+      2: "Some monitoring exists but coverage is partial and alerting is noisy."
+      3: "Monitoring and alerting cover the critical paths."
+      4: "Service health and SLOs are measured against targets."
+      5: "Observability is continuously tuned; tooling pre-empts issues before users feel them."
+  - key: run.techniques
+    area: run
+    lens: techniques
+    title: Run · Techniques
+    anchors:
+      1: "No incident process; responses are improvised."
+      2: "A loose incident response exists but post-incident learning is rare."
+      3: "A defined incident process with blameless reviews is followed."
+      4: "Incident metrics (MTTR, recurrence) are measured."
+      5: "Operational practices continuously improve from incident and reliability data."
+  - key: plan.team
+    area: plan
+    lens: team
+    title: Plan · Team
+    anchors:
+      1: "No alignment between engineering and the business; comms are reactive."
+      2: "Some leadership comms exist but stakeholder alignment is inconsistent."
+      3: "Engineering leadership communicates clearly and is aligned with business goals."
+      4: "Alignment and stakeholder confidence are measured (e.g., via structured feedback)."
+      5: "Leadership continuously strengthens trust and influence; the function shapes strategy."
+  - key: plan.tools
+    area: plan
+    lens: tools
+    title: Plan · Tools
+    anchors:
+      1: "No roadmap or planning tooling; priorities live in someone's head."
+      2: "A basic backlog or roadmap exists but is not kept current."
+      3: "A maintained roadmap and planning tooling support prioritisation."
+      4: "Delivery against plan and outcome analytics are tracked."
+      5: "Planning tooling continuously informs strategy with measured outcome data."
+  - key: plan.techniques
+    area: plan
+    lens: techniques
+    title: Plan · Techniques
+    anchors:
+      1: "No strategy or prioritisation method; work is driven by whoever shouts loudest."
+      2: "Strategy is being established but prioritisation is inconsistent."
+      3: "A defined strategy and prioritisation method guide investment."
+      4: "Strategic bets and their outcomes are measured."
+      5: "Strategy continuously adapts from measured business and delivery outcomes."

package/package.json

@@ -0,0 +1,50 @@
+{
+  "name": "runboard",
+  "version": "0.1.0",
+  "description": "Local-first CLI for the Runboard technical-leadership maturity framework. Deterministic scoring core, portable AI adapters, no phone-home.",
+  "type": "module",
+  "license": "MIT",
+  "engines": {
+    "node": ">=20"
+  },
+  "bin": {
+    "runboard": "dist/cli.js",
+    "runboard-mcp": "dist/mcp.js"
+  },
+  "files": [
+    "dist",
+    "rubric",
+    "templates",
+    "skills",
+    "examples",
+    "AGENTS.md",
+    "README.md",
+    "LICENSE"
+  ],
+  "scripts": {
+    "build": "tsup",
+    "typecheck": "tsc --noEmit",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "lint": "biome check .",
+    "format": "biome format --write .",
+    "prepublishOnly": "npm run lint && npm run typecheck && npm run test && npm run build"
+  },
+  "dependencies": {
+    "@clack/prompts": "^0.7.0",
+    "@modelcontextprotocol/sdk": "^1.0.4",
+    "commander": "^12.1.0",
+    "eta": "^3.5.0",
+    "picocolors": "^1.1.1",
+    "yaml": "^2.6.1",
+    "zod": "^4.0.0"
+  },
+  "devDependencies": {
+    "@biomejs/biome": "^1.9.4",
+    "@types/node": "^20.17.0",
+    "@vitest/coverage-v8": "^2.1.8",
+    "tsup": "^8.3.5",
+    "typescript": "^5.7.2",
+    "vitest": "^2.1.8"
+  }
+}

package/rubric/rubric.yaml

@@ -0,0 +1,95 @@
+# Runboard rubric — the 9-dimension technical-leadership maturity model.
+# Areas: build | run | plan.  Lenses: team | tools | techniques.
+# Levels: 1 Ad-hoc · 2 Repeatable · 3 Defined (target) · 4 Measured · 5 Optimising.
+version: "1.0.0"
+dimensions:
+  - key: build.team
+    area: build
+    lens: team
+    title: Build · Team
+    anchors:
+      1: "All delivery depends on contractors or heroics; no retained engineering capability."
+      2: "A core team exists but knowledge is concentrated in a few people; onboarding is informal."
+      3: "Roles and ownership are defined; the team can deliver without single points of failure."
+      4: "Team health and delivery capacity are measured and actively managed."
+      5: "The team continuously improves its own capability; hiring and growth are deliberate and data-informed."
+  - key: build.tools
+    area: build
+    lens: tools
+    title: Build · Tools
+    anchors:
+      1: "No shared build/CI; environments are set up by hand and differ per developer."
+      2: "Basic version control and some scripts exist, but builds are inconsistent."
+      3: "CI is in place; builds and environments are reproducible."
+      4: "Build/delivery metrics (lead time, failure rate) are tracked."
+      5: "Tooling is continuously optimised; investments are driven by measured developer-experience data."
+  - key: build.techniques
+    area: build
+    lens: techniques
+    title: Build · Techniques
+    anchors:
+      1: "No agreed engineering practices; quality is accidental."
+      2: "Some practices exist (reviews, tests) but are applied inconsistently."
+      3: "A defined delivery cadence and engineering standards are followed consistently."
+      4: "Practice effectiveness (coverage, defect escape) is measured."
+      5: "Practices evolve continuously based on outcome data; experimentation is routine."
+  - key: run.team
+    area: run
+    lens: team
+    title: Run · Team
+    anchors:
+      1: "No clear ownership of production; incidents are handled ad-hoc by whoever is around."
+      2: "Informal on-call exists; operational knowledge is concentrated."
+      3: "Clear operational ownership and a defined on-call rotation are in place."
+      4: "Operational load and responsiveness are measured and balanced."
+      5: "The team continuously reduces operational toil; reliability is a shared, optimised discipline."
+  - key: run.tools
+    area: run
+    lens: tools
+    title: Run · Tools
+    anchors:
+      1: "No monitoring; problems are discovered from users."
+      2: "Some monitoring exists but coverage is partial and alerting is noisy."
+      3: "Monitoring and alerting cover the critical paths."
+      4: "Service health and SLOs are measured against targets."
+      5: "Observability is continuously tuned; tooling pre-empts issues before users feel them."
+  - key: run.techniques
+    area: run
+    lens: techniques
+    title: Run · Techniques
+    anchors:
+      1: "No incident process; responses are improvised."
+      2: "A loose incident response exists but post-incident learning is rare."
+      3: "A defined incident process with blameless reviews is followed."
+      4: "Incident metrics (MTTR, recurrence) are measured."
+      5: "Operational practices continuously improve from incident and reliability data."
+  - key: plan.team
+    area: plan
+    lens: team
+    title: Plan · Team
+    anchors:
+      1: "No alignment between engineering and the business; comms are reactive."
+      2: "Some leadership comms exist but stakeholder alignment is inconsistent."
+      3: "Engineering leadership communicates clearly and is aligned with business goals."
+      4: "Alignment and stakeholder confidence are measured (e.g., via structured feedback)."
+      5: "Leadership continuously strengthens trust and influence; the function shapes strategy."
+  - key: plan.tools
+    area: plan
+    lens: tools
+    title: Plan · Tools
+    anchors:
+      1: "No roadmap or planning tooling; priorities live in someone's head."
+      2: "A basic backlog or roadmap exists but is not kept current."
+      3: "A maintained roadmap and planning tooling support prioritisation."
+      4: "Delivery against plan and outcome analytics are tracked."
+      5: "Planning tooling continuously informs strategy with measured outcome data."
+  - key: plan.techniques
+    area: plan
+    lens: techniques
+    title: Plan · Techniques
+    anchors:
+      1: "No strategy or prioritisation method; work is driven by whoever shouts loudest."
+      2: "Strategy is being established but prioritisation is inconsistent."
+      3: "A defined strategy and prioritisation method guide investment."
+      4: "Strategic bets and their outcomes are measured."
+      5: "Strategy continuously adapts from measured business and delivery outcomes."

package/skills/assess/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: runboard-assess
+description: Run a Runboard 9-dimension maturity self-assessment with a technical leader, then persist it via the runboard CLI. Use when someone wants to assess or score their engineering maturity.
+---
+
+# Runboard: Assess
+
+You conduct the assessment conversation. **The CLI computes and stores everything — you
+never calculate scores, averages, or constraints yourself.**
+
+## Steps
+
+1. Ensure the workspace exists. If `.runboard/` is absent, run:
+
+   ```bash
+   runboard init
+   ```
+
+2. Read the anchors from `.runboard/rubric.yaml`. For each of the nine dimensions
+   (`build.team`, `build.tools`, `build.techniques`, `run.team`, `run.tools`,
+   `run.techniques`, `plan.team`, `plan.tools`, `plan.techniques`):
+   - Show the 1–5 behavioural anchors.
+   - Ask what best matches today. Suggest a level, but let the leader decide.
+   - Capture a trajectory: `up`, `flat`, `down`, or `volatile`.
+   - Capture one line of evidence.
+
+3. Persist the assessment in a single non-interactive call. Pass every dimension:
+
+   ```bash
+   runboard assess \
+     --set build.team=2:flat:"All devs contracted; no retained capability" \
+     --set build.tools=3:up:"CI introduced last quarter" \
+     --set build.techniques=2:flat:"Cadence inconsistent" \
+     --set run.team=2:flat:"Informal on-call; knowledge concentrated" \
+     --set run.tools=2:up:"Monitoring being extended" \
+     --set run.techniques=3:flat:"Defined incident process" \
+     --set plan.team=2:up:"CEO comms strengthening" \
+     --set plan.tools=1:flat:"No roadmap tool or analytics" \
+     --set plan.techniques=2:up:"Strategy being established"
+   ```
+
+4. Show the result:
+
+   ```bash
+   runboard board
+   ```
+
+   Read back the average and the named binding constraint from the CLI output. Do not
+   restate numbers you computed yourself.
+
+## Rules
+
+- All nine dimensions are required in one `assess` call.
+- Levels are 1–5; trajectory is one of up/flat/down/volatile.
+- If the CLI reports a validation error, fix the offending dimension and re-run.
+- Never overwrite an existing same-day assessment without confirming `--force` with the user.

package/skills/board-update/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: runboard-board-update
+description: Generate a board-ready, business-language technology update from the latest Runboard assessment. Use when someone needs a board pack, leadership update, or exec summary of engineering maturity.
+---
+
+# Runboard: Board Update
+
+The CLI renders the report from the latest data and a template. You make sure it reads
+well for a non-technical board.
+
+## Steps
+
+1. Generate the board-update report:
+
+   ```bash
+   runboard report --type board-update
+   ```
+
+2. Read the generated file under `.runboard/reports/board-update-<date>.md`.
+
+3. Present it (max two pages). It already translates the framework's jargon into business
+   outcomes. Optionally also produce the shareable board:
+
+   ```bash
+   runboard board --html
+   ```
+
+   and point the leader at `.runboard/board.html`.
+
+## Rules
+
+- Keep it to business language and outcomes. Do not paste raw dimension keys into a board
+  pack — use the titles and the constraint framing the CLI provides.
+- All figures come from the CLI. Do not compute or estimate maturity yourself.

package/skills/pulse/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: runboard-pulse
+description: Generate a Runboard pulse comparing the two latest maturity assessments and surface stuck dimensions. Use when someone asks what changed, what moved, or whether progress is real.
+---
+
+# Runboard: Pulse
+
+The CLI computes the deltas and the auto-triggers. You interpret them in plain language.
+
+## Steps
+
+1. Generate the pulse:
+
+   ```bash
+   runboard pulse
+   ```
+
+   This needs at least two assessments. If the CLI says so, run `runboard assess` to add
+   one (or explain that a second sitting is needed later).
+
+2. Read the generated memo at `.runboard/reports/pulse-<date>.md`.
+
+3. Summarise for the leader, using only the CLI's numbers:
+   - What improved, what regressed.
+   - Any **auto-triggers** — dimensions flat or regressing across three consecutive
+     assessments. Treat these as the things to act on.
+
+## Rules
+
+- Never compute deltas or decide what is "stuck" yourself — read it from the CLI output.
+- Keep the read-back short and business-focused.