1. Find Fable-worthy work

<aside>

Act as my triage partner for deciding what deserves a Claude Fable 5 run. Nothing gets executed in this session — your only output is an assessment of my work landscape and polished, hand-off-ready briefs for the strongest candidates.

About me and what I'm optimizing for:

[Describe your role, priorities, team, business goals, creative goals, or personal operating constraints.]

Where you're allowed to look:

[List the sources you can inspect: repositories, project folders, docs, Notion, Slack, Linear/Jira, email, calendar, analytics, customer research, previous agent sessions, task lists, or anything else relevant.]

Hard limits:

[List deadlines, privacy boundaries, accounts or tools you may not use, budget, sensitive areas, approval rules, and work that must remain human.]

Step one — survey, don't invent. Go through the actual context above. I don't want hypothetical or generic suggestions; everything you propose must trace back to something you found.

Catalogue what you see across these categories:

  1. Projects currently in motion.
  2. Workflows I run over and over.
  3. Decisions that have been sitting unmade.
  4. Backlogs that have gotten disorganized.
  5. Work scattered across multiple tools or sources.
  6. Anything where stronger planning, judgment, verification, or follow-through would meaningfully change the outcome.

Step two — pick and score the contenders. Rate every candidate 1–5 on each of:

  1. How much multi-source context it demands.
  2. How cleanly it can be handed off.
  3. How much real judgment it requires.
  4. Whether "done" is unambiguous.
  5. How much leverage a good result creates.
  6. Overall suitability for Fable.

Be selective: Fable is slower and costlier, so only recommend it where the scale of the task earns that trade. Penalize anything that's quick, trivially obvious, dependent on constant back-and-forth, difficult to verify, or a better match for a faster Claude model or a person.

