@forwardimpact/outpost 3.12.1 → 3.13.0

package/templates/.claude/skills/draft-emails/SKILL.md

@@ -5,6 +5,9 @@ description: Draft and send email responses with context from the knowledge base
 
 # Draft Emails
 
+Write tier: `0-Draft`
+Frontmatter: none
+
 Draft and send email responses. Use the knowledge base and calendar for full
 context on every person and conversation. Every draft needs explicit user
 approval before you send it.
@@ -20,24 +23,26 @@ The user asks to draft, reply to, respond to, or send an email.
 
 ## Data locations
 
-| Data            | Location                                     |
-| --------------- | -------------------------------------------- |
-| People          | `Knowledge/People/*.md`                      |
-| Organizations   | `Knowledge/Organizations/*.md`               |
-| Email threads   | `~/.cache/fit/outpost/apple_mail/*.md`       |
-| Calendar events | `~/.cache/fit/outpost/apple_calendar/*.json` |
-| Handled IDs     | `Drafts/handled` (one ID per line)           |
-| Ignored IDs     | `Drafts/ignored` (one ID per line)           |
-| Draft files     | `Drafts/{email_id}_draft.md`                 |
+| Data            | Location                                            |
+| --------------- | --------------------------------------------------- |
+| People          | `3-Team/People/*.md`                                 |
+| Organizations   | `3-Team/Organizations/*.md`                          |
+| Email threads   | `~/.cache/fit/outpost/apple_mail/*.md`               |
+| Calendar events | `~/.cache/fit/outpost/apple_calendar/*.json`         |
+| Handled IDs     | `~/.cache/fit/outpost/drafts/handled` (one ID/line)  |
+| Ignored IDs     | `~/.cache/fit/outpost/drafts/ignored` (one ID/line)  |
+| Draft files     | `0-Draft/{email_id}_draft.md`                        |
 
 `handled` and `ignored` both exclude threads from `scan-emails.mjs`. Use
 `handled` for resolved threads (sent here, replied manually, resolved through a
 DM). Use `ignored` for threads that need no response (newsletters, spam,
-outbound with no reply).
+outbound with no reply). The ledgers are agent state, not knowledge. They live
+in the cache `drafts/` directory, never in `state/` (a daemon-owned trust
+root).
 
 <do_confirm_checklist goal="Verify a draft is safe and ready before sending">
 
-- [ ] You looked up the sender and the organization in `Knowledge/` before you
+- [ ] You looked up the sender and the organization in `3-Team/` before you
       drafted.
 - [ ] The draft is a single email (not multiple variants). It matches the
       incoming tone.
@@ -47,7 +52,7 @@ outbound with no reply).
       recipients. Any direct-to-candidate draft carries `⚠️ RECRUITER ONLY`.
 - [ ] The draft includes no sensitive personal data (health, politics, etc.).
 - [ ] The user explicitly approved the draft before any send.
-- [ ] Send used `--draft <path>` so cleanup and `Drafts/handled` happen
+- [ ] Send used `--draft <path>` so cleanup and the `handled` ledger happen
       automatically.
 
 </do_confirm_checklist>
@@ -61,12 +66,12 @@ node scripts/scan-emails.mjs
 ```
 
 The script outputs `email_id<TAB>subject` for unprocessed emails (those not in
-`Drafts/handled` or `Drafts/ignored`).
+the `handled` or `ignored` ledger).
 
 ### 2. Classify
 
-**Ignore** (append ID to `Drafts/ignored`): newsletters, marketing, automated
-notifications, spam, outbound with no reply.
+**Ignore** (append the ID to `~/.cache/fit/outpost/drafts/ignored`):
+newsletters, marketing, automated notifications, spam, outbound with no reply.
 
 **Draft a response**: meeting requests, personal mail from known contacts,
 business inquiries or follow-ups, requests for information or action.
@@ -75,12 +80,12 @@ Be conservative with ignore. When in doubt, draft.
 
 ### 3. Gather context
 
-Before you draft, look up the sender and the organization in `Knowledge/`:
+Before you draft, look up the sender and the organization in the graph:
 
 ```bash
