feat(aidd-context): audit an existing rule corpus for conflicts, duplication and drift

Start with docs/ARCHITECTURE.md, plugins/aidd-context/skills/05-rule-generate/SKILL.md, and its actions/03-validate.md to understand the existing lifecycle and placement options. Compare the read-only audit patterns in plugins/aidd-dev/skills/04-audit/SKILL.md and plugins/aidd-refine/skills/03-shadow-areas/actions/01-detect.md; done means a corpus-wide report identifies source files, separates finding categories, and requires approval before remediation.

Problem

A project can accumulate many AI rules over time. Each individual rule may be structurally valid while the corpus as a whole develops inconsistencies that per-file validation cannot detect: contradictory instructions, semantic duplicates, partial overlaps, ambiguous or inconsistent scopes, obsolete rules, or equivalent concerns represented differently across rule locations.

A corpus can also be internally consistent while still being poor persistent AI context: it may repeat standard language, framework, or tool knowledge; over-explain a valid project decision; retain generic examples or copied reference documentation; or embed unstable details. The relevant question is useful project context per token, not minimum rule length.

Repository-level AGENTS.md already requires checking new instructions and rules against existing ones for coverage or contradiction. Issue #791 makes that principle systematic during rule generation. There is still no dedicated workflow for applying the same consistency check retrospectively to an existing rule corpus.

05-rule-generate validates generated rule files individually; it does not provide a project-wide audit for accumulated conflicts, duplication, overlap, scope problems, drift, or context efficiency.

Scope

• Discover the rule sources applicable to the current project.
• Analyze rule intent and scope across the discovered corpus.
• Cross-check rules for likely semantic duplicates, conflicting instructions, partial overlaps or tensions, suspicious or inconsistent scopes, and potential restructuring opportunities.
• Analyze context efficiency within rules: substantial standard knowledge, over-explanation, generic examples or copied reference material, and unstable details that add persistent context without project-specific value.
• Distinguish project-specific policy, team conventions, explicit choices between valid alternatives, exceptions, security or compliance constraints, scope restrictions, and examples that genuinely remove ambiguity from explanatory content that can be shortened or moved.
• Distinguish strong conflicts from lower-confidence overlaps or tensions.
• Produce a read-only report identifying the source files involved in every finding.
• Suggest possible remediation without modifying the corpus by default. For context-efficiency findings, this may include shortening or relocating explanatory material to an on-demand artifact while preserving the project-specific decision.
• Require explicit user approval before applying any merge, deletion, rewrite, scope change, or restructuring.
• Keep implementation open: a dedicated skill, an extension of an existing audit/refinement skill, or a reusable rule-consistency capability shared with #791.

Acceptance criteria

• Running the audit discovers the supported rule sources applicable to the current project.
• Two semantically equivalent applicable rules are reported as a possible duplicate with both source files identified.
• Two incompatible applicable instructions are reported as a conflict with both source files identified.
• Partial semantic overlaps are distinguishable from definite conflicts.
• Suspicious scope differences are reported separately from semantic conflicts.
• Every finding identifies the rules or files that produced it.
• The audit produces a readable summary of findings by category.
• A valid project policy with substantial generic tutorial content is reported as a context-efficiency finding without challenging the policy itself.
• Generic examples are distinguishable from examples that encode project-specific behavior or remove genuine ambiguity.
• Every suggested simplification identifies the project-specific requirement that must be retained, and may recommend a more appropriate artifact.
• Rule length alone is never evidence that a rule is over-specified.
• Running the default audit does not modify any rule file.
• Suggested remediation can include merge, split, rewrite, removal, or scope or priority clarification.
• No remediation modifies existing rules without explicit user approval.

Prior art in this repo

• AGENTS.md#L27 requires checking whether an existing instruction, finding, or rule covers or contradicts a new one before adding it.
• docs/ARCHITECTURE.md#L44-L60 places aidd-context in Knowledge production and says capability placement follows concern, while leaving the concrete implementation seam open.
• 05-rule-generate/SKILL.md#L7-L20 defines the current capture, write, and validate lifecycle.
• 03-validate.md#L1-L22 validates each written rule against authoring and tool-path contracts, not corpus-level semantic consistency.
• aidd-dev/04-audit/SKILL.md#L8-L33 is a read-only seven-pillar codebase audit; its listed pillars do not include rule-artifact consistency.
• aidd-refine/03-shadow-areas/SKILL.md#L7-L29 and 01-detect.md#L3-L20 scan one written artifact for blind spots and deduplicate gaps within that scan; they do not compare an applicable rule corpus pairwise.
• 05-rule-generate/references/rule-authoring.md#L6-L12 already requires ultra-short rule bullets and no prose, while permitting an example only when it removes ambiguity.
• Issue #618 treats source-backed references, verification dates, and silent drift as a structural lifecycle concern, supporting an auditable approach to evolving knowledge artifacts.
• Issue #791 addresses the prevention case: compare a candidate rule with existing rules before writing it. This issue addresses the complementary detection case: audit rules that have already accumulated.

I searched open and closed issues and pull requests for rule audit, rule consistency, conflicting or duplicate rules, semantic comparison, drift, and rules refactoring. I found no equivalent corpus-wide proposal.

Out of scope

• Automatically fixing every reported finding.
• Modifying rules during the default audit.
• Replacing 05-rule-generate or its existing per-file validation.
• Treating every semantic similarity as a duplicate or every tension as a hard conflict.
• Determining the canonical owner or location of every project context artifact; that is a separate context-architecture concern.
• Defining a new universal precedence model across host AI tools.
• Auditing general source-code quality, architecture, security, performance, dependencies, or tests when those concerns belong to existing codebase audit capabilities.