If you keep asking Claude to redo the same step, save that correction in a skill. Give the skill one job, a clear result, and a stopping point. Then compare its output with the work you kept sending back before adding more instructions.
Austin Marchese’s How Matt Pocock ACTUALLY Creates Claude Skills draws a five-step method from Pocock’s videos and skills. Its useful starting point is the correction you repeat. Claude Code’s documentation supplies the file format and controls below; the test procedure is our recommendation.
01Start with a repeated correction
Save a failed request, the result, and the correction you gave. Identify the step that failed. If Claude writes a launch plan before examining what could go wrong, a skill for reviewing launch risks has a clear purpose.
Marchese describes the tendency to rush toward a finished artifact. Give the review its own stopping point: return the risks and unresolved questions, then wait for your decision about the plan. Combining review and execution can let the agent act before you have read the findings.
Choose where the correction belongs:
| Repeated problem | Useful place for the fix |
|---|---|
| A procedure needs the same explanation | A skill with inputs, steps, and a completion check |
| A code rule can be checked automatically | A lint rule or test, as in Turn repeated fixes into rules |
| The output needs an established format | An accepted example, as in Build a skill from an approved example |
Run the task without a new skill first. If the result already meets your criteria, keep the working request. Expertise you can install explains what to package when the procedure needs to be reused.
02Name the method, define the task
An established term can replace a long description of a familiar method. A premortem assumes a proposed project has failed and works backward to possible causes. Marchese includes it among his examples of useful terms.
The term still needs your task’s inputs and output requirements. This original skill applies the method to a supplied launch plan. Save it as .claude/skills/launch-premortem/SKILL.md in your project:
---
name: launch-premortem
description: Review a supplied launch plan for likely causes of failure before implementation.
disable-model-invocation: true
---
Run a premortem on the supplied launch plan. Ask for the plan if it is missing.
For each plausible failure, identify the assumption behind it, an early warning sign, and a practical mitigation. Distinguish evidence in the plan from assumptions that need checking.
Return the risks in priority order and list unresolved decisions. Stop after the review and wait for the user's next instruction.
Short files can still depend on substantial instructions elsewhere. The current grill-me skill in Pocock’s repository tells Claude to call another skill named grilling. Read those dependencies before copying the file. Its length alone does not show how much instruction the complete task uses.
03Choose who starts the skill
Use manual invocation when you want to choose the moment a workflow begins. In the example above, type /launch-premortem and supply the plan. This prevents Claude from choosing that skill during an unrelated conversation.
Anthropic’s invocation controls distinguish two settings:
| Setting | You can invoke it | Claude can invoke it |
|---|---|---|
| Default | Yes | Yes |
disable-model-invocation: true | Yes | No |
user-invocable: false | No | Yes |
These controls are specific to Claude Code. Check the runtime’s documentation before copying them into another agent’s setup.
By default, skill descriptions are available in context so Claude can choose among them; the full instructions load when invoked. With disable-model-invocation: true, the description is omitted too. The skill still uses context when you invoke it. Stop hitting your token limit covers the wider context budget.
Automatic invocation remains useful for a routine you want Claude to select on relevant requests. Test that selection with a matching request and a nearby request that should leave the skill unused. Manual invocation trades that convenience for your choice of when to run it. It does not replace tool permissions or approval rules.
04Check what you still send back
“If you don't have to send back the result, the skill is working.”
Austin Marchese, “How Matt Pocock ACTUALLY Creates Claude Skills” · 10:58Accepting an output is weaker evidence when errors are hard to see. Check the result against its source material or an expected answer before deciding the correction worked.
Our recommendation is to save the failed input and another case that already worked. Run both with the old and revised skill, keeping the model and available tools the same. Check whether the original defect disappeared and whether the successful case still passes. Repeat a close or inconsistent result before keeping the edit.
Marchese’s examples of skill revisions each address a specific complaint, such as conversations dragging or an agent implementing a plan before confirmation. Add the instruction that fixes the observed behavior, then try again. Make skills improve after each run covers locating the cause and checking the repair.
For the premortem, inspect whether each risk follows from the supplied plan, assumptions are labeled, and the agent stops after the review. Score your agent on known good answers covers keeping reusable cases when correctness needs more than your immediate reaction.
05Remove lines that add no value
Test suspected filler by removing one sentence and comparing the same work. Marchese calls instructions that change nothing no-ops. A generic line such as “be thorough” is a candidate to test; a required field or approval rule describes an obligation even if the model has never missed it.
Trim the instructions your model outgrew explains how to distinguish fixed requirements from workarounds you can remove and test. Preserve the old file so you can restore an instruction when a later case needs it.
State the desired action where possible. “Return the risks and wait for the user’s next instruction” gives the review a defined endpoint. Keep an explicit restriction when it expresses a real boundary.
Before adding another skill, check whether existing skills already cover the steps you need. Reusing them in sequence may be enough. Inspect their instructions and dependencies, choose where human review belongs, and review the result before approving its use. That is the practical lesson in Marchese’s warning about blindly copied setups.