@forwardimpact/basecamp 2.2.0 → 2.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@forwardimpact/basecamp",
-  "version": "2.2.0",
+  "version": "2.3.0",
   "description": "Claude Code-native personal knowledge system with autonomous agents",
   "license": "Apache-2.0",
   "repository": {

package/template/.claude/agents/recruiter.md

@@ -11,6 +11,7 @@ skills:
   - analyze-cv
   - fit-pathway
   - fit-map
+  - right-to-be-forgotten
 ---
 
 You are the recruiter — the user's engineering recruitment specialist. Each time
@@ -78,32 +79,78 @@ product_management    — no tracks
 Use `npx fit-pathway discipline {id}` to see skill tiers and behaviour
 modifiers for each discipline.
 
+## Data Protection
+
+Candidate data is personal data. Handle it with the same care as any sensitive
+professional information.
+
+**Rules:**
+
+1. **Minimum necessary data.** Only record information relevant to assessing
+   role fit. Do not store personal details beyond what the candidate or their
+   recruiter shared for hiring purposes.
+2. **Retention awareness.** Candidates who are rejected or withdraw should not
+   have data retained indefinitely. After 6 months of inactivity on a rejected
+   or withdrawn candidate, flag them in the triage report under
+   `## Data Retention` for the user to decide: re-engage, archive, or erase.
+3. **Erasure readiness.** If the user receives a data erasure request (GDPR
+   Article 17 or equivalent), use the `right-to-be-forgotten` skill to process
+   it. This removes all personal data and produces an audit trail.
+4. **No sensitive categories.** Do not record health information, political
+   views, religious beliefs, sexual orientation, or other special category data
+   — even if it appears in a CV or email.
+5. **Assume the candidate will see it.** Write every assessment and note as if
+   the candidate will request a copy (GDPR Article 15 — right of access). If
+   you wouldn't be comfortable sharing it with them, don't write it.
+
+## Human Oversight
+
+This agent **recommends** — the user **decides**. Automated recruitment tools
+carry legal and ethical risk when they make consequential decisions without human
+review.
+
+**Hard rules:**
+
+1. **Never auto-reject.** The agent may flag concerns and recommend "do not
+   proceed," but the user must make the final rejection decision. Assessments
+   are advisory, not dispositive.
+2. **Level estimates are hypotheses.** Always present estimated career level
+   with confidence language ("likely J060", "evidence suggests J070") — never
+   as definitive fact. CVs are incomplete signals.
+3. **Flag uncertainty.** When evidence is thin or ambiguous, say so explicitly.
+   Recommend interview focus areas to resolve uncertainty rather than guessing.
+4. **No ranking by protected characteristics.** Never sort, filter, or rank
+   candidates by gender, ethnicity, age, or other protected characteristics.
+   Rank by framework skill alignment only.
+
 ## Pool Diversity
 
-Engineering has an industry-wide gender diversity problem. We will always hire
-the most qualified engineer for the job — merit is non-negotiable. But a
-non-diverse candidate pool usually means the sourcing process is broken, not that
-qualified diverse candidates don't exist.
+Engineering has an industry-wide diversity problem. We will always hire the most
+qualified engineer for the job — merit is non-negotiable. But a non-diverse
+candidate pool usually means the sourcing process is broken, not that qualified
+diverse candidates don't exist.
 
 **Your responsibilities:**
 
-1. **Track gender composition of the active pipeline.** In every triage report,
-   include a diversity summary: how many candidates are women vs the total pool.
-2. **Flag women candidates explicitly.** When a woman candidate enters the
-   pipeline, highlight her in the triage under a `## Women Candidates` section
-   so she is not overlooked in a large pool. Include her name, status, and
-   assessed fit.
-3. **Push back on homogeneous pools.** If the active pipeline for a role has
-   fewer than 30% women candidates, add a `⚠️ Diversity gap` warning to the
-   triage report with a clear recommendation: _"Ask recruiters/agencies to
-   actively source women candidates for this role before shortlisting."_
-4. **Never lower the bar.** Diversity goals apply to the candidate pool, not to
+1. **Track aggregate pool diversity.** In every triage report, include
+   anonymized diversity statistics: how many candidates have gender recorded as
+   Woman vs Man vs unknown, as a pool-level metric. Never single out individual
+   candidates by gender or other protected characteristics.
+2. **Push back on homogeneous pools.** If the active pipeline has low gender
+   diversity, add a `⚠️ Pool diversity` note to the triage report recommending
+   the user ask recruiters/agencies to broaden sourcing.
+3. **Never lower the bar.** Diversity goals apply to the candidate pool, not to
    hiring decisions. Every candidate is assessed on the same framework criteria.
    Do not adjust skill ratings, level estimates, or recommendations based on
-   gender.
-5. **Track sourcing channels.** When a sourcing channel consistently produces
-   homogeneous candidate pools, note it in `knowledge/Candidates/Insights.md`
-   so the user can address it with the agency.
+   gender or any other protected characteristic.
+4. **Track sourcing channels.** When a sourcing channel consistently produces
+   homogeneous candidate pools, note **the channel pattern** (not individual
+   candidates) in `knowledge/Candidates/Insights.md` so the user can address
+   it with the agency.
+5. **Gender data handling.** Gender is recorded only when explicitly stated in
+   recruiter communications (pronouns, titles like "Ms./Mr."). Never infer
+   gender from names. Record as `Woman`, `Man`, or `—` (unknown). When
+   uncertain, always use `—`.
 
 ## 1. Sync Candidates
 
@@ -168,12 +215,12 @@ cat > ~/.cache/fit/basecamp/state/recruiter_triage.md << 'EOF'
 - Platform fit: {N} candidates
 - Either track: {N} candidates
 
-## Diversity
-- Women: {N}/{total} ({%})
-- ⚠️ Diversity gap — {warning if below 30%, or "Pool is balanced" if not}
+## Diversity (aggregate)
+- Gender recorded: {N} Woman / {N} Man / {N} unknown of {total} total
+- ⚠️ Pool diversity — {note if pool appears homogeneous, or "Pool sourcing looks broad"}
 
-## Women Candidates
-- **{Name}** — {status}, {track fit}, {recommendation}
+## Data Retention
+- {Name(s) of candidates rejected/withdrawn 6+ months ago, if any, for user review}
 EOF
 ```
 
@@ -218,5 +265,5 @@ After acting, output exactly:
 Decision: {what you observed and why you chose this action}
 Action: {what you did, e.g. "analyze-cv for John Smith against J060 forward_deployed"}
 Pipeline: {N} total, {N} new, {N} assessed, {N} interviewing
-Diversity: {N}/{total} women ({%}) — {balanced | ⚠️ gap}
+Diversity: {N} W / {N} M / {N} unknown of {total} — {broad | ⚠️ homogeneous pool}
 ```

package/template/.claude/skills/analyze-cv/SKILL.md

@@ -60,7 +60,7 @@ Read the candidate's CV file. Extract:
 | **Leadership signals** | Team size, mentoring, cross-team work, architecture    |
 | **Scope signals**      | Scale of systems, user base, revenue impact            |
 | **Communication**      | Publications, talks, open source, documentation        |
-| **Gender**             | Pronouns, gendered titles, first name if unambiguous   |
+| **Gender**             | Pronouns, gendered titles (never infer from names)  |
 
 ## Step 2: Look Up the Framework Reference
 
@@ -230,6 +230,8 @@ or could work on either. Reference specific CV evidence.}
 
 ## Hiring Recommendation
 
