@forwardimpact/outpost 3.11.0 → 3.12.1

package/templates/.claude/skills/req-track/SKILL.md

@@ -7,14 +7,14 @@ description: Scan synced email threads for recruitment candidates, extract struc
 
 Scan synced email threads from `~/.cache/fit/outpost/apple_mail/` for
 recruitment candidates. Extract structured candidate profiles and create or
-update notes in `Knowledge/Candidates/`. Builds a local, searchable recruitment
-pipeline from scattered email threads.
+update notes in `Knowledge/Candidates/`. This skill builds a local, searchable
+recruitment pipeline from scattered email threads.
 
 ## Trigger
 
 - The user asks to track, process, or update candidates.
 - The user asks about recruitment pipeline status.
-- After `sync-apple-mail` has pulled new threads.
+- After `sync-apple-mail` pulls new threads.
 
 ## Prerequisites
 
@@ -34,15 +34,15 @@ pipeline from scattered email threads.
 - `~/.cache/fit/outpost/state/graph_processed` — processed-file index (shared
   with `extract-entities`).
 - `~/.cache/fit/outpost/state/identity.md` — user identity for self-exclusion
-  (written by the `person-identify` skill).
+  (the `person-identify` skill writes it).
 
 ## Outputs
 
 - `Knowledge/Candidates/{Full Name}/brief.md` — candidate profile note.
 - `Knowledge/Candidates/{Full Name}/CV.pdf` (or `CV.docx`) — local CV copy.
 - `Knowledge/Candidates/{Full Name}/headshot.jpeg` — candidate photo.
-- `Knowledge/Roles/*.md` — role files created/updated; the `**Status:**` field
-  determines visibility (open/closed).
+- `Knowledge/Roles/*.md` — role files created or updated. The `**Status:**`
+  field determines visibility (open/closed).
 - `~/.cache/fit/outpost/state/graph_processed` — updated with processed threads.
 
 <do_confirm_checklist goal="Verify candidate processing batch is complete and
@@ -50,17 +50,17 @@ correct">
 
 - [ ] Required Info fields present on every brief (Title, Source, Status, First
       seen, Last activity, Channel).
-- [ ] Pipeline status reflects latest thread activity; timeline in chronological
-      order.
+- [ ] Pipeline status reflects the latest thread activity. Timeline in
+      chronological order.
 - [ ] Bidirectional links present (Candidate ↔ Org / Recruiter / Role /
       Project).
-- [ ] Role files synced — Candidates tables rebuilt, stubs created for any
+- [ ] Role files synced. Candidates tables rebuilt. Stubs created for any
       unknown reqs.
 - [ ] CV and headshot copied into the candidate directory when available.
 - [ ] Skills tagged with agent-aligned engineering standard IDs from
       `bunx fit-pathway skill --list`.
 - [ ] Gender field populated only from explicit pronouns or titles.
-- [ ] No duplicate candidate notes; all processed threads marked in the state
+- [ ] No duplicate candidate notes. All processed threads marked in the state
       file.
 
 </do_confirm_checklist>
@@ -72,14 +72,14 @@ Process **10 files per run**.
 ### 1. Load context and pick the batch
 
 Read the user's name, email, and domain from
-`~/.cache/fit/outpost/state/identity.md` (run the `person-identify` skill first
-if it is missing or stale). List new or changed source files:
+`~/.cache/fit/outpost/state/identity.md`. Run the `person-identify` skill first
+if that file is missing or stale. List new or changed source files:
 
 ```bash
 node .claude/skills/extract-entities/scripts/state.mjs check
 ```
 
-Filter the output to `apple_mail/*.md` only — calendar files are not relevant
+Filter the output to `apple_mail/*.md` only. Calendar files are not relevant
 here.
 
 ### 2. Build candidate, people, and org indexes
@@ -95,49 +95,49 @@ links.
 
 ### 3. Sync `Knowledge/Roles/`
 
