Add conversation capture receipts skill

CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## 0.2.0 - 2026-06-01
+
+- Added a conversation capture receipts skill for turning rough chat, voice-note, or inbox-dump input into human-useful no-write receipts.
+- Added a sanitized conversation capture example and workflow gate.
+
 ## 0.1.1 - 2026-06-01
 
 - Added a publication-risk scanner for catching private paths, credential-like tokens, and internal hostnames before release.

README.md

@@ -5,6 +5,7 @@ Reusable prompt contracts, review gates, and maintenance workflows for running c
 This repository is intentionally small. It packages field-tested operator patterns into files that other maintainers can copy into their own repos:
 
 - `AGENTS.md` prompt intake contract for ambiguous or dictated tasks
+- conversation capture receipts for rough chat, voice notes, and inbox dumps
 - maintainer triage skill for evidence-first issue and PR review
 - milestone review skill for substantial implementation work
 - application packet template for programs that evaluate OSS maintainer signal
@@ -55,12 +56,13 @@ bash scripts/check-publication-risk.sh
 ## Repository Map
 
 - `templates/AGENTS.md` - compact global intake and completion-review contract
+- `skills/conversation-capture-receipts/SKILL.md` - no-write receipt workflow for messy human input
 - `skills/oss-maintainer-triage/SKILL.md` - issue, PR, and bounty-style evidence triage
 - `skills/milestone-review/SKILL.md` - milestone and adversarial completion review workflow
 - `docs/maintenance-model.md` - the operating model behind the kit
 - `docs/workflows.md` - copyable maintainer workflows
 - `docs/publication-risk.md` - how to screen workflow packs before publishing
-- `examples/` - sanitized example packets
+- `examples/` - sanitized example packets and receipts
 - `docs/codex-for-oss-application.md` - application packet and field-ready answers
 - `scripts/validate.sh` - local validation checks
 - `scripts/check-publication-risk.sh` - conservative private-context leak scanner

docs/workflows.md

@@ -12,6 +12,16 @@ Use when a maintainer needs to decide whether an issue is actionable.
 4. State the smallest next action: reproduce, ask for missing evidence, link duplicate, accept, or close.
 5. Do not assign implementation work until the failure mode is concrete.
 
+## Conversation Capture Receipt
+
+Use when a chat agent receives rough dictated input, a messy inbox dump, or a long context note.
+
+1. Start in no-write mode unless the user already approved a write path.
+2. Produce `What I caught` before routing details so the user can tell whether the agent understood the point.
+3. Add one to three `Meaning cards` that preserve emotional weight, decisions, open loops, or context value.
+4. Separate safe next actions from write-requiring actions such as memory, task, calendar, issue, or outbound-message changes.
+5. Ask one narrow clarification only when the next action changes risk, destination, credentials, cost, or user-facing consequences.
+
 ## Pull Request Review Gate
 
 Use before approving or merging a PR.

examples/conversation-capture-receipt.md

@@ -0,0 +1,28 @@
+# Example: Conversation Capture Receipt
+
+## Input
+
+```text
+I keep saying I want the assistant to save important context, but I do not want every random thought turned into a task. When I am talking fast, I need it to catch the point, show me what it heard, and only write something permanent after I trust that it understood me.
+```
+
+## Receipt
+
+### What I caught
+
+You want capture to feel safe before it becomes storage. The assistant should understand the point of a messy note, show a small receipt, and avoid turning every thought into a task or record.
+
+### Meaning cards
+
+- **Trust boundary:** Understanding comes before persistence.
+- **Workflow preference:** Rough input should produce a human-readable receipt, not hidden routing metadata.
+- **Open loop:** Durable writes need an approval point unless the destination was already clear.
+
+### Possible next moves
+
+- Safe: turn this into a reusable prompt or checklist.
+- Needs approval: save it as memory, create a task, file an issue, or send it to another system.
+
+## Notes
+
+This example intentionally avoids private project names and service-specific routing. The reusable pattern is the receipt shape and write boundary.

scripts/validate.sh

@@ -14,9 +14,11 @@ required=(
   "docs/publication-risk.md"
   "docs/workflows.md"
   "docs/codex-for-oss-application.md"
+  "examples/conversation-capture-receipt.md"
   "examples/issue-triage.md"
   "examples/pr-review-gate.md"
   "examples/release-readiness.md"
+  "skills/conversation-capture-receipts/SKILL.md"
   "skills/oss-maintainer-triage/SKILL.md"
   "skills/milestone-review/SKILL.md"
   "templates/AGENTS.md"

skills/conversation-capture-receipts/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: conversation-capture-receipts
+description: Use when Codex needs to process rough dictated notes, chat messages, inbox dumps, or stream-of-consciousness user input into a human-useful no-write receipt before deciding whether to create memory, tasks, issues, calendar items, or other durable records. Helps preserve meaning, emotional weight, decisions, and open loops while keeping write actions gated.
+---
+
+# Conversation Capture Receipts
+
+## Goal
+
+Turn messy human input into a receipt that proves understanding before taking action. The receipt should help the user feel accurately heard, not merely routed.
+
+## Default Stance
+
+Start in no-write mode unless the user clearly approved a specific durable write. Treat capture as understanding first, persistence second.
+
+## Receipt Shape
+
+Use this structure:
+
+1. `What I caught` - two to four plain sentences naming the core point in the user's language.
+2. `Meaning cards` - one to three short cards that preserve why the input matters.
+3. `Possible next moves` - safe actions first, write-requiring actions clearly marked.
+4. `Clarifying question` - only when the answer changes risk, destination, credentials, cost, or user-facing consequences.
+
+## Meaning Cards
+
+Create cards for signals such as:
+
+- emotional weight or personal stakes
+- a decision the user is circling
+- context that should shape future work
+- a task that is implied but not yet approved
+- a risk, trust boundary, or possible false interpretation
+
+Keep cards short. Do not convert every sentence into metadata.
+
+## Write Boundaries
+
+Before creating memory, tasks, issues, calendar events, outbound messages, or external writes:
+
+1. Name the target surface.
+2. State the exact proposed record or action.
+3. Ask for approval unless the user already gave explicit permission for that surface.
+
+If the input contains ambiguous dates, meetings, people, or commitments, do not create calendar or task records until the missing facts are grounded.
+
+## Output Contract
+
+Prefer concise receipts:
+
+```markdown
+## What I caught
+...
+
+## Meaning cards
+- **Decision:** ...
+- **Context:** ...
+
+## Possible next moves
+- Safe: ...
+- Needs approval: ...
+```
+
+Do not expose internal routing labels, private project names, hidden classifier output, or long audit trails unless the user asks for implementation details.