Many apps are only as good as the data people keep feeding them. Features can be solid and the UI polished — and the product still feels stale when the live data behind those screens stops getting updated. The hard part is rarely “add it once.” It is keeping it current every week: find what is new, skip what you already have, decide what is safe to ship, and apply changes without breaking production.
That work is repetitive, easy to get slightly wrong, and expensive to re-explain in chat. That is what an agent skill is for in this shape: a versioned playbook next to the repo that teaches an AI agent how your team actually runs the job — not only which script to run. I put this into practice for HornsApp and Muvin: a weekly skill that prepares a safe pack for review, then hands it to a human for the production write.
A concrete scenario
Imagine a small team whose app depends on live data behind the screens. Every week that data has to stay current. Each run you need to:
- discover what is new in a defined window
- skip what is already done
- decide what is solid enough to ship vs what still needs a human
- verify outputs that will hit real clients — not “looks fine in a browser”
- apply only this run’s changes — without rewriting production by accident
None of that is hard once. It is hard repeatedly. Without a shared playbook, each run invents slightly different rules: different windows, soft duplicates, weak checks, and silent bad results that only show up later.
What you are trying to protect
Three goals show up again and again when you turn a recurring job into a skill:
1. Same output, easy to invoke. Whoever runs the skill should get the same gates and a comparable result. Calling the playbook should be boring and reliable — not a fresh improvisation each time.
2. A playbook you can improve. Rules in one place are easier to track, debug after a bad run, and refactor. Improvement is an edit to the playbook — not a new tribal version in someone’s head.
3. One standard that gets smarter for everyone. Runs will still fail. Fix the skill once, and every later run — and every teammate — benefits. Without that, each person rediscovers the same issue alone.
If your team is living through “we know how to do this, we just keep rediscovering it in chat,” you are already in this use case.
Why a script alone is not enough
Scripts are great for deterministic steps: validate shape, convert formats, clear stale output. Recurring ops also need judgment: is this a duplicate? Is it solid enough to ship? Should the agent stop and ask instead of guessing?
An agent can help with that judgment — but only if the rules live somewhere durable. Chat memory is not a process. A project skill sits with the code: triggered on purpose, readable in review, updated when the product rules change.
How to split the system
A clear way to draw the boundaries:
┌───────────────────────────────────────────┐ │ Shared context │ │ What already exists / last known state │ ├───────────────────────────────────────────┤ │ Agent skill (ops playbook) │ │ Judgment · gates · when to stop │ ├───────────────────────────────────────────┤ │ Prepared output (this run only) │ │ Safe pack for human review │ ├───────────────────────────────────────────┤ │ Human write boundary │ │ Approve → production · improve skill │ └───────────────────────────────────────────┘
Read it top to bottom as four moves: shared context, judgment, prepared hand-off, human write + improve. The agent prepares; a person still commits the live change when that is the safer boundary.
Encode judgment, not only steps
A checklist of steps is useful — “scan, write files, hand off.” What usually breaks in production is the judgment between those steps: what counts as a duplicate, when something is ready vs still fuzzy, what “good enough” means for the live data behind the screens, and when the agent should stop and ask a human instead of guessing.
That judgment is the content worth putting in a skill. Not only the sequence of actions, but the decision rules:
- What “done” means for this run — and what must stay out until it is solid.
- How to compare a new candidate against what you already have (so you do not rely on “looks familiar”).
- What to reject or park even if a source looks exciting.
- What to verify before treating an output as safe for clients or production.
- Where the human boundary is — prepare vs approve vs write to the live system.
Steps tell the agent what to do next. Judgment tells it how to choose. That is the difference between “ask the AI to handle this” and “run our process the way we defined it.”
What stays human
Automation should shrink the boring surface area, not remove ownership. In this design the human still:
- decides when something is too ambiguous for the skill to finish alone
- owns the irreversible step — promoting prepared output into production
- reviews a bad run and updates the skill so the next one is better
- changes the playbook when product judgment itself changes
The skill makes those decisions rarer and clearer. It does not pretend the process can never be wrong.
Checklist you can take to your team
- Name the recurring job. If you do it every week, it deserves a skill — not another chat thread.
- Start from shared context. The skill should know what “already done” looks like before it invents work.
- Encode judgment, not only steps. Decide what is ready, what waits, and what must not be guessed.
- Hand off prepared output. Prefer a safe pack for this run; do not make “replace everything” the happy path.
- Keep a human write boundary when production data is hard to undo — then improve the skill after a miss.
What you gain (and what you trade)
You pay a bit of upfront writing: the skill has to capture real judgment, not slogans. You gain a process that is easy to invoke, reviewable in the repo, and improvable after each miss — less time rediscovering the same mistakes in chat, more time on the work that actually needs a human.
In HornsApp and Muvin, that meant turning the weekly job of keeping live data behind the screens current into a contract next to the code: same gates every run, clearer hand-offs, and a playbook that gets sharper when something goes wrong.
In practice that looked like four moves:
- Start from shared context — what already exists before inventing work.
- Encode judgment in the skill — what is ready to ship, what should wait, and what must not be guessed.
- Hand off prepared output — humans review and import; they should not rediscover the process.
- Improve the skill after a miss — one standard gets better for every later run.
Start with one painful recurring job. Write the judgment you already know. Put the skill next to the repo. Improve it the next time a run teaches you something.
I build native iOS and Android apps and write about designs that survive real shipping. If keeping live data current — or encoding that job as an agent skill — is a problem your team is facing, let's connect on LinkedIn.