@forwardimpact/outpost 3.12.0 → 3.12.1

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

@@ -2,10 +2,11 @@
 /**
  * Scan for unprocessed emails and output their IDs and subjects.
  *
- * Checks ~/.cache/fit/outpost/apple_mail/ for email thread markdown files not
- * yet listed in Drafts/handled or Drafts/ignored. Outputs one tab-separated
- * line per unprocessed thread: email_id<TAB>subject. Used by the draft-emails
- * skill to identify threads that need a reply.
+ * 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.
  */
 
 import { existsSync, readdirSync, readFileSync } from "node:fs";

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

@@ -1,13 +1,15 @@
 #!/usr/bin/env bun
 /**
- * Send an email via Apple Mail using AppleScript.
+ * Send an email through Apple Mail with AppleScript.
  *
- * Builds an AppleScript command to create and send an outgoing message through
- * Apple Mail. The script writes a temporary .scpt file, executes it with
- * osascript, and cleans up afterwards. Mail.app must be running.
+ * The script builds an AppleScript command. That command creates an outgoing
+ * message and sends it through Apple Mail. The script writes a temporary
+ * .scpt file. It runs the file with osascript. It then deletes the file.
+ * Mail.app must run.
  *
- * The body should be plain text — no HTML. Do NOT include an email signature
- * or sign-off; Apple Mail appends the user's configured signature automatically.
+ * Use plain text for the body. Do not use HTML. Do NOT include an email
+ * signature or sign-off. Apple Mail appends the user's configured signature
+ * automatically.
  */
 
 import { execFileSync } from "node:child_process";
@@ -20,7 +22,7 @@ import {
 import { basename, join } from "node:path";
 import { tmpdir } from "node:os";
 
-const HELP = `send-email — send an email via Apple Mail
+const HELP = `send-email — send an email through Apple Mail
 
 Usage: node scripts/send-email.mjs --to <addrs> --subject <subj> --body <text> [options]
 
@@ -30,10 +32,10 @@ Options:
   --bcc <addrs>      Comma-separated BCC recipients
   --subject <subj>   Email subject line (required)
   --body <text>      Plain-text email body (required)
-  --draft <path>     Draft file — deleted after send, ID appended to Drafts/handled
+  --draft <path>     Draft file. The script deletes it after send and appends the ID to Drafts/handled
   -h, --help         Show this help message and exit
 
-Mail.app must be running. No signature or sign-off needed — Apple Mail appends it.`;
+Mail.app must run. You need no signature or sign-off. Apple Mail appends it.`;
 
 if (process.argv.includes("-h") || process.argv.includes("--help")) {
   console.log(HELP);

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

@@ -1,25 +1,25 @@
 ---
 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 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.
 ---
 
 # Extract Entities
 
 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
+under `Knowledge/`. 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,7 +31,7 @@ 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
 
@@ -39,54 +39,54 @@ under `Knowledge/`. The core knowledge-graph builder.
   `Knowledge/Topics/` — created or updated.
 - `Knowledge/Priorities/` — **updated only**, never
   auto-created.
-- `Knowledge/Conditions/` — created when cross-cutting patterns are detected, or
+- `Knowledge/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
+  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 absolute paths `[[Folder/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
 
@@ -96,27 +96,28 @@ find Knowledge/People Knowledge/Organizations Knowledge/Projects \
      Knowledge/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 +127,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,42 +135,42 @@ 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).
@@ -180,7 +181,7 @@ For **existing** entities, apply targeted edits — never rewrite the file:
 
 ### 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 +190,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,14 @@
 # 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.
 
 - [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,18 +18,18 @@ 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").
+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.
@@ -39,9 +39,9 @@ When a Condition is created or updated:
 4. Log the Condition reference in activity entries:
    `- **YYYY-MM-DD** ({source}): {update}. See [[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}`.
@@ -51,5 +51,6 @@ Source content indicates the Condition has ended: "approved", "freeze lifted",
 ## 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

@@ -4,7 +4,7 @@ Reference for `extract-entities` Step 10 and Step 7c (Priorities).
 
 ## Bidirectional link rules
 
-After writing, verify each link goes both ways.
+After you write, verify each link goes both ways.
 
 | If you add...          | Then also add...                             |
 | ---------------------- | -------------------------------------------- |
@@ -24,10 +24,10 @@ Use absolute paths everywhere: `[[People/Sarah Chen]]`,
 Match source themes against priority names and descriptions.
 
 - Add `[[Priorities/{Priority}]]` to a Project or Topic `## Related` section if
-  not already present.
+  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

@@ -15,30 +15,31 @@ 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 Knowledge/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
    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/`.
 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 `Knowledge/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
 
@@ -49,7 +50,7 @@ When a thread references candidates (name match against
 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 +64,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.
@@ -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.

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

@@ -19,11 +19,11 @@ Calendar events. Internal-only meetings still enrich Project and Topic notes
 (decisions, agenda items). Only skip all-day placeholders with no attendees and
 no description (e.g. "Block", "OOO").
 
-**Stub guard:** calendar attendance alone never creates a People note — calendar
-events only *enrich* existing notes (see the table below). An attendee who is
-only on the invite list, with no interaction or decision attributed to them, is
-not profiled. If they matter, they go in the Organization's `## Contacts`. Never
-write a placeholder profile; see the
+**Stub guard:** calendar attendance alone never creates a People note. Calendar
+events only *enrich* existing notes (see the table below). Do not profile an
+attendee who is only on the invite list, with no interaction or decision
+attributed to them. If they matter, they go in the Organization's `## Contacts`.
+Never write a placeholder profile. See the
 [minimum content bar](resolution.md#minimum-content-bar--no-stubs).
 
 ## Skip entirely
@@ -54,9 +54,9 @@ write a placeholder profile; see the
 If an email is a warm introduction from someone with a note, and they introduce
 a new person, **create** a note for the introduced person.
 
-Signals: subject contains "Intro:", "Introduction:", "Meet", "Connecting"; body
-contains "introduce you to", "want to connect", "meet [Name]"; new person is
-CC'd.
+Signals: the subject contains "Intro:", "Introduction:", "Meet", or
+"Connecting". The body contains "introduce you to", "want to connect", or
+"meet [Name]". The sender CCs the new person.
 
 ## Self-exclusion
 

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

@@ -1,8 +1,8 @@
 # Condition Template
 
 Conditions are time-bound organizational states that affect multiple entities.
-They can be **auto-created** by the librarian agent when cross-cutting patterns
-are detected, or manually created by the user. Lifecycle: active → resolved.
+The librarian agent can **auto-create** them when it detects cross-cutting
+patterns. The user can also create them manually. Lifecycle: active → resolved.
 
 ```markdown
 # {Condition Name}