Context Kit Capture

End-of-Chat Capture Skill

Captures the work from the current conversation into a self-contained task .md file, updates CLAUDE.md to reference it, and provides a continuation prompt to resume work in a new session.

Conventions (governed by context-kit-steward)

--- GOVERNED CONVENTIONS (source: context-kit-steward charter v1.0) --- Do not edit here. Change the charter in context-kit-steward and re-run it to re-sync; local edits to this block will be overwritten on the next sync.

This skill honors these shared Context Kit conventions (full text + rationale in the context-kit-steward charter):

• Encodes C1 (dating): record the work/conversation-START date (not wall-clock "now"), YYYY-MM-DD, never future; CLAUDE.md and status.md carry a Last Updated line.
• Encodes C2 (ordering): changelog.md and the status.md recent-changes table are newest-first; history.md is chronological; insert each row in its correct date position, not blindly at the top.
• Encodes C3 (concurrency): before editing a shared index file, re-read from disk, make a minimal targeted insert (not a full rewrite), set Version = on-disk + 1; one writer-of-record when multiple sessions/agents share the kit.
• Encodes C4 (session folders): per-session assets under docs/sessions/<work-date>-<slug>/notes.md.
• Encodes C7 (hygiene): no verbatim transcripts or secrets; no absolute mount/session paths in kit prose.
• Follows C5/C6/C8/C10: use the kit's own entity term (don't assume "tenant"); reference the global kit skills rather than embedding copies; treat leading-underscore dirs as read-only; never rm -- move to Trash.

When to Use

• End of any troubleshooting, configuration, or multi-step technical session
• User asks to "document what we just did" or "save this as a skill/runbook"
• A fix or procedure was reached that is likely to recur or be handed off
• User explicitly asks to update CLAUDE.md
• Trigger phrases: "create a skill file", "capture this as a task file", "update CLAUDE.md", "document what we just did", "save this workflow", or any request to wrap up a session with documentation
• Proactive: if the user says "we're done" or "that fixed it" after a multi-step technical session, suggest running this capture before closing. If more work remains, provide a continuation prompt for the next session.

Session Date (read this FIRST -- governs every date this skill writes)

Every date this skill records -- session folder slugs, changelog rows, history entries, task-file dates -- must be the date the CURRENT conversation STARTED, not the current wall-clock time when the capture runs. A long session can cross midnight, and a session may be captured hours or days after the work was done; in both cases the wall-clock "now" would record the wrong day.

Determine the session date, in this order of preference:

1. The timestamp of the first message in the current conversation. If session metadata or a transcript is available (e.g. a session-info/transcript tool, or a visible timestamp on the opening message), read the earliest message's date from it.
2. If no timestamp is exposed, scan the conversation for an explicit date the user or the environment stated at the outset (e.g. a "Today's date is ..." line in the opening context).
3. Only if neither is available, fall back to the current date -- and note in the entry that the date is the capture date, not a confirmed session-start date.

Format every recorded date as ISO YYYY-MM-DD. Use this single resolved session date consistently across all files written in this capture; do not re-derive it per file.

Output Mode (read this FIRST -- governs how all deliverables are returned)

Before doing anything, determine whether file-creation / code-execution tools are available. They are available in Claude Code, Claude Cowork, and in Chat when the file-creation feature is on.

If file tools ARE available (default, preferred path)

• Produce every deliverable as a real file and present it for download/use. This means the task .md, the updated CLAUDE.md, and the continuation prompt are each written to disk and presented -- never pasted inline, and never returned as a "go edit this file yourself" instruction.
• For updates to an existing file (CLAUDE.md or an existing task .md): read the current version from context, produce the COMPLETE rewritten file with all prior content preserved plus the additions, and present that whole file as a drop-in replacement. Do not emit a partial diff or an "insert this section here" instruction.
• Exception -- shared kit index files (CLAUDE.md, changelog.md, history.md, status.md). Do NOT deliver these as a blind COMPLETE-file rewrite from your in-context copy -- that clobbers rows a concurrent session appended. RE-READ from disk, then apply a MINIMAL targeted edit: insert the single new changelog/history/status row in its correct position (see Step 0 and Step 3), or the one new CLAUDE.md tree/Resources line, preserving everything else byte-for-byte. The full-rewrite delivery still applies to NEW task files and session assets (which no other session is editing).
• Filenames:
  • New task file -> use the naming rules in Step 2.
  • Updated knowledge file -> keep the name exactly CLAUDE.md.
  • Continuation prompt -> continuation_prompt.md.
