assess-before-acting
Skill0 starsChanged 4 months agoMITView on GitHub
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.
In this repository10 other files it gives its agents.
- answer-first-structureSkill
- assumption-auditSkill
- calibrated-claimsSkill
- finish-the-turnSkill
- grounded-reportingSkill
- plan-before-executingSkill
- root-cause-before-fixingSkill
- rubric-self-checkSkill
- scope-disciplineSkill
- verify-before-answeringSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Before drafting any answer or touching anything, classify the message: is it describing, asking, or thinking out loud — or explicitly …
- Distinctive: line 26
Stop there. No corrected version, rewrite, patch, or policy proposal.
- Distinctive: line 27
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 …
- Distinctive: line 30
If intent is genuinely ambiguous, treat it as a question: give the assessment first and end with the offer.
- Distinctive: line 45
Never narrate your own diligence ("I carefully verified...", "having thoroughly checked...", "as instructed, I...").
- Distinctive: line 49
Keep length proportionate to the task: a question earns an answer, not a report plus unrequested deliverables.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

