@forwardimpact/outpost 3.11.0 → 3.12.1

package/templates/.claude/skills/deck-summarize/SKILL.md

@@ -1,21 +1,22 @@
 ---
 name: deck-summarize
-description: Synthesize PowerPoint decks into engineer-friendly markdown briefs covering Jobs-To-Be-Done, dependencies, and synthetic data needs. Use when the user asks to break down, summarize, or make sense of a slide deck (.pptx) for engineering work.
+description: Synthesize PowerPoint decks into engineer-friendly markdown briefs. Each brief covers Jobs-To-Be-Done, dependencies, and synthetic data needs. Use when the user asks to break down, summarize, or make sense of a slide deck (.pptx) for engineering work.
 compatibility: Node.js only — no external dependencies.
 ---
 
 # Synthesize Deck
 
 Turn messy PowerPoint specification decks into clear, actionable markdown briefs
-that forward deployed engineers can build from. Strip business jargon and focus
-on what matters: what needs to be built, what blocks progress, what data is
-needed to start prototyping.
+that forward deployed engineers can build from. Strip business jargon. Focus on
+what matters: what the team must build, what blocks progress, and what data you
+need to start a prototype.
 
 ## Trigger
 
-The user asks to summarize, synthesize, or break down a `.pptx` deck; make sense
-of a specification or proposal deck for engineering; create an engineering brief
-from a slide deck; or understand what a project deck is actually asking for.
+Run when the user asks to summarize, synthesize, or break down a `.pptx` deck.
+Run when the user wants to make sense of a specification or proposal deck for
+engineering. Run when the user asks for an engineering brief from a slide deck.
+Run when the user wants to understand what a project deck really asks for.
 
 ## Prerequisites
 
@@ -35,16 +36,17 @@ from a slide deck; or understand what a project deck is actually asking for.
 <do_confirm_checklist goal="Verify the brief is engineer-actionable before
 delivering">
 