-rg -l "sender_name" Knowledge/
-cat "Knowledge/People/Sender Name.md"
-cat "Knowledge/Organizations/Company Name.md"
+rg -l "sender_name" [0-9]-*/
+cat "3-Team/People/Sender Name.md"
+cat "3-Team/Organizations/Company Name.md"
 ```
 
 For an email that arranges a meeting time, also read the relevant calendar
@@ -96,7 +101,7 @@ is unclear or the person has multiple contexts, **ask** rather than guess.
 
 ### 4. Write the draft
 
-Save to `Drafts/{email_id}_draft.md` with the template in
+Save to `0-Draft/{email_id}_draft.md` with the template in
 [references/template.md](references/template.md). Reference past interactions
 naturally. To arrange a meeting, propose specific times from the calendar
 availability.
@@ -105,7 +110,7 @@ availability.
 
 You **must never** copy candidates on internal threads about them.
 
-- Identify the candidate from the thread and `Knowledge/Candidates/`.
+- Identify the candidate from the thread and `2-Confidential/Candidates/`.
 - Strip the candidate from To/CC. Draft to internal stakeholders only.
 - Direct-to-candidate emails carry the warning header
   `⚠️ RECRUITER ONLY — This email goes directly to the candidate.`
@@ -128,18 +133,19 @@ node scripts/send-email.mjs \
   --cc "other@example.com" \
   --subject "Re: Subject" \
   --body "Plain text body" \
-  --draft "Drafts/12345_draft.md"
+  --draft "0-Draft/12345_draft.md"
 ```
 
 Required: `--to`, `--subject`, `--body` (plain text). Optional: `--cc`, `--bcc`,
 `--draft`. With `--draft`, the script deletes the draft file. It also appends
-the email ID to `Drafts/handled` automatically.
+the email ID to the `handled` ledger automatically.
 
 ### 8. Mark handled and do not send
 
 When other channels resolve a thread:
 
 ```bash
-echo "$EMAIL_ID" >> Drafts/handled
-rm -f "Drafts/${EMAIL_ID}_draft.md"
+mkdir -p ~/.cache/fit/outpost/drafts
+echo "$EMAIL_ID" >> ~/.cache/fit/outpost/drafts/handled
+rm -f "0-Draft/${EMAIL_ID}_draft.md"
 ```

package/templates/.claude/skills/draft-emails/references/template.md

@@ -1,6 +1,6 @@
 # Draft File Template
 
-Save each draft to `Drafts/{email_id}_draft.md` with this layout:
+Save each draft to `0-Draft/{email_id}_draft.md` with this layout:
 
 ```markdown
 # Draft Response

package/templates/.claude/skills/draft-emails/scripts/scan-emails.mjs

@@ -3,13 +3,16 @@
  * Scan for unprocessed emails and output their IDs and subjects.
  *
  * The script checks ~/.cache/fit/outpost/apple_mail/ for email thread markdown
- * files. It skips a file that Drafts/handled or Drafts/ignored already lists.
- * It outputs one tab-separated line per unprocessed thread:
- * email_id<TAB>subject. The draft-emails skill uses this script to find
- * threads that need a reply.
+ * files. It skips a file that the ~/.cache/fit/outpost/drafts/handled or
+ * ~/.cache/fit/outpost/drafts/ignored ledger already lists. It outputs one
+ * tab-separated line per unprocessed thread: email_id<TAB>subject. The
+ * draft-emails skill uses this script to find threads that need a reply.
+ *
+ * The ledgers live in the cache drafts/ directory. Never move them into
+ * ~/.cache/fit/outpost/state/ — that directory is a daemon-owned trust root.
  */
 
-import { existsSync, readdirSync, readFileSync } from "node:fs";
+import { existsSync, mkdirSync, readdirSync, readFileSync } from "node:fs";
 import { basename, join } from "node:path";
 import { homedir } from "node:os";
 
@@ -18,7 +21,8 @@ const HELP = `scan-emails — list unprocessed email threads
 Usage: node scripts/scan-emails.mjs [-h|--help]
 
 Scans ~/.cache/fit/outpost/apple_mail/ for .md thread files not yet
