@forwardimpact/outpost 3.12.1 → 3.13.0

package/templates/.claude/skills/candidate-report/SKILL.md

@@ -8,6 +8,9 @@ description: >
 
 # Candidate Report
 
+Write tier: `0-Draft` (the report is an export artifact)
+Frontmatter: none
+
 Generate a polished, single-page A4 HTML report that benchmarks a candidate
 against a specific role in the agent-aligned engineering standard. The report
 serves hiring managers and pod leads. They need a quick visual summary before
@@ -24,11 +27,11 @@ they decide whether to invest interview time.
 - `@forwardimpact/pathway` CLI installed (`bunx fit-pathway --help`).
 - Playwright for PDF output
   (`bun install playwright && bunx playwright install chromium`).
-- The candidate has a `brief.md` in `Knowledge/Candidates/{Name}/`.
+- The candidate has a `brief.md` in `2-Confidential/Candidates/{Name}/`.
 
 ## Inputs
 
-- **Candidate name** — locates `Knowledge/Candidates/{Name}/brief.md`.
+- **Candidate name** — locates `2-Confidential/Candidates/{Name}/brief.md`.
 - **Target role** — discipline, level, track (e.g.
   `software-engineering J070 forward-deployed`). If the user does not give it,
   infer it from the candidate's `Req` field → Role file. Ask the user when you
@@ -38,7 +41,7 @@ they decide whether to invest interview time.
 
 ## Outputs
 
-- `Drafts/{Recipient}-{CandidateSurname}-Report.html` — the A4 one-pager.
+- `0-Draft/{Recipient}-{CandidateSurname}-Report.html` — the A4 one-pager.
 - Optional PDF with `scripts/render-pdf.mjs`.
 
 <do_confirm_checklist goal="Verify the report before delivering it">
@@ -64,17 +67,17 @@ they decide whether to invest interview time.
 Read whatever exists for the candidate:
 
 ```text
-Knowledge/Candidates/{Name}/brief.md        # required
-Knowledge/Candidates/{Name}/screening.md    # if produced by req-screen
-Knowledge/Candidates/{Name}/interview-*.md  # if produced by req-assess
-Knowledge/Candidates/{Name}/CV.pdf|CV.md    # raw CV if needed
+2-Confidential/Candidates/{Name}/brief.md        # required
+2-Confidential/Candidates/{Name}/screening.md    # if produced by req-screen
+2-Confidential/Candidates/{Name}/interview-*.md  # if produced by req-assess
+2-Confidential/Candidates/{Name}/CV.pdf|CV.md    # raw CV if needed
 ```
 
 If `screening.md` exists, treat its skill and behaviour ratings as the primary
 source. They are already standard-calibrated. Otherwise map them manually in
 Step 3.
 
-Search the graph for surrounding context: `rg "{Candidate Name}" Knowledge/`.
+Search the graph for surrounding context: `rg "{Candidate Name}" [0-9]-*/`.
 
 ### 2. Load the standard benchmark
 
@@ -122,7 +125,7 @@ preview overflows, cut content.
 Save the completed HTML to:
 
 ```text
-Drafts/{Recipient}-{CandidateSurname}-Report.html
+0-Draft/{Recipient}-{CandidateSurname}-Report.html
 ```
 
 `{Recipient}` is the first name of the person the report is for.

package/templates/.claude/skills/changelog/SKILL.md

@@ -1,64 +1,79 @@
 ---
 name: changelog
-description: Record the knowledge-graph changes from the current session into one shared Knowledge/CHANGELOG.md. The team can then see what changed and why. Use when the user asks to log, record, or write up the changes they just made to the knowledge base. This typically happens at the end of a session of edits.
+description: Record the knowledge-graph changes from the current session into one CHANGELOG.md per shared tier. The team can then see what changed and why. Use when the user asks to log, record, or write up the changes they just made to the knowledge base. This typically happens at the end of a session of edits.
 ---
 
 # Changelog
 
-Record the changes to the **knowledge graph** (`Knowledge/`) from the current
-working session. Write them in one shared `Knowledge/CHANGELOG.md`, newest
-first. Teammates who sync the same filesystem can then see what changed and why.
+Write tier: each shared tier (rank 1 and up)
+Frontmatter: changelog
 
