sk-create-repo-rule

create-repo-rule

create-repo-rule is the repo-rule authoring workflow packet of the sk-doc family. It turns a user's request — a behaviour they want, or a failure they keep hitting — into a file under repo-rules/, wired into that repository's REPO RULES.md router.

Most requests should not become a rule. The four decision tests in references/decision-tests.md refuse more than they admit, and running them first is the cheap order. Authoring a rule that then fails a test is the expensive one.

A repo rule supplements the harness. It sits below AGENTS.md and below a live operator instruction, it can be changed when it stops matching the work, and it can be removed when it stops earning its load. This mode owns all three.

---

1. WHEN TO USE

Activation Triggers

• Someone asks for a repo rule, a project rule, or a convention that should bind before an action.
• Someone describes a recurring failure and asks how to stop it happening again.
• An existing rule needs changing because it no longer matches how the work is done.
• A rule needs retiring because nothing it prevents still happens.
• A repository needs a rule router because it has none.

Keyword triggers: create repo rule, /create:repo-rule, repo rule, project rule, REPO RULES.md, repo-rules, add a rule, retire a rule, revise a rule, trigger table, rule router.

When NOT to Use

• It teaches how to do something. A skill is capability, a rule is constraint. Route to the skill-authoring mode.
• It must bind on every turn. Content that holds when no trigger fires belongs in the always-loaded document, not behind a trigger. This is decision test 1 and the most common refusal.
• It is routing. Which skill, which command, which agent, which flags. The always-loaded document and the skills it routes to own that.
• It is one line, not a cluster. A single row is a section inside an existing rule.
• A sibling mode already produces it. README, changelog, command, catalog, playbook and diagram all have owners.