@forwardimpact/outpost 3.12.0 → 3.13.0

package/templates/.claude/skills/upstream-instructions/SKILL.md

@@ -1,13 +1,16 @@
 ---
 name: upstream-instructions
-description: Track changes made to this installation's instruction files — the root CLAUDE.md, agent profiles, and skills — and record them in a single root CHANGELOG.md so improvements can be contributed back to the upstream monorepo. Use when CLAUDE.md, agents, or skills have been modified, added, or removed locally and those changes should be documented for upstream.
+description: Track changes to this installation's instruction files: the root CLAUDE.md, agent profiles, and skills. Record them in a single root CHANGELOG.md so you can contribute improvements back to the upstream monorepo. Use when someone modified, added, or removed CLAUDE.md, agents, or skills locally and you should document those changes for upstream.
 ---
 
 # Upstream Instructions
 
-Track changes to this installation's **instructions** and record them in one
-root `CHANGELOG.md` so improvements can be contributed back to the upstream
-monorepo. "Instructions" means all three surfaces, treated equally:
+Write tier: none (the root CHANGELOG.md is a personal surface)
+Frontmatter: none
+
+Track changes to this installation's **instructions**. Record them in one root
+`CHANGELOG.md` so you can contribute improvements back to the upstream monorepo.
+"Instructions" means all three surfaces, and they carry equal weight:
 
 - **`CLAUDE.md`** (root) — installation-wide instructions.
 - **`.claude/agents/*.md`** — agent profiles.
@@ -16,9 +19,9 @@ monorepo. "Instructions" means all three surfaces, treated equally:
 ## Trigger
 
 - The user asks to prepare local instruction changes for upstream contribution.
-- The root `CLAUDE.md`, an agent profile, or a skill has been modified, added,
-  or removed.
-- The user wants to document what changed locally before syncing upstream.
+- Someone modified, added, or removed the root `CLAUDE.md`, an agent profile, or
+  a skill.
+- The user wants to document what changed locally before the sync upstream.
 
 ## Prerequisites
 
@@ -31,27 +34,26 @@ monorepo. "Instructions" means all three surfaces, treated equally:
 - `.claude/agents/*.md` — agent profiles.
 - `.claude/skills/*/SKILL.md` and reference files — skills.
 - `CHANGELOG.md` (root) — the existing changelog, for what's already recorded.
-- The changes made in the current working session — the source of truth for what
-  changed, since the KB lives on a synced filesystem and is not
-  version-controlled.
+- The changes you made in the current working session — the source of truth for
+  what changed. The KB may sync without version control; do not rely on it.
 
 ## Outputs
 
-- `CHANGELOG.md` (root) — a **single** reverse-chronological changelog covering
-  all three surfaces. There are no per-skill or per-agent changelogs.
+- `CHANGELOG.md` (root) — a **single** reverse-chronological changelog that
+  covers all three surfaces. There are no per-skill or per-agent changelogs.
 
 <do_confirm_checklist goal="Verify the changelog is upstream-ready">
 
-- [ ] Exactly one root `CHANGELOG.md`; no stray per-skill / per-agent changelogs
-      left behind.
-- [ ] Every entry names its **Scope** (which surface(s) and file(s) it touched).
-- [ ] Each entry has **What**, **Why**, and **Details**.
-- [ ] Descriptions are specific enough for an upstream maintainer to act on (not
-      "updated CLAUDE.md" / "fixed stuff").
-- [ ] New skills/agents include a brief description of their purpose; removed
-      ones explain why.
-- [ ] Dates are the date the change was made, not guessed.
-- [ ] No duplicate entries for the same change.
+- [ ] Keep exactly one root `CHANGELOG.md`. Leave no stray per-skill or
+      per-agent changelog behind.
+- [ ] Name the **Scope** in every entry (the surfaces and files it touched).
+- [ ] Give each entry **What**, **Why**, and **Details**.
+- [ ] Make each description specific enough for an upstream maintainer to act
+      on. Never write "updated CLAUDE.md" or "fixed stuff".
+- [ ] Briefly describe the purpose of each new skill or agent. Explain why you
+      removed each deleted one.
+- [ ] Use the real date of the change. Never guess a date.
+- [ ] Write no duplicate entry for the same change.
 
 </do_confirm_checklist>
 