• After presenting, give a one-line note per file stating whether it was Created or Updated.
• Exception -- continuation prompt: in ADDITION to writing continuation_prompt.md, ALWAYS also display the continuation prompt inline in a copyable fenced code block (see Step 4). This applies in every environment, regardless of whether file tools are available.
• Environment note for the user: In Chat, these files are downloads -- the user must upload/replace them in their project's knowledge to persist them. In Code/Cowork, edits to the working directory persist automatically, so write/replace in place there.

If file tools are NOT available (fallback only)

• Use the inline labeled-block format shown in Step 5. This is the only situation in which file content should appear inline in the chat.

Kit Layout (shared files this skill maintains)

These are the files the capture workflow reads from and writes to. Not every project will have all of them; create one only when the workflow calls for it, and treat this list as the common set rather than an exhaustive one.

Step 1: Inventory Existing Files and Extract from Conversation

1a. Check for Existing Related Files

Before writing anything new, look for files that already cover this topic:

1. Read CLAUDE.md (if provided or available in context) -- note every .md file referenced and what each covers
2. Scan the project directory / project knowledge for any .md files not yet referenced in CLAUDE.md
3. Compare scope: does any existing file cover the same system, procedure, or ticket as the current session?

When updating an existing file, preserve all prior content. Add new sections, expand existing ones, or append to open items -- never overwrite or truncate what was there. Per Output Mode, an "update" is delivered as a complete rewritten file, not a partial instruction.

1b. Extract from Conversation

Scan the full conversation for:

Step 2: Write or Update the Task File

Naming (new files only)

• snake_case, all lowercase, descriptive: vcenter_cert_renewal.md, appx_surgery_m90q.md
• If ticket-scoped, include the ticket ID: acme_48217_appx_repair.md

Structure

# [Task Title]

## Purpose
One sentence: what this file helps you do.

## Scope
- Client / system / ticket this applies to
- Environment context (OS version, tool versions, etc.)
- Session date: [YYYY-MM-DD -- the conversation-start date]

## Prerequisites
- [ ] Item 1 (e.g., snapshot taken, BitLocker key verified)
- [ ] Item 2

## Procedure

### Step 1: [Step Name]
What to do and why.

```shell
# Exact command(s)
```

### Step 2: [Step Name]
...

## Gotchas / Lessons Learned
- Bullet list of surprises, failures, or important caveats

## Open Items / Next Steps
- [ ] Deferred action 1
- [ ] Deferred action 2

## References
- [filename.md] -- cross-references to related skill files (filename only, no path)

Rules

• Self-contained: someone (or Claude) must be able to execute this with no other context
• Preserve all detail: do not summarize away commands, error messages, or decision points
• Use [ ] checkboxes for prerequisites and open items
• Use [filename.md] reference pattern for cross-links to other skill files -- filename only, no path
• Date with the session date (conversation start), not the capture time

Step 0 (REQUIRED before any shared-file update): Staleness & concurrency validation

Multiple sessions AND multiple agents may share this context at the same time. The collision-prone files are CLAUDE.md, docs/changelog.md, docs/history.md, docs/status.md, but there may be others. Before editing ANY of them:

1. RE-READ the file from disk immediately before editing -- never write from a stale in-context copy.
2. Detect concurrent edits: compare the on-disk CLAUDE.md Version to the top changelog row. If they already disagree, another session/agent is mid-update -- pause and reconcile before writing.
3. Derive the new CLAUDE.md Version from the on-disk value + 1 (never from memory); add the changelog row for THAT number.
4. One writer per shared index file at a time. If you are not the designated writer (e.g. you are a sub-agent or a parallel session), do NOT edit the shared index files directly -- record your work in your own docs/sessions/<session-date>-<slug>/notes.md and hand the index update to the writer (see Optional section). This keeps parallel agents from clobbering each other.
5. Make each edit a minimal, single-row/single-line insertion (never a full-file rewrite of a shared index), so that if two writes do interleave, they are easy to reconcile by re-reading.

Step 3: Update CLAUDE.md and the shared index files

Where each entry goes (insert at the correct position, not blindly at the top)

The point of being multi-session/multi-agent aware is that entries land in their right place, so the kit stays coherent no matter who wrote last. Apply these placement rules:

