# Context Kit Steward > Design-before-run meta-skill that keeps the Context Kit skill family coherent and evolving. It owns the shared conventions charter (references/CONVENTIONS.md) that every kit skill must honor -- work-start dating, newest-first ordering, multi-session concurrency, entity vocabulary, reference-don't-embed, hygiene, and skill-authoring limits -- audits each kit skill for drift from the charter, and harvests recurring lessons from real operating context kits to propose updates. Always produces an approval-gated proposal first and emits drop-in skill edits; it never auto-edits skills. Use whenever the operator wants to align, sync, audit, or evolve the context-kit skills, reconcile conventions across them, propagate one lesson into the whole suite, or asks 'keep my kit skills consistent', 'update the charter', 'do my context skills still agree', or 'propagate this across the kit skills'. Run it after changing any one kit skill, or after operating several kits, to catch cross-skill drift before it spreads. - Skill: `wawoodwa/context-kit-steward` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add wawoodwa/context-kit-steward` - Raw SKILL.md: https://api.skillmd.com/api/skills/wawoodwa/context-kit-steward/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: wawoodwa (https://skillmd.com/u/wawoodwa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/wawoodwa/context-kit-steward --- # Context Kit Steward The keeper of the **Context Kit** skill family. The family is a set of skills that all operate on the same artifact -- a context kit (`CLAUDE.md` + `docs/` tree): | Role | Current skill name | |---|---| | capture a session into the kit | `context-kit-capture` | | audit one kit | `context-kit-check` | | backfill pre-kit work | `context-kit-ingest` | | scaffold the next kit | `context-kit-scaffold` | | shrink / reorg kit docs | `context-kit-split` | | **keep the family coherent (this skill)** | `context-kit-steward` | These skills share a set of conventions (dating, ordering, concurrency, entity vocabulary, hygiene, and more). When those rules live copy-pasted inside each skill, they **drift** -- one skill gets a fix the others don't. This steward exists to stop that: it makes the conventions a single referenced charter, checks every skill against it, and folds new lessons back into the whole suite. This is to the skill FAMILY what `context-kit-check` is to a single kit: a read-first coherence audit, one level up. --- ## The charter is the single source of truth `references/CONVENTIONS.md` is the canonical statement of every shared convention, plus a per-skill conformance matrix, and it carries a `Charter-Version`. **Conventions change there first, then propagate.** ### Governance model: embedded copies, synced through the steward Skills cannot reliably read another skill's files at runtime (install paths are environment-specific and a referenced skill may not be present). So the family does NOT rely on runtime cross-reads. Instead: - **Each kit skill embeds its OWN copy** of the conventions it must honor, under the provenance header defined in the charter's Governance section, stamped with the `Charter-Version` it was synced from. The copy is self-contained. - **The embedded copy is governed, not authored locally.** Nobody edits a convention inside an individual skill. To change one: edit the charter, bump `Charter-Version`, then run THIS skill to re-sync every copy. - **The steward is the one writer-of-record** for conventions (Convention 3 applied to the skills). It is the only thing that writes those embedded blocks. Drift is therefore mechanically detectable: a skill whose stamped `vX.Y` is older than the charter's `Charter-Version` is out of sync. (For distribution, the whole family is best shipped as one plugin so the charter and skills version together; the governance model above is what holds regardless of how they are installed.) --- ## Design before run (non-negotiable) This skill is **design-before-run**. It NEVER edits a skill as a side effect. The flow is: read everything, produce a written proposal, get explicit approval, only then emit drop-in edits. Environment note: in this runtime, installed skills cannot be modified in place. The steward delivers updated skills as **drop-in files** (an installable bundle or replacement `SKILL.md` + `references/`), and the operator installs them via Settings > Capabilities. State this plainly in the report; never imply a live edit. --- ## Workflow ### Phase 0 -- Load the charter and inventory the family Read `references/CONVENTIONS.md` in full and note its `Charter-Version`. Inventory the installed kit skills (by the roles in the table above; match on description/role, not just exact name, since the operator may have renamed them). For each, read its `SKILL.md` and any `references/`, and grep its embedded provenance header for the stamped charter version (`GOVERNED CONVENTIONS (source: context-kit-steward charter vX.Y)`). A skill with no governed block has never been synced; a skill whose stamp is older than the charter is out of sync. If the charter is missing, STOP and offer to scaffold it from the conventions found across the skills (the charter must exist before an audit is meaningful). ### Phase 1 (design) -- Conformance audit First, the **version-stamp check** (mechanical): for each skill, compare its stamped charter version to the charter's `Charter-Version`. Missing stamp = never synced; older stamp = out of sync. Then, the **content check** -- for each convention in the charter's matrix, check the responsible skill's text: - **encodes** -- does the skill actually teach/write the rule, and match the charter wording (dates = work start, newest-first, version = on-disk+1, etc.)? - **verifies** -- does the auditor skill actually check it? - **seeds** -- does the scaffold skill bake it into generated stubs? - **follows/aware/respects** -- does the skill avoid contradicting it (e.g. no "prepend at top" where the charter says "insert in date position"; no hardcoded "tenant"; no `rm`; no embedded global skill)? Record each as PASS / DRIFT / MISSING with the exact file + line evidence. ### Phase 2 (design) -- Harvest from operating kits If the operator points at real context kits (one or more project roots), scan them read-only for: recurring friction, convention violations the skills should have prevented, and patterns worth promoting into the charter. Distill to signal -- never copy verbatim kit content or secrets into the proposal. A new lesson that recurs across two or more kits is a charter candidate, not a one-off. ### Phase 3 (design) -- Synthesize the proposal Produce ONE written proposal covering: - **Charter changes** -- new/edited conventions (with rationale), if any. - **Per-skill drop-in edits** -- for every DRIFT/MISSING, the precise change to realign the skill to the charter, keyed to file + location. - **Naming/grouping** -- flag any skill whose name or cross-references are out of step with the family (optional; only if asked or clearly broken). - **Risk + order** -- which edits are safe vs need judgment; suggested apply order. Show it as a table the operator can approve or amend row by row. ### Phase 4 (approval gate) -- STOP for sign-off Present the proposal and WAIT. Do not generate any edited skill before the operator approves (use a multiple-choice approval for small sets; plain-text edits for large ones). This gate is the point of a design-before-run skill. ### Phase 5 (run) -- Emit the approved drop-ins For each approved item, produce the COMPLETE updated file(s) -- charter and/or each skill's `SKILL.md` + `references/` -- as drop-in replacements, packaged installable. For every skill being synced, **regenerate its governed conventions block** from the charter and **re-stamp the provenance header** with the current `Charter-Version` (insert the block if the skill has none yet). Put each convention's text only inside the governed block so the next sync can replace it cleanly. Honor the charter's own skill-authoring limits on anything you emit: every YAML `description` stays under 1024 characters and contains no angle brackets (the governed block lives in body text, never in the YAML `description`). ### Phase 6 (verify) -- Self-check before handing off - Every emitted `description` is < 1024 chars and bracket-free (mechanically check). - Cross-references between skills resolve (a skill that names another names it correctly; the charter path each skill cites exists). - Re-run the Phase 1 matrix against the EDITED skills: every cell should now PASS. - If a real kit was touched in Phase 2, it was read-only -- confirm no writes. Report PASS / FIX / PROPOSE, and restate that the operator must install the drop-ins via Settings > Capabilities (no live edits happen here). --- ## When to use - After changing any one kit skill -- to propagate the change so the others don't fall out of step. - After operating several real kits -- to harvest recurring lessons into the charter. - On inheriting or periodically reviewing the family. - Trigger phrases: "align the kit skills", "update the charter", "do my context skills still agree", "propagate this lesson across the kit skills", "audit the context-kit family". ## Safety and gotchas - **Design before run, always.** No skill is edited before Phase 4 approval. - **No live skill edits in this runtime.** Deliver drop-ins; point to Settings > Capabilities. Never claim an installed skill was changed in place. - **Charter first.** A convention change lands in `CONVENTIONS.md` before any skill; skills reference the charter rather than restate it. - **Read-only against real kits.** Phase 2 distills signal; it never writes to a kit or copies verbatim content/secrets into the proposal. - **Honor the family's own rules on your own output** -- dating, no-`rm`, description limits. The steward must not violate the charter it enforces.