-- [ ] No invented requirements — every claim traces to the deck.
-- [ ] Plain language; no marketing jargon (no "synergize", "orchestrate",
+- [ ] No invented requirements. Every claim traces to the deck.
+- [ ] Plain language, with no marketing jargon (no "synergize", "orchestrate",
       "leverage", "intelligent \_\_\_ hub").
-- [ ] JTBDs describe the user's goal, not the proposed solution; one job per
-      statement; each includes the "so that".
-- [ ] Data dependencies table flags blockers (missing, locked, compliance).
+- [ ] JTBDs describe the user's goal. They do not describe the proposed
+      solution. One job per statement. Each job includes the "so that".
+- [ ] The data-dependencies table flags blockers (missing, locked, compliance).
 - [ ] Synthetic data needs name fields, ranges, edge cases, and volume.
 - [ ] Gaps and open questions list what an engineer would notice missing.
-- [ ] Brief is under 2,000 lines — a summary, not a transcription.
-- [ ] Knowledge base looked up for mentioned people, orgs, and projects.
+- [ ] The brief is under 2,000 lines. It summarizes the deck. It does not
+      transcribe it.
+- [ ] You looked up mentioned people, orgs, and projects in the knowledge base.
 
 </do_confirm_checklist>
 
@@ -65,20 +67,21 @@ For multiple decks, pass all files at once. To save the extracted text:
 node .claude/skills/deck-summarize/scripts/extract-pptx.mjs "$FILE_PATH" -o /tmp/deck_extract.txt
 ```
 
-Read all extracted text before continuing.
+Read all extracted text before you continue.
 
 ### 2. Identify the core problem
 
-Plain-language answers to: what process exists today; what's broken, slow, or
-painful; who suffers. Don't restate the deck's framing.
+Give plain-language answers. Name the process that exists today. Name what is
+broken, slow, or painful. Name who suffers. Don't restate how the deck frames
+the problem.
 
 ### 3. Extract Jobs-To-Be-Done
 
 Format: `When [situation], I need to [action], so that [outcome].`
 
-Group by user role/persona. One job per statement. Use the user's goal, not the
-proposed solution. A job should still make sense if you discard the deck's
-solution. Don't restate the deck's feature list as jobs and don't reuse its
+Group by user role/persona. One job per statement. Use the user's goal. Do not
+use the proposed solution. A job should still make sense if you discard the
+deck's solution. Don't restate the deck's feature list as jobs. Don't reuse its
 jargon.
 
 ### 4. Map dependencies
@@ -87,39 +90,42 @@ jargon.
 [references/brief-template.md](references/brief-template.md#data-dependencies-table).
 Flag blockers (missing, locked, unstructured, compliance).
 
-**4b. Systems & integrations** — every external system/API/platform: what the
-integration does, read-only vs read-write, API vs manual/scraping, access
-confirmed?
+**4b. Systems & integrations** — list every external system, API, and platform.
+For each one, say what the integration does. Say whether it is read-only or
+read-write. Say whether access runs through an API or through manual work or
+scraping. Say whether someone confirmed access.
 
-**4c. People & approvals** — approvals, reviews, or co-creation needed before
-engineering can proceed. Flag long lead-time items (legal, compliance, vendor
-contracts).
+**4c. People & approvals** — list the approvals, reviews, or co-creation that
+must happen before engineering can proceed. Flag long lead-time items (legal,
+compliance, vendor contracts).
 
 ### 5. Define synthetic-data needs
 
 For each core feature/use case:
 
 - **Generate:** entity, key fields and types, realistic value ranges and
-  distributions, edge cases that matter, volume for meaningful testing.
+  distributions, edge cases that matter, volume for a meaningful test.
 - **Simulate:** workflows and state transitions, time-series patterns,
   multi-actor interactions, error/failure modes.
-- **Format:** prefer CSV/JSON; PII-shaped fake data only — never real PII;
-  include happy-path _and_ adversarial examples; consider ML training/eval data.
+- **Format:** prefer CSV/JSON. Use PII-shaped fake data only. Never use real
+  PII. Include happy-path _and_ adversarial examples. Consider ML training and
+  eval data.
 
 ### 6. Translate the proposed solution
 
-Describe the build in engineering terms: components, what each does in plain
-terms, how they connect, end-to-end data flow, AI/ML capabilities and what
-they're actually doing. Translate branded names — e.g. "Intelligent Intake Hub"
-→ "OCR + NLP pipeline that extracts structured fields from scanned enrollment
-forms"; "Copay Guardian" → "Anomaly detection on weekly claims data".
+Describe the build in engineering terms. Cover the components and what each does
+in plain terms. Cover how they connect and the end-to-end data flow. Cover the
+AI/ML capabilities and what they actually do. Translate branded names. For
+example, "Intelligent Intake Hub" →
+"OCR + NLP pipeline that extracts structured fields from scanned enrollment
+forms". "Copay Guardian" → "Anomaly detection on weekly claims data".
 
 ### 7. Identify what's missing
 
-Call out: features without clear data sources; AI capabilities without a
-training-data strategy; assumed integrations; user workflows that skip edge
-cases; metrics promised without measurement infrastructure; timeline–scope
-mismatches.
+Call out features without clear data sources. Call out AI capabilities without a
+training-data strategy. Call out assumed integrations. Call out user workflows
+that skip edge cases. Call out metrics promised without measurement
+infrastructure. Call out timeline–scope mismatches.
 
 ### 8. Assemble the brief
 
@@ -130,10 +136,10 @@ decks, write one combined brief with shared dependencies.
 
 ### 9. Save and report
 
-Tell the user the file path and give a 3-sentence project summary.
+Tell the user the file path. Give a 3-sentence project summary.
 
-## Writing style
+## Style
 
-Plain language, concrete over abstract, honest about uncertainty, opinionated
-when helpful (flag dependency or timeline risks), short sentences. Engineers
-scan, they don't read essays.
+Use plain language. Choose the concrete over the abstract. Be honest about
+uncertainty. Be opinionated when it helps, and flag dependency or timeline
+risks. Keep sentences short. Engineers scan. They don't read essays.

package/templates/.claude/skills/deck-summarize/references/brief-template.md

@@ -76,9 +76,10 @@ what's realistic and what depends on what}
 
 ## Data dependencies table
 
-For Step 4a, fill in this table. Flag any data that doesn't seem to exist yet,
-is locked behind inaccessible systems, is unstructured and would need heavy
-preprocessing, or carries compliance/privacy constraints.
+For Step 4a, fill in this table. Flag any data that doesn't seem to exist yet.
+Flag data that is locked behind inaccessible systems. Flag unstructured data
+that would need heavy preprocessing. Flag data that carries compliance or
+privacy constraints.
 
 | Data        | Where It Lives             | Format                             | Access                          | Blocker?       |
 | ----------- | -------------------------- | ---------------------------------- | ------------------------------- | -------------- |

package/templates/.claude/skills/deck-summarize/scripts/extract-pptx.mjs

@@ -2,9 +2,9 @@
 /**
  * Extract text from PowerPoint (.pptx) slides.
  *
- * PPTX files are ZIP archives containing XML. This script extracts all text
- * from each slide and outputs it as structured markdown with slide headings.
- * Handles multiple files and outputs to stdout or a file.
+ * A PPTX file is a ZIP archive that holds XML. This script extracts all text
+ * from each slide. It outputs the text as structured markdown with slide
+ * headings. It handles multiple files. It writes to stdout or to a file.
  *
  * Usage:
  *   node scripts/extract-pptx.mjs <path-to-pptx>
@@ -12,7 +12,8 @@
  *   node scripts/extract-pptx.mjs file1.pptx file2.pptx
  *   node scripts/extract-pptx.mjs -h|--help
  *
- * No external dependencies — uses Node.js built-in modules only.
+ * The script needs no external dependencies. It uses Node.js built-in
+ * modules only.
  */
 
 import { readFileSync, writeFileSync } from "node:fs";
@@ -26,7 +27,7 @@ Usage:
   node scripts/extract-pptx.mjs -h|--help
 
 Options:
-  -o <path>   Write output to file instead of stdout
+  -o <path>   Write output to a file instead of stdout
   -h, --help  Show this help
 
 Output: Markdown-formatted text with ## Slide N headings per slide.
@@ -136,8 +137,8 @@ function readEntry(buf, entry) {
 }
 
 /**
- * Extract all text content from slide XML using the DrawingML namespace.
- * Matches <a:t>text</a:t> elements used by PowerPoint.
+ * Extract all text content from slide XML with the DrawingML namespace.
+ * The pattern matches the <a:t>text</a:t> elements that PowerPoint uses.
  * @param {string} xml
  * @returns {string[]}
  */

package/templates/.claude/skills/doc-collab/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: doc-collab
-description: Help the user create, edit, and refine documents in the knowledge base. Use when the user asks to create, edit, review, or collaborate on a document. Supports direct editing and approval-based workflows with knowledge base context for entity references.
+description: Help the user create, edit, and refine documents in the knowledge base. Use when the user asks to create, edit, review, or collaborate on a document. Supports direct edits and approval-based workflows, with context from the knowledge base for entity references.
 ---
 
 # Document Collaboration
 
-Help the user create, edit, and refine documents in the knowledge base. Supports
-direct editing and approval-based workflows. Always uses knowledge base context
-for entity references.
+Help the user create, edit, and refine documents in the knowledge base. This
+skill supports direct edits and approval-based workflows. It always uses context
+from the knowledge base for entity references.
 
 ## Trigger
 
@@ -19,7 +19,7 @@ Run when the user asks to create, edit, review, or collaborate on a document.
 
 ## Inputs
 
-- User's editing instructions
+- The user's edit instructions
 - `Knowledge/` — existing notes and documents
 - Document to edit (user-specified or searched)
 
@@ -31,46 +31,46 @@ Run when the user asks to create, edit, review, or collaborate on a document.
 
 ## First: Ask About Edit Mode
 
-**Before doing anything, ask:** "Should I make edits directly, or show you
+**Ask before you do anything:** "Should I make edits directly, or show you
 changes first for approval?"
 
-- **Direct mode:** Make edits immediately, confirm after
-- **Approval mode:** Show proposed changes, wait for approval
+- **Direct mode:** Make edits immediately, then confirm
+- **Approval mode:** Show proposed changes, then wait for approval
 
 Follow their choice for the entire session.
 
 ## Core Principles
 
-- **Re-read before every response** — the user may have edited the file manually
+- **Re-read before every response** — the user may edit the file manually
 - **Be concise** — don't propose outlines unless asked
-- **Don't assume** — if unclear, ask ONE simple question
-- **Use knowledge context** — search knowledge base for mentioned entities, use
-  `[[wiki-links]]`
+- **Don't assume** — if something is unclear, ask ONE simple question
+- **Use knowledge context** — search the knowledge base for mentioned entities,
+  then use `[[wiki-links]]`
 
-## Processing Flow
+## Process Flow
 
 ### Step 1: Find the Document
 
-Search thoroughly before saying a document doesn't exist:
+Search thoroughly before you say a document doesn't exist:
 
 ```bash
 rg -l -i "roadmap" Knowledge/
 find Knowledge/ -iname "*roadmap*" 2>/dev/null
 ```
 
-**If found:** Read it and proceed. **If NOT found:** Ask "I couldn't find
+**If found:** Read it. Then proceed. **If NOT found:** Ask "I couldn't find
 [name]. Shall I create it?"
 
-**Creating new documents:**
+**Create a new document:**
 
 1. Ask: "Shall I create Knowledge/[name].md?"
-2. Create with just a title — don't pre-populate with structure
+2. Create it with just a title. Don't pre-populate it with structure
 3. Ask: "What would you like in this?"
 
 ### Step 2: Understand the Request
 
-**NEVER make unsolicited edits.** If the user hasn't specified what to change,
-ask: "What would you like to change?"
+**NEVER make unsolicited edits.** If the user did not say what to change, ask:
+"What would you like to change?"
 
 Types of requests:
 
@@ -83,8 +83,8 @@ Types of requests:
 
 ### Step 3: Execute Changes
 
-Make targeted edits — change only what's needed. Preserve the user's voice and
-don't reorganize unless asked.
+Make targeted edits. Change only what's needed. Preserve the user's voice. Don't
+reorganize unless the user asks.
 
 ### Step 4: Confirm and Continue
 
@@ -92,7 +92,7 @@ don't reorganize unless asked.
 - Ask: "What's next?"
 - Don't read back the entire document unless asked
 
-## Searching Knowledge for Context
+## Search Knowledge for Context
 
 When the user mentions people, companies, or projects:
 
@@ -107,6 +107,6 @@ Use `[[wiki-links]]` to connect to other notes. Only link to notes that exist.
 ## Constraints
 
 - Match the user's tone and style
-- Make surgical edits — change only what's needed
-- Preserve the user's voice — don't reorganize unless asked
-- Only link to notes that exist — use `[[Person Name]]` for existing notes
+- Make surgical edits that change only what's needed
+- Preserve the user's voice, and don't reorganize unless the user asks
+- Only link to notes that exist, and use `[[Person Name]]` for existing notes

package/templates/.claude/skills/doc-create/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: doc-create
-description: Generate PDF documents from user requests using Playwright to render HTML to A4 PDF. Use when the user asks to create a document, proposal, report, or any multi-page PDF that is not a slide deck. Pulls context from the knowledge base for company info, project details, and people.
+description: Generate PDF documents from user requests. Playwright renders the HTML to an A4 PDF. Use when the user asks to create a document, proposal, report, or any multi-page PDF that is not a slide deck. Pulls context from the knowledge base for company info, project details, and people.
 compatibility: Requires Node.js installed. Playwright is installed on first use.
 ---
 
 # Create Documents
 
-Generate multi-page A4 PDF documents from user requests. Uses Playwright to
-render self-contained HTML to PDF. Can pull context from the knowledge base for
-company info, project details, and people.
+Generate multi-page A4 PDF documents from user requests. This skill uses
+Playwright to render self-contained HTML to PDF. It can pull context from the
+knowledge base for company info, project details, and people.
 
 ## Trigger
 
@@ -18,7 +18,7 @@ submission, brief, or any multi-page PDF that is not a slide deck.
 ## Prerequisites
 
 - Node.js installed
-- Playwright will be installed on first use
+- Playwright installs on first use
 
 ## Inputs
 
@@ -36,21 +36,21 @@ submission, brief, or any multi-page PDF that is not a slide deck.
 
 1. Check `Knowledge/` for relevant context about the company, product, team,
    projects, or people mentioned.
-2. Ensure Playwright is installed:
+2. Make sure Playwright is installed:
    `bun install playwright && bunx playwright install chromium`
 3. Create a self-contained HTML file with all CSS inlined. The HTML must handle
-   its own page layout — see **HTML Document Rules** below.
+   its own page layout. See **HTML Document Rules** below.
 4. Run the conversion script:
 
    ```text
     node .claude/skills/doc-create/scripts/convert-to-pdf.mjs <input.html> [output.pdf]
    ```
 
-   If output is omitted, the PDF is written alongside the HTML file with the
-   same name.
+   If you omit the output path, the script writes the PDF next to the HTML file
+   with the same name.
 5. Read the PDF back to visually verify it renders correctly. Check each page
-   for overflow, clipped content, and correct page breaks. Fix and re-render if
-   needed.
+   for overflow, clipped content, and correct page breaks. If you find a
+   problem, fix it and re-render.
 
 **Do NOT show HTML code to the user. Just create the PDF and deliver it.**
 
@@ -60,8 +60,9 @@ submission, brief, or any multi-page PDF that is not a slide deck.
 
 - Each page is a `<div class="page">` sized to exactly 210mm × 297mm (A4)
 - Use `page-break-after: always` on every `.page` except the last
-- Handle margins with padding inside `.page`, not with PDF margin settings
-- The PDF is rendered with zero margins — the HTML owns all spacing
+- Handle margins with padding inside `.page` rather than with PDF margin
+  settings
+- Playwright renders the PDF with zero margins, so the HTML owns all spacing
 
 **Print colours:**
 
@@ -70,16 +71,16 @@ submission, brief, or any multi-page PDF that is not a slide deck.
 
 **Fonts:**
 
-- Use system fonts only — no external font loading
+- Use system fonts only, and do not load an external font
 - Monospace stack: `'SF Mono', 'Menlo', 'Monaco', 'Consolas', monospace`
 - Sans-serif stack:
   `-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif`
 
-**Content fitting:**
+**Content fit:**
 
 - After the first render, visually check every page for overflow
-- Content must not bleed past the `.page` boundary — if it does, reduce spacing
-  or font sizes and re-render
+- Content must not bleed past the `.page` boundary. If it does, reduce spacing
+  or font sizes, then re-render
 - Page numbers, if used, must not overlap with content. Position them in a
   corner that has whitespace
 
@@ -93,14 +94,14 @@ submission, brief, or any multi-page PDF that is not a slide deck.
 
 - Use absolute `file://` paths for local images
 - Inline small images as base64 data URIs when possible
-- Verify images appear in the rendered PDF — Playwright can fail silently on
-  missing images
+- Verify images appear in the rendered PDF, because Playwright can fail silently
+  on missing images
 
 ## Design Principles
 
 - Clean, professional typography with clear hierarchy
 - Use monospace for section headers and numbers for a technical/engineering feel
-- Tables should be compact and readable — right-align monetary values
+- Keep tables compact and readable, and right-align monetary values
 - Use colour sparingly: one accent colour, one dark, lots of white space
 - Dark-background panels (timelines, hero sections) create visual contrast
 - Callout boxes with left borders draw attention to key statements

package/templates/.claude/skills/doc-create/scripts/convert-to-pdf.mjs

@@ -1,18 +1,18 @@
 #!/usr/bin/env bun
 /**
- * Convert an HTML document to A4 PDF using Playwright.
+ * Convert an HTML document to an A4 PDF with Playwright.
  *
- * Renders an HTML file into an A4 PDF with background colours preserved and
- * zero margins (the HTML is expected to handle its own page layout via CSS
- * @page rules and page-break-after). Defaults to writing the PDF alongside
- * the input file when no output path is given.
+ * The script renders an HTML file into an A4 PDF. It keeps the background
+ * colours. It sets zero margins. The script expects the HTML to handle its own
+ * page layout through CSS @page rules and page-break-after. Without an output
+ * path, the script writes the PDF next to the input file.
  *
  * Requires: bun install playwright && bunx playwright install chromium
  */
 
 import { resolve, dirname, basename, join } from "node:path";
 
-const HELP = `convert-to-pdf — render an HTML document to A4 PDF via Playwright
+const HELP = `convert-to-pdf — render an HTML document to A4 PDF with Playwright
 
 Usage: bun scripts/convert-to-pdf.mjs <input.html> [output.pdf] [-h|--help]
 

package/templates/.claude/skills/draft-emails/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: draft-emails
-description: Draft and send email responses using the knowledge base and calendar for context. Use when the user asks to draft, reply to, respond to, or send an email.
+description: Draft and send email responses with context from the knowledge base and calendar. Use when the user asks to draft, reply to, respond to, or send an email.
 ---
 
 # Draft Emails
 
-Draft and send email responses using the knowledge base and calendar for full
-context on every person and conversation. Every draft requires explicit user
-approval before sending.
+Draft and send email responses. Use the knowledge base and calendar for full
+context on every person and conversation. Every draft needs explicit user
+approval before you send it.
 
 ## Trigger
 
@@ -31,20 +31,22 @@ The user asks to draft, reply to, respond to, or send an email.
 | Draft files     | `Drafts/{email_id}_draft.md`                 |
 
 `handled` and `ignored` both exclude threads from `scan-emails.mjs`. Use
-`handled` for resolved threads (sent here, replied manually, resolved via DM);
-`ignored` for threads that need no response (newsletters, spam, outbound with no
-reply).
+`handled` for resolved threads (sent here, replied manually, resolved through a
+DM). Use `ignored` for threads that need no response (newsletters, spam,
+outbound with no reply).
 
 <do_confirm_checklist goal="Verify a draft is safe and ready before sending">
 
-- [ ] Sender and organization were looked up in `Knowledge/` before drafting.
-- [ ] Draft is a single email (not multiple variants) and matches the incoming
-      tone.
-- [ ] Body has no sign-off / name / "Best" — Apple Mail signature handles it.
-- [ ] Recruitment thread: candidate excluded from internal recipients; any
-      direct-to-candidate draft is flagged `⚠️ RECRUITER ONLY`.
-- [ ] No sensitive personal data (health, politics, etc.) was included.
-- [ ] User has explicitly approved the draft before any send.
+- [ ] You looked up the sender and the organization in `Knowledge/` before you
+      drafted.
+- [ ] The draft is a single email (not multiple variants). It matches the
+      incoming tone.
+- [ ] The body has no sign-off, name, or "Best". The Apple Mail signature
+      handles it.
+- [ ] In a recruitment thread, the candidate is excluded from internal
+      recipients. Any direct-to-candidate draft carries `⚠️ RECRUITER ONLY`.
+- [ ] The draft includes no sensitive personal data (health, politics, etc.).
+- [ ] The user explicitly approved the draft before any send.
 - [ ] Send used `--draft <path>` so cleanup and `Drafts/handled` happen
       automatically.
 
@@ -58,7 +60,7 @@ reply).
 node scripts/scan-emails.mjs
 ```
 
-Outputs `email_id<TAB>subject` for unprocessed emails (those not in
+The script outputs `email_id<TAB>subject` for unprocessed emails (those not in
 `Drafts/handled` or `Drafts/ignored`).
 
 ### 2. Classify
@@ -69,11 +71,11 @@ notifications, spam, outbound with no reply.
 **Draft a response**: meeting requests, personal mail from known contacts,
 business inquiries or follow-ups, requests for information or action.
 
-Be conservative with ignore — when in doubt, draft.
+Be conservative with ignore. When in doubt, draft.
 
 ### 3. Gather context
 
-Before drafting, look up the sender and organization in `Knowledge/`:
+Before you draft, look up the sender and the organization in `Knowledge/`:
 
 ```bash
 rg -l "sender_name" Knowledge/
