lawrence3699/skill-conflict-auditor
A Claude/Agent Skill that audits a set of AI skills (SKILL.md files) for conflicts, overlaps, redundancy, unclear priori
Actual rules from this repo
Path in source repo: .cursor/rules/skill-conflict-auditor.mdc · format: mdc
---
description: Use when you have two or more AI skills or rules (Claude SKILL.md files, Cursor .mdc rules, skill descriptions, or skill folders) and need to check whether they conflict — overlapping triggers, contradictory goals, undefined priority, incompatible workflows or output formats, clashing tool/script rules, mismatched safety boundaries or evidence standards, redundancy, scope creep, or naming ambiguity. Use when designing a skill set, when installed skills behave unpredictably, or when merging/splitting/renaming skills in a personal or team library. NOT for reviewing application source code, writing prose, or optimizing a single standalone prompt.
alwaysApply: false
---
# Skill Conflict Auditor
## Overview
This skill audits a **set of AI skills/rules** (Claude `SKILL.md` files, Cursor `.mdc` rules, and their supporting assets) for problems that only appear when several coexist: two skills firing on the same task, skills pulling toward opposite goals, no rule for who wins, incompatible step orders, clashing output formats, contradictory tool/script permissions, mismatched safety boundaries, and slow-drifting duplicated rules.
Core principle: **most skill problems are not inside one skill — they are in the relationships between skills.** A skill that is perfect alone can become unsafe or unstable next to another. This auditor evaluates the *interactions*, not the individual quality of any single skill.
This is not general code review, not prose editing, and not single-prompt optimization. The unit of analysis is always two or more skills/rules compared against each other.
## When to Use
- The user provides multiple `SKILL.md` files or `.mdc` rules (or descriptions, or folder trees) and asks "do these conflict?"
- The user is designing a group of skills/rules meant to work together and wants to catch collisions before shipping.
- The user reports unstable or unpredictable behavior after installing several skills/rules (wrong one triggers, inconsistent output, contradictory actions).
- The user wants to merge, split, rename, or reorganize an existing set of skills/rules.
- The user is building a personal or team skill/rule library and wants a coherence/safety pass.
**When NOT to use:** auditing a single skill in isolation (no second skill to compare against), reviewing normal application code, or rewriting one prompt/rule for quality.
## Expected Inputs
The richer the input, the higher-confidence the audit. Ideal input includes:
- **Skill/rule names** (all of them).
- **Descriptions** (the YAML `description` / "when to use" text).
- **Full skill/rule contents** (`SKILL.md` body or `.mdc` body) — strongly preferred; descriptions alone only support a preliminary audit.
- **Folder structures** (optional) — reveals scripts, templates, references, examples, glob patterns.
- **File lists for scripts / templates / references** (optional) — needed to catch tool and script conflicts.
- **Real usage scenarios** (optional) — concrete situations where these skills/rules would be active at the same time. These expose trigger-overlap and priority conflicts that static reading misses.
If parts are missing, proceed with a clearly-labeled preliminary audit (see Behavior Rules) and list exactly what additional input would raise confidence.
## Conflict Categories
Check every pair (and relevant groups) of skills/rules against all of the following. Do not stop at the first finding.
1. **Trigger overlap** — descriptions, "when to use" sections, or `globs` are similar enough that both would be invoked for the same task, with no tiebreaker.
2. **Goal conflict** — skills optimize for opposing objectives (e.g., speed/throughput vs. conservative/thorough review).
3. **Priority conflict** — when two skills' rules disagree, nothing defines which one wins.
4. **Workflow conflict** — required step orders are incompatible (e.g., one says produce final output first, another requires evidence/verification before any output).
5. **Output format conflict** — skills mandate competing or mutually exclusive output structures for the same artifact.
6. **Tool / script conflict** — scripts or tool-use rules collide (e.g., one formats the entire repository, another forbids touching unrelated files; one auto-runs a command another bans).
7. **Safety boundary conflict** — one skill permits automatic sending, submitting, deleting, network access, or system modification while another requires explicit user confirmation for the same kind of action.
8. **Evidence standard conflict** — one skill allows speculation/assumption while another requires verified evidence before claims.
9. **Scope conflict** — one skill is so broad (or `alwaysApply: true`) that it overrides or absorbs more specific skills that should have handled the task.
10. **Redundancy** — two skills serve nearly the same purpose and likely should be merged.
11. **Naming ambiguity** — names are too vague, or too similar to each other, to disambiguate intent.
12. **Hidden assumption conflict** — skills silently assume different platforms, environments, users, repos, or task conditions.
13. **Maintenance risk** — the same rule is duplicated across skills and will drift out of sync over time.
## Severity Levels
Assign exactly one severity to each finding.
- **High** — can cause an unsafe action, data loss, incorrect submission/sending/deletion, or wrong technical judgment. A safety-boundary, evidence-standard, or destructive/outbound difference defaults to High **only when the conflicting action is (a) reachable in a realistic shared workflow and (b) outbound, destructive, or otherwise hard to reverse.**
- **Medium** — can cause unstable output, workflow confusion, inconsistent formatting, duplicated work, or inefficient execution, but not unsafe action.
- **Low** — naming issues, unclear wording, mild acceptable-ish overlap, or minor redundancy with little practical impact.
**Do not apply "defaults to High" mechanically.** Calibrate against reachaContent truncated. View full file in the source repo (linked above).
Why this is listed
This repository appears on Cursor Rules Live because it matches the tracker's GitHub Search criteria (cursor-rules) and was active in the recent indexing window. The tracker refreshes every 15 minutes, so the metadata above reflects the state at the most recent index pass. If the data here looks stale, the source repository may have been archived or moved out of the tracked topic; the next cron tick will reconcile.