@forwardimpact/basecamp 2.3.0 → 2.3.1

package/package.json

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

package/template/.claude/skills/sync-apple-mail/SKILL.md

@@ -26,6 +26,8 @@ their email.
 
 - `~/.cache/fit/basecamp/state/apple_mail_last_sync` — last sync timestamp
   (single-line text file)
+- `~/.cache/fit/basecamp/state/apple_mail_last_rowid` — highest message ROWID
+  seen at last sync (single-line text file)
 - `~/Library/Mail/V*/MailData/Envelope Index` — Apple Mail SQLite database
 
 ## Outputs
@@ -36,6 +38,8 @@ their email.
   attachment files for each thread (PDFs, images, documents, etc.)
 - `~/.cache/fit/basecamp/state/apple_mail_last_sync` — updated with new sync
   timestamp
+- `~/.cache/fit/basecamp/state/apple_mail_last_rowid` — updated with highest
+  ROWID seen
 
 ---
 
@@ -53,13 +57,17 @@ The script:
 1. Finds the Mail database (`~/Library/Mail/V*/MailData/Envelope Index`)
 2. Loads last sync timestamp (or defaults to `--days` days ago for first sync)
 3. Discovers the thread grouping column (`conversation_id` or `thread_id`)
-4. Finds threads with new messages since last sync (up to 500)
-5. For each thread: fetches messages, batch-fetches recipients and attachment
+4. Loads last-seen ROWID (or defaults to 0 for first sync)
+5. Finds threads with new messages since last sync (up to 500), using both
+   timestamp and ROWID to catch late-arriving emails (emails downloaded after
+   a delay may have `date_received` before the last sync timestamp, but their
+   ROWID will be higher than the last-seen ROWID)
+6. For each thread: fetches messages, batch-fetches recipients and attachment
    metadata, parses `.emlx` files for full email bodies (falling back to
    database summaries), copies attachment files to the output directory
-6. Writes one markdown file per thread to `~/.cache/fit/basecamp/apple_mail/`
-7. Updates sync state timestamp
-8. Reports summary (threads processed, files written)
+7. Writes one markdown file per thread to `~/.cache/fit/basecamp/apple_mail/`
+8. Updates sync state (timestamp and max ROWID)
+9. Reports summary (threads processed, files written)
 
 The script imports `scripts/parse-emlx.mjs` to extract plain text bodies from
 `.emlx` / `.partial.emlx` files (handles HTML-only emails by stripping tags).

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

@@ -130,18 +130,27 @@ For each candidate found in a recruitment email, extract:
 
 | Field             | Source                                            | Required            |
 | ----------------- | ------------------------------------------------- | ------------------- |
-| **Name**          | Filename, email body, CV                          | Yes                 |
-| **Role**          | Email body, CV                                    | Yes                 |
-| **Rate**          | Email body (e.g. "$120/hr", "€80/h")              | If available        |
-| **Availability**  | Email body (e.g. "1 month notice", "immediately") | If available        |
-| **English**       | Email body (e.g. "B2", "Upper-intermediate")      | If available        |
-| **Location**      | Email body, CV                                    | If available        |
-| **Source agency** | Sender domain → Organization                      | Yes                 |
-| **Recruiter**     | Email sender or CC'd recruiter                    | Yes                 |
-| **CV path**       | Attachment directory                              | If available        |
-| **Skills**        | Email body, CV                                    | If available        |
-| **Gender**        | Name, pronouns, recruiter context                 | If identifiable     |
-| **Summary**       | Email body, CV                                    | Yes — 2-3 sentences |
+| **Name**             | Filename, email body, CV                                        | Yes                 |
+| **Title**            | Email body, CV — the candidate's professional title/function    | Yes                 |
+| **Rate**             | Email body (e.g. "$120/hr", "€80/h")                            | If available        |
+| **Availability**     | Email body (e.g. "1 month notice", "immediately")               | If available        |
+| **English**          | Email body (e.g. "B2", "Upper-intermediate")                    | If available        |
+| **Location**         | Email body, CV                                                  | If available        |
+| **Source agency**    | Sender domain → Organization                                    | Yes                 |
+| **Recruiter**        | Email sender or CC'd recruiter                                  | Yes                 |
+| **CV path**          | Attachment directory                                            | If available        |
+| **Skills**           | Email body, CV                                                  | If available        |
+| **Gender**           | Name, pronouns, recruiter context                               | If identifiable     |
+| **Summary**          | Email body, CV                                                  | Yes — 2-3 sentences |
+| **Role**             | Internal requisition profile being hired against                | If available        |
+| **Req**              | Requisition ID from hiring system                               | If available        |
+| **Internal/External**| Whether candidate is internal or external                       | If available        |
+| **Model**            | Engagement model (B2B, Direct Hire, etc.)                       | If available        |
+| **Current title**    | CV or email body                                                | If available        |
+| **Email**            | Email body, CV, signature                                       | If available        |
+| **Phone**            | Email body, CV, signature                                       | If available        |
+| **LinkedIn**         | Email body, CV                                                  | If available        |
+| **Also known as**    | Alternate name spellings or transliterations                    | If available        |
 
 ### Determining Gender
 
