Prompts work once
I wrote hundreds of prompts for Planark.
Most of them worked the first time. Some worked twice. None of them worked reliably after that.
The problem was not the model. The problem was that I was treating every task like a new conversation. "Audit the trip builder flow." "Check if the region cards feel too heavy." "Review this screen for spacing consistency."
Each prompt worked in isolation. But the judgment behind them never stuck.
When I came back to the same task a week later, the agent had no memory of what mattered. I had to re-explain the standards, the context, the examples of what worked and what didn't. The prompt got longer. The output got more generic. I was spending more time explaining than building.
That is when I learned the difference between a prompt and a skill.
What A Skill Actually Is
A skill is a playbook.
It teaches an agent how to do a specific type of work. Not just once, but every time. It includes the objective, the inputs required, the process to follow, the outputs expected, and the criteria for done.
The format looks like this:
Objective: What this skill does
Inputs: What the agent needs before starting
Process: Step-by-step approach
Outputs: What the agent produces
Done criteria: How to know the work is completeThe structure is deliberate. An agent can read it, follow it, and produce consistent results without being told what to do every single time.
This is not a template you fill in once. It is a reference the agent reads before every task that matches the skill.
Skill vs Prompt vs Workflow vs Agent
These four terms get mixed up. Here is what each one means:
Prompt: A one-off instruction. "Audit this screen for accessibility."
Skill: A reusable playbook. The audit skill that works across screens, projects, and weeks.
Workflow: A human-led sequence. The designer decides what happens next.
Agent: The AI that reads the skill and does the work.
A prompt happens once. A skill happens repeatedly. A workflow is the sequence of skills. The agent is the thing that reads them.
You write prompts for specific moments. You write skills for repeated tasks.
What Belongs In A Skill
A good skill includes judgment, not just steps.
Here is what I put in the Planark audit skill:
Design judgment rules
Regional discovery should feel calm, not busy. Trip cards need hierarchy: destination, dates, context. Private invites should not look like public stories.
Source requirements
Read the product book first. Check the actual screen against design memory. Compare to the live app if changes were shipped.
Quality gates
Did the agent catch spacing drift? Did it flag missing context? Did it suggest fixes grounded in product goals?
Examples and anti-patterns
Good: "Region card density is too high for calm discovery"
Bad: "Consider reducing visual complexity"
The rules make the difference. Without them, an audit becomes a generic list of suggestions. With them, the agent knows what matters for this product.
Planark Example: The Audit Skill
I built the first version of the audit skill after catching the same design drift three times.
The trip builder was getting heavier with each iteration. More fields. More options. More visual weight. The agent was following my instructions, but it was not catching the pattern.
I wrote the audit skill to teach it what "too heavy" means for Planark.
The skill said:
- A trip card needs three pieces of information: destination, dates, itinerary state
- Anything else is optional context, not primary data
- If the card needs scrolling, it is too heavy
- Compare the card to the current design memory file
The next time I asked the agent to audit a screen, it flagged the extra fields before I saw them. It cited the audit skill. It referenced the design memory file. It suggested removing two fields instead of adding visual hierarchy.
That is when I knew the skill worked.
It saved the judgment. I did not need to re-explain what mattered every time.
Your First Skill Template
Start with this skeleton:
# [Skill Name]
## Objective
What this skill does in one sentence.
## Inputs Required
- Context file (DESIGN.md, product docs, etc.)
- Source material (screen, flow, prototype)
- Standards (what is the quality bar?)
## Process
1. Read the context
2. Analyze against standards
3. Flag issues
4. Suggest fixes grounded in product goals
5. Cite sources
## Outputs
- List of findings
- Suggested changes
- Next steps
## Done Criteria
- [ ] All required inputs were used
- [ ] Findings cite specific examples
- [ ] Suggestions are actionable
- [ ] Agent checked its work against standards1. Fill in the objective first. That forces clarity. If you cannot explain what the skill does in one sentence, the skill is not clear enough yet.
2. Then fill in the inputs. What does the agent need to read before starting? This is where context files, design memory, and product docs belong.
3. The process comes next. Write it like you are teaching someone how you think through this type of work. Not just the steps, but the judgment calls.
4. The done criteria is the gate. If the agent cannot check all the boxes, the work is not done.
This Leads To Skill Chains
A skill handles one type of work.
A skill chain connects several skills into a sequence where each output becomes context for the next step.
Research skill produces findings. Brief skill turns findings into requirements. Prototype skill builds from requirements. Review skill validates against the brief. Each step preserves intent.
That is the next chapter.
What you learned: Skills are reusable playbooks written for agents to follow. They include judgment rules, source requirements, quality gates, and examples. They work repeatedly where prompts drift. Planark proved that design memory saved in skills catches problems before they ship. The skill format makes your judgment portable.