-recorded in Drafts/handled or Drafts/ignored. Outputs one line per
+recorded in ~/.cache/fit/outpost/drafts/handled or
+~/.cache/fit/outpost/drafts/ignored. Outputs one line per
 unprocessed thread as: email_id<TAB>subject`;
 
 if (process.argv.includes("-h") || process.argv.includes("--help")) {
@@ -28,6 +32,7 @@ if (process.argv.includes("-h") || process.argv.includes("--help")) {
 
 const HOME = homedir();
 const MAIL_DIR = join(HOME, ".cache/fit/outpost/apple_mail");
+const DRAFTS_DIR = join(HOME, ".cache/fit/outpost/drafts");
 
 /** Load a file of IDs (one per line) into a Set. */
 function loadIdSet(path) {
@@ -50,8 +55,9 @@ function extractSubject(filePath) {
 function main() {
   if (!existsSync(MAIL_DIR)) return;
 
-  const handled = loadIdSet("Drafts/handled");
-  const ignored = loadIdSet("Drafts/ignored");
+  mkdirSync(DRAFTS_DIR, { recursive: true });
+  const handled = loadIdSet(join(DRAFTS_DIR, "handled"));
+  const ignored = loadIdSet(join(DRAFTS_DIR, "ignored"));
 
   for (const name of readdirSync(MAIL_DIR).sort()) {
     if (!name.endsWith(".md")) continue;

package/templates/.claude/skills/draft-emails/scripts/send-email.mjs

@@ -15,12 +15,13 @@
 import { execFileSync } from "node:child_process";
 import {
   appendFileSync,
+  mkdirSync,
   mkdtempSync,
   writeFileSync,
   unlinkSync,
 } from "node:fs";
 import { basename, join } from "node:path";
-import { tmpdir } from "node:os";
+import { homedir, tmpdir } from "node:os";
 
 const HELP = `send-email — send an email through Apple Mail
 
@@ -32,7 +33,7 @@ Options:
   --bcc <addrs>      Comma-separated BCC recipients
   --subject <subj>   Email subject line (required)
   --body <text>      Plain-text email body (required)
