Project Rules — Extract & Enforce — refactor-chain · diagnose / do-the-work guardrail

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: diagnose (extract) → do-the-work (enforce) · Prerequisite: refactor-understand (stack known) · Next: refactor-plan / whichever lane runs, then the review gate. Adaptivity / conditional: repo-agnostic — infers rules from whatever stack refactor-understand reported; read-only while extracting, advisory when it reports a violation (it never rewrites code on its own).

Purpose

Every codebase has unwritten rules: "controllers never touch the database directly," "every service is constructor-injected, never new-ed," "no module under core/ may import from web/," "DTOs live in dto/ and end in Dto." This skill reads the code, infers those rules from the patterns that already dominate, and writes them into a rules manifest (rules-manifest.md). It then runs that manifest as a checklist twice: once before a modernization step to record the starting state, and once after to prove the step introduced no new violation. The manifest becomes the project's shared definition of "still structurally correct."

When to use

• The orchestrator is about to enter a lane and wants a structural contract to hold the work to. Trigger: "extract the project's rules", "what conventions does this repo follow".
• Before/after a change, to prove no architectural rule was broken. Trigger: "make sure the refactor respects our architecture", "did we break a layer rule".
• Someone asks specifically about DI, naming, module boundaries, or layering. Trigger: "enforce DI / naming / module boundaries", "check for a layering violation".