Chief of Staff Get started

In your folder: brain/playbooks/decisions.md

Rendered from release 0.24.0, the version the download installs. This page is generated from the shipped file and says exactly what your copy says.

Playbook: Decision Log (RAPID)

Decisions are how the org actually moves — and they get lost in chat. Whenever a decision is made or implied — explicitly ("we're going with X") or implicitly ("let's just ship it Friday") — call it out and log it as its own tracked item in memory/decisions.md, with roles per RAPID. This is always-on capture (see brain/schemas/capture-rules.md), not only on request.

This playbook logs and tracks decisions. To help the principal make a hard one (options + recommendation), use brain/playbooks/decision-brief.md — the two are complementary.

The log — memory/decisions.md

A single file. Frontmatter type: decision. One row per decision:

---
name: memory-decisions
description: Decision log — one row per decision, with RAPID roles and status.
type: decision
updated: <YYYY-MM-DD>
---

# Decisions

| decision | status | R (recommend) | A (agree) | P (perform) | I (input) | D (decide) | date | rationale / source |
|---|---|---|---|---|---|---|---|---|
| Go with vendor X over Y | decided | Jane | — | Ops | Finance, Security | me | 2026-07-20 | lower TCO; [migration](projects/migration.md) |
| Reorg the data team | open | Raj | HR | — | Raj, leads | me | due 2026-08-01 | consolidate on-call |
  • status: open · decided · reversed (if a later decision overturns it, mark the old row reversed and add the new one — keep the log the source of truth, newest wins).
  • RAPID roles (people from memory/people/ where known; me = the principal; if none):
    • R — Recommend: drives the proposal, gathers input.
    • A — Agree: must sign off / has veto — only for specialized decisions (legal, compliance).
    • P — Perform: executes once decided.
    • I — Input: consulted for information/advice (SMEs, affected stakeholders); no approval.
    • D — Decide: the single decision-maker.
  • date: when decided (or due <date> while open). rationale/source: the why + where it came from (link the project/meeting).

Capturing a decision

  1. Spot it. A decision is a choice with consequences and alternatives (vs a mere task, which goes to memory/commitments.md). One decision can spawn commitments — those are the P.
  2. Log it as a row; assign RAPID roles from what you know.
  3. Fill gaps, don't fabricate. If who Decides (or Agrees) is unclear, leave it blank and ask the principal — never invent authority.
  4. Right-size RAPID. Full roles are for complex, high-stakes, multi-stakeholder decisions. For a small/one-person call, log it lightly (decision + D + date) — don't force five roles.
  5. Sequence (when helping run one): gather Input first, then Recommend → Agree → Perform stages, then Decide.
  6. Confidential decisions use the code name only.
  7. Tell the principal what you logged, in one line.

Surfacing & closing the loop

  • In briefs/reviews, surface open decisions (esp. past their due) and what they're waiting on.
  • When a decision lands, set decided + the date + rationale. If it's later reversed, mark the old row and add the new one (so the log always reflects the current call).