ckb/.agents/skills/ckb-decide/SKILL.md

name

description

ckb-decide

Record a decision into wiki/decisions/ as a numbered decision record — what was decided, by whom, when, why, what it affects, and which earlier decision it supersedes or reverses — and answer questions about decisions already recorded ("what did we decide about X", "show decision 7", "which decisions are still open", "what changed the database choice"). Use when the user says "record a decision", "log a decision", "we decided ...", "ADR", "decision record", or asks what/when/why/by whom something was decided. Distinct from `ckb-ingest` (which turns raw source material into entity pages) and from `ckb-retrieve` (general KB questions — this skill is the decisions-scoped path, and hands off to it for anything wider).

Decision log skill

Purpose

A decision is a different kind of knowledge from an entity page. An entity page describes what something is, and gets rewritten as understanding improves. A decision record describes what was chosen at a point in time, by whom, and why — and is never rewritten to reflect a later change of mind. When the choice changes, a new decision supersedes the old one and both stay on the record. That's the whole point: the value is in being able to ask "why is it like this?" and get the reasoning, the people, and the date, not just the current state.

This skill owns both halves of that:

• Recording — turning "we decided X" into a numbered, linked, logged decision record under wiki/decisions/, with the supersession links wired in both directions.
• Looking up — answering questions about decisions already recorded, scoped to wiki/decisions/ rather than searching the whole wiki.

It writes only inside wiki/ (wiki/decisions/, wiki/decisions/index.md, wiki/decisions/log.md, wiki/graph/edges.json, and a pointer line in wiki/log.md). It never edits an existing decision's substance — see Rule: decisions are append-only, below.

Trigger phrases

Recording:

• "record a decision" / "log a decision" / "add a decision record" / "write an ADR"
• "we decided ..." / "we've agreed to ..." / "the call was ..."
• "we're reversing ..." / "that supersedes decision N"

Looking up:

• "what did we decide about X" / "why do we ... ?" (when the answer is a decision)
• "show decision 7" / "show me D-0007"
• "which decisions are still open" / "what's proposed but not accepted"
• "who decided X" / "when did we decide X"
• "what decisions affect <project/system/person>"
• "what superseded decision N" / "what changed the X decision"

For a question that only touches decisions as part of a wider answer, use ckb-retrieve instead and let it pull decision pages in as one source among many. This skill is for when decisions themselves are the subject.

The decision record format

One page per decision at wiki/decisions/NNNN-short-slug.md, numbered sequentially from 0001. Numbers are never reused and never renumbered — a superseded or reversed decision keeps its number and its page.

---
type: decision
tldr: One sentence stating the decision itself, not the topic.
status: accepted
decided_on: 2026-09-01
decided_by: Alice Smith, Bob Jones
affects: /wiki/entities/billing-service.md, /wiki/projects/index.md
review_on: 2027-03-01
supersedes: /wiki/decisions/0003-use-mysql.md
confidence: 0.9
quality: 0.8
last_updated: 2026-09-01
freshness_window_days: 365
retention: high
---

# D-0007 — Use Postgres for the billing store

**Status:** Accepted · **Decided:** 2026-09-01 · **Deciders:** [[Alice Smith]] / [Alice Smith](/wiki/entities/alice-smith.md), [[Bob Jones]] / [Bob Jones](/wiki/entities/bob-jones.md)

## Context

What forced a choice. The problem, the constraints, what was true at the
time. Written so it still makes sense to someone reading it in two years
with none of the surrounding conversation.

## Decision

What was actually decided, stated plainly and in the active voice.

## Rationale

Why this option won. The reasoning that would have to change for the
decision to be worth revisiting.

## Consequences

What follows — what this commits us to, what it rules out, what work it
creates. Both the good and the costly.

## Alternatives considered

What else was on the table and why each was not chosen. A decision record
without this is much less useful on re-reading: it's the part that stops
the same option being re-proposed every six months.

## Supersession

Supersedes [[D-0003]] / [D-0003](/wiki/decisions/0003-use-mysql.md) — MySQL
was chosen before the reporting requirements landed.

