@forwardimpact/outpost 3.12.0 → 3.13.0

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

@@ -1,25 +1,28 @@
 ---
 name: extract-entities
-description: Process synced email/calendar files from ~/.cache/fit/outpost/ and ad-hoc document files (e.g. from ~/Desktop/ or ~/Downloads/) to extract structured knowledge into Knowledge/ as Obsidian-compatible markdown notes. Use on a schedule, when the user asks to process/extract entities, or when invoked by another skill (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 passed by other skills, into Obsidian-compatible markdown notes
-under `Knowledge/`. The core knowledge-graph builder.
+ad-hoc documents from other skills, into Obsidian-compatible markdown notes
+in the tier directories. This skill builds the core knowledge graph.
 
 ## Trigger
 
-- Schedule (every 15 minutes) for synced data.
+- The schedule runs every 15 minutes for synced data.
 - The user asks to process / extract entities from synced data.
-- Another skill passes ad-hoc file paths (e.g. `organize-files` after organising
-  `~/Desktop/` and `~/Downloads/`).
+- Another skill passes ad-hoc file paths (e.g. `organize-files` after it
+  organises `~/Desktop/` and `~/Downloads/`).
 
 ## Prerequisites
 
 - Synced data in `~/.cache/fit/outpost/` and/or ad-hoc paths.
-- User identity from running the `person-identify` skill, which writes
+- User identity from the `person-identify` skill. That skill writes
   `~/.cache/fit/outpost/state/identity.md` (Name, Email, Domain).
 
 ## Inputs
@@ -31,92 +34,91 @@ under `Knowledge/`. The core knowledge-graph builder.
 - `~/.cache/fit/outpost/state/graph_processed` — processed-file index (TSV,
   shared with `req-track` and `anarlog-process`).
 - `~/.cache/fit/outpost/state/identity.md` — user identity for self-exclusion
-  (written by the `person-identify` skill).
+  (the `person-identify` skill writes it).
 
 ## Outputs
 
-- `Knowledge/People/`, `Knowledge/Organizations/`, `Knowledge/Projects/`,
-  `Knowledge/Topics/` — created or updated.
-- `Knowledge/Priorities/` — **updated only**, never
-  auto-created.
-- `Knowledge/Conditions/` — created when cross-cutting patterns are detected, 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. New role stubs created 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,
 well-grounded notes">
 
-- [ ] Source type correctly identified; meeting-vs-email rules applied (meetings
-      create, emails only update).
-- [ ] Self and `@user.domain` excluded from extraction.
-- [ ] "Would I prep?" test applied; no stub profiles — every new People note has
-      a substantive `## Summary`, calendar-only attendees routed to Organization
-      `## Contacts`.
-- [ ] All links use absolute paths `[[Folder/Name]]`; bidirectional links
-      consistent (incl. Project ↔ Priority).
-- [ ] Summaries describe relationship, not communication method; key facts are
-      substantive; open items are commitments.
-- [ ] State changes logged with `[Field → value]`; no Priority entities
-      auto-created.
-- [ ] Conditions created only when ≥ 3 entities reference the same cross-cutting
-      state; resolution detected when evidence supports.
-- [ ] Recruitment: Req numbers detected and Role files created/enriched;
-      HM/recruiter/domain-lead inferred where strongly supported.
-- [ ] `graph_processed` updated for every processed file.
+- [ ] Identify the source type correctly. Apply the meeting-vs-email rules
+      (meetings create, emails only update).
+- [ ] Exclude yourself and `@user.domain` from the extraction.
+- [ ] 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 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
+      entity.
+- [ ] Create a Condition only when ≥ 3 entities reference the same
+      cross-cutting state. Detect resolution when the evidence supports it.
+- [ ] Recruitment: detect Req numbers and create or enrich Role files. Infer
+      HM/recruiter/domain-lead where the evidence strongly supports it.
+- [ ] Update `graph_processed` for every processed file.
 
 </do_confirm_checklist>
 
 ## Procedure
 
-Process **10 files per run**. Write **one file at a time** — do not batch
+Process **10 files per run**. Write **one file at a time**. Do not batch
 writes.
 
 ### 0. Load context and pick the batch
 
-Read the user's identity from `~/.cache/fit/outpost/state/identity.md` (run the
-`person-identify` skill first if it is missing or stale). Find new/changed
-files:
+Read the user's identity from `~/.cache/fit/outpost/state/identity.md`. Run the
+`person-identify` skill first if the file is missing or stale. Find new or
+changed files:
 
 ```bash
 node scripts/state.mjs check
 ```
 