-Role files are flat here; the `**Status:**` field is `open` or `closed`.
+Role files are flat here. The `**Status:**` field is `open` or `closed`.
 
 1. Read each Role file's Info block to map Req → Role file path, Hiring manager,
    Domain lead, recruiter, Channel. Look up by filename substring so a req-less
    role stays findable: `ls Knowledge/Roles/ | grep "{partial_name_or_req}"`.
-2. Find Reqs in candidate briefs missing a Role file:
+2. Find Reqs in candidate briefs that have no Role file:
    `rg "^\*\*Req:\*\*" Knowledge/Candidates/*/brief.md`. Check all Role files
-   first; for a genuinely missing open role, create a stub with `**Status:**
-   open` using the **Role file stub** in
-   [references/templates.md](references/templates.md), then enrich:
+   first. For a genuinely missing open role, create a stub with
+   `**Status:** open` from the **Role file stub** in
+   [references/templates.md](references/templates.md). Then enrich:
    `rg "{req_number}" Knowledge/`.
-3. Rebuild each **open** Role file's `## Candidates` table by scanning briefs:
+3. Scan briefs to rebuild each **open** Role file's `## Candidates` table:
    `rg -l "Req:.*{req_number}" Knowledge/Candidates/*/brief.md`. Use the **Role
    Candidates table** format from `references/templates.md`, newest first.
 4. If a Role file has a hiring manager but no domain lead, walk the
    `**Reports to:**` chain in `Knowledge/People/` to a VP or senior leader.
 5. When a role closes (filled, cancelled, or frozen 6+ months), set its
-   `**Status:**` field to `closed` — only on a clear signal.
+   `**Status:**` field to `closed`. Do this only on a clear signal.
 
 ### 4. Identify recruitment threads
 
 For each thread in the batch, decide whether it contains recruitment content
-using the signals in [references/signals.md](references/signals.md). Skip
+with the signals in [references/signals.md](references/signals.md). Skip
 threads that match no signal.
 
 ### 5. Extract candidate data
 
-For each candidate found, populate the field map from
-[references/fields.md](references/fields.md). That reference covers field
-sources, the `Channel` rule, the hiring-manager / domain-lead resolution chain,
-gender rules, source/recruiter resolution, CV copying, and headshot discovery.
+For each candidate you find, populate the field map from
+[references/fields.md](references/fields.md). It covers field sources, the
+`Channel` rule, the hiring-manager / domain-lead resolution chain, gender rules,
+source/recruiter resolution, how to copy a CV, and headshot discovery.
 
 ### 6. Determine pipeline status
 
-Assign a status using the table and advancement signals in
+Assign a status with the table and advancement signals in
 [references/statuses.md](references/statuses.md). Default to `new`. Read the
-full thread chronologically; the most recent signal wins.
+full thread chronologically. The most recent signal wins.
 
 ### 7. Build the pipeline timeline
 
-Extract a chronological timeline — one `**{date}**: {event}` line per meaningful
-event, capturing who did what. Skip noise (signature blocks, disclaimers,
-forwarded headers).
+Extract a chronological timeline. Write one `**{date}**: {event}` line per
+meaningful event. Each line captures who did what. Skip noise (signature
+blocks, disclaimers, forwarded headers).
 
 ### 8. Write or update the candidate note
 
@@ -147,22 +147,22 @@ the **Candidate brief** template in
 fields** after `Last activity` in the order shown there. Add the **Optional
 sections** when data warrants. Omit `## CV` if no attachment.
 
-For **existing** candidates, apply targeted edits — do not rewrite the file:
-update `Status` and `Last activity`, append Pipeline entries, fill in newly
+For **existing** candidates, apply targeted edits. Do not rewrite the file.
+Update `Status` and `Last activity`, append Pipeline entries, fill in newly
 known Info fields, and add new Skills.
 
 ### 9. Capture cross-candidate insights
 
 Update `Knowledge/Candidates/Insights.md` only when an observation is
-high-signal: candidate may suit a **different role**, is a **strong match** for
-a specific team or leader, a meaningful **comparison between candidates**, or a
-hiring trade-off needs to be **remembered across sessions**.
+high-signal: the candidate may suit a **different role**, is a **strong match**
+for a specific team or leader, a meaningful **comparison between candidates**,
+or you must **remember a hiring trade-off across sessions**.
 
