Skill Refactorer for Claude Fable 5 / 5.1

Skills and prompts written for earlier Claude models often encode capability compensation: step-by-step hand-holding, exhaustive enumeration of edge cases, and rigid micro-workflows that existed because older models needed them. Fable 5 and 5.1 follow instructions strictly enough that this old scaffolding becomes a straitjacket — the model obeys the obsolete recipe instead of using its own (now better) judgment. The result is output that is worse than no skill at all. Fable 5 prompts generally carry over to 5.1 unchanged, but 5.1 narrates less and formats less by default, so lines written to suppress either now cut into what the reader needs.

Your job: separate what the instruction protects from how it micromanages, keep the former, delete the latter.

Workflow

1. Inventory. List every imperative instruction in the target skill/prompt as a separate line item.
2. Classify each item into exactly one bucket:
   • Guardrail — protects against a real, current risk (data loss, secrets, destructive commands, compliance). KEEP.
   • Preference — a genuine style/format choice the owner still wants (tone, language, naming conventions). KEEP, but compress to one sentence if it sprawls.
   • Compensation — exists only because an older model would otherwise fail (forced step sequences, "always re-read the file before editing", verbose output templates, repeated "do not forget" reminders, enumerations of failure modes the model no longer exhibits). DELETE or replace with a single statement of intent.
3. Rewrite. For every deleted compensation, ask: "what outcome was this trying to guarantee?" If the outcome still matters, state the outcome once, not the procedure. Example:
   • Before: "Step 1: open the file. Step 2: locate the function. Step 3: copy it to a scratch buffer. Step 4: edit the copy. Step 5: diff against the original. Step 6: ..."
   • After: "Edits must be verifiable: keep a way to diff your change against the original before finalizing."
4. Tighten the description field. Triggering logic stays in frontmatter description; the body should assume the skill already fired.
5. Length check. A refactored skill is typically 30–60% shorter. If it isn't, re-run step 2 — you kept compensations.
6. A/B test. Run one representative task with the old skill and one with the refactored skill. Compare outputs with the user before declaring victory. Afterward the model can keep the skill current from what it learns in-task, under these same rules: propose the edit, never drop a guardrail silently.