Work lives in Linear. Knowledge lives in the wiki.

# The wiki — Notion or Outline

The wiki is the crew's memory. Linear holds the work; the wiki holds what the
company knows. Quill writes to it at the end of every run. Anvil reads it at
the start of every scope. If you skip this layer the agents re-learn the
company every session.

Pick one. Notion if you already live there; Outline if you want a fast,
markdown-native wiki you can self-host. The structure is the same.

## Pages (top level)

| Page | What goes there | Who writes | Who reads |
|---|---|---|---|
| **Charter** | Who Alderline is, who the customers are, what the CRM is for, what it is not. One page. | Priya, once; Quill edits on decision | Anvil, Beacon, every kickoff |
| **Decisions** | One sub-page per decision: date, issue, options in one line each, the choice, the reason, who approved. | Quill | Anvil (the last three, every scope) |
| **Specs** | A link per Linear issue. Linear is the record; this is the index. | Quill | Anyone |
| **Runbooks** | How to deploy, how to roll back, how to rotate a key, how to seed a preview, how to run Bellows. Dated change line at the top of each. | Quill, Ember | Ember, Flint, Bellows |
| **Learning log** | One entry each time the crew changed how it works: the lesson as the title, the issue, what file changed. This is what the dashboard counts as learning. | Quill | Priya, monthly |
| **Customer journey** | Stages, what the customer feels, where tickets cluster. | Beacon, monthly | Anvil, Priya |
| **Ticket pulse** | Weekly: tickets by category, median first reply, top three requests, one line for Anvil. | Ledger | Priya, Anvil |
| **Release notes (customers)** | Two lines per deployed issue, in the customer's words. Marked Ready for Priya until sent. | Beacon | Priya |
| **Threat model** | The standing threats for a CRM with customer data, and the controls in place. Warden adds to it. | Warden | Warden, Ember, Flint |

## Notion

1. Create a page **Alderline CRM — Wiki** and the nine pages above under it.
   Make **Decisions**, **Learning log** and **Release notes (customers)**
   databases with properties `Date`, `Issue` (text, the ALD id), `Status`.
2. Create an internal integration **Alderline Crew** at notion.so/my-integrations
   and share the wiki page with it. The hosted Notion MCP server in
   `.mcp.json` signs in as you; Quill's headless runs use the integration
   token as `NOTION_TOKEN`.
3. Tell the crew where it is: add the page URL to `CLAUDE.md` under a heading
   `## Wiki`.

## Outline

1. Create a collection **Alderline CRM** with the nine documents above.
2. Settings → API → create a token for a user **Alderline Crew**. Set
   `OUTLINE_URL` and `OUTLINE_TOKEN` in the environment.
3. Outline's REST API is `POST /api/documents.create`, `documents.update`,
   `documents.search` with a bearer token. `kit/scripts/outline-mcp.mjs` is
   a thin MCP bridge over those three calls so Quill can use the same tool
   names as it would for Notion. Remove the `notion` entry from `.mcp.json`.

## What "trigger" means here

The wiki does not trigger anything. Linear state changes trigger agents
(Bellows watches them). The wiki is read at the start of runs and written at
the end. Keeping that boundary is what stops the two systems drifting: work
in Linear, knowledge in the wiki.

## The one rule

An agent that made a decision writes it down before it finishes. If it
forgot, the Stop hook reminds it. If it still forgot, Bellows calls Quill.

Notion or Outline

Both work. Pick one and do not run two. Alderline chose Notion because Priya already ran the company from it. The rest of this chapter shows Notion; the Outline path is the same pages with a different connector.

---
name: quill
description: >-
  Quill, the scribe. Use at the end of any run to write back what was decided
  and learned: a decision record when a choice was made, a changelog entry
  when an issue is Deployed, a runbook change when a process changed, and a
  learning-log entry when an agent found a better way. Writes to the wiki
  (Notion or Outline). The write-back step nobody else remembers.
tools: Read, Grep, Glob, mcp__notion__*, mcp__linear__*, mcp__github__*
model: sonnet
---

You are Quill. You write short, dated entries and you link every one to the
issue it came from. You record what was decided and why, never what was
discussed.

## Where things go (wiki structure in kit/wiki/notion-template.md)

- **Decisions**: one page per decision. Title, date, the issue, the options
  considered in one line each, the choice, the reason, who approved.
- **Changelog**: one entry per Deployed issue. Date, issue, one line of what
  changed in the team's words. Beacon writes the customer version.
- **Runbooks**: edit in place when a procedure changed. Add a dated line at
  the top: "Changed <date>: <what>". Never delete the old step; strike it.
- **Learning log**: one entry when an agent's kickoff prompt, agent file or
  test approach changed because of something that went wrong. Title it with
  the lesson, not the incident. This is what the dashboard counts as
  "learning".
- **Specs**: link the Linear issue; do not copy it. Linear is the record.

## When you are called

Bellows calls you after every `Deployed`, after any `ESCALATE`, and after any
run where a kit file changed. You may also be called by any agent that made a
decision it wants remembered.

## Output

The list of pages you created or edited, each as `wiki:<title> · <url>`.
Then `QUILL DONE`.

Use the quill agent.

Linear issue {{ISSUE_ID}} ("{{ISSUE_TITLE}}") is Deployed. Write back to the
wiki: a Changelog entry (date, issue, one line in the team's words); a
Decision record if any comment on the issue or its PR records a choice
between options; a Runbook edit if a procedure changed; a Learning-log entry
if any file under .claude/, AGENTS.md or CLAUDE.md changed during this issue.
Link every entry to the issue. List what you wrote as `wiki:<title> · <url>`
and finish with `QUILL DONE`.
{{EXTRA}}

Here is what Quill wrote the evening ALD-42 went live. A decision record first. Notice the shape: options in one line each, then the choice, then the reason, then who approved. Not the discussion.

Then the learning log. The title is the lesson, not the incident, so a year from now someone can read the titles alone and know what the crew learned. Each entry names the issue and the file that changed. This database is what the dashboard counts as learning.

Here is one tick, run by hand at 1:30 pm on Monday 14 September, fifteen minutes after Anvil moved ALD-42 to Detailed. Priya had answered the customer-data gate with approve customer-data at 9:42 that morning, so Bellows found the approval and started Ember. The script prints nothing on a clean tick; it writes telemetry and Linear comments. The tick blocks while the agent runs, which is why Bellows lives on a timer and not in your terminal.

That is the trigger, end to end. The state changed, Bellows noticed, an agent ran, the agent changed the state, and the next tick noticed that. The Bellows script itself is quoted and walked through in chapter 11.

Founder Q&A