Step three — deliver:

  1. A ranked top 10 of Fable-worthy use cases.
  2. The specific evidence behind each pick.
  3. A justification for why Fable in particular is (or isn't) the right engine for each.
  4. What the finished output would look like.
  5. How the result would be verified.
  6. The context, tools, and access each task would need.
  7. Risks, open blockers, and any calls a human must make.
  8. Complete, ready-to-launch Fable Briefs for the top three.

Each of the three briefs must spell out:

Then stop. Present the ranking and the three briefs and wait — no Fable task begins until I've picked one.

</aside>

2. Clone any software (Stop paying for subscriptions)

Fable is smart enough to rebuild software you pay a subscription for, as a free version that runs on your own laptop. Take WhisperFlow, the AI voice dictation tool (it turns your speech into text). Here's the play:

Step 1. Research it. Run the /deep-research

Found in my skills here: https://drive.google.com/drive/folders/1FpnhNV9rX83rs4NIfm7Exr6G2n4tZcv5?usp=drive_link

/deep-research I want a plan to clone [the software you want to copy, e.g.
WhisperFlow]. Do some deep research on how it works and what we'd need to
recreate its core features on our own computer. I want to run it locally, as a
local model on Ollama, that basically does what [the software] does.

Step 2. Turn the research into a build prompt. Deep research hands you back a research.md file. Drop that file into Opus and say:

[Attach the research.md file the deep research produced.]

Build me a /goal prompt to make this software.

Step 3. Build it. Take the /goal prompt Opus writes back, paste it into Fable, and send it off. Fable builds the whole thing, start to finish.

This works for almost any tool: a Calendly-style booking page, a Loom-style screen recorder, a meeting-notes transcriber, whatever you're sick of paying for. Ask Fable first whether it can build what you've got in mind, then let it go. It's one of the fastest ways to start cutting subscriptions you don't really need.

3. Audit your Entire Claude setup

<aside>

Complete Setup Audit — my whole Claude Code configuration: all instruction files, all skills

Your job is to put my entire Claude Code configuration under the microscope. What I want at the end: a leaner, tighter system — every rule earning its place, skills that fire when they should and haven't decayed, no rules fighting each other, no references pointing at things that are gone. Don't spare my feelings about anything I've written — but don't condemn anything without proof either: inspect the real filesystem instead of taking a file's word for what's true.

Every finding should be explained in ordinary language — describe what the problem is before prescribing the fix.

Proceed phase by phase. Phases 1–2 touch nothing — no edits, no deletions, no pushes until I've signed off on the report. Hand the heavy reading to subagents so your main context stays free for analysis and synthesis — the volume may be large.

(Optional — if any of my config or skills sit in non-standard spots, add them here: ___________)

Phase 1 — Map and ingest the whole setup

Build the map empirically — look, don't assume. Cover every standard Claude Code location:

Instruction files:

Skills — every possible home (absence from this session's skill list does NOT mean a skill doesn't exist):

Price out the context tax as well: estimate the token count of everything that loads unconditionally at session start (global CLAUDE.md + project CLAUDE.md + all their imports + the memory index). That figure is the backdrop for the entire audit — each of those lines is a cost incurred on every session, indefinitely.

Phase 2a — Audit the instructions

Walk through every single rule, directive, preference, and standing assertion in all the instruction files above — nested CLAUDE.mds, imported files, and memory files included. Interrogate each one:

  1. Already default? Would you behave this way anyway, unprompted? Rules authored for weaker past models are top deletion candidates.
  2. In conflict? Does anything elsewhere in the setup contradict it? Identify both parties, state which one wins today, and explain why.
  3. Duplicated? Does the same rule appear in two or more locations? Copies inevitably drift — choose ONE canonical home.
  4. Scar tissue? Does it smell like a patch for one bad output rather than a general improvement? (Single-incident rules that got over-generalized.)
  5. Fuzzy? Could you read it two different ways on two different days? ("be more natural", "use a good tone" — anything lacking a testable standard.)
  6. Rotten? Does it name a path, file, tool, ID, URL, account, or workflow that's since moved or vanished? Verify the references for real — confirm paths resolve, scripts exist, tools are still reachable. No guessing.
  7. Misplaced? Would it serve better elsewhere — inside a particular skill, at project level instead of global (or the reverse), as a settings.json hook (anything that must run without fail belongs in a hook, since hooks are enforced and prose isn't), or as a memory file — rather than taxing every session's context?

Assign each item a verdict: KEEP / TIGHTEN (sharpen the wording) / MOVE (to a named destination) / MERGE (with a named counterpart) / CUT — plus one line of justification.

Phase 2b — Audit the skills

For each skill that belongs to me (personal and project-scoped — plugin cache excluded), read the complete SKILL.md along with any references/ and scripts/ directories, and evaluate:

  1. Trigger precision. Examine the frontmatter description — will it activate exactly when it should and never otherwise? Does it honestly describe what the body does?
  2. Trigger overlap. Chart the skills whose activation surfaces collide — mine AND any plugin skills competing for the same territory (e.g. multiple writing or research skills that could all grab one request). Per cluster: who should take priority, and should any be merged or made to defer?
  3. Redundancy. Does it replicate another skill, or replicate behavior you'd now produce well with no instructions whatsoever?
  4. Freshness. Test every hard reference it contains — paths, database/page IDs, URLs, tool and MCP names, accounts, model names. Report everything dead or renamed. This is the fastest-rotting part of any skill.
  5. Determinism. Are the steps specific enough that two separate runs would do the same thing? Is there a success criterion ("it worked if…") and a fallback ("if X breaks, do Y")? Call out anything hand-wavy.
  6. Weight and layout. Is the SKILL.md itself slim, with bulky reference content pushed into references/ files that only load on demand? Frontmatter valid? Scripts present and actually executable?
  7. Security. Zero credentials, keys, or tokens anywhere in skill files. If skills sit in a repo other people can see, confirm nothing private leaked into it. Flag any third-party skills installed sight-unseen — skills execute with full agent permissions, so recommend a review or scan before they keep running.
  8. Sync state. For any skills folder under git: run git status and check against the remote — surface anything uncommitted, unpushed, or diverged. If nothing is git-backed at all, record that as a finding in itself (no backup, no history).
  9. Dead weight. Skills that appear superseded, orphaned, or bound to workflows that no longer exist — mark them as retirement candidates and say whether to archive or delete.
  10. Self-improvement loop. Record whether each skill already closes with a ## Self-Improvement Loop section (relevant to Phase 4).

Every skill gets a verdict: KEEP / FIX (enumerate the fixes) / MERGE (into which one) / RETIRE — one-line rationale apiece.

Phase 2c — Deliver the report (then HALT)

</aside>