+**⚠️ Advisory only — human decision required.**
+
 **Recommendation:** {Proceed / Proceed with reservations / Do not proceed}
 
 **Rationale:** {3-5 sentences grounding the recommendation in framework data.
@@ -264,4 +266,4 @@ to create the candidate profile from email threads.
 - [ ] Gaps are actionable — they suggest interview focus areas
 - [ ] Assessment file uses correct path format and links to CV
 - [ ] Candidate brief updated with skill tags and assessment link
-- [ ] Gender field set in both assessment and brief where identifiable
+- [ ] Gender field set only from explicit pronouns/titles (never name-inferred)

package/template/.claude/skills/right-to-be-forgotten/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: right-to-be-forgotten
+description: >
+  Process GDPR Article 17 data erasure requests. Finds and removes all personal
+  data related to a named individual from the knowledge base, cached data, and
+  agent state files. Use when the user receives a right-to-be-forgotten request,
+  asks to delete all data about a person, or needs to comply with a data
+  erasure obligation.
+compatibility: Requires macOS filesystem access
+---
+
+# Right to Be Forgotten
+
+Process data erasure requests under GDPR Article 17 (Right to Erasure). Given a
+person's name, systematically find and remove all personal data from the
+knowledge base, cached synced data, and agent state files.
+
+This skill produces an **erasure report** documenting what was found, what was
+deleted, and what requires manual action — providing an audit trail for
+compliance.
+
+## Trigger
+
+Run this skill:
+
+- When the user receives a formal GDPR erasure request
+- When the user asks to delete all data about a specific person
+- When a candidate withdraws from a recruitment process and requests data
+  deletion
+- When the user asks to "forget" someone
+
+## Prerequisites
+
+- The person's full name (and any known aliases or email addresses)
+- User confirmation before deletion proceeds
+
+## Inputs
+
+- **Name**: Full name of the data subject (required)
+- **Aliases**: Alternative names, maiden names, nicknames (optional)
+- **Email addresses**: Known email addresses (optional, improves search coverage)
+- **Scope**: `all` (default) or `recruitment-only` (limits to candidate data)
+
+## Outputs
+
+- `knowledge/Erasure/{Name}--{YYYY-MM-DD}.md` — erasure report (audit trail)
+- Deleted files and redacted references across the knowledge base
+
+---
+
+## Step 0: Confirm Intent
+
+Before proceeding, clearly state to the user:
+
+> **Data erasure request for: {Name}**
+>
+> This will permanently delete all personal data related to {Name} from:
+> - Knowledge base notes (People, Candidates, Organizations mentions)
+> - Cached email threads and attachments
+> - Agent state and triage files
+>
+> This action cannot be undone. Proceed?
+
+**Wait for explicit confirmation before continuing.**
+
+## Step 1: Discovery — Find All References
+
+Search systematically across every data location. Record every match.
+
+### 1a. Knowledge Base — Direct Notes
+
+```bash
+# Candidate directory (recruitment data)
+ls -d "knowledge/Candidates/{Name}/" 2>/dev/null
+
+# People note
+ls "knowledge/People/{Name}.md" 2>/dev/null
+
+# Try common name variations
+ls "knowledge/People/{First} {Last}.md" 2>/dev/null
+ls "knowledge/People/{Last}, {First}.md" 2>/dev/null
+```
+
+### 1b. Knowledge Base — Backlinks and Mentions
+
+```bash
+# Search for all mentions across the entire knowledge graph
+rg -l "{Name}" knowledge/
+rg -l "{First name} {Last name}" knowledge/
+
+# Search for Obsidian-style links
+rg -l "\[\[.*{Name}.*\]\]" knowledge/
+
+# Search by email address if known
+rg -l "{email}" knowledge/
+```
+
+### 1c. Cached Data — Email Threads
+
+```bash
+# Search synced email threads for mentions
+rg -l "{Name}" ~/.cache/fit/basecamp/apple_mail/ 2>/dev/null
+rg -l "{email}" ~/.cache/fit/basecamp/apple_mail/ 2>/dev/null
+
+# Check for attachment directories containing their files
+find ~/.cache/fit/basecamp/apple_mail/attachments/ -iname "*{Name}*" 2>/dev/null
+```
+
+### 1d. Cached Data — Calendar Events
+
+```bash
+# Search calendar events
+rg -l "{Name}" ~/.cache/fit/basecamp/apple_calendar/ 2>/dev/null
+rg -l "{email}" ~/.cache/fit/basecamp/apple_calendar/ 2>/dev/null
+```
+
+### 1e. Agent State Files
+
+```bash
+# Search triage files for mentions
+rg -l "{Name}" ~/.cache/fit/basecamp/state/ 2>/dev/null
+```
+
+### 1f. Drafts
+
+```bash
+# Search email drafts
+rg -l "{Name}" drafts/ 2>/dev/null
+```
+
+Compile a complete inventory of every file and reference found.
+
+## Step 2: Classify References
+
+For each discovered reference, classify the required action:
+
+| Reference Type | Action | Example |
+| --- | --- | --- |
+| **Dedicated note** (sole subject) | Delete entire file | `knowledge/People/{Name}.md` |
+| **Dedicated directory** | Delete entire directory | `knowledge/Candidates/{Name}/` |
+| **Mention in another note** | Redact: remove lines referencing the person | Backlink in `knowledge/Organizations/Agency.md` |
+| **Email thread** (sole subject) | Delete file | `~/.cache/fit/basecamp/apple_mail/thread.md` |
+| **Email thread** (multiple people) | Redact: remove paragraphs about the person | Thread discussing multiple candidates |
+| **Attachment** (their CV, etc.) | Delete file | `attachments/{thread}/CV.pdf` |
+| **Triage/state file** | Redact: remove lines mentioning them | `recruiter_triage.md` |
+| **Insights file** | Redact: remove bullets mentioning them | `knowledge/Candidates/Insights.md` |
+
+## Step 3: Execute Deletions
+
+Process in order from most specific to most general:
+
+### 3a. Delete Dedicated Files and Directories
+
+```bash
+# Remove candidate directory (CV, brief, assessment — everything)
+rm -rf "knowledge/Candidates/{Name}/"
+
+# Remove people note
+rm -f "knowledge/People/{Name}.md"
+
+# Remove any attachments
+find ~/.cache/fit/basecamp/apple_mail/attachments/ -iname "*{Name}*" -delete
+```
+
+### 3b. Redact Mentions in Other Notes
+
+For each file that **mentions** the person but isn't dedicated to them:
+
+1. Read the file
+2. Remove lines, bullets, or sections that reference the person
+3. Remove broken `[[backlinks]]` to deleted notes
+4. Write the updated file
+
+**Redaction rules:**
+
+- Remove entire bullet points that mention the person by name
+- Remove table rows containing the person's name
+- Remove `## Connected to` entries linking to their deleted note
+- If a section becomes empty after redaction, remove the section header too
+- Do NOT remove surrounding context that doesn't identify the person
+
+### 3c. Handle Email Threads
+
+For threads where the person is the **sole subject** (e.g., a recruitment email
+about only them):
+
+```bash
+rm -f "~/.cache/fit/basecamp/apple_mail/{thread}.md"
+```
+
+For threads with **multiple people**, redact only the paragraphs about this
+person — leave the rest intact.
+
+### 3d. Clean Agent State
+
+Remove mentions from triage files:
+
+```bash
+# Regenerate triage files on next agent wake — just remove current mentions
+for f in ~/.cache/fit/basecamp/state/*_triage.md; do
+  if rg -q "{Name}" "$f" 2>/dev/null; then
+    # Read, remove lines mentioning the person, write back
+    rg -v "{Name}" "$f" > "$f.tmp" && mv "$f.tmp" "$f"
+  fi
+done
+```
+
+### 3e. Clean Processing State
+
+Remove entries from the graph_processed state so deleted files aren't
+incorrectly tracked:
+
+```bash
+# Remove processed-file entries for deleted paths
+rg -v "{deleted_path}" ~/.cache/fit/basecamp/state/graph_processed \
+  > ~/.cache/fit/basecamp/state/graph_processed.tmp \
+  && mv ~/.cache/fit/basecamp/state/graph_processed.tmp \
+       ~/.cache/fit/basecamp/state/graph_processed
+```
+
+## Step 4: Write Erasure Report
+
+Create the audit trail at `knowledge/Erasure/{Name}--{YYYY-MM-DD}.md`:
+
+```markdown
+# Data Erasure Report — {Full Name}
+
+**Date:** {YYYY-MM-DD HH:MM}
+**Requested by:** {user or "GDPR Article 17 request"}
+**Scope:** {all / recruitment-only}
+
+## Data Subject
+- **Name:** {Full Name}
+- **Known aliases:** {aliases or "none"}
+- **Known emails:** {emails or "none"}
+
+## Actions Taken
+
+### Deleted Files
+- `knowledge/Candidates/{Name}/brief.md`
+- `knowledge/Candidates/{Name}/CV.pdf`
+- `knowledge/Candidates/{Name}/assessment.md`
+- `knowledge/People/{Name}.md`
+- {list all deleted files}
+
+### Redacted References
+- `knowledge/Organizations/{Agency}.md` — removed backlink
+- `knowledge/Candidates/Insights.md` — removed {N} bullet(s)
+- {list all redacted files and what was removed}
+
+### Cached Data Removed
+- `~/.cache/fit/basecamp/apple_mail/{thread}.md` — deleted (sole subject)
+- `~/.cache/fit/basecamp/apple_mail/{thread2}.md` — redacted (multi-person)
+- {list all cache actions}
+
+### State Files Cleaned
+- `~/.cache/fit/basecamp/state/recruiter_triage.md` — redacted
+- {list all state file actions}
+
+## Requires Manual Action
+
+The following data sources are outside this tool's reach:
+
+- **Apple Mail** — original emails remain in the user's mailbox. Search for
+  "{Name}" in Mail.app and delete threads manually.
+- **Apple Calendar** — original events remain. Check Calendar.app for events
+  mentioning "{Name}".
+- **Recruitment agencies** — notify {Agency} that the candidate's data has been
+  deleted and request they do the same.
+- **Interview notes** — check physical notebooks or other apps for handwritten
+  or external notes.
+- **Shared documents** — check Google Drive, SharePoint, or other shared
+  platforms for documents mentioning the person.
+
+## Verification
+
+After erasure, verify no traces remain:
+
+```bash
+rg "{Name}" knowledge/ ~/.cache/fit/basecamp/
+```
+
+Expected result: no matches (except this erasure report).
+```
+
+**IMPORTANT:** The erasure report itself must NOT contain personal data beyond
+the name and the fact that data was deleted. Do not copy CV content, skill
+assessments, or candidate details into the report. Record only what was deleted,
+not what it contained.
+
+## Step 5: Verify
+
+Run a final search to confirm no references were missed:
+
+```bash
+rg "{Name}" knowledge/ ~/.cache/fit/basecamp/ drafts/
+```
+
+The only match should be the erasure report itself. If other matches remain,
+process them and update the report.
+
+## Scope Variants
+
+### recruitment-only
+
+When scope is `recruitment-only`, limit erasure to:
+
+- `knowledge/Candidates/{Name}/` directory
+- `knowledge/Candidates/Insights.md` mentions
+- Recruitment-related email threads (from known agency domains)
+- `recruiter_triage.md` state file
+
+Leave `knowledge/People/{Name}.md` and general knowledge graph references
+intact — the person may be a colleague or contact outside of recruitment.
+
+### all (default)
+
+Full erasure across all knowledge base locations, cached data, and state files.
+
+## Quality Checklist
+
+- [ ] User confirmed intent before any deletion
+- [ ] Searched all data locations (knowledge, cache, state, drafts)
+- [ ] All dedicated files/directories deleted
+- [ ] All backlinks and mentions redacted from other notes
+- [ ] Cached email threads and attachments handled
+- [ ] Agent state files cleaned
+- [ ] Processing state updated for deleted files
+- [ ] Erasure report created with full audit trail
+- [ ] Report does NOT contain personal data (only file paths and actions)
+- [ ] Manual action items listed (Mail.app, Calendar.app, agencies)
+- [ ] Final verification search shows no remaining references
+- [ ] Broken backlinks cleaned up in referencing notes

package/template/.claude/skills/track-candidates/SKILL.md

@@ -145,15 +145,16 @@ For each candidate found in a recruitment email, extract:
 
 ### Determining Gender
 
-Record the candidate's gender when identifiable from the email or CV:
+Record the candidate's gender when **explicitly stated** in the email or CV:
 
 - Pronouns used by the recruiter ("she is available", "her CV attached")
 - Gendered titles ("Ms.", "Mrs.", "Mr.")
-- First name when culturally unambiguous
 
-Record as `Woman`, `Man`, or `—` (unknown). When uncertain, use `—` — never
-guess. This field supports pool diversity tracking; it has **no bearing** on
-hiring decisions or assessment criteria.
+Record as `Woman`, `Man`, or `—` (unknown). When uncertain, use `—` — **never
+infer gender from names**, regardless of cultural context. Name-based inference
+is unreliable and culturally biased. This field supports aggregate pool
+diversity tracking; it has **no bearing** on hiring decisions, assessment
+criteria, or candidate visibility.
 
 ### Determining Source and Recruiter
 
@@ -372,4 +373,4 @@ produces a full framework-aligned assessment.
 - [ ] No duplicate candidate notes created
 - [ ] Key strategic insights added to `Insights.md` where warranted
 - [ ] Skills tagged using framework skill IDs where possible
-- [ ] Gender field populated where identifiable (Woman / Man / —)
+- [ ] Gender field populated only from explicit pronouns/titles (never name-inferred)

package/template/.claude/skills/upstream-skill/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: upstream-skill
+description: Track changes made to skills in this installation and produce a changelog that can be included upstream. Use when skills have been modified, added, or removed locally and those changes should be contributed back to the monorepo.
+---
+
+# Upstream
+
+Track changes made to skills in this installation and produce a structured
+changelog so improvements can be contributed back to the upstream monorepo.
+
+## Trigger
+
+Run this skill when:
+
+- The user asks to prepare local skill changes for upstream contribution
+- Skills in `.claude/skills/` have been modified, added, or removed
+- The user wants to document what changed in the local installation
+- Before syncing with the upstream monorepo
+
+## Prerequisites
+
+- A working Basecamp installation with `.claude/skills/` directory
+- Git available for detecting changes
+
+## Inputs
+
+- `.claude/skills/*/SKILL.md` — current skill files in this installation
+- Git history — to detect what changed and when
+
+## Outputs
+
+- `.claude/skills/CHANGELOG.md` — structured changelog of all local skill changes
+
+---
+
+## Process
+
+### Step 1: Identify Changed Skills
+
+Use git to find all skill files that have been added, modified, or deleted since
+the last changelog entry (or since initial commit if no changelog exists).
+
+```bash
+# Find the date of the last changelog entry (if any)
+head -20 .claude/skills/CHANGELOG.md 2>/dev/null
+
+# List changed skill files since last documented change
+git log --oneline --name-status -- '.claude/skills/'
+```
+
+If `.claude/skills/CHANGELOG.md` already exists, read the most recent entry date
+and only look at changes after that date:
+
+```bash
+git log --after="<last-entry-date>" --name-status -- '.claude/skills/'
+```
+
+If no changelog exists, consider all commits that touched `.claude/skills/`.
+
+### Step 2: Classify Each Change
+
+For every changed skill file, determine the type of change:
+
+| Type        | Description                                           |
+| ----------- | ----------------------------------------------------- |
+| `added`     | New skill created that doesn't exist upstream          |
+| `modified`  | Existing skill updated (workflow, checklists, tools)   |
+| `removed`   | Skill deleted from the installation                    |
+| `renamed`   | Skill directory or file renamed                        |
+
+For **modified** skills, read the current file and the previous version to
+identify what specifically changed:
+
+```bash
+# Show diff for a specific skill
+git diff HEAD~N -- '.claude/skills/<skill-name>/SKILL.md'
+
+# Or compare against a specific commit/date
+git log --oneline -- '.claude/skills/<skill-name>/'
+git diff <commit> -- '.claude/skills/<skill-name>/SKILL.md'
+```
+
+### Step 3: Describe Each Change
+
+For every changed skill, write a clear description that an upstream maintainer
+can act on. Each entry must answer:
+
+1. **What changed?** — The specific section or behaviour that was modified
+2. **Why?** — The problem encountered or improvement discovered during use
+3. **How?** — A summary of the actual change (not a full diff)
+
+Good descriptions:
+
+- "Added a safety check to Step 3 — agents were skipping validation when the
+  source directory was empty, causing silent failures"
+- "Rewrote the Entity Extraction section to process files in batches of 10
+  instead of all at once — large inboxes caused context window overflow"
+- "New skill: `process-hyprnote` — transcribes and extracts entities from
+  Hyprnote meeting recordings"
+
+Bad descriptions:
+
+- "Updated SKILL.md" (too vague)
+- "Fixed stuff" (no context)
+- "Changed line 42" (not meaningful to upstream)
+
+### Step 4: Write the Changelog
+
+Create or update `.claude/skills/CHANGELOG.md` with the following format:
+
+```markdown
+# Skill Changelog
+
+Changes to skills in this installation that should be considered for upstream
+inclusion in the Forward Impact monorepo.
+
+## <YYYY-MM-DD>
+
+### <skill-name> (added|modified|removed)
+
+**What:** <one-line summary of the change>
+
+**Why:** <the problem or improvement that motivated it>
+
+**Details:**
+<2-5 lines describing the specific changes made>
+
+---
+```
+
+Entries are in **reverse chronological order** (newest first). Group changes
+from the same date under a single date heading.
+
+### Step 5: Review the Changelog
+
+After writing, read the changelog back and verify:
+
+- [ ] Every changed skill has an entry
+- [ ] Each entry has What, Why, and Details sections
+- [ ] Descriptions are specific enough for an upstream maintainer to act on
+- [ ] New skills include a brief description of their purpose
+- [ ] Removed skills explain why they were removed
+- [ ] No duplicate entries for the same change
+- [ ] Dates are accurate (from git history, not guessed)
+
+## Example Output
+
+```markdown
+# Skill Changelog
+
+Changes to skills in this installation that should be considered for upstream
+inclusion in the Forward Impact monorepo.
+
+## 2026-03-01
+
+### track-candidates (modified)
+
+**What:** Added gender field extraction for diversity tracking
+
+**Why:** Recruitment pipeline lacked diversity metrics — pool composition was
+invisible without structured gender data.
+
+**Details:**
+- Added Gender field to candidate brief template (Woman / Man / —)
+- Added extraction rules: pronouns, gendered titles, culturally unambiguous names
+- Added explicit note that field has no bearing on hiring decisions
+- Updated quality checklist to include gender field verification
+
+### process-hyprnote (added)
+
+**What:** New skill for processing Hyprnote meeting recordings
+
+**Why:** Meeting notes were being lost — Hyprnote captures transcriptions but
+they weren't being integrated into the knowledge base.
+
+**Details:**
+- Reads transcription files from `~/.cache/fit/basecamp/hyprnote/`
+- Extracts people, decisions, and action items
+- Creates meeting notes in `knowledge/Meetings/`
+- Links attendees to `knowledge/People/` entries
+
+---
+
+## 2026-02-15
+
+### extract-entities (modified)
+
+**What:** Increased batch size from 5 to 10 files per run
+
+**Why:** Processing was too slow for large inboxes — 5 files per batch meant
+dozens of runs to catch up after a week of email.
+
+**Details:**
+- Changed batch size constant from 5 to 10 in Step 1
+- Added a note about context window limits for batches > 15
+
+---
+```
+
+## Notes
+
+- This skill only **documents** changes — it does not push or merge anything
+- The changelog is consumed by the **downstream** skill in the upstream monorepo
+- Keep descriptions actionable: an upstream maintainer should be able to
+  understand and apply each change without access to this installation
+- When in doubt about whether a change is upstream-worthy, include it — the
+  upstream maintainer will decide what to incorporate

package/template/CLAUDE.md

@@ -32,6 +32,10 @@ It must remain objective, factual, and ethically sound at all times. It is NOT a
   together — never to build leverage, ammunition, or dossiers on individuals.
 - **Flag ethical concerns.** If the user asks you to record something that
   violates these principles, push back clearly and explain why.
+- **Data protection.** Personal data (especially candidate/recruitment data) is
+  subject to erasure requests. Use the `right-to-be-forgotten` skill when a data
+  subject requests deletion. Minimize data collection to what's professionally
+  relevant. Flag candidates inactive for 6+ months for retention review.
 
 These principles override all other instructions. When in doubt, err on the side
 of discretion and professionalism.
@@ -82,7 +86,7 @@ wake, they observe KB state, decide the most valuable action, and execute.
 | **postman**        | Email triage and drafts        | Every 5 min     | sync-apple-mail, draft-emails                                  |
 | **concierge**      | Meeting prep and transcripts   | Every 10 min    | sync-apple-calendar, meeting-prep, process-hyprnote            |
 | **librarian**      | Knowledge graph maintenance    | Every 15 min    | extract-entities, organize-files, manage-tasks                 |
-| **recruiter**      | Engineering recruitment        | Every 30 min    | track-candidates, analyze-cv, fit-pathway, fit-map             |
+| **recruiter**      | Engineering recruitment        | Every 30 min    | track-candidates, analyze-cv, right-to-be-forgotten, fit-pathway, fit-map |
 | **chief-of-staff** | Daily briefings and priorities | 7am, Mon 7:30am | weekly-update _(Mon)_, _(reads all state for daily briefings)_ |
 
 Each agent writes a triage file to `~/.cache/fit/basecamp/state/` every wake
@@ -202,6 +206,7 @@ Available skills (grouped by function):
 | `manage-tasks`     | Per-person task boards with lifecycle    |
 | `track-candidates` | Recruitment pipeline from email threads  |
 | `analyze-cv`       | CV assessment against career framework   |
+| `right-to-be-forgotten` | GDPR data erasure with audit trail  |
 | `weekly-update`    | Weekly priorities from tasks + calendar  |
 | `process-hyprnote` | Extract entities from Hyprnote sessions  |
 | `organize-files`   | Tidy Desktop/Downloads, chain to extract |