@@ -81,42 +83,44 @@ cat "Knowledge/People/Sender Name.md"
 cat "Knowledge/Organizations/Company Name.md"
 ```
 
-For scheduling emails, also read the relevant calendar event:
+For an email that arranges a meeting time, also read the relevant calendar
+event:
 
 ```bash
 ls ~/.cache/fit/outpost/apple_calendar/ 2>/dev/null
 cat "$HOME/.cache/fit/outpost/apple_calendar/event123.json"
 ```
 
-Extract role, organization, relationship history, and open items. If intent is
-unclear or the person has multiple contexts, **ask** rather than guess.
+Extract role, organization, relationship history, and open items. If the intent
+is unclear or the person has multiple contexts, **ask** rather than guess.
 
 ### 4. Write the draft
 
-Save to `Drafts/{email_id}_draft.md` using the template in
+Save to `Drafts/{email_id}_draft.md` with the template in
 [references/template.md](references/template.md). Reference past interactions
-naturally; for scheduling, propose specific times from calendar availability.
+naturally. To arrange a meeting, propose specific times from the calendar
+availability.
 
 ### 5. Recruitment & staffing emails
 
-Candidates **must never** be copied on internal threads about them.
+You **must never** copy candidates on internal threads about them.
 
 - Identify the candidate from the thread and `Knowledge/Candidates/`.
-- Strip the candidate from To/CC; draft to internal stakeholders only.
+- Strip the candidate from To/CC. Draft to internal stakeholders only.
 - Direct-to-candidate emails carry the warning header
   `⚠️ RECRUITER ONLY — This email goes directly to the candidate.`
 
 If a thread mentions a candidate and includes multiple internal recipients,
-treat it as internal and exclude the candidate.
+treat it as internal. Exclude the candidate.
 
 ### 6. Present and approve
 
-Show the draft to the user. Wait for explicit approval before sending. Apply
-edits and present again as needed.
+Show the draft to the user. Wait for explicit approval before you send. Apply
+edits. Present the draft again as needed.
 
 ### 7. Send
 
-After approval, send via Apple Mail:
+After the user approves, send the email through Apple Mail:
 
 ```bash
 node scripts/send-email.mjs \
