Ad Level Up

/ad-level-up

Evolve the rule-set without bloating it. Where ad-audit audits work against the rules, this skill curates the rules — adding only the generalising survivors, leanly, with evidence, and never without your explicit approval.

Prime directive — HARD human gate

A full or drifting context, or a model having an off moment, must never edit the rule-set unsupervised — that is exactly when a bad write slips in. So: NEVER write without explicit human approval. Always present the proposal plus a plain-language rationale first; apply only on the user's OK, one item at a time. No batch writes, no "while I'm here" edits. This gate is enforced by this contract, not by tool permissions — hold to it even though Edit is available.

Rules target

Two curated layers exist (ADR-0035 + ADR-0043); every accepted candidate targets exactly one:

• Machine store — a you-everywhere convention: $AGENTIC_RULES_DIR if set, else ~/.agentic/rules/.
• Project rules — a this-project convention: .agentic/rules/ at the repo root. On genuine conflict, a project rule shadows a machine-store rule (the audit reports the shadowing), so curate a project rule when the project deliberately deviates from the practitioner's global set.

Recommend the layer from the rule's own content (does it generalize beyond this repo?); the user confirms. Read the target layer before proposing (the edit needs a prior read; voice-matching needs the current text). If the target layer does not exist yet, say so — offer to create it on approval, rather than inventing a path. First project-rule creation: ask whether .agentic/rules/ is committed (versions with the repo; the team inherits it) or machine-local; in machine-local mode, on approval, write the .agentic/rules/ entry into .git/info/exclude yourself — never .gitignore, which is committed and team-visible. When you find an .agentic/rules/ that is neither committed nor excluded (e.g. a fresh clone), re-offer the choice. A convention that belongs in a repo binding doc (AGENTS.md, GUIDELINES.md) or is bigger than a rule line routes to /ad-adr or /ad-guidelines instead — this skill owns the terse rule-set.

Step 1 — State candidate + evidence

One sentence plus the citation (a finding, PR, transcript, or file:line — or the ad-audit handoff that surfaced it). If it cannot be cited, stop — it is not grounded, and a lone uncited slip is a memory note, not a rule.

Step 2 — Trace to root cause

Where was this seeded? Attach the candidate to the upstream cause (an investigation / grounding / verification gap), not the surface symptom.

Step 3 — Four anti-overfitting gates

All four must pass; reject the rest out loud:

1. Recurrence or deliberate decision — it recurs / matches a known prior pattern, OR it is a deliberate forward-looking standardisation. A lone accidental slip with neither is a memory note, not a rule.
2. Generalisation — it helps a whole class of future work, not just re-prevents this exact scenario.
3. Load-bearing root cause — an upstream cause that cascaded, not a leaf symptom.
4. Proportionate cost — it earns its keep against every reader carrying it forever (each extra rule lowers adherence to all the others). A rule preventing a rare, cheaply-caught-downstream slip is a net negative — reject it.

Step 4 — Effectiveness pass

• Classify: improvement · correction · increment · merge into an existing rule · extend an existing rule · reject. Prefer sharpening / merging / extending over adding a new line.
• Redundancy: does an existing rule (or a repo binding doc) already watch this? If so, merge — never add an overlapping rule.
• Real behaviour: does it catch a defect actually observed (cite it), or a hypothetical? A rule guarding a defect nobody has hit is dead weight — reject or shelve as a note.
• Dead-rule sweep: if an existing rule no longer maps to real behaviour or is subsumed by another, flag it for retirement in the same proposal.