CLAUDE.md entry format

### [Category: e.g., Endpoint Repair / VMware / M365]
- **[task_filename.md]** -- [1-2 sentence description of what it covers and when to load it]

Rules:

• Place in the most relevant existing section; create a new section only if nothing fits
• Keep the description to 1-2 sentences -- enough to know when to load the file
• Never remove existing entries unless explicitly asked
• Delivery (per Output Mode):
  • If file tools are available: produce the complete updated CLAUDE.md as a file (existing content preserved + the new entry) and present it as a drop-in replacement.
  • If file tools are NOT available: output the update block inline with a note indicating where to insert it.
• Exception -- shared kit index files (CLAUDE.md, changelog.md, history.md, status.md). Do NOT deliver these as a blind COMPLETE-file rewrite from your in-context copy -- that clobbers rows a concurrent session/agent appended. RE-READ from disk, then apply a MINIMAL targeted edit: insert the single new changelog/history/status row in its correct chronological position (see the table above), or the one new CLAUDE.md tree/Resources line in its correct section, preserving everything else byte-for-byte. The full-rewrite delivery still applies to NEW task files and session assets (which no other session is editing).

Step 4: Generate Continuation Prompt for New Session

Compose a self-contained prompt the user can paste at the start of a new Claude session to resume this work without loss of context. The prompt must include:

• Objective -- what the overall goal is and where we are in it
• Completed steps -- what was done this session (brief, factual)
• Current state -- any relevant artifacts, file paths, config values, or system state
• Next step -- the exact action to take first in the new session
• Open issues / decisions -- anything unresolved or flagged for review

Write the prompt in the user's voice, addressed to a fresh Claude instance, so it can be pasted as-is. A new Claude instance should be able to read it and act immediately -- no follow-up questions needed.

Delivery -- ALWAYS show inline, regardless of file tools:

1. Always display the full continuation prompt in the chat inside a fenced code block, so the user can copy it directly with one click:

   ```
   [full continuation prompt text]
   ```
   

2. Additionally, when file tools are available, also write it to disk as continuation_prompt.md and present it with the other deliverables.

The inline copyable block is mandatory in every environment -- never skip it just because the file was written to disk.

Step 5: Output

Deliver all outputs per Output Mode above. State upfront whether each task file / CLAUDE.md was Updated (existing file) or Created (new file), and why. If a prior version of either file was provided in context, note any meaningful changes made. State the resolved session date you used.

Preferred (file tools available)

Present the deliverables as files:

• [task_filename.md] -- Created / Updated
• CLAUDE.md -- Updated (complete replacement)
• continuation_prompt.md -- Created

Then give a short per-file summary line, plus the reminder that in Chat the user uploads/replaces these in the project, while in Code/Cowork they persist in place.

Finally, always end by displaying the continuation prompt inline in a copyable fenced code block (per Step 4), even though continuation_prompt.md was also written to disk.

Fallback (no file tools available)

Use inline labeled blocks:

---
## [task_filename.md]  <- Updated / Created
> Updated: added [section name] based on [ticket/session], session date [YYYY-MM-DD]
[full file content]

---
## CLAUDE.md Update
[either the full updated CLAUDE.md, or the block to insert with insertion location noted]

---
## Continuation Prompt
> Paste this at the start of a new session to resume work:

```
[prompt text -- written in the user's voice, addressed to a fresh Claude instance,
providing all context needed to proceed without referencing this session]
```

Optional: Multi-agent / multi-session writer convention

When several agents or sessions are working a shared kit at once, keep the shared index files coherent with a one-writer rule:

• Each session/agent owns its own docs/sessions/<session-date>-<slug>/notes.md and any task files it creates -- these are never contended, so write them freely.
• Only the designated writer touches the shared index files (CLAUDE.md, changelog.md, history.md, status.md) at any given moment. A non-writer records what the index should say in its session notes and hands it off, rather than editing the index directly.
• The writer applies each handoff as a minimal, re-read-then-insert edit (Step 0), placing every row in its correct chronological/section position (Step 3) so concurrent work merges cleanly.

Optional: Proactive Suggestion

If a multi-step technical session has clearly concluded (user says "perfect", "that worked", "we're done") and no capture has been requested, offer:

"Want me to capture this as a task file and update your CLAUDE.md before we close out?"