-Skip per-candidate status and generic strengths/weaknesses — those belong on
+Skip per-candidate status and generic strengths/weaknesses. Those belong on
 `brief.md`. Format: one bullet under `## Placement Notes` with
 `[[Candidates/Name/brief|Name]]` and relevant people/org backlinks.
 
-### 10. Ensure bidirectional links
+### 10. Make sure links are bidirectional
 
 | If you add...            | Then also add...                                           |
 | ------------------------ | ---------------------------------------------------------- |
@@ -173,7 +173,7 @@ Skip per-candidate status and generic strengths/weaknesses — those belong on
 
 Use absolute paths: `[[Candidates/Name/brief|Name]]`,
 `[[Organizations/Agency]]`, `[[People/Recruiter]]`. Only add a backlink when the
-target note doesn't already reference the candidate.
+target note does not already reference the candidate.
 
 ### 11. Mark each thread processed
 
@@ -181,8 +181,8 @@ target note doesn't already reference the candidate.
 node .claude/skills/extract-entities/scripts/state.mjs update "{file_path}"
 ```
 
-Shares state with `extract-entities`, so the thread won't be re-scanned by
-either skill until it changes.
+`req-track` and `extract-entities` share this state. Neither skill re-scans the
+thread until it changes.
 
 ### 12. Tag skills against the standard
 

package/templates/.claude/skills/req-track/references/fields.md

@@ -18,12 +18,12 @@ Field map and resolution rules for Step 2 of `req-track`.
 | Skills            | Email body, CV                                               | If available        |
 | Gender            | Pronouns or gendered titles only                             | If identifiable     |
 | Summary           | Email body, CV                                               | Yes — 2-3 sentences |
-| Role              | Internal requisition profile being hired against             | If available        |
+| Role              | Internal requisition profile you hire against                | If available        |
 | Req               | Requisition ID from hiring system                            | If available        |
 | Channel           | `hr` or `vendor` — see below                                 | Yes                 |
 | Hiring manager    | Cross-source inference — see below                           | If determinable     |
 | Domain lead       | Resolved from hiring manager's reporting chain               | If determinable     |
-| Internal/External | Whether candidate is internal or external                    | If available        |
+| Internal/External | Whether the 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        |
@@ -35,46 +35,47 @@ Field map and resolution rules for Step 2 of `req-track`.
 
 - `vendor` — Source links to an `[[Organizations/...]]` flagged as
   vendor/partner (keywords: supplier, recruitment partner, contractor,
-  staffing), or Req contains "via {vendor name}" rather than a system ID.
-- `hr` — candidate came through a hiring system (numeric Req), applied
-  internally, or was submitted by an internal recruiter.
+  staffing). A Req that contains "via {vendor name}" instead of a system ID
+  also means `vendor`.
+- `hr` — the candidate came through a hiring system (numeric Req), or applied
+  internally, or an internal recruiter submitted the candidate.
 
 ## Hiring manager and domain lead — resolution chain
 
 Stop at the first match:
 
-1. **Req-first inheritance** — search `Knowledge/Roles/` for a file matching the
-   Req number or role description (use filename substring lookup for req-less
-   roles); check the `**Status:**` field (open/closed), then inherit Hiring
-   manager and Domain lead from the Role file.
+1. **Req-first inheritance** — search `Knowledge/Roles/` for a file that matches
+   the Req number or the role description. Use a filename substring lookup for
+   req-less roles. Check the `**Status:**` field (open/closed). Then inherit
+   Hiring manager and Domain lead from the Role file.
 2. **Calendar inference** —
    `rg -l "{Candidate Name}" ~/.cache/fit/outpost/apple_calendar/`. The non-user
    organizer of an interview event is likely the hiring manager.
-3. **Email inference** — internal To/CC recipients (besides the user)
-   cross-checked against `Knowledge/People/`.
-4. **Reporting chain** — read the hiring manager's `**Reports to:**` field; walk
+3. **Email inference** — cross-check internal To/CC recipients (besides the
+   user) against `Knowledge/People/`.
+4. **Reporting chain** — read the hiring manager's `**Reports to:**` field. Walk
    up to a VP / senior leader for the domain lead.
 5. **Staffing project timeline** — search staffing notes for the candidate or
-   vendor; surrounding context often names the manager.
+   vendor. The nearby context often names the manager.
 
 If none resolve, set `—` and revisit on the next cycle.
 
 ## Gender
 
-Record only when **explicitly stated**:
+Record only when the source states it **explicitly**:
 
 - Pronouns from the recruiter ("she is available", "her CV attached")
 - Gendered titles ("Ms.", "Mrs.", "Mr.")
 
 Record as `Woman`, `Man`, or `—` (unknown). When uncertain, use `—`. **Never
-infer gender from names** — name-based inference is unreliable and culturally
-biased. The field supports aggregate diversity tracking; it has no bearing on
+infer gender from names.** Name-based inference is unreliable and culturally
+biased. The field lets you track diversity in aggregate. It has no bearing on
 hiring decisions, assessment criteria, or candidate visibility.
 
 ## Source and recruiter
 
-- Map sender email domain to an organization in `Knowledge/Organizations/`.
-- The person who sent or forwarded the profile is the recruiter — link with
+- Map the sender email domain to an organization in `Knowledge/Organizations/`.
+- The person who sent or forwarded the profile is the recruiter. Link with
   `[[People/Name]]`.
 - Create the organization or recruiter notes if missing.
 

package/templates/.claude/skills/req-track/references/signals.md

@@ -1,7 +1,7 @@
 # Recruitment Signals
 
 Decide whether an email thread is recruitment-related. Skip threads that match
-no signal — most email is not.
+no signal. Most email is not recruitment-related.
 
 ## CV/resume attachments
 
@@ -10,25 +10,25 @@ no signal — most email is not.
 
 ## Recruiter sender domains
 
-Sender domain maps to an organization in `Knowledge/Organizations/` tagged as a
-recruitment agency. When no agencies are catalogued yet, treat these patterns as
-hints:
+The sender domain maps to an organization in `Knowledge/Organizations/` tagged
+as a recruitment agency. When no agencies are catalogued yet, treat these
+patterns as hints:
 
-- Multiple candidates presented by the same sender
-- Structured profile formatting (rate, availability, skills)
-- Forwarding candidate CVs on behalf of others
+- The same sender presents multiple candidates
+- The profile uses a structured format (rate, availability, skills)
+- The sender forwards candidate CVs on behalf of others
 
 ## Profile presentation patterns
 
-Structured candidate descriptions containing:
+Structured candidate descriptions that contain:
 
 - "Rate:" or rate/cost information
 - "Availability:" or notice period
 - "English:" or language level
 - "Location:" or country/city
-- Candidate name + role formatting (e.g. "Staff Software Engineer")
+- Candidate name + role format (e.g. "Staff Software Engineer")
 - "years of experience" / "YoE"
-- Skills/tech stack listings
+- Lists of skills or the tech stack
 
 ## Interview scheduling
 
@@ -38,5 +38,5 @@ Structured candidate descriptions containing:
 
 ## Follow-up on existing candidates
 
-A thread mentions a candidate already in `Knowledge/Candidates/` by name —
-process it to update pipeline status.
+A thread mentions a candidate already in `Knowledge/Candidates/` by name.
+Process it to update the pipeline status.

package/templates/.claude/skills/req-track/references/statuses.md

@@ -1,7 +1,8 @@
 # Pipeline Statuses
 
-Used by Step 3 of `req-track`. Default to `new` if no advancement signals are
-found. Read the full thread chronologically; the most recent signal wins.
+Step 3 of `req-track` uses these statuses. Default to `new` if you find no
+advancement signals. Read the full thread chronologically. The most recent
+signal wins.
 
 ## Statuses
 

package/templates/.claude/skills/req-track/references/templates.md

@@ -1,10 +1,10 @@
 # Templates
 
-Markdown templates used by `req-track` for Role files and Candidate briefs.
+`req-track` uses these markdown templates for Role files and Candidate briefs.
 
 ## Role file stub
 
-Used by Step 0b when a Req appears on a candidate brief but no Role file exists.
+Step 0b uses this stub when a candidate brief has a Req but no Role file exists.
 
 ```markdown
 # {Title from candidate Req field}
