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):

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.