@@ -193,9 +202,11 @@ Assign a status based on the email context:
 | `screening`        | Under review, questions asked about the candidate     |
 | `first-interview`  | First interview scheduled or completed                |
 | `second-interview` | Second interview scheduled or completed               |
+| `work-trial`       | Paid work trial or assessment project in progress     |
 | `offer`            | Offer extended                                        |
 | `hired`            | Accepted and onboarding                               |
 | `rejected`         | Explicitly passed on ("not a fit", "pass", "decline") |
+| `withdrawn`        | Candidate withdrew from the process                   |
 | `on-hold`          | Paused, waiting on notice period, or deferred         |
 
 **Default to `new`** if no response signals are found. Read the full thread
@@ -207,7 +218,10 @@ Look for these patterns in the hiring manager's replies:
 
 - "let's schedule" / "set up an interview" → `first-interview`
 - "second round" / "follow-up interview" → `second-interview`
+- "work trial" / "assessment project" / "paid trial" → `work-trial`
 - "not what we're looking for" / "pass" → `rejected`
+- "candidate withdrew" / "no longer interested" / "accepted another offer" →
+  `withdrawn`
 - "extend an offer" / "make an offer" → `offer`
 - "they've accepted" / "start date" → `hired`
 - "put on hold" / "come back to later" → `on-hold`
@@ -244,7 +258,7 @@ Then create `knowledge/Candidates/{Full Name}/brief.md`:
 # {Full Name}
 
 ## Info
-**Role:** {role title}
+**Title:** {professional title/function}
 **Rate:** {rate or "—"}
 **Availability:** {availability or "—"}
 **English:** {level or "—"}
@@ -254,6 +268,7 @@ Then create `knowledge/Candidates/{Full Name}/brief.md`:
 **Status:** {pipeline status}
 **First seen:** {date profile was shared, YYYY-MM-DD}
 **Last activity:** {date of most recent thread activity, YYYY-MM-DD}
+{extra fields here — see below}
 
 ## Summary
 {2-3 sentences: role, experience level, key strengths}
@@ -271,7 +286,11 @@ Then create `knowledge/Candidates/{Full Name}/brief.md`:
 ## Skills
 {comma-separated skill tags}
 
+## Interview Notes
+{interview feedback, structured by date — omit section if no interviews yet}
+
 ## Notes
+{free-form observations — always present, even if empty}
 ```
 
 If a CV attachment exists, **copy it into the candidate directory** before
@@ -279,6 +298,37 @@ writing the note.
 
 If no CV attachment exists, omit the `## CV` section entirely.
 
+### Extra Info Fields
+
+Place any of these **after Last activity** in the order shown, only when
+available:
+
+```markdown
+**Role:** {internal requisition profile, e.g. "Staff Engineer"}
+**Req:** {requisition ID, e.g. "4950237 — Principal Software Engineer"}
+**Internal/External:** {Internal / External / External (Prior Worker)}
+**Model:** {engagement model, e.g. "B2B (via Agency) — conversion to FTE not possible"}
+**Current title:** {current job title and employer}
+**Email:** {personal or work email}
+**Phone:** {phone number}
+**LinkedIn:** {LinkedIn profile URL}
+**Also known as:** {alternate name spellings}
+```
+
+### Additional Sections
+
+Some candidates accumulate richer profiles over time. These optional sections go
+**after Skills and before Notes**, in this order:
+
+1. `## Education` — degrees, institutions, years
+2. `## Certifications` — professional certifications
+3. `## Work History` — chronological career history (when extracted from CV)
+4. `## Key Facts` — notable bullet points from CV review
+5. `## Interview Notes` — structured by date as `### YYYY-MM-DD — {description}`
+
+`## Notes` is always the **last section**. If an `## Open Items` section exists
+(pending questions or follow-ups), place it after Notes.
+
 ### For EXISTING candidates
 
 Read `knowledge/Candidates/{Full Name}/brief.md`, then apply targeted edits:
