KEEP — Knowledge Engine for Engineering Persistence

KEEP turns a code repository into a living knowledge graph an LLM agent both consults and maintains. Code is the execution layer; /knowledge/ is the memory layer; the agent is the reasoning layer. The skill is successful when a new contributor (human or agent) can answer how and why the system evolved without re-deriving everything from code, and when changes to code automatically surface as proposed changes to knowledge.

When to trigger

KEEP is failing if it triggers only on code changes. The read path — consulting knowledge when answering questions — is what compounds value.

Read — run /keep-ask first, before answering, on prompts like:

• "how does X work?", "why did we choose Y?", "what did we decide about Z?"
• "is there a convention for", "where does X live", "what happens when"
• "are we using X or Y?", "is there already something for", "is it safe to change"

The user is reaching for information that should be in /knowledge. Even if the answer is also in code, the knowledge layer has the why (rationale, rejected alternatives, edge cases) that code does not. Antipattern: answering from memory or grep.

Decision-grade cross-check. When the user is about to act on the answer (merge, deploy, debug-in-progress), /keep-ask consults /knowledge first then verifies anchored load-bearing claims against code — a spec can drift between merges, and the user deserves the warning before they act. Cues: "sto per mergeare", "is this still true", "safe to deploy?". See references/commands/keep-ask.md.

Write — run /keep-compile after non-trivial code changes in a /knowledge-enabled repo: new features, dependency/framework swaps, topology changes, post-incident fixes, runtime-affecting config changes.