-This skill tracks **graph content**. Graph content is the notes under
-`Knowledge/People/`, `Organizations/`, `Projects/`, `Topics/`, `Candidates/`,
-`Priorities/`, and the other subdirectories. It does **not** track changes to
-instructions (`CLAUDE.md`, agents, skills). The `upstream-instructions` skill
-owns those.
+Record the changes to the **knowledge graph** (the tier directories) from the
+current working session. Write them into one `CHANGELOG.md` per shared tier
+(`<N>-<Label>/CHANGELOG.md`, ranks 1 and up), newest first. Teammates who
+receive a tier can then see what changed in it and why.
+
+The changelog is per tier because its audience is the tier's audience. An
+entry never names a note in a narrower tier: a change to a tier-2 note goes
+to `2-Confidential/CHANGELOG.md` only, never to `3-Team/CHANGELOG.md`.
+`0-Draft/` keeps no changelog. Discover changelogs inside the tier
+directories only.
+
+This skill tracks **graph content**: the notes under each tier's entity
+subdirectories (`People/`, `Organizations/`, `Projects/`, `Candidates/`, and
+the rest). It does **not** track changes to instructions (`CLAUDE.md`,
+agents, skills). The `upstream-instructions` skill owns those, and the root
+instruction `CHANGELOG.md` is a personal surface this skill never touches.
 
 ## Trigger
 
 - The user asks to write, update, or record a changelog after they edit the KB.
-- A session added, modified, removed, or renamed notes in `Knowledge/`. The user
-  wants a record of those changes for the team.
+- A session added, modified, removed, or renamed notes in a shared tier. The
+  user wants a record of those changes for the team.
 
 ## Inputs
 
-- **The edits made in the current session** — the source of truth. The KB lives
-  on a synced filesystem and has no version control, so no commit history exists
-  to diff. Recall every note that you created, edited, removed, or renamed under
-  `Knowledge/` during this conversation.
+- **The edits made in the current session** — the source of truth. A tier may
+  sync over a mount with no version control, so never rely on commit history.
+  Recall every note that you created, edited, removed, or renamed in a shared
+  tier during this conversation.
 - `~/.cache/fit/outpost/state/identity.md` — the current user's identity. Use
-  its **Name** as the author on each entry. The KB is shared, so every entry
+  its **Name** as the author on each entry. The tiers are shared, so every entry
   must name the team member who made the change. Resolve `~` to `$HOME` before
   you read it.
-- `Knowledge/CHANGELOG.md` — the existing changelog. Read it to see what is
-  already recorded and to avoid duplicates.
+- `<N>-<Label>/CHANGELOG.md` per shared tier — the existing changelogs. Read
+  them to see what is already recorded and to avoid duplicates.
 
 ## Outputs
 
-- `Knowledge/CHANGELOG.md` — a **single** reverse-chronological changelog that
-  covers all graph subdirectories. No per-folder or per-note changelogs.
+- One `CHANGELOG.md` per shared tier that had changes: a
+  reverse-chronological log that covers that tier's subdirectories. No
+  per-folder or per-note changelogs, and none in `0-Draft/`.
 
 ## Ethics
 
-The team shares `Knowledge/`. Every entry obeys the KB's integrity rules:
-objective and factual, work-relevant, no personal judgments. Assume the person a
-note is about will read its changelog entry. Describe
+The team shares each tier with its own audience. Every entry obeys the KB's
+integrity rules: objective and factual, work-relevant, no personal judgments.
+Assume the person a note is about will read its changelog entry. Describe
 **what changed in the graph**. Do not record opinions about the people in it.
 
 <do_confirm_checklist goal="Verify the changelog is accurate and shareable">
 
