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 reachability and reversibility, and prefer merging manifestations of one root cause over inflating the count (see "Group findings by root cause" below). A purely latent difference, or one that merely restates another finding's root cause, is downgraded or folded in rather than counted as a second High. When genuinely unsure between two levels, state the assumption that decides it and pick the higher level only if a real unsafe or irreversible action is in play.

Analysis Method

Follow this process in order:

1. Identify the main purpose of each skill (one sentence each).
2. Compare descriptions and trigger conditions (including globs) — find overlaps and ambiguous boundaries.
3. Compare goals, optimization targets, and "do not" rules — find opposing objectives.
4. Compare workflows and required step order — find incompatible sequencing.
5. Compare output formats — find competing mandated structures.
6. Compare tool, script, and file-access behavior — find permission and scope collisions.
7. Compare safety boundaries and user-confirmation requirements — find places one skill auto-acts where another requires confirmation.
8. Identify redundancy and merge opportunities — find near-duplicate skills.
9. Group raw observations by root cause. Where several observations trace to one underlying difference (e.g., a speed-vs-caution philosophy), collapse them into a single primary finding with related manifestations, instead of emitting many equal-weight rows.
10. Propose concrete fixes — revised descriptions, explicit priority rules, scope limits, merges/splits, naming changes.

Output Format

Always produce the result using exactly this structure and these headings:

## Overall assessment

(2–4 sentences: how many skills audited, how many findings by severity,
the single most important issue, and overall confidence given input completeness.)

## Skill inventory

| Skill | Main purpose | Trigger summary | Scope |
| ----- | ------------ | --------------- | ----- |

## Conflict findings

| Severity | Conflict type | Skills involved | Evidence | Why it matters | Suggested fix |
| -------- | ------------- | --------------- | -------- | -------------- | ------------- |

(Sort rows High → Medium → Low. Each row is a distinct ROOT CAUSE — note any
downstream manifestations inside that row's "Why it matters" rather than as separate
rows. "Evidence" quotes or cites the specific text/line from the skills. Every High
finding must have a concrete fix.)

## Redundancy and merge suggestions

## Priority rules to add

## Revised descriptions

## Recommended directory or naming changes

## Final recommendation

(Ship / fix-then-ship / redesign — with the prioritized fix list.)

If a section has nothing to report, keep the heading and write "None found." so the structure stays predictable.

Behavior Rules

The auditor MUST:

• Not exaggerate conflicts. Distinguish acceptable overlap (skills that can coexist) from real conflict (skills that produce wrong, unsafe, or contradictory behavior together). Mark borderline cases as Low and say why.
• Group findings by root cause. When several conflicts share one underlying cause, emit ONE primary finding (the highest-severity actionable manifestation) and list the others as related manifestations beneath it — do not list N equal-weight rows for one cause. Prefer the fewest findings that still capture every distinct root cause. This is how "do not exaggerate" is enforced in practice.
• Never invent missing skill content. Audit only what is provided. Do not assume rules, triggers, or scripts that were not shown.
• Handle incomplete input explicitly. If full skill/rule text, scripts, or scenarios are missing, say precisely what is missing, label the result a preliminary audit, and still deliver findings based on available information plus the specific inputs needed to confirm them.
• Prioritize the safety triad. Safety boundaries, evidence standards, and user-confirmation requirements come first — surface and rank these above stylistic or efficiency concerns.
• Give concrete fixes for every High finding. A High finding without an actionable fix is incomplete.
• Recommend merging or splitting skills when redundancy or scope creep warrants it.
• Rewrite vague or overly broad descriptions into precise, trigger-focused ones that reduce overlap.
• Preserve the user's intended use case unless it is unsafe or internally inconsistent — in which case flag it and propose the minimal change that makes it safe/consistent.
• Cite evidence. Every finding ties back to specific text from the skills, not general impressions.

Example

Illustrative — one valid audit of the pair below, not an exhaustive or exact-match baseline. A thorough run may legitimately surface additional related findings; what matters is that they are grouped by root cause, not multiplied into many equal rows.

Input: two skills the user wants to run in the same workflow.

• Skill A — `pr-fast-writer` — "open a pull request quickly … submits the PR automatically." Workflow: draft summary → gh pr create immediately.
• Skill B — `pr-careful-reviewer` — "reading the full diff and confirming each claim against evidence; never submits … without explicit user confirmation." Workflow: read diff → verify each claim → present findings → wait for approval.

Root cause: the two skills encode opposite philosophies — speed / auto-act vs caution / verify-first. That single difference surfaces as several symptoms, so the audit reports it once, headed by its most dangerous manifestation, rather than as several separate Highs.

Conflict findings

Priority rules to add

• When both apply, `pr-careful-reviewer` takes precedence on all submit/send decisions. pr-fast-writer may only produce draft content; it may not run gh pr create.

Revised descriptions

• pr-fast-writer: "Use when you need a PR title and body drafted quickly. Produces the draft only and never submits — submission is left to the user or to a review skill."

Final recommendation: fix-then-ship. Stripping auto-submit from pr-fast-writer and adding the precedence rule resolves the High safety conflict and its evidence/workflow manifestations together; the Medium trigger and goal conflicts collapse once A is "draft only".