email-capture
Skill3 starsChanged 4 months agoMITView on GitHub
Converts email threads, SOWs, change requests, and pasted documents into structured capture documents for spec-driven development. Extracts requirements, decisions, commitments, and open questions with source attribution to sender and message date. Use when given an email thread, SOW, change request, or pasted document that needs to be converted into structured requirements with per-message source attribution.
In this repository86 other files it gives its agents.
- AGENTS.mdAGENTS.md
- project-templates/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- project-templates/CLAUDE.mdCLAUDE.md
- alembic-migration-managerSkill
- architecture-journalSkill
- architecture-reviewSkill
- automated-code-reviewSkill
- axum-scaffolderSkill
- capture-consolidateSkill
- cargo-package-scaffoldSkill
- code-review-coachSkill
- confluence-guide-writerSkill
- dependency-mapperSkill
- doc-syncSkill
- dotnet-architecture-checklistSkill
- dotnet-controller-api-scaffolderSkill
- dotnet-security-reviewSkill
- dotnet-vertical-sliceSkill
- ef-migration-managerSkill
- environment-healthSkill
- evaluate-testsSkill
- fastapi-scaffolderSkill
- fitness-functionsSkill
- jira-comment-writerSkill
- legacy-migration-analyzerSkill
- minimal-api-scaffolderSkill
- nuget-package-scaffoldSkill
- oss-vettingSkill
- pattern-tradeoff-analyzerSkill
- php-api-scaffolderSkill
- php-architecture-checklistSkill
- php-feature-sliceSkill
- php-migration-managerSkill
- php-package-scaffoldSkill
- php-security-reviewSkill
- pr-feedback-writerSkill
- pypi-package-scaffoldSkill
- python-architecture-checklistSkill
- python-feature-sliceSkill
- python-modernization-analyzerSkill
- python-security-reviewSkill
- qraspi-architectureSkill
- qraspi-graduateSkill
- qraspi-implementSkill
- qraspi-planSkill
- qraspi-questionsSkill
- qraspi-researchSkill
- qraspi-skeletonSkill
- qrspi-implementSkill
- qrspi-planSkill
- qrspi-questionsSkill
- qrspi-researchSkill
- qrspi-specSkill
- react-app-scaffolderSkill
- react-architecture-checklistSkill
- react-component-scaffolderSkill
- react-feature-sliceSkill
- react-modernization-analyzerSkill
- react-security-reviewSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Ask the PM to provide the email thread — paste text or give file path
- Very specific: line 49
Treat a single document (SOW, change request, spec) as one high-authority block.
- Very specific: line 53
Call search_knowledge("requirements extraction stakeholder communication written") to calibrate (KB lookups: …
- Very specific: line 61
Call search_knowledge("acceptance criteria given when then format") to confirm format
- Distinctive: line 64
If Confluence publish is requested: ask for target space and parent page before publishing
- Very specific: line 66
Default output path: captures/[YYYY-MM-DD]-[thread-slug].md
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Email Capture
"The difference between a requirement and a preference is whether anyone will know if you ship without it." -- Adapted from Karl Wiegers, "Software Requirements"
"Every email thread is a negotiation. Requirements hide in the agreement, not the conversation."
Core Philosophy
Email threads are lower-noise than meeting transcripts but structurally messier. Requirements are embedded in reply chains, buried under greetings and signatures, split across multiple messages, and sometimes contradicted in later replies. A change request buried in a forwarded attachment is still a requirement.
This skill reads email threads and documents methodically — parsing by sender authority, chronological order, and message type — to extract requirements, decisions, commitments, and open questions with source attribution. Email content is often more decisive ("we need X by date Y") but also more fragmented (the final agreed version is in message 12 of a 15-message thread, not in message 1).
What this skill does: Accepts pasted email thread text or a file path. Parses the thread to identify senders, dates, and message sequence. Extracts requirements, decisions, commitments, and open questions with source attribution. Flags contradictions between earlier and later messages. Produces a structured capture markdown with provisional DRAFT-NNN IDs.
What this skill does NOT do: Access email accounts or inboxes (input is manual paste or file), synthesize requirements from ambiguous phrasing, resolve contradictions autonomously, or push to Confluence without explicit PM instruction.
The seven domain principles (chronology, sender authority, attachments-first-class, contradictions-surfaced-not-resolved, commitments-as-requirements, provisional IDs, logged trimming), the knowledge-base lookups, the AI discipline rules, anti-patterns, and error-recovery procedures live in references/capture-discipline.md.
Workflow
The INTAKE → PARSE → EXTRACT → OUTPUT loop. Every phase template (intake, parse log, extraction guide + log, capture document, session opening) is in references/email-capture-templates.md. Parsing depth — thread structure, authority map, document types, contradiction patterns, boilerplate, attachment handling — is in references/thread-parsing.md.
Phase 1: INTAKE — Gather PM Context
- Ask the PM to provide the email thread — paste text or give file path
- Collect context with the Intake Template (five fields: project/client, thread description, authoritative senders, in-scope topics, out-of-scope topics)
- Confirm understanding of authoritative senders and document scope
- Only then → PARSE
Do not proceed without all five context fields.
Phase 2: PARSE — Structure the Thread
- Identify all messages (sender, date, subject if available)
- Detect forwarded chains, inline replies, and attachment references
- Build a chronological message map; identify the authoritative senders from intake
- Flag any referenced attachment not present as
[ATTACHMENT NOT PROVIDED: filename] - Log the Parse Summary before extraction
Treat a single document (SOW, change request, spec) as one high-authority block. Inline replies are attributed to the replying sender. (Full parse rules: references/email-capture-templates.md.)
Phase 3: EXTRACT — Requirements, Decisions, Commitments, Open Questions
- Call
search_knowledge("requirements extraction stakeholder communication written")to calibrate (KB lookups:references/capture-discipline.md) - Work through the thread chronologically, extracting signal by message using the Extraction Signal Guide
- Assign provisional
DRAFT-NNNIDs to each item - Mark the most recent position on each topic; tag earlier ones
[SUPERSEDED by DRAFT-NNN]— keep for audit, never delete - Produce the Extraction Log before OUTPUT
Phase 4: OUTPUT — Produce Capture Document
- Call
search_knowledge("acceptance criteria given when then format")to confirm format - Organize extracted content by signal type
- Produce the capture markdown using the Output Template (below)
- If Confluence publish is requested: ask for target space and parent page before publishing
Default output path: captures/[YYYY-MM-DD]-[thread-slug].md
State Block
<email-capture-state>
phase: intake | parse | extract | output
project: [project or client name]
thread: [thread description and date range]
messages_parsed: N
authoritative_senders: [list]
requirements_found: N
decisions_found: N
commitments_found: N
open_questions_found: N
contradictions_found: N
attachments_missing: [list or "none"]
output_path: [file path, or "pending"]
last_action: [what was just done]
next_action: [what should happen next]
</email-capture-state>Output Template
# [Thread Title] — [Date Range] — [Project / Client]
Sections: Participants (Name / Role / authority level) | Summary (2–3 sentences) | Key Decisions (statement + Source: sender, date) | Requirements Extracted (DRAFT-NNN + statement + source, with [SUPERSEDED by DRAFT-NNN] or ⚠ [UNCERTAIN] tags) | Commitments (DRAFT-NNN + statement + source) | Open Questions (question + source + status: Unanswered / Answered in msg N) | Contradictions Flagged (table: Item / Earlier Position / Later Position / Source-Earlier / Source-Later / PM Resolution) | Action Items (owner + due date) | Missing Attachments (filename + who referenced it) | Thread Trim Log (table: Excluded / Reason).
Session Opening: Explain the 4-phase process (intake → parse → extract → output). State that nothing is silently excluded. Ask: where is the thread/document, what project does it feed into, and who has decision authority. Emit initial <email-capture-state> with phase: intake.
Full capture-document template and all phase templates: references/email-capture-templates.md.
Integration with Other Skills
transcript-capture— Use when the intake source is a meeting transcript rather than an email or document. Both skills produce the sameDRAFT-NNNcapture format. Usecapture-consolidateto merge outputs.capture-consolidate— Run after one or more capture sessions to assign canonicalREQ-XXXIDs, deduplicate overlapping requirements, and surface contradictions.confluence-guide-writer— If the final capture document should be published to Confluence, use this skill to format and publish after PM approval.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