-Each line is a path. When invoked with ad-hoc paths, process those directly
-instead of scanning `~/.cache/fit/outpost/` — still check each against
-`graph_processed` and skip when the hash hasn't changed.
+Each line is a path. When another skill gives you ad-hoc paths, process those
+directly. Do not scan `~/.cache/fit/outpost/`. Still check each path against
+`graph_processed`. Skip a path when its hash did not change.
 
 ### 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
 ```
 
-For each note, `head -20` to capture key fields. Build a mental index of People,
-Organizations, Projects, Priorities, Topics by name, email, organization,
-role, status, and aliases.
+Run `head -20` on each note to capture the key fields. Build a mental index of
+People, Organizations, Projects, Priorities, Topics by name, email,
+organization, role, status, and aliases.
 
 ### 2. Classify the source
 
-Type detection, skip rules, warm-intro exception, and the source-type rules
-summary: [references/sources.md](references/sources.md).
+Find the type-detection rules, the skip rules, the warm-intro exception, and
+the source-type summary in [references/sources.md](references/sources.md).
 
 ### 3. Read and parse the source
 
 - **Emails:** Date, Subject, From, To/Cc, Thread ID, Body.
 - **Meetings:** Date, Attendees, Transcript / Notes.
-- **Ad-hoc documents:** Date (file mtime), Filename, Source path, Content. `.md`
-  / `.txt` / `.rtf` direct; `.pdf` via `pdftotext` or `mdcat`; `.csv` as-is
-  (look for names / emails / orgs in columns); `.doc` / `.docx` via
-  `textutil -convert txt`.
+- **Ad-hoc documents:** Date (file mtime), Filename, Source path, Content. Read
+  `.md`, `.txt`, and `.rtf` direct. Read `.pdf` with `pdftotext` or `mdcat`.
+  Read `.csv` as-is and look for names, emails, or orgs in the columns. Read
+  `.doc` and `.docx` with `textutil -convert txt`.
 
 Ad-hoc documents follow **meeting** rules (can create notes).
 
-Exclude self per [references/sources.md](references/sources.md#self-exclusion).
+Exclude yourself per
+[references/sources.md](references/sources.md#self-exclusion).
 Collect every name variant per
 [references/resolution.md](references/resolution.md#name-variant-collection).
 
@@ -126,7 +128,7 @@ For each variant, search the knowledge index. Apply the
 [matching table](references/resolution.md#matching) and the
 [disambiguation priority](references/resolution.md#disambiguation-priority).
 Priorities are
-[never auto-created](references/resolution.md#never-auto-create) — link to
+[never auto-created](references/resolution.md#never-auto-create). Link to
 existing entries only.
 
 ### 5. Identify new entities (meetings only)
@@ -134,53 +136,53 @@ existing entries only.
 Apply the
 ["Would I prep?" test](references/resolution.md#would-i-prep-for-this-person--step-5)
 and the [role inference rules](references/resolution.md#role-inference). For
-contacts who don't merit their own note, add to the Organization's `## Contacts`
-section.
+contacts who don't merit their own note, add them to the Organization's
+`## Contacts` section.
 
 ### 6. Extract content
 