## Sources

Where this came from — a meeting, a thread, a `raw/archive/` file, a ticket.

Field reference

Field	Required	Notes
type	yes	always decision
tldr	yes	the decision itself in one sentence ("Billing uses Postgres"), not the topic ("database choice") — this is what shows in the index and in search results
status	yes	proposed / accepted / rejected / superseded / reversed — vocabulary defined in wiki/decisions/index.md
decided_on	yes for accepted/rejected/reversed	YYYY-MM-DD, the date the call was made. Distinct from last_updated, which is when the page last changed. A proposed decision may have no decided_on yet.
decided_by	yes when known	comma-separated names, kept flat and plain so tooling can read it. The body's Deciders line carries the dual-links to entity pages. If genuinely unknown, write unknown rather than omitting the field — "we don't know who decided this" is itself worth recording.
affects	no	comma-separated project-root-absolute wiki paths this decision constrains. Cheap way to answer "what decisions touch X" without walking the graph.
review_on	no	YYYY-MM-DD to revisit. ckb-lint reports these once the date passes.
supersedes / superseded_by	when relevant	project-root-absolute path to the other decision. Always set both sides (see below).
confidence, quality, last_updated, freshness_window_days, retention	as usual	standard page schema. Decisions default to freshness_window_days: 365 and retention: high — a decision record doesn't rot the way a status page does, and it should survive a retention sweep.

How to run this skill — recording

Step 1 — Collect the facts, ask only for what's missing

Take everything the user already said at face value; don't re-ask for it. Then check what's missing against this list, in priority order:

1. The decision itself — what was chosen. Without this there's nothing to record.
2. Who decided — names. This is the field users most often leave out and most often want later.
3. When — a date. "Today" is fine; "last Tuesday's architecture review" is fine, resolve it to a date.
4. Why — the rationale, and the alternatives that lost.
5. Whether it changes an existing decision — see Step 2.

