people-update
Updates or creates a person note in 02-people/ after an interaction. Append-only on the timeline, never overwriting existing observations. Handles fuzzy matching to avoid duplicates. Use when the user
SKILL.md.claude/skills/people-update/SKILL.md
GitHubSkill: People Update
When to activate
- The user explicitly says: "people update", "[Name]'s note", "note on [Name]", "update [Name]".
- The user shares significant info about a person (role change, new behavioral observation, important feedback).
- As propagation from
meeting-ingest(interaction logged automatically). - As propagation from
braindump(if a significant interaction is detected). - The user asks to create a new person note.
Do NOT use people-update when:
- A passing mention with no new info → skip.
- The last interaction was < 24h ago AND the new info isn't substantial → skip (avoid over-writing).
People-CRM philosophy
This is the strategic core of the second brain for anyone who manages relationships. A person note is NOT a résumé:
- It's an interaction journal (append-only timeline).
- It's an evolving mental model (compiled truth + recency markers).
- It's a relationship-strategy tool (motivations, levers, observed constraints).
The decisive test: if in a year the user must re-onboard with this person after 6 months of no contact, does the note let them pick up smoothly? If yes = useful note. If no = vault rot.
Preflight
- Read
_CLAUDE.md(rules, the person type schema) and00-inbox/MY-PROFILE.md(working language, critical stakeholders, per-skill preferences). - Get the real timestamp.
- Get context: the new interaction, source (meeting / email / chat / observation), nature.
- Determine the invocation mode:
- Manual: explicit invocation → enrich fully (compiled truth, observations, follow-ups).
- Auto: invoked by daily-brief orchestration → minimal update only (see "Auto mode").
- Propagation from meeting-ingest: intermediate — log the interaction with a factual observation, without touching compiled truth.
Auto mode (invoked by daily-brief)
When invoked by daily-brief orchestration, specific behavior:
Allowed in auto mode
✅ Update frontmatter:
last-interaction: YYYY-MM-DD(today)updated: YYYY-MM-DD(today)- Clear
staleness-flagif present
✅ Append ONE aggregated timeline entry for the day:
### YYYY-MM-DD — Daily interactions (auto-logged)
- Calendar: [N events, short detail "1-1 30min 'topic'"]
- Email: [N threads, main topic if detectable]
- Chat: [N DMs or mentions]
- Source: daily-brief auto-propagation
FORBIDDEN in auto mode
❌ NEVER modify "Compiled truth" (manual mode only). ❌ NEVER modify "Open threads" (manual mode only). ❌ NEVER create a new person note (flag in the brief for the user to validate). ❌ NEVER add an interpretive observation to the timeline. ❌ NEVER modify the tags (role, region).
Recognizable format
The (auto-logged) suffix in the timeline entry header is mandatory and
non-modifiable. It lets challenge-decision and other skills distinguish
human signal from automatic signal.
Daily duplicate handling
If an (auto-logged) entry already exists for the day (daily-brief run twice or by debug):
- Update the existing entry instead of creating a new one.
- Preserve already-logged sources, add only new ones.
- NEVER duplicate.
Weighting for challenge-decision
(auto-logged) entries carry less signal than manual observations.
challenge-decision should use them mainly for:
- ✅ Frequency quantification (how many interactions over X months).
- ✅ Temporal pattern detection (an interaction that fades gradually).
- ❌ NOT as evidence of a behavioral pattern or strategic positioning.
Staleness-flag: automatic management
The staleness-flag field is fully managed automatically:
- Set by the
Stale People Checkscheduled task iflast-interaction > 30 days. - Cleared by
daily-briefauto mode as soon as a new interaction is detected. - Cleared by a manual
people-updateinvocation (any update clears the flag).
Flag format:
staleness-flag: "stale-30d-since-2026-05-22"
# or for critically stale:
staleness-flag: "stale-60d-since-2026-04-22"
The user NEVER touches this flag manually. The system self-heals.
Process
Step 1 — Identify the person
1.1 Fuzzy match
Search 02-people/*.md:
- Exact full-name match.
- First + last name with typo tolerance.
- First name only (ambiguous, ask for confirmation).
- Description ("the PM in Spain", "my manager") → cross-reference frontmatter.
1.2 Cases
- Single match found → proceed with update.
- Multiple matches → present the list, ask for confirmation.
- No match → offer to create (Step 2).
- Match with typo → confirm before acting: "Do you mean [[Alex Rivera]]?"
Step 2 — Creation (if new person)
⚠️ ALWAYS ask for confirmation before creating a new person note. An orphan note is less harmful than a duplicate.
Ask the user if not obvious:
- Correct full name?
- Role / function?
- Team / company?
- Region?
- Relationship to you (direct-report, peer, manager, stakeholder, external)?
Create the note at 02-people/First Last.md with this template:
---
date: YYYY-MM-DD # date of the first logged interaction
updated: YYYY-MM-DD
type: person
tags: [person, <role-tag>, <region-tag>]
role: "[exact role]"
company: "" # company / org name
team: "[team]"
region: WE|NA|LATAM|APAC|Global
relationship: direct-report|peer|manager|stakeholder|external
languages: ["en"]
last-interaction: YYYY-MM-DD
staleness-flag: ""
ai-first: true
---
## For future Claude
Person note for [Name], [role] at [company/team]. First interaction logged on [date].
[1-2 sentence summary of relationship and context.]
## Compiled truth
[What's stable and known about this person, updated episodically. NOT the timeline. Rather:]
- **Professional background**: [trajectory, context]
- **Working style**: [stable observations]
- **Apparent motivations**: [what seems to drive them]
- **Sensitive topics / red buttons**: [what to avoid]
- **Levers / good practices**: [what works to collaborate]
- **Internal network**: [who they work closely with]
## Timeline
[APPEND-ONLY. Each entry = 1 interaction or observation, dated, sourced.]
### YYYY-MM-DD — [Interaction type]
- Source: [[04-meetings/...]] / email / chat / observation
- What: [1-3 factual sentences about what happened]
- Observation: [interpretation, hypothesis, detected signal]
- [ ] Follow-up: [action if applicable — checkbox form so task-roundup picks it up;
plain `- Follow-up:` (no checkbox) for FYI-only notes]
## Open threads
[Ongoing topics with this person, to track. Editable section, not append-only.]
## Links
- Shared projects: [[03-projects/...]]
- Manager: [[02-people/...]]
- Reports: [[02-people/...]]
- Recent meetings: [[04-meetings/...]]
Step 3 — Update (existing note)
3.1 Append timeline
Add ONE entry to the "Timeline" section:
### 2026-05-20 — Weekly 1-1
- Source: [[04-meetings/2026-05-20-1to1-alex]]
- What: Alex raised friction on the qualification script V2, especially edge cases.
Looking for a sponsor to push a training redesign.
- Observation: 2nd time this month they've raised this proactively. Signal they want
to make it a project.
- [ ] Follow-up: decide whether to put it in their Q3 development plan — owner: me
⚠️ Append-only: NEVER delete an existing timeline entry. If old info is contradicted, add a new entry that mentions the contradiction; don't edit in place.
3.2 Update compiled truth (if applicable)
"Compiled truth" is editable but sparingly. Modify only if:
- You have a new stable observation (not a one-off signal).
- It's confirmed across multiple interactions (visible recency markers).
When you modify "Compiled truth", include the update date:
- **Working style**: very field-oriented, little patience for abstract process *(updated 2026-05-20, confirmed across 3 interactions)*
3.3 Update frontmatter
updated:→ today.last-interaction:→ today.- If role/team/region changed → update those fields (and log the change in the timeline).
3.4 Update "Open threads" and "Links"
- Add the ongoing topic to "Open threads" if not already there.
- Add the meeting/project to Links if new.
Step 4 — Propagation
4.1 People index (optional)
If 02-people/_index.md exists, update the relevant line (name, role, last interaction, status).
4.2 Daily note
Append to 01-daily/YYYY-MM-DD.md under ## People touched today:
- [[02-people/Alex Rivera]] — [interaction type] — topic: [topic]
4.3 Related projects
If the interaction concerns a project, verify the project is linked under "Links" and related-people.
Step 5 — Report
✓ Note updated: 02-people/Alex Rivera.md
✓ Timeline: 1 entry added (weekly 1-1)
✓ Compiled truth: "Working style" updated (3rd-iteration confirmation)
✓ Daily note 2026-05-20 updated
✓ Open threads: "Qualification script training redesign" added
→ Pattern detected: 2nd proactive raise on this topic this month
→ Suggestion: create project [[03-projects/Qualification Script Training Refresh]]?
Suggested tags for people
Role (1 required tag)
agent|team-lead|manager|head|vp|c-levelspecialist|coach|trainerpm|eng|design|data|opsexternal-vendor|external-client
Region (1 required tag if internal)
region-we|region-na|region-latam|region-apac|region-global
Optional tags
direct-report|peer|manager-of-mine|sponsor|blocker|championhigh-trust|building-trust|caution
Anti-patterns to avoid
❌ Overwriting the timeline — append-only, never retroactive edits. ❌ Compiled truth without recency — if you update, date the change. ❌ Duplicate — fuzzy-match before create, always. ❌ Orphan note — make sure at least today's daily note links to it. ❌ Unsourced judgment — every observation must point to a source (dated meeting/email/observation). ❌ Inventing info — if you don't know, write "unknown" or ask the user. ❌ Descriptive note with no use — no flat résumé. Always ask: "useful in 6 months?"
Special cases
External person (client, vendor, partner)
company:= external name.relationship:= external.- More tolerance for incompleteness (less info available).
- Explicitly log the nature of the contact (commercial, customer success, partnership, etc.).
Person who left the org / leaver
- Keep the note, never delete.
- Update frontmatter:
status: alumni,relationship: external-alumni. - Note in timeline: "YYYY-MM-DD — Left for [destination]".
- Useful for your future network.
A key direct report
Special case: the person the user interacts with most. The note can get long. Manage it:
- Timeline grouped by month (sub-headers
## YYYY-MM). - Editable "Development plan" section.
- Editable "Quarterly objectives" section.
- Special tags:
direct-report+high-trust.
Cross-region stakeholder
For multi-region stakeholders:
- Tag
region-global. - Explicit note of sub-teams / zones of influence.
- Timeline tagged by regional context if relevant.
First negative observation
If you log a first potentially negative observation (frustration, friction, disagreement), do it factually, never as a value judgment. The goal is to track signals, not to label people.
✅ Good: "Alex expressed frustration about a lack of product-PM support during the standup. Tense tone, visible disagreement."
❌ Bad: "Alex is negative and hard to manage."
Final note
This is probably the most valuable skill long-term. A well-kept people CRM = cumulative relationship capital. Poorly kept = a vault that pollutes searches.
Discipline > volume. 20 excellent notes beat 200 mediocre ones.