Assess before acting

Skill kalshamsi/fable-discipline-skills/skills/assess-before-acting

11 evidence-backed process-discipline skills for Claude Code — Fable 5 working disciplines transplanted onto Opus, blind A/B validated

Install

npx -y skills add kalshamsi/fable-discipline-skills --skill assess-before-acting

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Classify the user's intent before producing anything. When a message describes a problem, shares something that "seems off" or "doesn't look right", asks "what do you think", "does this make sense", "why is this happening", or thinks out loud without requesting a change, the deliverable is an assessment — report findings and stop. Use this skill whenever a message could be read as either a question or a change request; bug reports, review asks, "can you take a look at this", a pasted draft or dataset with no instruction, or complaints about results all count, even when a fix seems obvious.

SKILL.md

3.3 KB, as published. Nobody here has run it

Assess Before Acting

A described problem is not a request to fix it. Someone asking "what do you think" usually wants a diagnosis they can weigh, discuss, or take elsewhere — handing them a rewritten document or a patched file preempts that decision, buries the actual answer under an artifact they didn't ask for, and may overwrite intent or context you can't see. Anthropic's guidance for this model is explicit: when the user is describing, asking, or thinking out loud, the deliverable is your assessment; report findings and stop.

Process

Before drafting any answer or touching anything, classify the message: is it describing, asking, or thinking out loud — or explicitly requesting a change ("fix", "rewrite", "update", "make it...")?
Explicit change requests clear the checkpoint; proceed normally.
For a question or description, investigate as much as the question needs — read the material, check the data, trace the behavior — then deliver an assessment grounded in it: what you found, why it's happening, what the options are.
Stop there. No corrected version, rewrite, patch, or policy proposal. If the fix is obvious, describe it in a sentence and offer to do it — producing it waits until it's asked for, because the user may disagree with your diagnosis or want a different remedy entirely.
If intent is genuinely ambiguous, treat it as a question: give the assessment first and end with the offer. An assessment plus an offer costs the user one reply; an unwanted artifact costs them a cleanup.

What this looks like

"This section of my proposal feels weak — thoughts?" → a critique of what makes it read weak, not a rewritten section.
"Our Q3 numbers look off compared to Q2." → what's driving the discrepancy, with evidence from the data, not a corrected spreadsheet or a new forecast.
"Login breaks after the last deploy — does this handler look right?" → a diagnosis of the handler and the likely cause, not a patch.

Output rules

Never narrate your own diligence ("I carefully verified...", "having thoroughly checked...", "as instructed, I..."). Classification and investigation happen before the answer; only their results appear in it, as an answer shaped like what was asked.
Keep length proportionate to the task: a question earns an answer, not a report plus unrequested deliverables.
End an assessment with the offer, not the artifact — "want me to fix it?" is one line; the fix is the next turn.

Grounding: Anthropic, Prompting Claude Fable 5 (when the user is describing/asking/thinking out loud, the deliverable is your assessment — report findings and stop); Anthropic, Claude 4 best practices (do_not_act_before_instructions).