Conflict Patterns

Conflict Patterns

This skill teaches you how to detect rule conflicts between two rule lists produced by the Rule Extraction skill.

Types of Conflicts

1. Direct Contradiction

Two rules that explicitly state opposite behaviors.

Patterns to detect:

• always X vs never X
• do X vs do not X / avoid X
• use X vs do not use X
• must X vs must not X
• 始终 X vs 禁止 X
• 必须 X vs 不允许 X

Examples:

❌ "Always add docstrings to every function"
   vs "Do not add docstrings — keep code self-documenting"

❌ "Use double quotes for strings"
   vs "Use single quotes for strings"

❌ "Write commit messages in Chinese"
   vs "Write commit messages in English"

2. Semantic Contradiction

Two rules that don't use opposite words but prescribe incompatible behaviors.

Examples:

❌ "Keep functions under 20 lines"
   vs "Always include full error handling, logging, and retry logic in every function"
   (the second makes the first impossible to satisfy)

❌ "Optimize for readability, use verbose variable names"
   vs "Minimize code length, prefer concise expressions"

❌ "Add a comment above every line of code"
   vs "Comments should only appear when logic is non-obvious"

Detection approach: Ask whether it is possible to satisfy both rules simultaneously in a realistic scenario. If not, it is a semantic contradiction.

3. Scope Overlap (Non-Conflicting, Worth Noting)

Two rules that cover the same topic but are compatible — one is more specific than the other.

Examples:

⚠️  "Use camelCase for all identifiers"
    and "Use PascalCase for class names"
    (PascalCase rule is a valid specialization of the camelCase rule — not a conflict)

⚠️  "Write tests for all code"
    and "Write unit tests for utility functions"
    (second is a subset — no conflict)

These are not conflicts — label them as overlap only, not conflict.

Non-Conflicts to Ignore

The following patterns look like conflicts but are not. Do not flag these.