# Context Kit Ingest > Repeatably ingest a pre-context-system session into a project context kit -- an old chat export or share link, prior engagement notes, a ticket export, or another engineer's handover/transcript -- by pulling the material, distilling it to signal (never storing verbatim transcripts), saving assets to dated docs/sessions/ directories, interleaving a docs/history.md entry, updating the affected entity's file (customer, client, stakeholder, or tenant -- whichever the kit uses), capturing reusable lessons, and verifying with a read-only sub-agent plus the context-kit-check. Use whenever the engineer wants to import, ingest, backfill, fold in, or capture work done BEFORE this kit existed -- including phrases like "ingest this old session", "import this chat into the kit", "we did this work outside the kit", "fold this handover into history", or onboarding a new customer/client/stakeholder whose earlier work lives outside the kit. Trigger even on terse asks like "ingest this session" or "add this old chat". - Skill: `wawoodwa/context-kit-ingest` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add wawoodwa/context-kit-ingest` - Raw SKILL.md: https://api.skillmd.com/api/skills/wawoodwa/context-kit-ingest/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: wawoodwa (https://skillmd.com/u/wawoodwa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/wawoodwa/context-kit-ingest --- # Prior Session Ingestion Take work that happened before this kit was in place -- an old chat export, prior engagement notes, exported scripts/policies, or another engineer's session -- and fold it into the kit cleanly: pull the material, distill it to signal, store reusable assets under `docs/sessions/`, record completed changes in `docs/history.md`, update the affected **entity's** file (see Step 0), capture lessons in the matching runbook companion file, and verify the result. The hard rule that shapes everything below: **never store a verbatim transcript.** A full chat log is noise, context-bloat, and a likely secret leak. You are extracting signal -- what changed, what was found, what assets were produced, what was learned -- not archiving a conversation. ## 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):** date entries to when the work was DONE (the session/ conversation start), `YYYY-MM-DD`, never future. - **Encodes C2 (ordering):** interleave history.md chronologically and the status.md table newest-first -- by the work date, not at the top. - **Encodes C3 (concurrency):** re-read shared index files before editing; minimal targeted inserts; Version = on-disk + 1; one writer-of-record. - **Encodes C4 (session folders):** assets under `docs/sessions/-/notes.md`. - **Encodes C5 (entity vocabulary):** discover the kit's entity term and directory (Step 0); never assume "tenant"; skip the entity layer if the kit has none. - **Encodes C7 (hygiene):** never store verbatim transcripts or secrets; no absolute mount/session paths; real IDs only in the entity file. - **Follows C6/C8/C10:** reference global kit skills rather than embedding; treat leading-underscore dirs as read-only; never `rm` -- move to Trash. ## Terminology: this skill adapts to the kit it runs in Kits organize durable work around a recurring **subject** -- the "in-circle entity." Different kits name it differently: a customer, a client, an account, a stakeholder, a vendor, a project, a property, or (in an MSP/M365 kit) a tenant. **This skill does not assume "tenant."** Step 0 discovers what *this* kit calls its entity and which directory holds the per-entity files; everywhere below, "the entity file" means that discovered file (for example `docs/customers/acme.md`, `docs/clients/acme.md`, or `docs/tenants/acme.md`). The MSP examples that appear throughout (a ticketing-system ticket, M365/Intune/Defender objects, a `tenants/` directory) are one instantiation, not a requirement -- substitute the kit's own terms. ## When to use - The engineer has notes or a transcript from work done before this kit existed. - A prior engagement produced scripts, policy exports, or baselines worth preserving as session assets. - A shared or on-call session produced durable findings that belong in `history.md` or an entity's per-subject file. - Onboarding a new customer / client / stakeholder whose prior work was done outside this kit. ## Before you start - Have the source in hand: a file path, a chat share link, a pasted transcript, or exported files. - Complete **Step 0** so you know the kit's entity vocabulary before writing. - Confirm write access to `docs/sessions/`, `docs/history.md`, `docs/status.md`, and the relevant entity file. - Know the ticket or reference for the original work (a Jira/ticket ID, a PR, or a description of the prior engagement). - **Run the `context-kit-check` skill first** so you know the kit's starting state before writing anything. You will run it again at the end. The copy-paste templates referenced throughout (session `notes.md`, the `history.md` entry, the lessons entry, and the read-only sub-agent brief) live in [references/templates.md](references/templates.md). Read that file when you reach the step that uses each one. --- ## Procedure ### Step 0 -- Identify the kit's entity layer Before ingesting anything, determine what this kit calls its in-circle entity and where per-entity files live. Do not assume "tenant." 1. **Find the per-entity directory.** Look under `docs/` for a directory of per-subject files. Common names: `tenants/`, `customers/`, `clients/`, `accounts/`, `stakeholders/`, `vendors/`, `projects/`, `properties/`. Whichever exists is the entity directory. 2. **If several exist**, pick the one whose files match the subject of the source material (e.g. ingest customer work into `customers/`, vendor work into `vendors/`). 3. **Learn the kit's term.** Read `CLAUDE.md` and an existing entity file for the word the kit uses for the subject (customer, client, account, stakeholder, tenant, etc.) and the per-entity file shape. Mirror that exact term and shape in everything you write -- do not introduce "tenant" if the kit says "customer." 4. **If the kit has no per-entity directory**, there is no entity layer here. Skip Step 5 and record the work in `history.md` only. Propose creating an entity directory only if the user asks for one; do not invent the convention unilaterally. Record the resolved entity term and directory for use in Steps 2, 4, 5, and 7. ### Step 1 -- Pull the source material Retrieve the source with the method that matches its form: - **Chat / assistant export or share link.** Use the available session or browser tools to read the transcript in memory. Do **not** paste the whole transcript into a file -- that creates the verbatim transcript the skill prohibits. Read it and go straight to Step 2. - **Prior notes / ticket export / handover doc.** Read the file(s) directly. Pull the actionable signal -- what changed, what was found, what was learned -- and ignore conversational filler. - **Exported assets (scripts, policy JSON, config backups, config files).** List and categorize them; they go to `docs/sessions/` in Step 3. Do not move them yet. ### Step 2 -- Distill: extract signal before writing anything Answer these four questions from the source. Nothing lands on disk until you have: - **2a. What was done?** List each discrete change (one change = one candidate `history.md` entry). For each: entity affected (the kit's subject from Step 0), date (best estimate if not recorded), what changed (specific object/policy/setting/system), why, outcome (verified / partial / failed), and any restore point or backup taken. - **2b. What was found but not changed?** Audit findings, misconfigurations, risks. These become "Open Items" in the entity file or a file under `docs/reviews/`. - **2c. What reusable assets were produced?** Scripts, policy JSON, config/baseline exports, infrastructure backups, modules. These go to `docs/sessions/`. - **2d. What lessons were learned?** Surprises, gotchas, gaps the runbook did not warn about, procedures that needed adapting. These go to the matching runbook's `-lessons.md` companion. Do not write verbatim transcript content anywhere. Distill to the signal. ### Step 3 -- Store generated assets in docs/sessions/ For each reusable asset from 2c: 1. Create the session directory if needed: `docs/sessions/-/`. The **date is when the work was done**, not today; the slug is a 2-4 word kebab-case description (e.g. `docs/sessions/2026-05-12-acme-ca-baseline/`). 2. Copy the asset files in. **Never store secrets** -- placeholders only; real values stay in a secret store or a `0600` file outside the repo. 3. Create or update a `notes.md` manifest using the template in [references/templates.md](references/templates.md). If the session produced no reusable assets (a read-only audit, a health check), skip the directory -- a `history.md` entry alone is enough. ### Step 4 -- Interleave a history.md entry For each completed change from 2a, add an entry to `docs/history.md`. **Re-read the live `docs/history.md` first and match the entry shape it actually uses on disk** -- read the "Entry shape" block at the top of the file and copy the most recent real entry's structure. Do not blindly paste a template from elsewhere: a change-management runbook and this skill's [references/templates.md](references/templates.md) show the *general* shape, but the live file's fields can be richer or have drifted (for example a `### ` heading with `Type`, `Entity / host`, `What shipped`, `Rollback points`, and `New risks / follow-ups`). The live file is the source of truth for format; the template is a fallback only when the file has no existing entry to mirror. Whatever shape you mirror, add the **"Ingested from"** line so the entry is marked as backfilled rather than written live. Where the source did not record a restore point or verification, write "none recorded" / "not recorded" rather than inventing one. **Interleave chronologically by the date the work was done -- do not just prepend.** `history.md` is newest-first, so an entry for work done weeks ago belongs in its correct date position (often well below the top), not at the head of the file. Find the entries that bracket the work date and insert between them. Then add a one-line summary row to the recent-changes table in `docs/status.md`, placed in the **same chronological position** (that table is newest-first too, so an older ingested session slots below the more recent rows, not at the top). ### Step 5 -- Update the entity file *(Skip this step if Step 0 found no per-entity directory; the `history.md` entry stands on its own.)* For each entity touched in 2a or 2b, open the kit's entity file for that subject (e.g. `docs/customers/.md`, `docs/clients/.md`, or `docs/tenants/.md` -- whatever Step 0 resolved) and refresh the now-stale sections: stack/baseline state, configuration/hardening state, Open Items (add findings from 2b; close anything resolved), and the last-updated date. Re-read the file from disk first and use targeted edits -- do not rewrite it from memory, or you will clobber edits made by the current session. ### Step 6 -- Capture lessons For each lesson from 2d, open the matching `docs/runbooks/-lessons.md` and **prepend** a new entry (newest-first) using the lessons template in [references/templates.md](references/templates.md). If a lesson does not clearly belong to one runbook, add it to the closest one and note the cross-cutting relevance. Mark any lesson you could not personally validate as "Ingested -- unverified" (see Safety and gotchas). ### Step 7 -- Verify with a read-only sub-agent Spawn a read-only sub-agent and brief it with the verification template in [references/templates.md](references/templates.md). It confirms the session `notes.md`, the `history.md` entry, the entity file state, and the prepended lessons all exist and cohere. A sub-agent's output is a proposal, not truth. If it reports a pass on a check you know should have failed, investigate before continuing. ### Step 8 -- Run the context integrity check Run the `context-kit-check` skill again to confirm the kit is coherent. Resolve any new FAILs the ingestion introduced before closing the task. --- ## Rollback Ingestion is additive and reversible. To undo one that introduced errors: 1. Remove the session directory. On a Mac, move it to the Trash per the file-deletion rule -- never `rm`. On a remote host with no Trash, remove it only after confirming a backup exists. 2. Remove the appended `history.md` entry and its `status.md` row. 3. Revert the entity file edits (re-read, then remove the ingested changes). 4. Remove the prepended lessons entries. 5. Re-run `context-kit-check` to confirm the kit is back to its pre-ingestion state. --- ## Safety and gotchas - **Never store verbatim transcripts.** Distill to signal -- what changed, what was learned, what assets were produced. A full transcript is context-bloat and a likely secret leak. - **Use the kit's own entity vocabulary (Step 0).** Writing "tenant" into a kit that organizes work by "customer" or "stakeholder" creates orphaned, confusing docs and has tripped up later agents. Mirror the term the kit actually uses. - **Date the session to when the work was done, not today.** The `sessions/` directory name is the date the work occurred, so provenance stays accurate when ingesting work from weeks or months ago. - **Secrets may be in prior session material.** A password, app secret, or API key in a code block must never be copied into `docs/`. Treat it as a rotation trigger: if the secret touched an uncontrolled channel (a shared transcript), it is burned -- rotate before ingesting the rest. - **"Not recorded" restore points are a gap, not a detail to hide.** If a prior destructive change took no restore point, record "none recorded" in `history.md` and add an open item to validate current state against a known baseline. - **Do not backfill lessons you have not personally validated.** Mark unconfirmed procedures "Ingested -- unverified". An unvalidated lesson that looks authoritative will mislead the next engineer. - **Real domain identifiers from prior sessions are real.** Unlike the kit's placeholder convention for IDs (e.g. an `ID` token), prior material may carry real values -- an M365 tenant GUID, an account number, a customer ID. They may go into the entity file (the right place) but must never appear in runbooks, `CLAUDE.md`, or shared templates.