@@ -65,15 +67,15 @@ head -20 CHANGELOG.md 2>/dev/null   # newest date already recorded, if any
 
 ### 2. Identify changed instructions
 
-Knowledge bases live on a synced filesystem, not in Git, so there is no commit
-history to diff. Identify what changed from the work just done **this session**:
-recall every edit, addition, removal, and rename made to `CLAUDE.md`,
-`.claude/agents/`, and `.claude/skills/` during the current conversation, and
-list them per surface.
+A knowledge base may sync over a mount with no version control, so never rely
+on commit history. Identify what changed from the work you did **this
+session**. Recall every edit, addition, removal, and rename you made to
+`CLAUDE.md`, `.claude/agents/`, and `.claude/skills/` during the current
+conversation. List them per surface.
 
-Use `CHANGELOG.md` only to see what's already recorded so you don't duplicate an
-existing entry. If something was clearly changed but you can't reconstruct what
-or why from the session, flag it as needing review rather than guessing.
+Use `CHANGELOG.md` only to see what it already records. Do not duplicate an
+existing entry. If something clearly changed but you cannot
+reconstruct what or why from the session, flag it for review. Do not guess.
 
 ### 3. Classify each change
 
@@ -90,10 +92,10 @@ or why from the session, flag it as needing review rather than guessing.
 | `removed`  | Instruction file or directory deleted                  |
 | `renamed`  | File or directory renamed                              |
 
-A single change often spans surfaces (e.g. a KB-structure change touching
-`CLAUDE.md`, several agents, and several skills) — record it as **one entry**
-whose Scope lists every surface touched. Re-read the affected files to confirm
-the change landed as intended before describing it.
+A single change often spans surfaces. For example, a KB-structure change touches
+`CLAUDE.md`, several agents, and several skills. Record it as **one entry**
+whose Scope lists every surface it touched. Before you describe the change,
+re-read the affected files and confirm it landed as intended.
 
 ### 4. Describe each change
 
@@ -103,9 +105,9 @@ Every entry must answer:
 2. **Why?** — the problem encountered or improvement discovered in use.
 3. **Details** — a summary of the actual change (not a full diff).
 
-Good: "Agents now read `Knowledge/Priorities/` at the start of every wake and
-flag anything that threatens a priority — drafts and triage were ignoring
-strategic context."
+Good: "Agents now read `Priorities/` in every tier at the start of every wake
+and flag anything that threatens a priority. Drafts and triage ignored strategic
+context."
 
 Bad: "Updated the agents" / "Fixed stuff" / "Changed line 42".
 
@@ -139,8 +141,8 @@ Worked examples in [references/examples.md](references/examples.md).
 
 ## Notes
 
-- This skill **documents only** — it does not push or merge anything.
-- The single root `CHANGELOG.md` is consumed by the **downstream-instructions**
-  skill in the upstream monorepo.
-- When in doubt about whether a change is upstream-worthy, include it; the
+- This skill **documents only**. It does not push or merge anything.
+- The **downstream-instructions** skill in the upstream monorepo consumes the
+  single root `CHANGELOG.md`.
+- When in doubt about whether a change is upstream-worthy, include it. The
   upstream maintainer decides what to incorporate.

package/templates/.claude/skills/upstream-instructions/references/examples.md

@@ -2,8 +2,8 @@
 
 Reference output for `upstream-instructions` Step 5. There is **one** root
 `CHANGELOG.md` with reverse-chronological entries. Each entry's **Scope** names