@@ -364,6 +414,11 @@ produces a full framework-aligned assessment.
 - [ ] Scanned all new/changed email threads for recruitment signals
 - [ ] Extracted all candidates found (check attachment directories too)
 - [ ] Each candidate has a complete note with all available fields
+- [ ] Info fields are in standard order (Title, Rate, Availability, English,
+      Location, Gender, Source, Status, First seen, Last activity, then extras)
+- [ ] Sections are in standard order (Info → Summary → CV → Connected to →
+      Pipeline → Skills → Education/Certifications/Work History/Key Facts →
+      Interview Notes → Notes → Open Items)
 - [ ] CV paths are correct and point to actual files
 - [ ] Pipeline status reflects the latest thread activity
 - [ ] Timeline entries are in chronological order

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

@@ -29,7 +29,8 @@ Run this skill when:
 
 ## Outputs
 
-- `.claude/skills/CHANGELOG.md` — structured changelog of all local skill changes
+- `.claude/skills/<skill-name>/CHANGELOG.md` — per-skill changelog of local
+  changes, one per modified skill directory
 
 ---
 
@@ -41,21 +42,22 @@ 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
+# Find the date of the last changelog entry for a skill (if any)
+head -20 .claude/skills/<skill-name>/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:
+If a skill already has a `.claude/skills/<skill-name>/CHANGELOG.md`, 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/'
+git log --after="<last-entry-date>" --name-status -- '.claude/skills/<skill-name>/'
 ```
 
-If no changelog exists, consider all commits that touched `.claude/skills/`.
+If no changelog exists for a skill, consider all commits that touched that
+skill's directory.
 
 ### Step 2: Classify Each Change
 
@@ -106,18 +108,17 @@ Bad descriptions:
 
 ### Step 4: Write the Changelog
 
-Create or update `.claude/skills/CHANGELOG.md` with the following format:
+For each changed skill, create or update its
+`.claude/skills/<skill-name>/CHANGELOG.md` with the following format:
 
 ```markdown
-# Skill Changelog
+# <skill-name> Changelog
 
-Changes to skills in this installation that should be considered for upstream
-inclusion in the Forward Impact monorepo.
+Changes to this skill 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>
@@ -128,14 +129,20 @@ inclusion in the Forward Impact monorepo.
 ---
 ```
 
-Entries are in **reverse chronological order** (newest first). Group changes
-from the same date under a single date heading.
+Entries are in **reverse chronological order** (newest first). Each skill has
+its own changelog file inside its directory.
+
+For **new skills**, create the `CHANGELOG.md` alongside the `SKILL.md` with a
+single `added` entry describing the skill's purpose.
+
+For **removed skills**, the changelog should be the last file remaining in the
+skill directory, documenting why the skill was removed.
 
-### Step 5: Review the Changelog
+### Step 5: Review the Changelogs
 
-After writing, read the changelog back and verify:
+After writing, read each changelog back and verify:
 
-- [ ] Every changed skill has an entry
+- [ ] Every changed skill has a `CHANGELOG.md` in its directory
 - [ ] 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
@@ -145,16 +152,16 @@ After writing, read the changelog back and verify:
 
 ## Example Output
 
+`.claude/skills/track-candidates/CHANGELOG.md`:
+
 ```markdown
-# Skill Changelog
+# track-candidates Changelog
 
-Changes to skills in this installation that should be considered for upstream
-inclusion in the Forward Impact monorepo.
+Changes to this skill 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
@@ -166,7 +173,18 @@ invisible without structured gender data.
 - Added explicit note that field has no bearing on hiring decisions
 - Updated quality checklist to include gender field verification
 
-### process-hyprnote (added)
+---
+```
+
+`.claude/skills/process-hyprnote/CHANGELOG.md`:
+
+```markdown
+# process-hyprnote Changelog
+
+Changes to this skill that should be considered for upstream inclusion in the
+Forward Impact monorepo.
+
+## 2026-03-01
 
 **What:** New skill for processing Hyprnote meeting recordings
 
@@ -180,10 +198,17 @@ they weren't being integrated into the knowledge base.
 - Links attendees to `knowledge/People/` entries
 
 ---
+```
 
-## 2026-02-15
+`.claude/skills/extract-entities/CHANGELOG.md`:
 
-### extract-entities (modified)
+```markdown
+# extract-entities Changelog
+
+Changes to this skill that should be considered for upstream inclusion in the
+Forward Impact monorepo.
+
+## 2026-02-15
 
 **What:** Increased batch size from 5 to 10 files per run
 
@@ -200,7 +225,8 @@ dozens of runs to catch up after a week of email.
 ## 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
+- The per-skill changelogs are 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