warden-rule-discovery

name	warden-rule-discovery
description	Discover which Warden rules a codebase needs by investigating it — the upstream step before any rule gets written. Use this whenever someone wants to set up, bootstrap, or onboard the warden on a project, asks "what rules should this repo have?", points the warden at a codebase that has zero rules, or wants to turn a team's conventions into enforceable policy. Trigger when the job is figuring out WHICH rules to create — as opposed to writing one already- decided rule, which is the sibling skill `warden-rule-author`. It surveys the repo, proposes a prioritized, evidence-backed rule set, confirms the real intent with a maintainer, then hands each confirmed rule to the author skill.
compatibility	Requires the warden CLI.

Discovering Warden rules for a codebase

This is the discover half of a two-skill pipeline:

warden-rule-discovery   →   warden-rule-author
"which rules does this        "write this one rule
 repo need, and why?"          as valid rules/*.yaml"

Your job here is to investigate a codebase and come back with a prioritized, evidence-backed proposal of rules — then, once a human confirms the intent, hand each rule to warden-rule-author to write the YAML and validate it. Do not write rule files yourself from this skill; producing the schema is the author skill's job.

The cardinal rule: propose and confirm, never guess the intent

Static signals tell you what the code does, not what the team considers wrong. These come apart constantly. The most important thing this skill teaches is to surface candidate anti-patterns and ask a maintainer before committing to any rule.

Real example this skill is built from: an agent saw all over a repo and proposed a "don't read env vars" rule. Plausible — and wrong. The team's actual anti-pattern was gating features on / instead of feature flags; the env reads were mostly legitimate boundary config. Only the maintainer's domain knowledge caught it. Grepping found the ; the human supplied the .