@@ -36,7 +36,7 @@ Used by Step 0b when a Req appears on a candidate brief but no Role file exists.
 
 ## Role Candidates table
 
-Step 0b rebuilds this table on each Role file by scanning briefs:
+Step 0b scans briefs and rebuilds this table on each Role file:
 
 ```markdown
 ## Candidates
@@ -49,7 +49,7 @@ Sort by First seen, newest first.
 
 ## Candidate brief
 
-Used by Step 5 for new candidates. File:
+Step 5 uses this template for new candidates. File:
 `Knowledge/Candidates/{Full Name}/brief.md`.
 
 ```markdown

package/templates/.claude/skills/req-workday/SKILL.md

@@ -2,8 +2,8 @@
 name: req-workday
 description: >
   Import candidates from a Workday requisition export (.xlsx) into
-  Knowledge/Candidates/. Parses requisition metadata and candidate data,
-  creates candidate briefs and CV.md files from resume text, and integrates
+  Knowledge/Candidates/. It parses requisition metadata and candidate data.
+  It creates candidate briefs and CV.md files from resume text. It integrates
   with the existing req-track pipeline. Use when the user provides a
   Workday export file or asks to import candidates from an XLSX requisition
   export.
@@ -12,9 +12,9 @@ description: >
 # Workday Requisition Import
 
 Import candidates from a Workday requisition export (`.xlsx`) into