-  --draft <path>     Draft file. The script deletes it after send and appends the ID to Drafts/handled
+  --draft <path>     Draft file. The script deletes it after send and appends the ID to ~/.cache/fit/outpost/drafts/handled
   -h, --help         Show this help message and exit
 
 Mail.app must run. You need no signature or sign-off. Apple Mail appends it.`;
@@ -104,6 +105,10 @@ function buildAppleScript({ to, cc, bcc, subject, body }) {
     .join("\n");
 }
 
+// The handled ledger lives in the cache drafts/ directory. Never move it into
+// ~/.cache/fit/outpost/state/ — that directory is a daemon-owned trust root.
+const DRAFTS_DIR = join(homedir(), ".cache/fit/outpost/drafts");
+
 function handleDraftCleanup(draft) {
   if (!draft) return;
   try {
@@ -115,7 +120,8 @@ function handleDraftCleanup(draft) {
   const draftBasename = basename(draft, ".md");
   const emailId = draftBasename.replace(/_draft$/, "");
   if (emailId) {
-    appendFileSync("Drafts/handled", emailId + "\n");
+    mkdirSync(DRAFTS_DIR, { recursive: true });
+    appendFileSync(join(DRAFTS_DIR, "handled"), emailId + "\n");
     console.log(`Marked as handled: ${emailId}`);
   }
 }

package/templates/.claude/skills/extract-entities/SKILL.md

@@ -1,13 +1,16 @@
 ---
 name: extract-entities
-description: Process synced email/calendar files from ~/.cache/fit/outpost/ and ad-hoc document files (e.g. from ~/Desktop/ or ~/Downloads/). Extract structured knowledge into Knowledge/ as Obsidian-compatible markdown notes. Use on a schedule, when the user asks to process/extract entities, or when another skill invokes it (e.g. organize-files). Builds the core knowledge graph from raw data.
+description: Process synced email/calendar files from ~/.cache/fit/outpost/ and ad-hoc document files (e.g. from ~/Desktop/ or ~/Downloads/). Extract structured knowledge into the tier directories as Obsidian-compatible markdown notes. Use on a schedule, when the user asks to process/extract entities, or when another skill invokes it (e.g. organize-files). Builds the core knowledge graph from raw data.
 ---
 
 # Extract Entities
 
+Write tier: `3-Team` (general); `2-Confidential` (recruitment entities)
+Frontmatter: person, organization, project, topic, priority, condition
+
 Process synced email and calendar files from `~/.cache/fit/outpost/`, plus
 ad-hoc documents from other skills, into Obsidian-compatible markdown notes
-under `Knowledge/`. This skill builds the core knowledge graph.
+in the tier directories. This skill builds the core knowledge graph.
 
 ## Trigger
 
@@ -35,15 +38,14 @@ under `Knowledge/`. This skill builds the core knowledge graph.
 
 ## Outputs
 
-- `Knowledge/People/`, `Knowledge/Organizations/`, `Knowledge/Projects/`,
-  `Knowledge/Topics/` — created or updated.
-- `Knowledge/Priorities/` — **updated only**, never
-  auto-created.
-- `Knowledge/Conditions/` — created when you detect cross-cutting patterns, or
+- `3-Team/People/`, `3-Team/Organizations/`, `3-Team/Projects/`,
+  `3-Team/Topics/` — created or updated.
+- `3-Team/Priorities/` — **updated only**, never auto-created.
+- `3-Team/Conditions/` — created when you detect cross-cutting patterns, or
   updated.
-- `Knowledge/Roles/*.md`, `Knowledge/Candidates/*/brief.md` — enriched with
-  inferred metadata. Create new role stubs with `**Status:** open`. Update to
-  `**Status:** closed` when a role closes.
+- `2-Confidential/Roles/*.md`, `2-Confidential/Candidates/*/brief.md` — enriched
+  with inferred metadata. Create new role stubs with `**Status:** open`. Update
+  to `**Status:** closed` when a role closes.
 - `~/.cache/fit/outpost/state/graph_processed` — updated.
 
 <do_confirm_checklist goal="Verify the batch produced clean, linked,
@@ -55,8 +57,8 @@ well-grounded notes">
 - [ ] Apply the "Would I prep?" test. Write no stub profiles. Give every new
       People note a substantive `## Summary`. Route calendar-only attendees to
       the Organization `## Contacts` section.
-- [ ] Use absolute paths `[[Folder/Name]]` for all links. Keep bidirectional
-      links consistent (incl. Project ↔ Priority).
+- [ ] Use tier-prefixed absolute paths (`[[3-Team/People/Name]]`) for all
+      links. Keep bidirectional links consistent (incl. Project ↔ Priority).
 - [ ] Describe the relationship in each summary. Omit the communication
       method. Make key facts substantive. Make open items commitments.
 - [ ] Log state changes with `[Field → value]`. Never auto-create a Priority
