Help us improve
Share bugs, ideas, or general feedback.
From grimoire
Adapts a best practice to fit specific constraints like team size, regulation, budget, or tech stack while preserving its core value.
npx claudepluginhub jeffreytse/grimoire --plugin grimoireHow this skill is triggered — by the user, by Claude, or both
Slash command
/grimoire:adapt-best-practiceThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Customize a practice for specific constraints while preserving its core effectiveness.
Proactively checks for applicable best practices before starting any user task, applying or offering them automatically. Inspired by poka-yoke error prevention.
Guides organizational AI adoption using Brian Balfour's CODER framework: diagnoses barriers, creates plans with constraints, ownership, directives, expectations, rewards.
Share bugs, ideas, or general feedback.
Customize a practice for specific constraints while preserving its core effectiveness.
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
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. 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:
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. |
A step is Core if skipping it would mean the practice no longer achieves its primary purpose. When in doubt, classify as Core — err toward preserving the practice.
For each constraint the user has, identify:
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]
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].
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].
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.