-`Knowledge/Candidates/`. Extract requisition metadata and candidate profiles,
-create standardized briefs and `CV.md` files from the embedded resume text, and
-integrate with the `req-track` pipeline format.
+`Knowledge/Candidates/`. Extract requisition metadata and candidate profiles.
+Create standardized briefs and `CV.md` files from the embedded resume text.
+Integrate with the `req-track` pipeline format.
 
 ## Trigger
 
@@ -45,18 +45,18 @@ integrate with the `req-track` pipeline format.
 <do_confirm_checklist goal="Verify the Workday import is consistent with
 req-track">
 
-- [ ] XLSX parsed; candidate count matches the parser summary.
+- [ ] XLSX parsed. Candidate count matches the parser summary.
 - [ ] Requisition metadata extracted (ID, title; HM/recruiter when available).
 - [ ] Each candidate has a directory under `Knowledge/Candidates/{Clean Name}/`
       (annotation stripped).
-- [ ] `CV.md` created for every candidate with resume text — faithfully
-      reproduced (no rewriting).
-- [ ] Pipeline status mapped from **Step / Disposition** (not Stage); raw step
+- [ ] `CV.md` created for every candidate with resume text. Text reproduced
+      faithfully, with no rewrite.
+- [ ] Pipeline status mapped from **Step / Disposition** (not Stage). Raw step
       preserved in the Pipeline entry.
 - [ ] Internal/External derived from name annotations and source.
-- [ ] Existing candidates updated via targeted edits (not duplicated).
-- [ ] Skills tagged with standard IDs; Gender set to `—` (export has no signal);
-      Channel = `hr`; Req backlinks to the Role file.
+- [ ] Existing candidates updated with targeted edits (not duplicated).
+- [ ] Skills tagged with standard IDs. Gender set to `—` (export has no signal).
+      Channel = `hr`. Req backlinks to the Role file.
 
 </do_confirm_checklist>
 
@@ -66,9 +66,9 @@ Process **10 candidates per run**.
 
 ### 1. Set up
 