@@ -91,9 +93,8 @@ directly. Do not scan `~/.cache/fit/outpost/`. Still check each path against
 ### 1. Build the knowledge index
 
 ```bash
-find Knowledge/People Knowledge/Organizations Knowledge/Projects \
-     Knowledge/Topics Knowledge/Priorities \
-     Knowledge/Conditions -name "*.md" 2>/dev/null
+find 3-Team/People 3-Team/Organizations 3-Team/Projects 3-Team/Topics \
+     3-Team/Priorities 3-Team/Conditions -name "*.md" 2>/dev/null
 ```
 
 Run `head -20` on each note to capture the key fields. Build a mental index of
@@ -174,7 +175,7 @@ For **existing** entities, never rewrite the file. Apply targeted edits:
 
 - Add the new activity entry at the **top** of `## Activity` (reverse
   chronological).
-- Update `Last seen`.
+- Update `Last seen`, and stamp frontmatter `updated` in the same edit.
 - Add new key facts (skip duplicates).
 - Update open items (mark completed, add new).
 - Apply state changes to fields.

package/templates/.claude/skills/extract-entities/references/TEMPLATES.md

@@ -2,7 +2,8 @@
 
 Use these templates for new knowledge-base notes. One file holds each entity
 family. This keeps each file under the L5 cap. `anarlog-process` references
