Skip to main content

codebase-doctrine

Derive or refresh durable, evidence-backed repository doctrine, including correctness atlases, doctrine audits, task-context projections, and repository-skill recommendations. Not quick onboarding, ordinary implementation, or generic review.

Source facts

Repository
tkersey/dotfiles
Last source activity
September 11, 2026 at 22:34
Detected SKILL.md language
English
Stars
70
Forks
1

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
12 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
codebase-doctrine
description
Derive or refresh durable, evidence-backed repository doctrine, including correctness atlases, doctrine audits, task-context projections, and repository-skill recommendations. Not quick onboarding, ordinary implementation, or generic review.
metadata
{"version":"3.0.0","activation_cost":"high","default_depth":"standard"}
# Codebase Doctrine ## Mission Recover the repository's **latent constitution** and render the smallest context that will materially improve a named future consumer's decisions. ```text repository evidence -> rival explanations -> selection pressures -> authorities, laws, freedoms, wounds, proof, and aporia -> exact consumer context ``` The result is not a schema-shaped inventory of everything discovered. It is the smallest explanatory basis that changes what a future maintainer or agent will inspect, preserve, reject, change freely, or prove. ## Activation boundary Use when the request combines deep repository understanding with durable correctness doctrine, a correctness atlas, authority/law/failure/proof analysis, doctrine refresh, an audit against doctrine, a task-specific doctrine projection, or evidence-based repository-skill recommendations. Do not use for: - quick onboarding or an architecture summary; - one feature, bug trace, or isolated invariant; - ordinary implementation or generic review; - skill brainstorming without repository evidence; - direct skill creation. The workflow is read-only. Persistence, implementation, skill creation, commits, pushes, and publication require their own explicit authority. ## Inquiry dimensions Infer these dimensions independently; do not force them into one mode enum. ```text operation discover | refresh search provisional | standard | deep rendering doctrine | task-context | audit | portfolio ``` Also establish the **consumer** and **change horizon**: who will use the context, which classes of future change it should improve, and which consequences matter. Use a reasonable provisional frame when the prompt already supplies enough context. Uncertain user intent does not stop descriptive discovery. It prevents the model from silently collapsing materially different normative branches. Continue learning the current system, expose the branch, and ask only when a user-owned choice becomes necessary to choose among target doctrines or effects. ## Evidence discipline Research before asserting. Keep these categories distinct: ```text observed fact inference current behavior current governing law documented intent explicit user target proposal governed aporia open question ``` Prefer, in order: 1. current creation, mutation, transition, certification, publication, rollback, and invalidation paths; 2. current executable proof and observable behavior; 3. current runtime evidence; 4. several independent current evidence lanes; 5. exact history, regressions, reverts, and failed routes; 6. current repository guidance; 7. names and comments. Generated reports, prompts, examples, memory summaries, and prior agent narratives are possible contamination, not independent proof. Keep search notes and evidence working material internal unless they help the consumer evaluate a consequential claim. Do not manufacture protocol artifacts, synthetic IDs, bidirectional graph bookkeeping, schemas, validators, compilers, or validation receipts merely to perform the inquiry. Never use `validated` as a generic synonym for convincing. Read [doctrine-induction.md](references/doctrine-induction.md) when inducing or reconstructing doctrine; projection alone does not require a new induction. ## Selected inquiry Select from the existing inquiry dimensions, not a new mode enum: | Current need | Read before proceeding | |---|---| | Discover doctrine, or reconstruct an unsupported part | [discovery.md](discovery.md); it retains the complete induction and adequacy workflow. | | Refresh existing doctrine | Refresh below; reopen changed/invalidated seams, using discovery only where the prior basis must be reconstructed. | | Project doctrine for a named task | Task-context projection below and [context-rendering.md](references/context-rendering.md); verify relevant current evidence rather than rerunning whole-repository discovery. | | Deep search or an unresolved high-impact question needs specialists | [specialists.md](specialists.md); all specialist authority remains read-only. | | Portfolio or skill recommendations | Induce the relevant doctrine first, then [skill-candidacy.md](references/skill-candidacy.md); an explicit portfolio request is required. | Do not treat an old doctrine or a summary as current authority. Missing evidence reopens only the affected claim and its dependencies, not an automatic repo tour. The complete law form remains required for consequential laws in every rendering: ```text Law what must remain true Jurisdiction where and when it applies Selection pressure why the repository needs it Evidence current observations supporting it Counterexample a trace that would violate it Permitted variation what may change without violating it Operational effect how future work should change because of it Proof burden what must establish preservation or refinement Invalidators what would make the law obsolete, local, or contested ``` <a id="workflow"></a> The discovery workflow is in [discovery.md](discovery.md#workflow). <a id="read-only-specialists"></a> Specialist rules are in [specialists.md](specialists.md#read-only-specialists). ## Task-context projection Bind the named consumer, task, and change horizon. Recover the exact existing doctrine and inspect current evidence for its relevant jurisdictions, freedoms, proof obligations, and invalidators. Project only what could change this task's decisions; preserve governing contradictions and evidence limits rather than turning a descriptive observation into a requirement. Refresh invalidated claims using Refresh below. Use the relevant parts of [discovery.md](discovery.md) when the evidence basis is missing; a projection is not permission to invent doctrine. Apply the existing [behavioral adequacy](references/behavioral-adequacy.md) to the projected context and the task's plausible changes. No implementation, persistence, or skill creation is authorized by this rendering. ## Evidence providers Codebase Doctrine owns analysis and synthesis. It may consume bounded evidence from existing architecture maps, direct repository research, `$seq`, `$negative-ledger`, and `$grill-me`. Missing optional providers do not block direct research. Providers never become competing doctrine owners. See [evidence-provider-handoffs.md](references/evidence-provider-handoffs.md). ## Output Read [context-rendering.md](references/context-rendering.md) for the requested repository doctrine, task-context, audit, or portfolio view. Use the complete law form in Selected inquiry; render only decision-relevant evidence and do not dump raw search notes. Portfolio analysis requires already-induced doctrine and an explicit request. ## Refresh A refresh reopens the doctrine from current evidence. It does not compare two prose snapshots and call the difference semantic refresh. 1. Reinspect changed and invalidated seams. 2. Ask which prior authorities, laws, freedoms, wounds, proofs, or aporia the changes could affect. 3. Re-falsify affected doctrine against current code and proof. 4. Preserve unaffected doctrine only when its jurisdiction and evidence still apply. 5. Report retained, revised, added, retired, and newly aporetic doctrine in plain language. 6. Re-render the requested consumer context and rerun behavioral adequacy. ## Persistence Default output is conversational. Persist only when requested: ```text .codebase-doctrine/doctrine.md ``` Local-exclude by default unless the user explicitly requests versioned doctrine. Do not silently create repository files. ## Skill-creation handoff Codebase Doctrine recommends; it does not create. When skill creation is already user-authorized, use the bounded `$tune create` handoff in [skill-candidacy.md](references/skill-candidacy.md). Preserve the exact authority and package scope; a model-authored assertion does not grant permission. ## Empirical evolution When a generated repository skill has actual decision episodes, use the evaluation and evolution guidance in [skill-candidacy.md](references/skill-candidacy.md). ## Hard rules - Read-only. - Research before asserting. - Trace change-bearing seams, not directory tours. - Form rivals before committing to a consequential explanation. - Recover selection pressures; do not preserve complexity merely because it exists. - Current behavior, documented intent, explicit target, proposal, and aporia remain distinct. - No law without jurisdiction, selection pressure, counterexample, freedoms, operational consequence, proof burden, and invalidators. - No invariant without owner, initialization, preserving transitions, counterexample, boundary, exception ownership, and proof posture. - Writes and transitions outrank readers and names for authority. - Preserve real contradiction as governed aporia rather than forcing false closure. - Route knowledge after doctrine and prefer stronger enforcement over skills. - Zero skills is valid. - Render the smallest decision-shaping context for the consumer. - No persistence or skill creation without explicit authorization. - Never claim exhaustive understanding.
View on GitHub