-Read the user's identity from `~/.cache/fit/outpost/state/identity.md` (run the
-`person-identify` skill first if it is missing or stale). Confirm the XLSX path.
-Ensure the parser dependency is installed:
+Read the user's identity from `~/.cache/fit/outpost/state/identity.md`. Run the
+`person-identify` skill first if that file is missing or stale. Confirm the
+XLSX path. Make sure the parser dependency is installed:
 
 ```bash
 bun pm ls read-excel-file 2>/dev/null || bun install read-excel-file
@@ -81,7 +81,7 @@ node .claude/skills/req-workday/scripts/parse-workday.mjs "<path>" --summary
 ```
 
 Review the summary for sanity (candidate count, header detection). For the JSON
-consumed by later steps:
+that later steps consume:
 
 ```bash
 node .claude/skills/req-workday/scripts/parse-workday.mjs "<path>"
@@ -99,13 +99,13 @@ ls Knowledge/Roles/ | grep "{Req ID}"
 
 New role files go in `Knowledge/Roles/` with `**Status:** open`. Use the
 **Role file stub** in
-[references/templates.md](references/templates.md). Resolve the domain lead by:
+[references/templates.md](references/templates.md). Resolve the domain lead:
 
 1. `rg "{Req ID}" Knowledge/` — look in project timelines, People notes, Topics
    for context.
-2. Reading the hiring manager's People note for `**Reports to:**` and walking up
-   to a VP or senior leader.
-3. Falling back to `Domain lead: —` for later cycles.
+2. Read the hiring manager's People note for `**Reports to:**` and walk up to a
+   VP or senior leader.
+3. Fall back to `Domain lead: —` for later cycles.
 
 If the Role file already exists, follow the existing-file rules in
 `references/templates.md`.
@@ -121,14 +121,14 @@ accents, spelling variations).
 
 ### 5. Determine pipeline status
 
-Map **Step / Disposition** to the `req-track` status using
+Map **Step / Disposition** to the `req-track` status with
 [references/status-mapping.md](references/status-mapping.md). Preserve the raw
 step value in the Pipeline entry.
 
 ### 6. Write `CV.md`
 
 For every candidate with resume text, create
-`Knowledge/Candidates/{Clean Name}/CV.md` using the **CV.md template** in
+`Knowledge/Candidates/{Clean Name}/CV.md` with the **CV.md template** in
 [references/templates.md](references/templates.md).
 
 ### 7. Write or update the brief
@@ -141,12 +141,12 @@ Brief layout (new candidates) and edit rules (existing candidates):
 mkdir -p "Knowledge/Candidates/{Clean Name}"
 ```
 
-For existing candidates, apply targeted Edit operations only — never rewrite the
+For existing candidates, apply targeted Edit operations only. Never rewrite the
 file.
 
 ### 8. Capture insights
 
-After the batch, review for strategic observations and add bullets to
+After the batch, review for strategic observations. Add bullets to
 `Knowledge/Candidates/Insights.md` under `## Placement Notes` with
 `[[Candidates/Name/brief|Name]]` links. See `req-track` Step 5b for the
 inclusion criteria.

package/templates/.claude/skills/req-workday/references/status-mapping.md

@@ -1,8 +1,8 @@
 # Step → Status Mapping
 
 Reference for `req-workday` Step 3. Map the **Step / Disposition** column to the
-`req-track` pipeline status. Do **not** use the Stage column for status — Stage
-is only used for row detection (stop condition).
+`req-track` pipeline status. Do **not** use the Stage column for status. Use
+Stage only for row detection (stop condition).
 
 | Workday Step / Disposition             | Pipeline status    |
 | -------------------------------------- | ------------------ |
@@ -25,10 +25,10 @@ is only used for row detection (stop condition).
 
 Empty or unrecognized step → default to `new`.
 
-## Preserving the raw step
+## Preserve the raw step
 