-Decisions, commitments, key facts, open items, activity lines, summaries:
-[references/content.md](references/content.md). Be substantive; never write
-filler or meta-commentary.
+Find the rules for decisions, commitments, key facts, open items, activity
+lines, and summaries in [references/content.md](references/content.md). Be
+substantive. Never write filler or meta-commentary.
 
 ### 7. Detect state changes and structural enrichment
 
 - **State changes** (Project status, open-item resolution, role / title changes,
-  relationship changes): tables in
+  relationship changes): see the tables in
   [references/content.md](references/content.md#state-change-tables). Be
-  conservative; log inline `[Field → value]`.
+  conservative. Log inline `[Field → value]`.
 - **Recruitment** (Req-number detection, hiring-manager / recruiter /
-  domain-lead inference):
+  domain-lead inference): see
   [references/recruitment.md](references/recruitment.md).
-- **Priority links** (Step 7c): rules in
+- **Priority links** (Step 7c): see the rules in
   [references/links.md](references/links.md#priorities-step-7c).
   **Never auto-create.**
-- **Conditions** (cross-cutting states affecting ≥ 3 entities):
+- **Conditions** (cross-cutting states that affect ≥ 3 entities): see
   [references/conditions.md](references/conditions.md).
 
 ### 8. Check for duplicates
 
-[references/content.md](references/content.md#duplicate-check-step-8) — skip
-same-day same-source activity entries, dedupe key facts and open items, mark
-contradictions "(needs clarification)".
+See [references/content.md](references/content.md#duplicate-check-step-8).
+Skip same-day same-source activity entries. Dedupe key facts and open items.
+Mark contradictions "(needs clarification)".
 
 ### 9. Write updates
 
-For **new** entities, use the templates indexed by
-[references/TEMPLATES.md](references/TEMPLATES.md).
+For **new** entities, use the templates.
+[references/TEMPLATES.md](references/TEMPLATES.md) indexes them.
 
-For **existing** entities, apply targeted edits — never rewrite the file:
+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.
 
 ### 10. Ensure bidirectional links
 
-After writing, verify links go both ways using the
+After you write, verify that links go both ways. Use the
 [bidirectional link rules](references/links.md#bidirectional-link-rules).
 
 ### 11. Update graph state
@@ -189,6 +191,5 @@ After writing, verify links go both ways using the
 node scripts/state.mjs update "$FILE"
 ```
 
-Run for every processed file. The state file is shared with `req-track` and
-`anarlog-process`, so this prevents either skill from re-scanning the same
-input.
+Run for every processed file. `req-track` and `anarlog-process` share the
+state file. So neither skill scans the same input again.

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

@@ -1,14 +1,15 @@
 # Note Templates
 
-Templates for creating new knowledge-base notes. Split by entity family to keep
-each file under the L5 cap. `anarlog-process` references this file as the
-index.
+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. 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,
   Topics.
 - [templates-priorities.md](templates-priorities.md) — Priorities.
-  **Never auto-created** by `extract-entities` or `anarlog-process`
-  — set by the user.
+  `extract-entities` and `anarlog-process` **never auto-create** them.
+  The user sets them.
 - [templates-conditions.md](templates-conditions.md) — Conditions (time-bound
   cross-cutting states).

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

@@ -1,9 +1,9 @@
 # Conditions
 
 Reference for `extract-entities` Step 7d. Conditions are time-bound
-organizational states (hiring freezes, reorgs, budget holds, leadership
-transitions) that affect multiple entities simultaneously — the "weather" of the
-knowledge graph.
+organizational states that affect multiple entities at the same time (hiring
+freezes, reorgs, budget holds, leadership transitions). They are the "weather"
+of the knowledge graph.
 
 ## Detection signals
 
@@ -18,38 +18,40 @@ same constraint or state, suspect a Condition.
 | "waiting on", "pending approval from"    | "Waiting on leadership decision" | Leadership Decision Pending |
 | "new CTO", "leadership change"           | "New CTO starting next month"    | Leadership Transition       |
 
-## Creating a Condition
+## Create a Condition
 
-1. Check existing: `ls Knowledge/Conditions/ 2>/dev/null`.
-2. **No match:** create a new Condition note using
-   [templates-conditions.md](templates-conditions.md). Name descriptively
-   ("Hiring Freeze Q2", "Division Reorg").
+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").
 3. **Match exists:** update with new activity and any changes to status,
    blocker, or affected entities.
 
-## Updating affected entities
+## Update affected entities
 
-When a Condition is created or updated:
+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}]]`.
 
-## Resolving Conditions
+## Resolve Conditions
 
-Source content indicates the Condition has ended: "approved", "freeze lifted",
+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
 
 Only create Conditions for genuinely cross-cutting states that affect 3+
-entities. A single project being "on hold" is a project status change, **not** a
-Condition. A hiring freeze affecting 20 roles across 5 teams **is** a Condition.
+entities. A single project that goes "on hold" is a project status change. It is
+**not** a Condition. A hiring freeze that affects 20 roles across 5 teams **is**
+a Condition.

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

@@ -15,8 +15,8 @@ Extract owner, action, deadline (if mentioned), status (`open`).
 
 ## Key facts — substantive only
 
-Specific numbers (budget, team size, timeline), preferences, working style,
-background, technical requirements, what was discussed or proposed.
+Specific numbers (budget, team size, timeline), preferences, work style,
+background, technical requirements, what people discussed or proposed.
 
 **Never include:** meta-commentary about missing data, placeholder text, or
 data-quality observations. If no key facts exist, leave the section empty.
@@ -40,9 +40,9 @@ background".
 Always use canonical names with absolute paths (`[[People/Name]]`,
 `[[Organizations/Name]]`).
 
-## Summary — relationship not method
+## Summary — relationship over method
 
-2–3 sentences answering: "Who is this person and why do I know them?"
+Write 2–3 sentences that answer: "Who is this person and why do I know them?"
 
 - **Good:** "VP Engineering at [[Organizations/Acme Corp]] leading the
   [[Projects/Acme Integration]] pilot."
@@ -84,8 +84,8 @@ Change `- [ ]` → `- [x]` with completion date.
 
 ## Conservatism
 
-Only apply clear, unambiguous state changes. If uncertain, add to activity but
-don't change fields.
+Only apply clear, unambiguous state changes. If you are uncertain, add to
+activity but don't change fields.
 
 Log changes inline:
 
@@ -95,10 +95,11 @@ Log changes inline:
 
 ## Duplicate check (Step 8)
 
-Before writing:
+Before you write:
 
 - Look at the Activity section for an existing entry on this date from this
   source.
-- Compare key facts; skip duplicates.
+- Compare key facts, then skip duplicates.
 - Don't add the same open item twice.
-- If new info contradicts existing, keep both with "(needs clarification)".
+- If new info contradicts the existing info, keep both with
+  "(needs clarification)".

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 writing, 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,21 +37,21 @@ After writing, 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
-  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.
 
-**Never auto-create Priorities.** Don't over-link — a project that already links
-to a Priority through a related Topic doesn't need a redundant direct Priority
-link.
+**Never auto-create Priorities.** Don't over-link. A project that already links
+to a Priority through a related Topic doesn't need a redundant direct link to
+the Priority.

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,41 +20,42 @@ distinguishes:
 Scan email subjects and bodies for requisition numbers (e.g. 7-digit Workday
 IDs).
 
-1. `ls Knowledge/Roles/ | grep "{req_number}"` — does a Role file exist?
-2. **No file:** create a stub using the Role-stub template in `req-track` Step
-   0b, with `**Status:** open`. Search `rg "{req_number}" Knowledge/` for
+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}" [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) and update
-   the Role file. If `closed`, link for historical reference only; do not add
-   new candidates or rebuild tables.
+   email provides new metadata (hiring manager, recruiter, locations). Then
+   update the Role file. If `closed`, link for historical reference only. Do not
+   add new candidates. Do not rebuild tables.
 
 ## Hiring manager — calendar inference
 
-When a calendar event title matches an interview pattern — "Interview",
-"Screening", "Screen", "Decomposition", "Panel", "Technical Assessment",
-"Candidate" — combined with a person name:
+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: look up the organizer in `Knowledge/People/` for a manager/HM role
-   indication.
-4. Check the candidate's `brief.md` for a `Req` field; if known, set the
-   matching Role file's `Hiring manager` (only if currently `—`).
-5. Set the candidate's `brief.md` `Hiring manager` field if currently `—`.
+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 `—`).
+5. Set the candidate's `brief.md` `Hiring manager` field if it is currently `—`.
 
 ## 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
-   (only if currently `—`).
+   (only if it is currently `—`).
 
 ## Domain lead — reporting-chain resolution
 
@@ -63,6 +69,6 @@ When a hiring manager is newly identified:
 
 ## Conservatism
 
-Set hiring manager / domain lead / recruiter only when evidence is strong. A
-single calendar invite organized by someone is suggestive but not conclusive —
-confirm against People notes or multiple data points before setting the field.
+Set hiring manager / domain lead / recruiter only when the evidence is strong. A
+single calendar invite from one organizer is suggestive but not conclusive.
+Confirm against People notes or multiple data points before you set the field.

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

@@ -4,7 +4,7 @@ Reference for `extract-entities` Steps 2b–5.
 
 ## Name-variant collection
 
-Extract every way each entity is referenced.
+Extract every way a source refers to each entity.
 
 - **People:** full names, first / last names, initials, email addresses,
   roles/titles, pronouns with clear antecedents.
@@ -12,7 +12,7 @@ Extract every way each entity is referenced.
 - **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
 
@@ -27,11 +27,12 @@ Extract every way each entity is referenced.
 
 Email match > Organization context > Role match > Aliases > Recency.
 
-If still ambiguous, **skip** rather than guess.
+If it is still ambiguous, **skip** rather than guess.
 
 ## "Would I prep for this person?" — Step 5
 
-Apply for entities not resolved to existing notes (meetings only).
+Apply this test to entities that you did not resolve to existing notes (meetings
+only).
 
 **Create a note for:**
 
@@ -48,27 +49,26 @@ Apply for entities not resolved to existing notes (meetings only).
 - Large-group attendees you didn't interact with.
 - Calendar-only attendees — people who appear solely on an invite's
   attendee list with no interaction, decision, or discussion attributed to them.
-- Assistants handling only logistics.
+- Assistants who handle only logistics.
 
 People who don't get their own note go in the Organization note's `## Contacts`
 section instead.
 
 ## Minimum content bar — no stubs
 
-A People note is only worth creating if you can write a substantive `## Summary`
-(who they are, why you know them, what you're working on together) grounded in
-the source. **If you cannot write that Summary from the source, do not create
-the note** — record the contact in the Organization's `## Contacts` section
-instead.
+Create a People note only if you can write a substantive `## Summary` from the
+source. The Summary says who they are, why you know them, and what you work on
+together. **If you cannot write that Summary from the source, do not create the
+note.** Record the contact in the Organization's `## Contacts` section instead.
 
 Never write a placeholder profile (name + email + generic role + a boilerplate
 "created from…" line and nothing else). An email address and a meeting invite
 are not, on their own, a reason to create a profile. These stubs add noise
-without signal and must not be produced.
+without signal. You must not produce them.
 
 ## Role inference
 
-When role isn't explicit, infer from context and qualify with the basis:
+When the role isn't explicit, infer it from context. Qualify it with the basis:
 
 - Organizer of a cross-company meeting → likely senior or partnerships.
 - Technical questions → likely engineering.
@@ -80,5 +80,5 @@ Format: `**Role:** Product Lead (inferred from evaluation discussions)`.
 
 ## Never auto-create
 
-`Priorities/`. Link to existing entries when referenced; update
-progress / backlinks; never create new ones from extracted content.
+`Priorities/`. Link to existing entries when a source references them. Update
+progress / backlinks. Never create new ones from extracted content.