negative-contrastive-framing skill

---
name: negative-contrastive-framing
description: Use when clarifying fuzzy boundaries, defining quality criteria, teaching by counterexample, preventing common mistakes, setting design guardrails, disambiguating similar concepts, refining requirements through anti-patterns, creating clear decision criteria, or when user mentions near-miss examples, anti-goals, what not to do, negative examples, counterexamples, or boundary clarification.
---

# Negative Contrastive Framing

## Table of Contents
- [Purpose](#purpose)
- [When to Use](#when-to-use)
- [What Is It](#what-is-it)
- [Workflow](#workflow)
- [Common Patterns](#common-patterns)
- [Guardrails](#guardrails)
- [Quick Reference](#quick-reference)

## Purpose

Define concepts, quality criteria, and boundaries by showing what they're NOT—using anti-goals, near-miss examples, and failure patterns to create crisp decision criteria where positive definitions alone are ambiguous.

## When to Use

**Clarifying Fuzzy Boundaries:**
- Positive definition exists but edges are unclear
- Multiple interpretations cause confusion
- Team debates what "counts" as meeting criteria
- Need to distinguish similar concepts

**Teaching & Communication:**
- Explaining concepts to learners who need counterexamples
- Training teams to recognize anti-patterns
- Creating style guides with do's and don'ts
- Onboarding with common mistake prevention

**Setting Standards:**
- Defining code quality (show bad patterns)
- Establishing design principles (show violations)
- Creating evaluation rubrics (clarify failure modes)
- Building decision criteria (identify disqualifiers)

**Preventing Errors:**
- Near-miss incidents revealing risk patterns
- Common mistakes that need explicit guards
- Edge cases that almost pass but shouldn't
- Subtle failures that look like successes

## What Is It

Negative contrastive framing defines something by showing what it's NOT:

**Types of Negative Examples:**
1. **Anti-goals:** Opposite of desired outcome ("not slow" → define fast)
2. **Near-misses:** Examples that almost qualify but fail on key dimension
3. **Failure patterns:** Common mistakes that violate criteria
4. **Boundary cases:** Edge examples clarifying where line is drawn

**Example:**
Defining "good UX":
- **Positive:** "Intuitive, efficient, delightful"
- **Negative contrast:**
  - ❌ Near-miss: Fast but confusing (speed without clarity)
  - ❌ Anti-pattern: Dark patterns (manipulative design)
  - ❌ Failure: Requires manual to understand basic tasks

## Workflow

Copy this checklist and track your progress:

```
Negative Contrastive Framing Progress:
- [ ] Step 1: Define positive concept
- [ ] Step 2: Identify negative examples
- [ ] Step 3: Analyze contrasts
- [ ] Step 4: Validate quality
- [ ] Step 5: Deliver framework
```

**Step 1: Define positive concept**

Start with initial positive definition, identify why it's ambiguous or fuzzy (multiple interpretations, edge cases unclear), and clarify purpose (teaching, decision-making, quality control). See [Common Patterns](#common-patterns) for typical applications.

**Step 2: Identify negative examples**

For simple cases with clear anti-patterns → Use [resources/template.md](resources/template.md) to structure anti-goals, near-misses, and failure patterns. For complex cases with subtle boundaries → Study [resources/methodology.md](resources/methodology.md) for techniques like contrast matrices and boundary mapping.

**Step 3: Analyze contrasts**

Create `negative-contrastive-framing.md` with: positive definition, 3-5 anti-goals, 5-10 near-miss examples with explanations, common failure patterns, clear decision criteria ("passes if..." / "fails if..."), and boundary cases. Ensure contrasts reveal the *why* behind criteria.

**Step 4: Validate quality**

Self-assess using [resources/evaluators/rubric_negative_contrastive_framing.json](resources/evaluators/rubric_negative_contrastive_framing.json). Check: negative examples span the boundary space, near-misses are genuinely close calls, contrasts clarify criteria better than positive definition alone, failure patterns are actionable guards. Minimum standard: Average score ≥ 3.5.

**Step 5: Deliver framework**

Present completed framework with positive definition sharpened by negatives, most instructive near-misses highlighted, decision criteria operationalized as checklist, common mistakes identified for prevention.

## Common Patterns

### By Domain

**Engineering (Code Quality):**
- Positive: "Maintainable code"
- Negative: God objects, tight coupling, unclear names, magic numbers, exception swallowing
- Near-miss: Well-commented spaghetti code (documentation without structure)

**Design (UX):**
- Positive: "Intuitive interface"
- Negative: Hidden actions, inconsistent patterns, cryptic error messages
- Near-miss: Beautiful but unusable (form over function)

**Communication (Clear Writing):**
- Positive: "Clear documentation"
- Negative: Jargon-heavy, assuming context, no examples, passive voice
- Near-miss: Technically accurate but incomprehensible to target audience

**Strategy (Market Positioning):**
- Positive: "Premium brand"
- Negative: Overpriced without differentiation, luxury signaling without substance
- Near-miss: High price without service quality to match

### By Application

**Teaching:**
- Show common mistakes students make
- Provide near-miss solutions revealing misconceptions
- Identify "looks right but is wrong" patterns

**Decision Criteria:**
- Define disqualifiers (automatic rejection criteria)
- Show edge cases that almost pass
- Clarify ambiguous middle ground

**Quality Control:**
- Identify anti-patterns to avoid
- Show subtle defects that might pass inspection
- Define clear pass/fail boundaries

## Guardrails

**Near-Miss Selection:**
- Near-misses must be genuinely close to positive examples
- Should reveal specific dimension that fails (not globally bad)
- Avoid trivial failures—focus on subtle distinctions

**Contrast Quality:**
- Explain *why* each negative example fails
- Show what dimension violates criteria
- Make contrasts instructive, not just lists

**Completeness:**
- Cover failure modes across key dimensions
- Don't cherry-pick—include hard-to-classify cases
- Show spectrum from clear pass to clear fail

**Actionability:**
- Translate insights into decision rules
- Provide guards/checks to prevent failures
- Make criteria operationally testable

**Avoid:**
- Strawman negatives (unrealistically bad examples)
- Negatives without explanation (show what's wrong and why)
- Missing the "close call" zone (all examples clearly pass or fail)

## Quick Reference

**Resources:**
- `resources/template.md` - Structured format for anti-goals, near-misses, failure patterns
- `resources/methodology.md` - Advanced techniques (contrast matrices, boundary mapping, failure taxonomies)
- `resources/evaluators/rubric_negative_contrastive_framing.json` - Quality criteria

**Output:** `negative-contrastive-framing.md` with positive definition, anti-goals, near-misses with analysis, failure patterns, decision criteria

**Success Criteria:**
- Negative examples span boundary space (not just extremes)
- Near-misses are instructive close calls
- Contrasts clarify ambiguous criteria
- Failure patterns are actionable guards
- Decision criteria operationalized
- Score ≥ 3.5 on rubric

**Quick Decisions:**
- **Clear anti-patterns?** → Template only
- **Subtle boundaries?** → Use methodology for contrast matrices
- **Teaching application?** → Emphasize near-misses revealing misconceptions
- **Quality control?** → Focus on failure pattern taxonomy

**Common Mistakes:**
1. Only showing extreme negatives (not instructive near-misses)
2. Lists without analysis (not explaining why examples fail)
3. Cherry-picking easy cases (avoiding hard boundary calls)
4. Strawman negatives (unrealistically bad)
5. No operationalization (criteria remain fuzzy despite contrasts)

**Key Insight:**
Negative examples are most valuable when they're *almost* positive—close calls that force articulation of subtle criteria invisible in positive definition alone.