-The raw `step` value is always preserved in the parser's JSON output and must be
-stored in the candidate brief's `## Pipeline` section, e.g.
+The parser always preserves the raw `step` value in its JSON output. Store that
+value in the candidate brief's `## Pipeline` section, e.g.
 
 ```text
 - **2026-02-10**: Applied via LinkedIn — Step: Manager Request to Move Forward (HS)

package/templates/.claude/skills/req-workday/references/templates.md

@@ -5,8 +5,8 @@ Reference templates for `req-workday` Steps 1b, 4, and 5.
 ## Role file stub
 
 Use when no Role file exists for the requisition. Filename:
-`Knowledge/Roles/{Req ID} — {Short Title}.md`. The `**Status:**` field
-(`open`/`closed`) is updated in place — never move files.
+`Knowledge/Roles/{Req ID} — {Short Title}.md`. Update the `**Status:**` field
+(`open`/`closed`) in place. Never move files.
 
 ```markdown
 # {Requisition Title}
@@ -37,14 +37,14 @@ Use when no Role file exists for the requisition. Filename:
 - Created from requisition export on {today}.
 ```
 
-If the Role file already exists: set `Hiring manager` only when the export
-provides one and the field is `—`; update `Last activity` to today; append
-`- Requisition export processed on {today}: {N} candidates` to Notes.
+If the Role file already exists, set `Hiring manager` only when the export
+provides one and the field is `—`. Then update `Last activity` to today. Then
+append `- Requisition export processed on {today}: {N} candidates` to Notes.
 
 ## CV.md template
 
 Save to `Knowledge/Candidates/{Clean Name}/CV.md` when resume text exists. Skip
-when it doesn't.
+the file when it does not.
 
 ```markdown
 # {Clean Name} — Resume
@@ -57,8 +57,8 @@ when it doesn't.
 {Resume text from column AC, preserving original formatting}
 ```
 
-**Formatting:** preserve paragraph breaks; convert ALL-CAPS headers to
-`## Heading`; keep bullets/lists; never rewrite or summarise.
+**Formatting:** preserve paragraph breaks. Convert ALL-CAPS headers to
+`## Heading`. Keep bullets and lists. Never rewrite or summarise.
 
 ## Candidate brief
 
@@ -121,8 +121,8 @@ Gender is `—` (Workday exports carry no gender signals).
 
 ## Existing-candidate edits
 
-Apply targeted edits to `brief.md` — never rewrite. Set/update `Req`, advance
-`Status` if the Workday step is more advanced, update `Last activity`, append
-`**{Date Applied}**: Applied to {Req ID} — {Title} via {Source}` to Pipeline,
-fill only missing Email/Phone/ Location. Never overwrite richer existing data
-with sparser Workday data.
+Apply targeted edits to `brief.md`. Never rewrite it. Set or update `Req`.
+Advance `Status` if the Workday step is more advanced. Update `Last activity`.
+Append `**{Date Applied}**: Applied to {Req ID} — {Title} via {Source}` to
+Pipeline. Fill only missing Email, Phone, and Location. Never overwrite richer
+existing data with sparser Workday data.

package/templates/.claude/skills/req-workday/references/xlsx-format.md

@@ -1,8 +1,8 @@
 # Workday Export Format
 
-Reference for `req-workday`. The export format varies between Workday versions;
-the parse script handles both with header-driven column mapping and dynamic
-header-row detection.
+Reference for `req-workday`. The export format varies between Workday versions.
+The parse script handles both. It maps columns by header and detects the header
+row dynamically.
 
 ## Sheet 1 — requisition metadata
 
@@ -33,16 +33,16 @@ The new format does not carry hiring manager, recruiter, or location.
 
 ## Candidates sheet
 
-Auto-detected:
+The parser detects the format automatically:
 
 - **Old format:** 3+ sheets; candidates on the "Candidates" sheet or Sheet3;
   header at row 3 (index 2); two "Job Application" columns.
 - **New format:** 2 sheets; candidates on Sheet2; header at row 8 (index 7);
   single "Job Application" column.
 
-Column mapping is header-driven — the parser reads the header row and maps
-columns by name. Columns that vary between exports ("Jobs Applied to", "Referred
-by", "Convenience Task") are handled automatically.
+Column mapping is header-driven. The parser reads the header row and maps
+columns by name. It automatically handles columns that vary between exports
+("Jobs Applied to", "Referred by", "Convenience Task").
 
 ## Name annotations