@forwardimpact/outpost 3.0.3

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

@@ -0,0 +1,187 @@
+---
+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.
+---
+
+# 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.
+
+## Trigger
+
+- Schedule (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/`).
+
+## Prerequisites
+
+- Synced data in `~/.cache/fit/outpost/` and/or ad-hoc paths.
+- User identity in `USER.md` (Name, Email, Domain).
+
+## Inputs
+
+- `~/.cache/fit/outpost/apple_mail/*.md`,
+  `~/.cache/fit/outpost/apple_calendar/*.json`,
+  `~/.cache/fit/outpost/teams_chat/*.md`.
+- Ad-hoc paths: `.pdf`, `.txt`, `.md`, `.rtf`, `.doc`, `.docx`, `.csv`, `.xlsx`.
+- `~/.cache/fit/outpost/state/graph_processed` — processed-file index (TSV,
+  shared with `req-track` and `hyprnote-process`).
+- `USER.md` — user identity for self-exclusion.
+
+## Outputs
+
+- `knowledge/People/`, `knowledge/Organizations/`, `knowledge/Projects/`,
+  `knowledge/Topics/` — created or updated.
+- `knowledge/Goals/`, `knowledge/Priorities/` — **updated only**, never
+  auto-created.
+- `knowledge/Conditions/` — created when cross-cutting patterns are detected, or
+  updated.
+- `knowledge/Roles/`, `knowledge/Candidates/*/brief.md` — enriched with inferred
+  metadata.
+- `~/.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 to each person.
+- [ ] All links use absolute paths `[[Folder/Name]]`; bidirectional links
+      consistent (incl. Goal ↔ Project, Priority ↔ Goal).
+- [ ] Summaries describe relationship, not communication method; key facts are
+      substantive; open items are commitments.
+- [ ] State changes logged with `[Field → value]`; no Goal or 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.
+
+</do_confirm_checklist>
+
+## Procedure
+
+Process **10 files per run**. Write **one file at a time** — do not batch
+writes.
+
+### 0. Load context and pick the batch
+
+Read `USER.md`. Find new/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.
+
+### 1. Build the knowledge index
+
+```bash
+find knowledge/People knowledge/Organizations knowledge/Projects \
+     knowledge/Topics knowledge/Goals knowledge/Priorities \
+     knowledge/Conditions -name "*.md" 2>/dev/null
+```
+
+For each note, `head -20` to capture key fields. Build a mental index of People,
+Organizations, Projects, Goals, 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).
+
+### 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 follow **meeting** rules (can create notes).
+
+Exclude self per [references/sources.md](references/sources.md#self-exclusion).
+Collect every name variant per
+[references/resolution.md](references/resolution.md#name-variant-collection).
+
+### 4. Resolve entities
+
+For each variant, search the knowledge index. Apply the
+[matching table](references/resolution.md#matching) and the
+[disambiguation priority](references/resolution.md#disambiguation-priority).
+Goals and Priorities are
+[never auto-created](references/resolution.md#never-auto-create) — link to
+existing entries only.
+
+### 5. Identify new entities (meetings 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.
+
+### 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.
+
+### 7. Detect state changes and structural enrichment
+
+- **State changes** (Project status, open-item resolution, role / title changes,
+  relationship changes): tables in
+  [references/content.md](references/content.md#state-change-tables). Be
+  conservative; log inline `[Field → value]`.
+- **Recruitment** (Req-number detection, hiring-manager / recruiter /
+  domain-lead inference):
+  [references/recruitment.md](references/recruitment.md).
+- **Goal & Priority links** (Step 7c): rules in
+  [references/links.md](references/links.md#goals-step-7c) and
+  [Priorities](references/links.md#priorities-step-7c). **Never auto-create.**
+- **Conditions** (cross-cutting states affecting ≥ 3 entities):
+  [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)".
+
+### 9. Write updates
+
+For **new** entities, use the templates indexed by
+[references/TEMPLATES.md](references/TEMPLATES.md).
+
+For **existing** entities, apply targeted edits — never rewrite the file:
+
+- Add the new activity entry at the **top** of `## Activity` (reverse
+  chronological).
+- Update `Last seen`.
+- 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
+[bidirectional link rules](references/links.md#bidirectional-link-rules).
+
+### 11. Update graph state
+
+```bash
+node scripts/state.mjs update "$FILE"
+```
+
+Run for every processed file. The state file is shared with `req-track` and
+`hyprnote-process`, so this prevents either skill from re-scanning the same
+input.

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

@@ -0,0 +1,14 @@
+# Note Templates
+
+Templates for creating new knowledge-base notes. Split by entity family to keep
+each file under the L5 cap. `hyprnote-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-goals-priorities.md](templates-goals-priorities.md) — Goals,
+  Priorities. **Never auto-created** by `extract-entities` or `hyprnote-process`
+  — set by the user.
+- [templates-conditions.md](templates-conditions.md) — Conditions (time-bound
+  cross-cutting states).

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

@@ -0,0 +1,55 @@
+# 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.
+
+## Detection signals
+
+When **3+ different entity updates in the same processing run** reference the
+same constraint or state, suspect a Condition.
+
+| Signal                                   | Example                          | Potential Condition         |
+| ---------------------------------------- | -------------------------------- | --------------------------- |
+| "on hold", "paused", "frozen", "blocked" | "All recruitment is on hold"     | Hiring Freeze               |
+| "reorg", "restructuring", "transition"   | "Team may move outside division" | Organizational Restructure  |
+| "budget", "cost reduction", "headcount"  | "30% reduction planned"          | Budget Constraint           |
+| "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
+
+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").
+3. **Match exists:** update with new activity and any changes to status,
+   blocker, or affected entities.
+
+## Updating affected entities
+
+When a Condition is created or updated:
+
+1. Add `[[Conditions/{Condition}]]` to the `## Blockers` section of affected
+   Goals.
+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}]]`.
+
+## Resolving Conditions
+
+Source content indicates the Condition has ended: "approved", "freeze lifted",
+"reorg complete", "back on track".
+
+- Set `**Status:** resolved`, `**Resolved:** {date}`.
+- Remove `[[Conditions/{Condition}]]` from affected Goal `## Blockers`.
+- 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.

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

@@ -0,0 +1,104 @@
+# Content Extraction
+
+Reference for `extract-entities` Step 6 (extract content) and Step 7 (detect
+state changes).
+
+## Decisions
+
+Signals: "We decided…", "We agreed…", "Let's go with…", "Approved", "Confirmed".
+
+## Commitments
+
+Signals: "I'll…", "We'll…", "Can you…", "Please send…", "By Friday".
+
+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.
+
+**Never include:** meta-commentary about missing data, placeholder text, or
+data-quality observations. If no key facts exist, leave the section empty.
+
+## Open items — commitments only
+
+```markdown
+- [ ] Send API documentation — by Friday
+- [ ] Schedule follow-up call with CTO
+```
+
+**Never include:** "find their email", "add their role", "research company
+background".
+
+## Activity — one line per source
+
+```markdown
+- **2025-01-15** (meeting): Kickoff for [[Projects/Acme Integration]]. [[People/David Kim]] needs API access.
+```
+
+Always use canonical names with absolute paths (`[[People/Name]]`,
+`[[Organizations/Name]]`).
+
+## Summary — relationship not method
+
+2–3 sentences answering: "Who is this person and why do I know them?"
+
+- **Good:** "VP Engineering at [[Organizations/Acme Corp]] leading the
+  [[Projects/Acme Integration]] pilot."
+- **Bad:** "Attendee on the scheduled meeting (Aug 12, 2024)."
+
+## State-change tables
+
+### Project status
+
+| Signal                                | New status |
+| ------------------------------------- | ---------- |
+| "approved" / "signed" / "green light" | active     |
+| "on hold" / "pausing" / "delayed"     | on hold    |
+| "cancelled" / "not proceeding"        | cancelled  |
+| "launched" / "completed" / "shipped"  | completed  |
+| "exploring" / "considering"           | planning   |
+
+### Open-item resolution
+
+| Signal                       | Action          |
+| ---------------------------- | --------------- |
+| "Here's the X you requested" | Mark X complete |
+| "I've sent the X"            | Mark X complete |
+| "X is done" / "X is ready"   | Mark X complete |
+
+Change `- [ ]` → `- [x]` with completion date.
+
+### Role / title
+
+- New title in email signature.
+- "I've been promoted to…".
+- Different role than what's in the note.
+
+### Relationship
+
+- "I've joined [New Company]".
+- "We signed the contract" → prospect → customer.
+- New email domain for a known person.
+
+## Conservatism
+
+Only apply clear, unambiguous state changes. If uncertain, add to activity but
+don't change fields.
+
+Log changes inline:
+
+```markdown
+- **2025-01-20** (email): Leadership approved pilot. [Status → active]
+```
+
+## Duplicate check (Step 8)
+
+Before writing:
+
+- Look at the Activity section for an existing entry on this date from this
+  source.
+- Compare key facts; skip duplicates.
+- Don't add the same open item twice.
+- If new info contradicts existing, keep both with "(needs clarification)".

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

@@ -0,0 +1,48 @@
+# Bidirectional Links
+
+Reference for `extract-entities` Step 10 and Step 7c (Goals / Priorities).
+
+## Bidirectional link rules
+
+After writing, verify each link goes both ways.
+
+| If you add...          | Then also add...                             |
+| ---------------------- | -------------------------------------------- |
+| Person → Organization  | Organization → Person (in People section)    |
+| Person → Project       | Project → Person (in People section)         |
+| Project → Organization | Organization → Project (in Projects section) |
+| Project → Goal         | Goal → Project (in Projects section)         |
+| Goal → Priority        | Priority → Goal (in Goals section)           |
+| Project → Priority     | Priority → Project (in Projects section)     |
+| Condition → Goal       | Goal → Condition (in Blockers section)       |
+| Condition → Project    | Project → Condition (in Related section)     |
+| Condition → Role       | Role → Condition (notes or status field)     |
+
+Use absolute paths everywhere: `[[People/Sarah Chen]]`,
+`[[Organizations/Acme Corp]]`, `[[Projects/Acme Integration]]`,
+`[[Goals/Goal Name]]`, `[[Priorities/Priority Name]]`,
+`[[Conditions/Condition Name]]`.
+
+## Goals (Step 7c)
+
+When source content references an existing `knowledge/Goals/*.md`:
+
+- Add a `[[Goals/{Goal}]]` link to the relevant Project or Topic activity entry.
+- Add a progress entry to the Goal's `## Progress` section.
+- If evidence suggests a status change ("we won't hit the Q3 target"), update
+  `**Status:**` and log `[Status → value]`.
+
+**Never auto-create Goals.**
+
+## 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.
+- 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 Goal which links to a Priority doesn't need a redundant direct Priority
+link.

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

@@ -0,0 +1,57 @@
+# Recruitment Inference
+
+Reference for `extract-entities` Step 7b. Enrich `knowledge/Roles/` and
+`knowledge/Candidates/` with metadata that no single source carries.
+
+## Requisition number detection
+
+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. Search `rg "{req_number}" knowledge/` for context to enrich it.
+3. **File exists:** check whether the email provides new metadata (hiring
+   manager, recruiter, locations) and update the Role file.
+
+## 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:
+
+1. Cross-reference the candidate against `knowledge/Candidates/`.
+2. Extract the **organizer**. If the organizer isn't the user (per `USER.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 `—`.
+
+## Recruiter — email-thread inference
+
+When a thread references candidates (name match against
+`knowledge/Candidates/`):
+
+1. Cross-reference To/CC against `knowledge/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 `—`).
+
+## Domain lead — reporting-chain resolution
+
+When a hiring manager is newly identified:
+
+1. Read their People note for `**Reports to:**`.
+2. Walk up the chain to a VP or senior leader listed in a stakeholder map or
+   organizational hierarchy note.
+3. Set both the Role file's `Domain lead` and the candidate brief's
+   `Domain lead`.
+
+## 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.

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

@@ -0,0 +1,71 @@
+# Entity Resolution
+
+Reference for `extract-entities` Steps 2b–5.
+
+## Name-variant collection
+
+Extract every way each entity is referenced.
+
+- **People:** full names, first / last names, initials, email addresses,
+  roles/titles, pronouns with clear antecedents.
+- **Organizations:** full names, short names, abbreviations, email domains.
+- **Projects:** explicit names, descriptive references ("the pilot", "the
+  deal").
+- **Goals:** references to time-bound targets, OKRs, or measurable outcomes that
+  match `knowledge/Goals/` entries.
+- **Priorities:** references to strategic directions that match
+  `knowledge/Priorities/` entries.
+
+## Matching
+
+| Source has               | Note has                 | Match if                  |
+| ------------------------ | ------------------------ | ------------------------- |
+| First name "Sarah"       | Full name "Sarah Chen"   | Same organization context |
+| Email "sarah@acme.com"   | Email field              | Exact match               |
+| Email domain "@acme.com" | Organization "Acme Corp" | Domain matches org        |
+| Any variant              | Aliases field            | Listed in aliases         |
+
+## Disambiguation priority
+
+Email match > Organization context > Role match > Aliases > Recency.
+
+If still ambiguous, **skip** rather than guess.
+
+## "Would I prep for this person?" — Step 5
+
+Apply for entities not resolved to existing notes (meetings only).
+
+**Create a note for:**
+
+- Decision makers or key contacts at customers, prospects, partners.
+- Investors or potential investors.
+- Candidates being interviewed.
+- Advisors or mentors with ongoing relationships.
+- Introducers who connect you to valuable contacts.
+
+**Do not create notes for:**
+
+- Transactional service providers (bank employees, support reps).
+- One-time administrative contacts.
+- Large-group attendees you didn't interact with.
+- Assistants handling only logistics.
+
+People who don't get their own note go in the Organization note's `## Contacts`
+section instead.
+
+## Role inference
+
+When role isn't explicit, infer from context and qualify with the basis:
+
+- Organizer of a cross-company meeting → likely senior or partnerships.
+- Technical questions → likely engineering.
+- Pricing questions → likely procurement or finance.
+- "I'll need to check with my team" → manager.
+- "I can make that call" → decision maker.
+
+Format: `**Role:** Product Lead (inferred from evaluation discussions)`.
+
+## Never auto-create
+
+`Goals/` and `Priorities/`. Link to existing entries when referenced; update
+progress / backlinks; never create new ones from extracted content.

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

@@ -0,0 +1,70 @@
+# Source Classification
+
+Reference for `extract-entities` Step 1.
+
+## Type detection
+
+- `Meeting:` / `Attendees:` / `Transcript:` headers → **meeting** (creates
+  notes).
+- `From:` and `To:` or `Subject:` → **email** (updates only).
+- `**Platform:** Microsoft Teams` → **teams chat** (updates only).
+- File in `Voice Memos/` → **voice memo** (creates notes).
+- File in `apple_calendar/` → **calendar event** (enriches existing notes only).
+- Ad-hoc document (from `~/Desktop/`, `~/Downloads/`, or another skill passing
+  the path) → **document** (creates notes — meeting rules).
+
+## Always process — never skip
+
+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").
+
+## Skip entirely
+
+- Newsletters (unsubscribe links, "View in browser", bulk-sender indicators).
+- Marketing emails (promotional language, no-reply senders).
+- Automated notifications (GitHub, Jira, Slack, CI/CD, shipping).
+- Spam / cold outreach with no existing relationship.
+- Product-update emails, release notes, changelogs.
+- Social-media notifications.
+- Receipts and order confirmations.
+- Calendar-invite emails that are just logistics.
+- Mass emails (many recipients, mailing-list headers).
+
+## Process — update existing notes only
+
+- Emails from people already in `knowledge/People/`.
+- Emails referencing existing projects or organizations.
+
+## Process — can create new notes
+
+- Meeting transcripts with external attendees.
+- Voice memos.
+- Ad-hoc documents.
+
+## Warm-intro exception
+
+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.
+
+## Self-exclusion
+
+Never create or update notes for the user (matches name, email, or @domain from
+`USER.md`) or for `@{user.domain}` colleagues.
+
+## Source-type rules summary
+
+| Source type             | Creates notes?  | Updates notes? | Detects state changes? |
+| ----------------------- | --------------- | -------------- | ---------------------- |
+| Calendar event          | No              | Yes (always)   | Yes                    |
+| Meeting                 | Yes             | Yes            | Yes                    |
+| Voice memo              | Yes             | Yes            | Yes                    |
+| Ad-hoc document         | Yes             | Yes            | Yes                    |
+| Email (known contact)   | No              | Yes            | Yes                    |
+| Email (unknown contact) | No (SKIP)       | No             | No                     |
+| Email (warm intro)      | Yes (exception) | Yes            | Yes                    |
+| Teams chat              | No              | Yes            | Yes                    |

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

@@ -0,0 +1,36 @@
+# 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.
+
+```markdown
+# {Condition Name}
+
+## Info
+**Status:** {active|resolved}
+**Since:** {YYYY-MM-DD}
+**Resolved:** {YYYY-MM-DD or —}
+**Trigger:** {What caused this condition}
+**Blocker:** {Who/what must act for this to resolve}
+**Resolution signal:** {What would indicate this condition has ended}
+
+## Affects
+{Goals, Projects, Roles, and People impacted by this condition}
+- [[Goals/{Goal}]] — {how it's affected}
+- [[Projects/{Project}]] — {how it's affected}
+- [[Roles/{Role}]] — {how it's affected}
+
+## Agent implications
+{How agents should modify their behavior while this condition is active}
+- **recruiter:** {e.g. "Hold offers. Continue interviews. Contractor route viable."}
+- **postman:** {e.g. "Don't flag recruitment emails as urgent."}
+- **chief-of-staff:** {e.g. "Surface in every briefing until resolved."}
+- **head-hunter:** {e.g. "Continue scouting but note freeze in prospect notes."}
+
+## Activity
+- **{YYYY-MM-DD}** ({source}): {Update — new information, escalation, progress toward resolution}
+
+## Key facts
+{substantive facts only — leave empty if none}
+```