Start With Repetition, Not Inspiration
The best reason to create a skill is not that you had a clever prompt. It is that you have typed some version of the same request three or more times and the task has a recognizable shape. A coding agent such as Codex or Claude Code can read files, edit files, run terminal commands, and call tools. A skill tells that agent how to do one repeatable job with less improvisation each time.
Begin by auditing recent agent sessions or your own memory. Look for tasks like “review this PR for missing tests,” “turn this meeting note into an implementation plan,” “run the release checklist,” or “summarize these logs and suggest the next command.” Good candidates repeat often, use available files or commands, and have an output you can describe. Poor candidates depend mostly on taste, judgment, or one-off context. For those, keep using the agent as an assistant instead of pretending the work is ready for automation.
Write the Skill as a Small Contract
Once you find a repeat task, turn it into a folder or document the agent can read before acting. The point is to shrink ambiguity. A useful skill needs a trigger description, inputs, steps, tools, expected output, and gotchas. The trigger says when the skill should be used and for whom. Inputs say what the agent must know before starting. Steps describe the workflow. Tools list commands, scripts, APIs, or MCP servers the agent may call. MCP means Model Context Protocol, a standard way for an agent to connect to external systems such as GitHub, databases, docs, or issue trackers.
Keep deterministic work out of prose when you can. If a calculation, formatting pass, API request, or validation can be done by a script, put the script in the skill folder and tell the agent when to run it. Scripts save context, reduce mistakes, and make the result easier to reproduce. Leave judgment to the language model, but give exact commands to the machine parts.
A simple first skill can be plain markdown: “Inputs: branch name, target file, acceptance criteria. Steps: inspect diff, identify risky changes, run tests, report findings first. Output: concise review with file references. Gotchas: do not rewrite unrelated code, do not mark subjective style as a defect.” That is enough to turn a fuzzy request into a reusable procedure.
Add Verification Before Automation
A skill is not good because it runs. It is good because you can tell whether it worked. Before you schedule anything or build a button for it, define the result. For code work, that might be passing tests, a clean typecheck, or a reviewer skill that returns pass or fail against a checklist. For writing work, it might be required sections, word count, banned phrases, or consistency with a style guide. Verification matters because agents are persuasive even when they are wrong.
This is where sub-agents help. A sub-agent is a separate agent instance given a focused assignment, often with its own context. Context is the working memory the agent sees: your instructions, files it has read, tool results, and conversation history. If one agent writes a migration plan, another can review it without being anchored by the same reasoning path. Use sub-agents for independent checks, parallel research, or separate perspectives, not for tightly coupled steps that need constant handoff.
For new skills, use a training mode. Make the agent pause after each major step and show what it found, what it plans to do, and what would count as done. After a few successful runs, remove pauses from the boring parts and keep human approval around high-risk zones such as payments, security, production data, or irreversible file operations.
Capture Memory and Gotchas
The first version of a skill will miss cases. That is normal. The mistake is to fix the prompt in the chat and then lose the lesson. Add a gotchas section and update it after every failure: inputs that confused the agent, commands that behaved differently on your machine, output formats stakeholders rejected, or edge cases the verifier missed. This turns each run into training data for the next run.
For larger workflows, give the agent a small filesystem map. A lightweight vault can have folders for raw inputs, structured notes, outputs, and skill docs. Add index files so the agent knows where to look first, and a top-level instruction file that explains naming conventions and lookup paths. This is not about building an elaborate knowledge base. It is about giving the agent stable navigation so it does not waste context rediscovering the same files.
Memory should be boring and inspectable. Markdown logs are often enough: date, input, commands run, output path, result, and what changed in the skill. When the agent starts a repeat task, have it read the relevant log before acting. That prevents circular work and helps it compare the current run against prior attempts.
Promote Skills Only When They Earn It
A skill can later become a routine: something triggered by a schedule, event, button, or command. Keep those concepts separate. The skill contains the instructions. The routine decides when to run them, what tools are available, and where the output goes. This separation lets you improve the workflow without rewriting the scheduler.
Promote slowly. If a skill still needs your taste, keep it as an assisted workflow. If it has clear inputs, stable tools, repeatable steps, and objective checks, it can become a loop that runs until it reaches a definition of done. A loop needs a trigger, execution skill, verification step, and memory. Without all four, you get an agent repeating work, burning context, or producing outputs no one trusts.
The central move is simple: stop treating every successful chat as disposable. When a task repeats, write down how the agent should recognize it, what it needs, what it should do, how it proves it is done, and what went wrong last time. That turns prompting into process, and process is what lets agents become useful beyond a single conversation.
Key takeaways
- Create a skill when a task repeats, has clear inputs, and produces an output you can judge.
- A useful skill includes a trigger, inputs, steps, tools, expected output, and gotchas.
- Use scripts for deterministic work and let the language model handle judgment-heavy parts.
- Verify skills before automating them; passing tests, checklists, or reviewer sub-agents make results safer.
- Log runs and failures in markdown so the skill improves instead of repeating the same mistakes.
- Promote a skill into a scheduled routine only after the manual version is reliable.