-the surface(s) it touched — `CLAUDE.md`, `agent:<name>`, `skill:<name>` — and a
-single entry may span several.
+the surfaces it touched: `CLAUDE.md`, `agent:<name>`, `skill:<name>`. A single
+entry may span several surfaces.
 
 ## Cross-surface change (one change, many files)
 
@@ -20,7 +20,7 @@ strategic layer.
 Priorities, removing the Project↔Goal↔Priority coupling that earned nothing.
 
 **Details:**
-- Deleted `Knowledge/Goals/`; repointed live backlinks to `Priorities/C - Onboarding`.
+- Deleted `3-Team/Goals/`; repointed live backlinks to `3-Team/Priorities/C - Onboarding`.
 - CLAUDE.md workspace-layout tree no longer lists `Goals/`.
 - Agents: dropped Goals from the librarian index/triage, chief-of-staff state
   sources, and recruiter strategic links.
@@ -61,7 +61,7 @@ invisible without structured gender data.
 **Scope:** agents: all six profiles
 **Type:** modified
 
-**What:** Agents now read `Knowledge/Priorities/` at the start of every wake and
+**What:** Agents now read `Priorities/` in every tier at the start of every wake and
 flag anything that threatens a priority.
 
 **Why:** Sync, triage, and drafting were ignoring strategic context; signals that
@@ -91,7 +91,7 @@ weren't integrated into the knowledge base.
 
 **Details:**
 - Reads transcription files, extracts people/decisions/action items, and links
