cep-retrofit

# CEP Retrofit ## Overview Every CEP consumption contract (`CONSUMING-CONTEXT-PACKAGE.md`, `CONSUMING-COMPILED-GUIDELINES.md`, `CONSUMING-CODE-GRAPH.md`) already says it's meant to be "referenced by a one-line pointer from each consuming skill's `SKILL.md`/`.prompt.md` rather than copied into each one." That's cheap in principle. In practice, adding that pointer to an *existing* skill library — correctly, one skill at a time, in a format that matches the library's own conventions — takes someone who has read `PROTOCOL.md` and the relevant contract(s) end to end. For a library with a dozen or more skills, that friction is real, and it sits squarely between CEP and "every retrofitted library becomes a live adoption story for free." This skill inventories an existing skill library — any shape, seen or unseen — asks a human which skills should consume which contract(s), then drafts the minimal pointer insertion, previews every change, and writes only what's confirmed. **It invents no new consumption mechanism.** It reuses the three `CONSUMING-*.md` contracts verbatim; if a real retrofit need doesn't map to any of them, that's a gap in CEP itself to raise separately (see "What this skill deliberately does not do"). ## The one hard rule: zero hardcoded knowledge of any specific library This skill must run identically against a library it has never seen, in a format nobody has described to it yet, and against the author's own private skill collections. Concretely: - No real li...