@@ -128,12 +132,12 @@ node scripts/send-email.mjs \
 ```
 
 Required: `--to`, `--subject`, `--body` (plain text). Optional: `--cc`, `--bcc`,
-`--draft`. With `--draft`, the draft file is deleted and the email ID is
-appended to `Drafts/handled` automatically.
+`--draft`. With `--draft`, the script deletes the draft file. It also appends
+the email ID to `Drafts/handled` automatically.
 
-### 8. Mark handled without sending
+### 8. Mark handled and do not send
 
-When a thread is resolved through other channels:
+When other channels resolve a thread:
 
 ```bash
 echo "$EMAIL_ID" >> Drafts/handled

package/templates/.claude/skills/draft-emails/references/template.md

@@ -1,6 +1,6 @@
 # Draft File Template
 
-Save each draft to `Drafts/{email_id}_draft.md` using this layout:
+Save each draft to `Drafts/{email_id}_draft.md` with this layout:
 
 ```markdown
 # Draft Response
@@ -22,5 +22,5 @@ Save each draft to `Drafts/{email_id}_draft.md` using this layout:
 ```
 
 The body must end with the last sentence of content. Apple Mail appends the
-user's configured signature automatically, so do **not** add a sign-off, "Best",
+user's configured signature automatically. So do **not** add a sign-off, "Best",
 "Cheers", or the user's name.