-- [ ] Keep exactly one `Knowledge/CHANGELOG.md`. Leave no stray per-folder
-      changelog.
-- [ ] Name the **Scope** in every entry, with the full path of each note or
-      folder touched.
-- [ ] Give each entry a **Who** (the author, from identity), a **What**, and a
-      **Why**.
-- [ ] Make each description specific enough to be useful (never "updated some
-      notes").
+- [ ] Keep exactly one `CHANGELOG.md` per shared tier, at the tier root.
+      Leave no stray per-folder changelog and none in `0-Draft/`.
+- [ ] Route every entry to the changelog of the tier that holds the changed
+      note. Never name a narrower tier's note in a wider tier's changelog.
+- [ ] Write every entry as **one line**: type, **Scope** (tier-prefixed
+      paths), **Who**, and a short pointer. No `What:`/`Why:` blocks.
+- [ ] Make the pointer specific enough to locate the change (never "updated
+      some notes").
 - [ ] Use the real date of each change. Never guess a date.
 - [ ] Add no duplicate entry for a change already in the changelog.
 - [ ] Keep every entry factual and fit for the subject to read.
+- [ ] Stamp the frontmatter core (`type: changelog`, `created`, `updated`) on
+      a changelog you create; stamp `updated` on one you edit.
+- [ ] Keep each file short (see Step 5). Compact or drop old entries when it
+      grows.
 
 </do_confirm_checklist>
 
@@ -67,8 +82,8 @@ note is about will read its changelog entry. Describe
 ### 1. Find what's already recorded, and who you are
 
 ```bash
-head -30 Knowledge/CHANGELOG.md 2>/dev/null     # newest date already logged, if any
-cat "$HOME/.cache/fit/outpost/state/identity.md"  # Name → the author for this session's entries
+head -30 3-Team/CHANGELOG.md 2>/dev/null          # per tier you changed
+cat "$HOME/.cache/fit/outpost/state/identity.md"  # Name → the author
 ```
 
 If `identity.md` is missing or stale, run the `person-identify` skill to refresh
@@ -76,22 +91,23 @@ it before you log the changes. Never guess the author.
 
 ### 2. Reconstruct this session's changes
 
-Recall every change you made to `Knowledge/` during the current conversation:
-creations, edits, removals, and renames. Group them by note. If you are unsure
-that a change landed, confirm it before you log it:
+Recall every change you made to the shared tiers during the current
+conversation: creations, edits, removals, and renames. Group them by note,
+then by tier. If you are unsure that a change landed, confirm it before you
+log it:
 
 ```bash
-rg --files Knowledge/ | rg "<note name>"        # confirm a note exists
-cat "Knowledge/People/Doe, Jane.md"             # confirm content landed
+rg --files [0-9]-*/ | rg "<note name>"            # confirm a note exists
+cat "3-Team/People/Doe, Jane.md"                  # confirm content landed
 ```
 
 Optionally, surface anything you edited recently and might have missed:
 
 ```bash
-find Knowledge -name '*.md' -newermt '-1 day' -not -path '*/.*'
+find [0-9]-* -name '*.md' -newermt '-1 day' -not -path '*/.*'
 ```
 
-Use `Knowledge/CHANGELOG.md` only to avoid a duplicate of an entry already
+Use each tier's `CHANGELOG.md` only to avoid a duplicate of an entry already
 there.
 
 ### 3. Classify each change
@@ -104,38 +120,72 @@ there.
 | `renamed`  | Note renamed or moved                |
 
 Some related changes form one logical edit. An example is a new project note
-plus the backlinks to the people it involves. Record these as **one entry**. The
-Scope of that entry lists every note touched.
+plus the backlinks to the people it involves. Record these as **one entry**
+when they live in one tier. Changes that span tiers split into one entry per
+tier, each naming only that tier's notes.
 
 ### 4. Write the changelog
 
-Create or update `Knowledge/CHANGELOG.md` (newest first). Group entries under
-one heading per day. Write one bullet per logical change:
+Create or update the changed tiers' `CHANGELOG.md` files (newest first).
+Group entries under one heading per day. Write one bullet per logical change.
+A new changelog opens with the frontmatter core (`type: changelog`,
+`created`, `updated`); an edited one gets a fresh `updated`.
 
 ```markdown
-# Knowledge Changelog
+---
+type: changelog
+created: 2026-01-01
+updated: 2026-01-01
+---
+
+# Team Changelog
 
-Changes to the shared knowledge graph, newest first. Maintained by hand at the
-end of editing sessions via the `changelog` skill. The KB is not
-version-controlled, so this is the record of what changed and why.
+Terse, newest-first pointers to changes in this tier. This is a hint for
+teammates who sync the same files, not a precious record. The `changelog`
+skill maintains it, and compacts and drops old entries as the file grows.
 
 ## <YYYY-MM-DD>
 
-- **<added | modified | removed | renamed>** — _<Scope: full path(s)>_ · <Who>
-  **What:** <one-line summary of the change.>
-  **Why:** <the reason — the email, meeting, or request that prompted it.>
+- **<added | modified | removed | renamed>** — _<Scope: tier-prefixed path(s)>_ · <Who> — <short pointer: what changed, and why only if it isn't obvious.>
 ```
 
+**Keep entries brief — a pointer, not a summary.** One line each. State the
+type, the scope (tier-prefixed paths), the author, and a short clause that
+lets a teammate find the change and grasp its gist. Do **not** reproduce the
+content of the edit. If someone needs the detail, they open the note.
+
 Use the real date of the change (today's date is in context). Use the **Name**
 from `identity.md` as `<Who>`. The team shares the file, so the author travels
-on each entry. The day's heading alone is not enough. A day with edits from more
-than one teammate then stays unambiguous. Keep each entry to its What and Why.
-Write a ledger. Do not write a diff.
+on each entry.
+
+Collapse related same-tier edits into one line. Several notes touched for one
+purpose, or the same note created-then-reworked in a session, is a single
+entry. Combine the types (e.g. `**added / renamed**`) and name the notes in
+the scope.
+
+### 5. Compact each file when it grows
+
+A changelog is a **disposable hint file, not an archive**. The notes
+themselves are the record. Keep it short. After you add this session's
+entries, compact the file in the same pass when it has grown large (rough
+guide: **more than ~150 lines, or older than ~2 months of daily headings**):
+
+- **Roll up old days.** Fold each day older than ~2 weeks into one or two
+  thematic lines per author.
+- **Merge iterative churn.** Collapse a run of edits to the same file or
+  topic into a single line that describes the net result.
+- **Drop the stale tail.** Delete day headings older than ~2–3 months
+  outright. The change already lives in the notes.
+
+Be aggressive: losing granularity here costs nothing. Never rewrite an entry
+to say something the edit did not do. Do not drop a *recent* change just to
+save space.
 
 ## Notes
 
 - This skill **documents only**. It records changes you already made. It does
   not make or undo edits.
-- One `Knowledge/CHANGELOG.md` at the graph root, never per-folder.
+- One `CHANGELOG.md` per shared tier, at the tier root, never per-folder.
 - For changes to instructions (`CLAUDE.md`, agents, skills), use
-  `upstream-instructions` instead.
+  `upstream-instructions` instead; its root `CHANGELOG.md` is a separate
+  personal artifact.

package/templates/.claude/skills/deck-create/SKILL.md

@@ -6,6 +6,9 @@ compatibility: Requires Node.js. The skill installs Playwright on first use.
 
 # Create Presentations
 
+Write tier: `0-Draft`
+Frontmatter: none
+
 Generate PDF slide decks from user requests. Playwright renders the HTML slides
 to PDF. This skill can pull context from the knowledge base for company info,
 project details, and people.
@@ -22,7 +25,7 @@ Run when the user asks to create a presentation, slide deck, or pitch deck.
 ## Inputs
 
 - User's description of the presentation
-- `Knowledge/` — optional context about company, product, team, projects
+- `3-Team/` — optional context about company, product, team, projects
 
 ## Outputs
 
@@ -32,7 +35,7 @@ Run when the user asks to create a presentation, slide deck, or pitch deck.
 
 ## Workflow
 
-1. Check `Knowledge/` for relevant context about the company, product, team,
+1. Check `3-Team/` for relevant context about the company, product, team,
    etc.
 2. Make sure Playwright is installed:
    `bun install playwright && bunx playwright install chromium`
@@ -54,6 +57,59 @@ The conversion script accepts optional arguments:
 Defaults: input = `/tmp/outpost-presentation.html`, output =
 `~/Desktop/presentation.pdf`
 
+## Source Annotations — REQUIRED
+
+Decks are condensed views of source documents (knowledge-base notes, drafts
+under `0-Draft/`, project docs). As a deck is iterated on, improvements get
+**back-ported** to those sources. So every deck must record what maps where.
+Embed the mapping as HTML comments (invisible in the browser and in the PDF).
+A deck with untraceable content is incomplete.
+
+### Comment syntax
+
+    <!-- src: <relative-path>#<heading> -->
+    <!-- src-note: <free text> -->
+
+- `src:` maps the **next element** (and everything inside it) to a source file
+  or section. A nested `src:` overrides its parent for that subtree.
+- The path is **relative to the deck file itself**. The heading is the exact
+  markdown heading text without the leading `#`-marks, as in an Obsidian
+  `[[file#heading]]` link. Omit `#<heading>` to map to the whole file.
+- `src: #<heading>` (path omitted) inherits the path from the nearest
+  **enclosing** `src:`. Use this for repeated sections within one annotated
+  slide, so the doc path is stated once per slide.
+- `src-note:` records exceptions and nuances in prose: content synthesized
+  from multiple sources, deliberately omitted source fields, or deviations
+  from the field conventions.
+
+### Placement rules
+
+1. **Legend first.** Put one legend comment right after `<body>`. It explains
+   the syntax and the deck's field conventions (see below). Never nest a
+   literal `<!--` inside it — write the syntax without comment delimiters.
+2. **One `src:` per slide**, mapping it to its primary source document, placed
+   immediately before the `<section class="slide">`.
+3. **One `src:` per repeated content block** (a goal, a priority, a feature
+   card…), mapping it to the source section heading, placed immediately
+   before the block's opening tag.
+4. **Field conventions instead of per-paragraph comments.** When a block's
+   inner elements map 1:1 to labelled source fields (e.g. `.card.why p` ↔
+   `**Why it matters:**`), declare that mapping **once in the legend**.
+   Annotate individual elements only when they deviate — then use `src-note:`.
+5. **Synthesized content** (title pages, summary slides that condense several
+   sources) gets a `src-note:` saying what it draws on.
+
+### Authoring for back-portability
+
+- Keep deck headings **verbatim from the source headings** where possible.
+  The anchor then doubles as an integrity check.
+- Keep stable IDs from the sources (A1, B2, goal numbers) visible in the deck
+  content, so items self-identify even if comments are stripped.
+- When back-porting: treat the deck text as the edited version of the mapped
+  source field. Apply the change to the source file at the given heading.
+  Carry the substance back, not the deck's condensed formatting. Find all
+  annotations with `rg '<!-- src' <deck>.html`.
+
 ## PDF Rendering Rules
 
 **These rules prevent problems when the PDF renders:**
@@ -109,6 +165,8 @@ See that skill for the install steps and the sidecar JSON schema.
 ## Constraints
 
 - Always use the knowledge base for context when available
+- Always embed source annotations (`src:` / `src-note:` comments + legend)
+  that map deck sections to their source documents — see Source Annotations
 - Output to `~/Desktop/presentation.pdf` unless the user specifies otherwise
 - Keep slides clean and readable (max 5-6 bullet points per slide)
 - Use the same styles throughout

package/templates/.claude/skills/deck-review/SKILL.md

@@ -6,6 +6,9 @@ compatibility: Standalone HTML deck opened in a Chromium-based browser (Chrome/E
 
 # Add a Review Overlay to a Deck
 
+Write tier: `0-Draft`
+Frontmatter: none
+
 Install the self-contained `slide-annotator.js` overlay onto an HTML deck. The
 user can then **highlight text on a slide and save the feedback as a sidecar
 JSON**. Each annotation carries a robust anchor (exact text + the context around
@@ -26,7 +29,7 @@ reviewable" or asks to set up a feedback loop on slides.
 ## Inputs
 
 - Path to the target deck `.html` file (ask, or default to the most recently
-  edited `*.html` in `Drafts/`).
+  edited `*.html` in `0-Draft/`).
 - The bundled tool at `assets/slide-annotator.js`. This skill's own copy is the
   source of truth. Edit it here, then re-install it to update decks.
 

package/templates/.claude/skills/deck-summarize/SKILL.md

@@ -6,6 +6,9 @@ compatibility: Node.js only — no external dependencies.
 
 # Synthesize Deck
 
+Write tier: `0-Draft` (promotion is a human act)
+Frontmatter: none
+
 Turn messy PowerPoint specification decks into clear, actionable markdown briefs
 that forward deployed engineers can build from. Strip business jargon. Focus on
 what matters: what the team must build, what blocks progress, and what data you
@@ -31,7 +34,8 @@ Run when the user wants to understand what a project deck really asks for.
 ## Outputs
 
 - One markdown file per deck (or one combined file for related decks) written to
-  `Knowledge/Projects/{Project Name} - Engineering Brief.md`.
+  `0-Draft/{Project Name} - Engineering Brief.md`. The human promotes a
+  finished brief into `3-Team/Projects/`.
 
 <do_confirm_checklist goal="Verify the brief is engineer-actionable before
 delivering">
@@ -131,7 +135,7 @@ infrastructure. Call out timeline–scope mismatches.
 
 Use the structure in
 [references/brief-template.md](references/brief-template.md). Save to
-`Knowledge/Projects/{Project Name} - Engineering Brief.md`. For multiple related
+`0-Draft/{Project Name} - Engineering Brief.md`. For multiple related
 decks, write one combined brief with shared dependencies.
 
 ### 9. Save and report

package/templates/.claude/skills/deck-summarize/references/brief-template.md

@@ -1,7 +1,7 @@
 # Engineering Brief Template
 
 Reference template for `deck-summarize` Step 8. Save the assembled brief to
-`Knowledge/Projects/{Project Name} - Engineering Brief.md`.
+`0-Draft/{Project Name} - Engineering Brief.md`.
 
 ```markdown
 ---

package/templates/.claude/skills/doc-collab/SKILL.md

@@ -5,9 +5,13 @@ description: Help the user create, edit, and refine documents in the knowledge b
 
 # Document Collaboration
 
+Write tier: `0-Draft` (working copies; the human promotes)
+Frontmatter: none
+
 Help the user create, edit, and refine documents in the knowledge base. This
 skill supports direct edits and approval-based workflows. It always uses context
-from the knowledge base for entity references.
+from the knowledge base for entity references. New documents start in
+`0-Draft/`. The human promotes a finished document into its tier.
 
 ## Trigger
 
@@ -15,17 +19,18 @@ Run when the user asks to create, edit, review, or collaborate on a document.
 
 ## Prerequisites
 
-- Knowledge base directory exists
+- The KB root exists with its tier directories
 
 ## Inputs
 
 - The user's edit instructions
-- `Knowledge/` — existing notes and documents
+- The tier directories — existing notes and documents
 - Document to edit (user-specified or searched)
 
 ## Outputs
 
-- Created or modified documents in `Knowledge/` or user-specified location
+- New documents in `0-Draft/` (or a user-specified location)
+- Modified documents in the tier where the user points
 
 ---
 
@@ -54,8 +59,8 @@ Follow their choice for the entire session.
 Search thoroughly before you say a document doesn't exist:
 
 ```bash
-rg -l -i "roadmap" Knowledge/
-find Knowledge/ -iname "*roadmap*" 2>/dev/null
+rg -l -i "roadmap" [0-9]-*/
+find [0-9]-*/ -iname "*roadmap*" 2>/dev/null
 ```
 
 **If found:** Read it. Then proceed. **If NOT found:** Ask "I couldn't find
@@ -63,7 +68,7 @@ find Knowledge/ -iname "*roadmap*" 2>/dev/null
 
 **Create a new document:**
 
-1. Ask: "Shall I create Knowledge/[name].md?"
+1. Ask: "Shall I create 0-Draft/[name].md?"
 2. Create it with just a title. Don't pre-populate it with structure
 3. Ask: "What would you like in this?"
 
@@ -92,14 +97,14 @@ reorganize unless the user asks.
 - Ask: "What's next?"
 - Don't read back the entire document unless asked
 
-## Search Knowledge for Context
+## Search the Graph for Context
 
 When the user mentions people, companies, or projects:
 
 ```bash
-rg -l "Name" Knowledge/
-cat "Knowledge/People/Person.md"
-cat "Knowledge/Organizations/Company.md"
+rg -l "Name" [0-9]-*/
+cat "3-Team/People/Person.md"
+cat "3-Team/Organizations/Company.md"
 ```
 
 Use `[[wiki-links]]` to connect to other notes. Only link to notes that exist.

package/templates/.claude/skills/doc-create/SKILL.md

@@ -6,6 +6,9 @@ compatibility: Requires Node.js installed. Playwright is installed on first use.
 
 # Create Documents
 
+Write tier: `0-Draft`
+Frontmatter: none
+
 Generate multi-page A4 PDF documents from user requests. This skill uses
 Playwright to render self-contained HTML to PDF. It can pull context from the
 knowledge base for company info, project details, and people.
@@ -23,18 +26,18 @@ submission, brief, or any multi-page PDF that is not a slide deck.
 ## Inputs
 
 - User's description of the document
-- `Knowledge/` — optional context about company, product, team, projects
+- `3-Team/` — optional context about company, product, team, projects
 
 ## Outputs
 
 - An HTML file and a PDF rendered from it, placed where the user specifies
-  (default: `Knowledge/Projects/`)
+  (default: `0-Draft/`; the human promotes a finished document into its tier)
 
 ---
 
 ## Workflow
 
-1. Check `Knowledge/` for relevant context about the company, product, team,
+1. Check `3-Team/` for relevant context about the company, product, team,
    projects, or people mentioned.
 2. Make sure Playwright is installed:
    `bun install playwright && bunx playwright install chromium`