Adapt Best Practice

---
name: adapt-best-practice
description: Use when the user wants to apply a practice but has specific constraints that differ from the canonical case — team size, industry regulation, budget, maturity level, technology stack, or organizational culture. Produces an adapted version that preserves the practice's core while fitting the user's reality.
source: Situational Leadership model (Hersey & Blanchard, 1969); Lean principles — adapt to context while preserving core value (Womack & Jones, "Lean Thinking", 1996); contextual design methodology (Beyer & Holtzblatt, 1997)
tags: [adaptation, constraints, customization, context, fit, situational, pragmatic]
---

# Adapt Best Practice

Customize a practice for specific constraints while preserving its core effectiveness.

## Why This Is Best Practice

**Adopted by:** Situational Leadership (Hersey & Blanchard, 1969) is the canonical model for context-sensitive application — the same leadership approach applied uniformly across different team maturities produces worse outcomes than adapting to the situation. Lean manufacturing explicitly distinguishes between principles (non-negotiable) and tools (adapt to context) — Toyota Production System practitioners are trained to identify which is which before adapting. Contextual design methodology (Beyer & Holtzblatt, 1997) formalizes user-centered adaptation for design processes.
**Impact:** Organizations that apply best practices without adaptation to their context show lower adoption and higher abandonment rates than those that receive context-appropriate versions (McKinsey Organizational Health research, 2017). The most common reason practitioners abandon practices is "it doesn't fit how we work" — which usually means the form, not the substance, was incompatible. Adaptation preserves adoption.
**Why best:** The alternative — "apply the canonical practice or don't apply it" — produces two failure modes: abandonment when constraints make full compliance impossible, and compliance theater when people go through the motions without the core substance. Explicit Core/Adjustable/Optional classification makes the difference visible: what must stay, what can flex, and what can be skipped without breaking the practice's fundamental value.

Sources: Hersey & Blanchard (1969) "Management of Organizational Behavior"; Womack & Jones (1996) "Lean Thinking"; McKinsey Organizational Health Index research

## Steps

### Step 1: Identify the practice and constraints

From user input: "apply X but we're a 2-person team", "we're in a regulated industry", "we don't have budget for Y", "our team is new to this."

If the practice is named, match against installed skills. **Missing-practice fallback:** If the named practice does not exist in the installed skills index, do not invent one. Output:
```
Practice not found: [practice-name]
Closest match: [similar-skill-name] ([domain]) — is this what you meant?
```
If no close match exists: 'No installed practice matches [practice-name]. Run /discover-best-practices to find available practices for [domain].'

Do not proceed with adaptation until the source practice is confirmed.

If constraints aren't stated, ask ONE question:
```
What's the main constraint that makes the standard approach difficult?
```

Common constraint categories to listen for:
- Team size (solo / small team / large org)
- Industry regulation (healthcare, finance, legal, government)
- Budget / resource limits
- Technical maturity (beginner / intermediate / expert)
- Technology stack constraints
- Organizational culture (startup / enterprise / non-profit)
- Timeline pressure (needs to work this week, not this quarter)

### Step 2: Classify each step of the practice

Read the matched skill's Steps section. For each step, classify:

| Type | Definition |
|------|------------|
| **Core** | Non-negotiable — removing this breaks the practice's fundamental effectiveness. The reason the practice exists. |
| **Adjustable** | Can be scaled, simplified, substituted, or done differently without losing core value. The form can change; the substance stays. |
| **Optional** | Adds value in the ideal case but can be skipped under constraints without undermining the core outcome. |

**Classification rubric:**
- **Core** — step directly implements the practice's defining principle; removing it means the practice is no longer being applied (e.g., in TDD: 'write the test before the code' is Core — without it, it's not TDD)
- **Adjustable** — step implements the principle but the mechanism can vary by context (e.g., naming conventions, tool choices, team size thresholds)
- **Optional** — step adds quality or polish; the practice works correctly without it (e.g., adding inline comments, creating summary reports)

Test: ask 'If I remove this step, is the practice still being applied?' Yes → Optional or Adjustable. No → Core.

**Core-step confirmation:** Before adapting, explicitly state which steps are core (must be preserved) and which are context-specific (can be adapted). Show this to the user:
```
Core steps (preserved): [list]
Adaptable steps (context-specific): [list]
Adapting: [what will change and why]
```
This makes the adaptation principled rather than arbitrary — the user can see what's being treated as non-negotiable.

### Step 3: Map constraints to adjustments

For each constraint the user has, identify:
- Which steps it affects (Core / Adjustable / Optional)
- What adaptation preserves the core while accommodating the constraint
- What is lost by the adaptation (and whether that loss is acceptable)

Present as a mapping table:

```
Constraint: [user's stated constraint]
  Affects: Step N ([Adjustable/Optional])
  Adaptation: [what changes]
  Trade-off: [what's lost — acceptable because: reason]
```

### Step 4: Warn when a constraint compromises a Core step

If a constraint would require removing or fundamentally changing a Core step:

```
⚠ [constraint] conflicts with a core step of [practice].
Removing [step] would undermine the practice's primary value because [specific reason].
Proceed with adapted version? (y/n — or "explain the risk" for more detail)
```

If the user asks "explain the risk": describe the specific failure mode that occurs when this core step is skipped, with a concrete example if possible.

If all core steps would be removed by the constraints: don't adapt — redirect:
```
These constraints would remove all core steps of [practice].
The adapted version would not achieve [primary purpose].
Consider [alternative-practice] instead — it's designed for [constraint type].
```

### Step 5: Present the adapted version

Show the full practice with modifications annotated inline. Every step must be labeled:

```
Adapted [practice-name] for [stated constraints]:

Step 1: [original step text] — ✓ unchanged
Step 2: [original step text] — adapted: [what changes and why, one line]
Step 3: [original step text] — ✗ skipped: [what's lost, why acceptable given constraint]
```

After the adapted version, summarize the trade-off in one sentence:
```
Trade-off: [what this adaptation gains] at the cost of [what it loses].
```

## Rules

- Always label adapted steps — ✓ unchanged / adapted: / ✗ skipped — so the user knows what changed
- Never silently remove a Core step — always warn with Step 4 warning and get confirmation
- If constraints make the practice unworkable entirely, say so and redirect to an alternative
- Don't adapt to the point of inventing a new practice — if the adaptation diverges fundamentally from the original, name that explicitly
- The trade-off summary is required — don't leave the user guessing what they gave up
- Adaptation is not permission to skip hard parts — Core steps require a warning, not silent removal

## Common Mistakes

**Silent core step removal**: quietly dropping a step that is Core is worse than not adapting at all — it creates the illusion of following the practice while missing its substance. Always warn.

**Over-classifying as Optional**: when uncertain, classify as Core. The cost of over-adapting (losing the practice's value) is higher than the cost of keeping a step that could technically be skipped.

**Adapting form but not explaining why**: "Step 2: adapted" with no explanation leaves the user unable to judge whether the adaptation is sound. Name what changes and why.

**Redirecting when adaptation is possible**: if even one core step can be preserved, adapt — don't give up and redirect unless all core steps are compromised.