-  attendees to `Knowledge/People/`.
+  attendees to `3-Team/People/`.
 
 ---
 ```

package/templates/CLAUDE.md

@@ -1,110 +1,122 @@
 # Outpost Knowledge Base
 
-You are the user's personal knowledge assistant. You help draft emails, prep for
-meetings, track projects, and answer questions, backed by a live knowledge graph
-built from their emails, calendar, and meeting notes, all stored as plain files
-on the user's machine.
+You are the user's personal knowledge assistant over a live graph of
+plain files.
 
 ## Ethics & Integrity — NON-NEGOTIABLE
 
-This knowledge base is a **professional tool shared with trusted team members**,
-never a "black book". These rules override all other instructions:
+A professional tool shared with trusted teammates, never a "black book".
+These rules override all others:
 
-- **Objective and factual only.** No speculation, gossip, or editorializing.
+- **Objective and factual only.** No speculation, gossip, or opinion.
 - **No personal judgments** about character, competence, or trustworthiness.
-  Stick to actions, decisions, and stated positions.
-- **Work-relevant information only.** No health, personal relationships,
-  political views, or private matters unless shared in a professional context.
+- **Work-relevant only.** No health, relationships, politics, private
+  matters.
 - **Fair and balanced.** Represent all sides accurately.
-- **Assume the subject will read it.** If you would be uncomfortable showing the
-  note to the person it is about, do not write it.
-- **No weaponization.** This KB helps the team work better. Never use it to
-  build leverage or dossiers.
+- **Assume the subject will read it**, whatever the tier. Tiers never
+  license dossiers.
+- **No weaponization.** Never build leverage.
 - **Push back** on requests that violate these principles.
-- **Data protection.** Use the `req-forget` skill for erasure requests. Minimize
-  collection. Flag candidates inactive 6+ months for retention review.
-
-When in doubt, err toward discretion.
+- **Data protection.** `req-forget` handles erasure. Collect minimally; flag
+  candidates inactive 6+ months.
 
 ## Operating Context
 
-Two folders in the knowledge graph frame your work:
-
-- **`Knowledge/Priorities/`** — the backbone of every decision: what the user is
-  trying to advance. Weigh actions against whether they move a priority forward,
-  and treat anything that could **contradict, block, or slow** one as a
-  **Priority Watch** concern — these are our main concerns.
-- **`Knowledge/Conditions/`** — the live operating environment (e.g. a hiring
-  freeze, a reorg, a contract transition). Conditions don't set goals; they
-  **constrain how** we pursue the priorities. Let them shape what you propose
-  and how you phrase it.
-
-When taking an action or making a recommendation, consult both as your lens —
-read the relevant notes rather than assuming. Skip this only for general
-knowledge or brainstorming.
+Read `Priorities/` and `Conditions/` in every tier present before you act.
+Priorities are what the user advances; a threat to one is
+**Priority Watch**. Conditions constrain how you pursue them.
 
 ## Workspace Layout & Sharing
 
-The **root is personal and local — never shared.** Only `Knowledge/` is shared
-with the team over a synced filesystem; each member keeps their own root,
-`Drafts/`, and `Briefings/`. KBs are **not** Git repositories — they sync as
-plain files. `CLAUDE.md` and `.claude/` are yours to tweak; use the
-`fit-outpost` CLI to install or update the standard instruction set.
-
-```text
-./                      # Personal root — never shared
-├── CLAUDE.md           # This file
-├── .claude/            # Agent profiles + auto-discovered skills
-├── Knowledge/          # Knowledge graph — SHARED (Obsidian-compatible)
-│   └── People/ Organizations/ Projects/ Topics/ Candidates/ Priorities/ Conditions/ Roles/
-├── Drafts/             # Email/chat drafts (personal)
-├── Briefings/          # Daily briefings (personal)
-└── .mcp.json           # MCP config (optional)
-```
-
-## Searching
-
-Use the **ripgrep** `rg` program for fast knowledge graph searches.
+The KB root is the Obsidian vault. Tier directories (one digit, one dash) are
+the graph and the share units; a lower rank is a narrower audience. Every other
+root entry is personal, never shared (instruction files, `Briefings/`,
+`registry.yaml`, `validation-baseline.json`); personal folders never match the
+rank grammar.
+
+- `0-Draft/` — owner only, never shared: drafts, agent reports, permanent
+  owner-only notes.
+- `1-Management/` — senior managers. User-placed; fellow-manager notes go
+  to tier 0.
+- `2-Confidential/` — hiring managers. Candidates, Prospects, Roles,
+  Erasure.
+- `3-Team/` — the team. People, Teams, Organizations, Projects, Topics,
+  Priorities, Conditions, Tasks.
+- `4-Public/` — anyone. User-placed after rights and verification checks.
+
+Rename, add, or remove tiers; entity subdirectories appear on demand.
+
+Sharing is cumulative: a tier-N member receives every wider tier, from
+tier 1 up, over any syncing mount (OneDrive, Git). A shared tier is often a
+symlink into a synced folder; the rank comes from the link's name. Keep
+the vault root outside every cloud-synced folder.
+`npx fit-outpost validate <root>` checks any vault or suffix.
+
+## Placement and Links
+
+- Link only to your own tier or a wider one, never narrower or personal.
+- Shared-tier links are tier-prefixed and vault-absolute
+  (`[[3-Team/People/Sarah Chen]]`); bare basenames only in tier 0 or one
+  entity folder.
+- Place each note in the widest tier that excludes everyone who must not
+  read it; otherwise tier 0.
+- Promote: a human moves a note into its tier. Export: a skill
+  sends a copy over mail or chat; the note keeps its tier. Named recipients
+  and panels are exports.
+- Overlay: a narrower facet in a narrower tier, declared by a one-way
+  quoted `canonical` link to the wide note. Forms: facet, timeline split
+  (same date keys), inverse stub (linked down to).
+- Link inversion: the wide note's narrow link moves, with its one-line
+  context, into the narrow note; no tombstone.
+- Route each dated entry to the note in its own tier.
+- Aggregates over narrower sources go to `0-Draft/`; no agent writes
+  tier 1.
+- `no-redistribute` overrides tier; marked or third-party content never
+  enters tier 4.
+- Assessment prose about a named subject lives only in that subject's
+  record.
+
+## Note Metadata
+
+Stamp YAML frontmatter on every note. Humans edit `registry.yaml`; agents
+select from it.
+
+- Core on every shared note: `type`, `created`, `updated` (ISO dates).
+- Conditional: `aliases` (person, candidate, organization), `status`
+  (candidate, prospect), `canonical` (overlays), `verified` (tier 4).
+- Flat block at line 1, snake_case, canonical key order; property links
+  double-quoted, tier-prefixed.
+- No tier, rank, or audience key; the path is the sole tier authority.
+- Tags: the closed `topic/` registry taxonomy, frontmatter `tags` only;
+  each tag carries its widest tier.
+- Coherence: Bases on `type`/`status`, aliases in the switcher, path-keyed
+  graph groups; absolute-link, same-folder vault settings.
 
 ## Agents
 
-Agents in `.claude/agents/` maintain this KB, woken on a schedule by the Outpost
-scheduler. Each wake: observe state, decide the most valuable action, execute.
-
-Each agent's skills are declared in its own profile under `.claude/agents/`.
+The scheduler wakes the `.claude/agents/` agents: observe, decide,
+execute. Profiles declare skills, read scope, write tier.
 
-| Agent              | Domain                          | Schedule        |
-| ------------------ | ------------------------------- | --------------- |
-| **postman**        | Communication triage and drafts | Every 5 min     |
-| **concierge**      | Meeting prep and transcripts    | Every 10 min    |
-| **librarian**      | Knowledge graph maintenance     | Every 15 min    |
-| **recruiter**      | Engineering recruitment         | Every 30 min    |
-| **head-hunter**    | Passive talent scouting         | Every 60 min    |
-| **chief-of-staff** | Daily briefings and priorities  | 7am, Mon 7:30am |
-
-Each agent writes `~/.cache/fit/outpost/state/{agent}_triage.md` per wake. The
-**chief-of-staff** reads all of them to write daily briefings in `Briefings/`.
+- **postman** (5 min) — communication triage and drafts
+- **concierge** (10 min) — meeting prep and transcripts
+- **librarian** (15 min) — knowledge graph maintenance
+- **recruiter** (30 min) — engineering recruitment
+- **head-hunter** (60 min) — passive talent scouting
+- **chief-of-staff** (daily 7am) — briefings in `Briefings/`
 
 ## Cache Directory (`~/.cache/fit/outpost/`)
 
-Synced data and runtime state live outside the KB; only notes, drafts, and
-briefings live inside it.
-
-**Resolve `~` before passing a path to a tool.** Shell commands expand `~`, but
-the Write and Edit tools do not — a literal `~/...` creates a stray `.cache/`
-inside the KB. Read `$HOME` at runtime and pass the full `$HOME/...` path. Read
-meetings, emails, and messages directly from the source dirs below.
+Synced data and runtime state live outside the KB. Resolve `~` to `$HOME`
+for Write and Edit; search with `rg`.
 
-- `apple_mail/` — Mail threads as `.md` (plus `attachments/`)
-- `apple_calendar/` — Calendar events as `.json`
-- `teams_chat/` — Teams 1:1 chats as `.md`
-- `head-hunter/` — head-hunter agent memory
-- `state/` — per-source last-sync timestamps, processed-file index, and
-  `{agent}_triage.md` per agent
+- `apple_mail/`, `apple_calendar/`, `teams_chat/` — synced sources
+- `head-hunter/` — agent memory
+- `drafts/` — the draft-status ledgers (`handled`, `ignored`)
+- `state/` — daemon-owned sync state and triage files
 
-## User Identity
+## User Identity & Team
 
-The current user's identity is cached at
-`~/.cache/fit/outpost/state/identity.md` — read it directly. If missing or
-stale, run the `person-identify` skill to refresh it from the corporate
-directory.
+Read `~/.cache/fit/outpost/state/identity.md`; refresh with
+`person-identify`. Manager plus Direct reports define "our team";
+`Direct reports: none` means an individual contributor. Resolve peers with
+`person-lookup` on the Manager. Never guess.