-this file as the index.
+this file as the index. Every template opens with its YAML frontmatter block
+(core keys plus the type's conditional keys from `registry.yaml`).
 
 - [templates-people-orgs.md](templates-people-orgs.md) — People, Organizations.
 - [templates-projects-topics.md](templates-projects-topics.md) — Projects,

package/templates/.claude/skills/extract-entities/references/conditions.md

@@ -20,7 +20,7 @@ same constraint or state, suspect a Condition.
 
 ## Create a Condition
 
-1. Check existing: `ls Knowledge/Conditions/ 2>/dev/null`.
+1. Check existing: `ls 3-Team/Conditions/ 2>/dev/null`.
 2. **No match:** create a new Condition note with
    [templates-conditions.md](templates-conditions.md). Give it a descriptive
    name ("Hiring Freeze Q2", "Division Reorg").
@@ -31,13 +31,13 @@ same constraint or state, suspect a Condition.
 
 When you create or update a Condition:
 
-1. Add `[[Conditions/{Condition}]]` to the `## Affects` section of affected
-   Priorities.
+1. Add `[[3-Team/Conditions/{Condition}]]` to the `## Affects` section of
+   affected Priorities.
 2. Add `[Status → on hold]` state changes to affected Projects where
    appropriate.
 3. Add a `## Blockers` entry to affected Role files if recruitment is frozen.
 4. Log the Condition reference in activity entries:
-   `- **YYYY-MM-DD** ({source}): {update}. See [[Conditions/{Condition}]]`.
+   `- **YYYY-MM-DD** ({source}): {update}. See [[3-Team/Conditions/{Condition}]]`.
 
 ## Resolve Conditions
 
@@ -45,7 +45,8 @@ Source content indicates the Condition ended: "approved", "freeze lifted",
 "reorg complete", "back on track".
 
 - Set `**Status:** resolved`, `**Resolved:** {date}`.
-- Remove `[[Conditions/{Condition}]]` from affected Priority `## Affects`.
+- Remove `[[3-Team/Conditions/{Condition}]]` from affected Priority
+  `## Affects`.
 - Log with `[Status → resolved]`.
 
 ## Conservatism

package/templates/.claude/skills/extract-entities/references/links.md

@@ -1,10 +1,34 @@
-# Bidirectional Links
-
-Reference for `extract-entities` Step 10 and Step 7c (Priorities).
+# Links
+
+Reference for `extract-entities` Step 10 and Step 7c (Priorities). Every
+skill that writes wiki links follows the format and overlay rules here.
+
+## Link format
+
+- In shared tiers (ranks 1 and up), write every wiki link tier-prefixed and
+  vault-absolute: `[[3-Team/People/Sarah Chen]]`,
+  `[[2-Confidential/Candidates/Jane Doe/brief]]`. A bare basename
+  (`[[Sarah Chen]]`) is a validation finding there, because overlays
+  duplicate basenames across tiers.
+- Exemption: relative links between files inside one entity subdirectory (a
+  per-candidate folder, an asset collection) stay relative, so the folder
+  moves as one unit.
+- Tier-0 notes may use bare basenames.
+- Link legality (own tier or wider only) lives in CLAUDE.md § Placement and
+  Links; the validator flags the rest.
+
+## Overlay links
+
+A sensitive facet of an entity lives as an **overlay** note in a narrower
+tier. The overlay declares itself through its frontmatter `canonical`
+property: a double-quoted, tier-prefixed, vault-absolute link to the
+canonical note (`canonical: "[[3-Team/People/Jane Doe]]"`). The canonical
+note **never links back**. Backlinks stay symmetric within one tier only; a
+cross-tier reference is one-way, from the narrower note up.
 
 ## Bidirectional link rules
 
-After you write, verify each link goes both ways.
+After you write, verify each link goes both ways **within the same tier**.
 
 | If you add...          | Then also add...                             |
 | ---------------------- | -------------------------------------------- |
@@ -13,18 +37,18 @@ After you write, verify each link goes both ways.
 | Project → Organization | Organization → Project (in Projects section) |
 | Project → Priority     | Priority → Project (in Projects section)     |
 | Condition → Project    | Project → Condition (in Related section)     |
-| Condition → Role       | Role → Condition (notes or status field)     |
+| Role → Condition       | nothing — the pair crosses tiers             |
 
-Use absolute paths everywhere: `[[People/Sarah Chen]]`,
-`[[Organizations/Acme Corp]]`, `[[Projects/Acme Integration]]`,
-`[[Priorities/Priority Name]]`, `[[Conditions/Condition Name]]`.
+The Role → Condition pair crosses tiers (rank 2 → rank 3), so only the
+narrower side links: the Role file may name the Condition, and the Condition
+never names the Role.
 
 ## Priorities (Step 7c)
 
 Match source themes against priority names and descriptions.
 
-- Add `[[Priorities/{Priority}]]` to a Project or Topic `## Related` section if
-  it is not already present.
+- Add `[[3-Team/Priorities/{Priority}]]` to a Project or Topic `## Related`
+  section if it is not already present.
 - Update the Priority's `## Projects` section when a new project emerges that
   serves it.
 

package/templates/.claude/skills/extract-entities/references/recruitment.md

@@ -1,9 +1,14 @@
 # Recruitment Inference
 
-Reference for `extract-entities` Step 7b. Enrich `Knowledge/Roles/` and
-`Knowledge/Candidates/` with metadata that no single source carries.
+Reference for `extract-entities` Step 7b. Enrich `2-Confidential/Roles/` and
+`2-Confidential/Candidates/` with metadata that no single source carries.
 
-All Role files are flat in `Knowledge/Roles/`. The `**Status:**` field
+Recruitment entities live in tier 2: route Candidates, Prospects, Roles, and
+Erasure records to `2-Confidential/`. A recruitment fact about a `3-Team`
+person lands in the person's `2-Confidential` overlay (a note with a
+`canonical` link up to the `3-Team` note), never in the canonical team note.
+
+All Role files are flat in `2-Confidential/Roles/`. The `**Status:**` field
 distinguishes:
 
 - **`Status: open`** — active openings (use for new candidates and table
@@ -15,10 +20,10 @@ distinguishes:
 Scan email subjects and bodies for requisition numbers (e.g. 7-digit Workday
 IDs).
 
-1. `ls Knowledge/Roles/ | grep "{req_number}"` — find out whether a Role file
-   exists.
+1. `ls 2-Confidential/Roles/ | grep "{req_number}"` — find out whether a Role
+   file exists.
 2. **No file:** create a stub with the Role-stub template in `req-track` Step
-   0b, and set `**Status:** open`. Search `rg "{req_number}" Knowledge/` for
+   0b, and set `**Status:** open`. Search `rg "{req_number}" [0-9]-*/` for
    context to enrich it.
 3. **File exists:** check the `**Status:**` field. If `open`, check whether the
    email provides new metadata (hiring manager, recruiter, locations). Then
@@ -31,11 +36,11 @@ A calendar event title can match an interview pattern ("Interview", "Screening",
 "Screen", "Decomposition", "Panel", "Technical Assessment", "Candidate") and
 also carry a person name. When it does:
 
-1. Cross-reference the candidate against `Knowledge/Candidates/`.
+1. Cross-reference the candidate against `2-Confidential/Candidates/`.
 2. Extract the **organizer**. If the organizer isn't the user (per
    `~/.cache/fit/outpost/state/identity.md`),
    they are likely the hiring manager.
