Project Rules Architect

Produces a rule set the agent will actually follow — not a style guide it skims and ignores. The failure this skill exists to prevent: someone asks for "all the rules, act like a senior dev," gets fifteen files of inconsistent depth, half of them contradicting each other, wired into nothing so none of it loads, and six months later nobody trusts the rules enough to maintain them.

The shape of the solution: a library of specialised rule templates — universal, per-domain, and per-technology — selected by probing the project, not copied wholesale. One fact lives in exactly one template. Everything the agent needs before it can act is in the entry file; everything else is a file it loads when relevant.

Read references/research-summary.md once per session before drafting — the evidence behind every principle below. Read references/postmortems.md whenever this run consolidates existing rules, adopts a project's conventions, or ports a pattern from another project. Both are real, previously-caught failures, not hypothetical ones. Don't re-derive them.