Ask for the missing ones in a single AskUserQuestion round rather than an interview — this is a recording task, not a discovery interview. If the user is clearly mid-flow and wants it written down now, record what you have, mark the gaps explicitly in the page body (## Rationale → "Not captured at recording time."), and say which fields you left open so they can fill them in later. A decision recorded with gaps beats a decision not recorded.

Do not invent context, rationale, or consequences. If the user gave you one sentence, the record is one sentence plus the metadata — a fabricated ## Consequences section is worse than an absent one, because a later reader can't tell it wasn't real.

Step 2 — Check whether it supersedes anything

Before writing, read wiki/decisions/index.md and scan for a decision on the same subject. If one exists and is still accepted:

• Confirm with the user that the new decision replaces it (don't assume — two decisions can coexist on the same subject at different scopes).
• If it replaces it outright, set supersedes on the new page and, on the old page, set superseded_by and change its status to superseded.
• If it undoes it and returns to the prior state, use the same two links but set the old page's status to reversed instead.
• Never edit anything else on the old page. Its context, rationale, and consequences stay exactly as they were written — that's the historical record.

Both directions must be set. A one-sided supersession link is a lint finding, and it breaks the "what changed this?" lookup in the other direction.

Step 3 — Allocate the number and write the page

The next number is the highest existing NNNN in wiki/decisions/ plus one, zero-padded to four digits — never reuse a number, even if the highest-numbered decision was rejected or superseded. Slug from the decision itself, not the topic: 0007-use-postgres-for-billing.md, not 0007-database.md.

Write the page using the format above. Link deciders to their entity pages where those pages exist (dual-linked, per Rule C). Where a decider has no entity page, write the name as plain text and mention the gap in your report — creating person pages is ckb-ingest's job, not this skill's.

Step 4 — Wire it into the index and graph

• wiki/decisions/index.md — add a bullet in number order: * **[Accepted]** [D-0007 — Use Postgres for the billing store](0007-use-postgres-for-billing.md) — <tldr> and remove the "no decisions recorded yet" placeholder once there's a first entry. When a decision's status changes (Step 2), update its index line too.
• wiki/graph/edges.json — add the edges this decision creates: decided_by (decision → person page), affects (decision → each page named in affects), and supersedes (new decision → old decision) where applicable. Skip any edge whose target page doesn't exist rather than pointing at a page you'd have to invent.

Step 5 — Log it, then report

Log the change in wiki/decisions/log.md (not wiki/log.md) using Rule B's format, and add a single pointer line to wiki/log.md: - See wiki/decisions/log.md for decision-record changes on this date. Per the Recursive Index & Log Convention, each change gets exactly one home log — don't write the full entry in both.

Then tell the user: the number and title assigned, the fields you filled, any fields left open, what it superseded (and that the old page's status was updated), which deciders had no entity page, and the standard reminder that this is on disk but not committed — "say 'sync changes' when you want it pushed."

How to run this skill — looking up

Step 1 — Start at the decisions index

Read wiki/decisions/index.md first. It carries every decision's number, title, status, and one-line summary — enough to answer "which decisions are open", "what's been decided about X", and "which decision covers Y" without opening a single page.

Step 2 — Open the pages that actually matter, and read them fully

For a specific decision, read the whole page — a decision's tldr states the choice but not the reasoning, and "why" is usually the real question. For a subject-scoped question ("what have we decided about billing?"), open every decision whose affects or body mentions the subject, including superseded ones.

Superseded decisions are part of the answer, not noise. "We use Postgres, and before that MySQL, changed in September because of reporting" is the useful answer; "we use Postgres" is the impoverished one. Follow supersedes/superseded_by chains in both directions and present the history in order.

Step 3 — Verify against the source before answering

Apply ckb-retrieve's standing rule: a decision page's ## Sources section points at where the decision came from. When the answer hinges on detail beyond what the page states — exact wording, a number, who was actually in the room — follow the source rather than paraphrasing the paraphrase.

Step 4 — Answer with the metadata attached

A decision answer is incomplete without who and when — lead with the decision, then attribute it. State the status plainly, especially when it isn't accepted: an answer built on a proposed or superseded decision must say so in the same breath, or the reader will act on something that isn't in force.

If nothing is recorded on the subject, say so plainly and offer to record one now — don't reconstruct a decision from surrounding wiki content and present it as if it were on the record. If the question revealed a genuine gap, that's a wiki/query-gaps.md entry (ckb-retrieve owns that file).

Rule: decisions are append-only

The only edits this skill makes to an existing decision page are: status, superseded_by, last_updated, and — when the user is explicitly correcting a recording error rather than changing their mind — the factual metadata fields. Context, Decision, Rationale, Consequences, and Alternatives are never rewritten to match a later view.

When the user says "actually we changed our mind about D-0003", that is a new decision superseding D-0003, not an edit to D-0003. Say so and record it that way. The exception is a genuine transcription error ("I said Alice, it was actually Anna") — fix that in place and note the correction in the log entry.

Edge cases

• No wiki/decisions/ directory yet — create it along with index.md and log.md (using the scaffold this template ships), then record the decision as 0001-….
• The user describes a decision that was already recorded — don't create a duplicate. Point at the existing record and ask whether they want to supersede it, correct it, or leave it.
• A decision with no clear decider ("we just kind of settled on it") — record decided_by: unknown rather than guessing or attributing it to whoever is in the room. Unattributed is a fact; misattributed is a defect.
• A decision that was never actually made ("we should probably...") — record it as status: proposed with no decided_on, or don't record it at all. Ask which; a proposal filed as accepted is the most damaging failure mode this skill has.
• A decision that reverses a reversal — normal chaining. Each link points one step back; the chain is the history.
• Bulk import of historical decisions (a meeting-notes backlog) — that's ckb-ingest's job for the extraction, then this skill's format for the pages. Record them in chronological order so the numbers run in the same order as the decisions.

---

Licensed under the Apache License, Version 2.0 — see LICENSE at the repository root, or http://www.apache.org/licenses/LICENSE-2.0.