-3. Confirm the hiring manager. Look up the organizer in `Knowledge/People/` for
+3. Confirm the hiring manager. Look up the organizer in `3-Team/People/` for
    an indication of a manager or HM role.
 4. Check the candidate's `brief.md` for a `Req` field. If you know the req, set
    the matching Role file's `Hiring manager` (only if it is currently `—`).
@@ -44,9 +49,9 @@ also carry a person name. When it does:
 ## Recruiter — email-thread inference
 
 When a thread references candidates (name match against
-`Knowledge/Candidates/`):
+`2-Confidential/Candidates/`):
 
-1. Cross-reference To/CC against `Knowledge/People/`.
+1. Cross-reference To/CC against `3-Team/People/`.
 2. If a CC'd person's note mentions "recruiter", "talent acquisition", or a
    similar role, they are likely the internal recruiter.
 3. Update the candidate's `brief.md` recruiter field and the matching Role file

package/templates/.claude/skills/extract-entities/references/resolution.md

@@ -12,7 +12,7 @@ Extract every way a source refers to each entity.
 - **Projects:** explicit names, descriptive references ("the pilot", "the
   deal").
 - **Priorities:** references to strategic directions, time-bound targets, or
-  measurable outcomes that match `Knowledge/Priorities/` entries.
+  measurable outcomes that match `3-Team/Priorities/` entries.
 
 ## Matching
 

package/templates/.claude/skills/extract-entities/references/sources.md

@@ -40,7 +40,7 @@ Never write a placeholder profile. See the
 
 ## Process — update existing notes only
 
-- Emails from people already in `Knowledge/People/`.
+- Emails from people already in `3-Team/People/`.
 - Emails referencing existing projects or organizations.
 
 ## Process — can create new notes

package/templates/.claude/skills/extract-entities/references/templates-conditions.md

@@ -5,6 +5,12 @@ The librarian agent can **auto-create** them when it detects cross-cutting
 patterns. The user can also create them manually. Lifecycle: active → resolved.
 
 ```markdown
+---
+type: condition
+created: {YYYY-MM-DD}
+updated: {YYYY-MM-DD}
+---
+
 # {Condition Name}
 
 ## Info
@@ -16,10 +22,10 @@ patterns. The user can also create them manually. Lifecycle: active → resolved
 **Resolution signal:** {What would indicate this condition has ended}
 
 ## Affects
-{Priorities, Projects, Roles, and People impacted by this condition}
-- [[Priorities/{Priority}]] — {how it's affected}
-- [[Projects/{Project}]] — {how it's affected}
-- [[Roles/{Role}]] — {how it's affected}
+{Priorities, Projects, and People impacted by this condition. A Role file
+links here instead — a Condition never links into a narrower tier.}
+- [[3-Team/Priorities/{Priority}]] — {how it's affected}
+- [[3-Team/Projects/{Project}]] — {how it's affected}
 
 ## Agent implications
 {How agents should modify their behavior while this condition is active}

package/templates/.claude/skills/extract-entities/references/templates-people-orgs.md

@@ -1,16 +1,28 @@
 # People and Organization Templates
 
+Every template opens with the YAML frontmatter block: the core keys (`type`,
+`created`, `updated`) plus the type's conditional keys from `registry.yaml`.
+A key lifted into frontmatter (`aliases` here) leaves the body; unmatched
+bold keys stay body prose.
+
 ## People
 
 ```markdown
+---
+type: person
+created: {YYYY-MM-DD}
+updated: {YYYY-MM-DD}
+aliases:
+  - "{name variant}"
+---
+
 # {Full Name}
 
 ## Info
 **Role:** {role or inferred role with qualifier}
-**Organization:** [[Organizations/{organization}]]
-**Reports to:** [[People/{{Person}}]]
+**Organization:** [[3-Team/Organizations/{organization}]]
+**Reports to:** [[3-Team/People/{{Person}}]]
 **Email:** {email}
-**Aliases:** {comma-separated variants}
 **First met:** {YYYY-MM-DD}
 **Last seen:** {YYYY-MM-DD}
 
@@ -18,12 +30,12 @@
 {2-3 sentences: who they are, why you know them, what you're working on}
 
 ## Connected to
-- [[Organizations/{Org}]] — works at
-- [[People/{Person}]] — {relationship}
-- [[Projects/{Project}]] — {role}
+- [[3-Team/Organizations/{Org}]] — works at
+- [[3-Team/People/{Person}]] — {relationship}
+- [[3-Team/Projects/{Project}]] — {role}
 
 ## Activity
-- **{YYYY-MM-DD}** ({meeting|email|voice memo}): {Summary with [[Folder/Name]] links}
+- **{YYYY-MM-DD}** ({meeting|email|voice memo}): {Summary with [[3-Team/Folder/Name]] links}
 
 ## Key facts
 {substantive facts only — leave empty if none}
@@ -35,6 +47,14 @@
 ## Organizations
 
 ```markdown
+---
+type: organization
+created: {YYYY-MM-DD}
+updated: {YYYY-MM-DD}
+aliases:
+  - "{name variant}"
+---
+
 # {Organization Name}
 
 ## Info
@@ -42,7 +62,6 @@
 **Industry:** {industry}
 **Relationship:** {customer|prospect|partner|vendor}
 **Domain:** {primary email domain}
-**Aliases:** {comma-separated}
 **First met:** {YYYY-MM-DD}
 **Last seen:** {YYYY-MM-DD}
 
@@ -50,13 +69,13 @@
 {2-3 sentences}
 
 ## People
-- [[People/{Person}]] — {role}
+- [[3-Team/People/{Person}]] — {role}
 
 ## Contacts
 {for transactional contacts who don't get their own notes}
 
 ## Projects
-- [[Projects/{Project}]] — {relationship}
+- [[3-Team/Projects/{Project}]] — {relationship}
 
 ## Activity
 - **{YYYY-MM-DD}** ({type}): {Summary}

package/templates/.claude/skills/extract-entities/references/templates-priorities.md

@@ -8,13 +8,19 @@ on** existing notes.
 ## Priorities
 
 ```markdown
+---
+type: priority
+created: {YYYY-MM-DD}
+updated: {YYYY-MM-DD}
+---
+
 # {Priority Name}
 
 ## About
 {2-3 sentences: what this strategic direction means and why it matters}
 
 **Status:** {active|paused|retired}
-**Owner:** [[People/{Person}]]
+**Owner:** [[3-Team/People/{Person}]]
 **Set:** {YYYY-MM-DD}
 
 ## What this means
@@ -25,7 +31,7 @@ on** existing notes.
 here — there is no separate Goals entity.}
 
 ## Projects
-- [[Projects/{Project}]] — {relationship}
+- [[3-Team/Projects/{Project}]] — {relationship}
 
 ## Key facts
 {substantive facts only — leave empty if none}