Service · Automation
Agent Skills & SKILL.md automation
Your best operator has a procedure in their head and a 600-word prompt in a notes app. We turn that into a versioned, tested, shareable Agent Skill — so the whole organisation gets their expertise, and it survives them leaving.
First, plainly
What an Agent Skill actually is
A skill is a folder. Inside it is a file called SKILL.md that tells an AI agent how to do one job properly — and, optionally, supporting reference documents and executable scripts it can use while doing it.
The file opens with a short block of metadata. Two fields matter most:
name— what the skill is called.description— what it does and when to use it. This is the trigger. It's the single highest-leverage sentence in the whole skill.
Below the metadata is the body: the instructions, the constraints, the edge cases, the house style, the things that must never happen.
Because it's a plain text file in a folder, a skill lives in version control like any other asset. It can be reviewed in a pull request, diffed, rolled back, owned by a named person, and shared across an entire company.
--- name: rfp-response description: Drafts a first-pass RFP response using our approved boilerplate, past win library, and pricing rules. Use whenever someone shares an RFP, ITT, or tender document and asks for a draft or a go/no-go recommendation. --- # RFP response ## Before drafting Run scripts/qualify.py against the document. If it returns NO-BID, stop and explain why. ## Drafting - Pull matching sections from references/wins.md - Follow the voice rules in references/tone.md - Leave [[PRICING]] markers — never invent a price ## Hard rules - Never claim a certification not in references/certs.md - Never commit to a date. Flag for a human. - Every claim needs a source in the win library
A real skill is usually 100–300 lines, with two or three reference files beside it.
The mechanism that makes it work
Progressive disclosure — why skills scale where giant prompts don't
If you paste every procedure your company has into one enormous system prompt, three things happen: it gets expensive, it gets slower, and the model starts mixing instructions from unrelated procedures. Skills solve this with layered loading.
Always loaded
Only each skill's name and description sit in context — a line or two per skill. Cheap enough that an agent can carry dozens of skills without meaningful overhead.
Loaded when relevant
When the description matches what's being asked, the agent reads the full SKILL.md. Now it has the whole procedure — and only for the task at hand.
Loaded on demand
Deeper material — reference files, schemas, examples, style guides — is pulled in only if the task actually needs it. A 40-page style guide costs nothing until it's opened.
The practical consequence: the description field decides whether a skill ever fires. Most skills that "don't work" are perfectly good instructions with a vague description. Getting that sentence right — specific about the triggering situation, generalised about phrasing — is a disproportionate share of the craft, and it's where we spend real time.
The part people miss
Skills can carry code — and should
A skill isn't limited to instructions. It can bundle executable scripts the agent runs directly. This matters more than it sounds, because it lets you draw a hard line:
Deterministic work belongs in code. Judgement belongs in the model.
Validating a CSV schema, computing a variance, hitting an internal endpoint, formatting a spreadsheet, checking a value against a lookup table — these should never be "reasoned about". They should be a script that either succeeds or fails loudly.
The result is a workflow where the fragile, must-be-exact steps are as reliable as any other program you run, and the model handles what it's genuinely good at: reading messy input, exercising judgement, and writing well.
It also makes skills auditable. When something goes wrong, you're debugging a script with a stack trace, not interrogating a paragraph of prose.
A typical skill folder
quarterly-close/ ├── SKILL.md # the procedure ├── references/ │ ├── tone.md # house voice │ ├── thresholds.md # what counts as a variance │ └── examples.md # two good past summaries ├── scripts/ │ ├── validate.py # schema + totals check │ └── reconcile.py # prior-quarter diff └── assets/ └── board-template.docx
Everything version-controlled, reviewable in a pull request, and owned by a named person.
Deployment
Where skills run
The same skill folder works across several surfaces. We pick based on who needs it and what it has to reach — and design it to be portable rather than locked to one.
| Surface | How skills get there | Best for |
|---|---|---|
| Coding agents (e.g. Claude Code) |
A .claude/skills/ directory committed to the repository. Engineers get the skill automatically on their next pull. |
Engineering standards, release procedures, review checklists, migration playbooks. |
| Desktop & web AI apps | Uploaded to the workspace so any authorised colleague can use them from the normal chat interface — no terminal, no code. | Non-technical teams: finance, HR, legal, marketing, operations. |
| Your own applications (via API) |
Attached to API requests alongside a code-execution container, so your product can invoke skills programmatically. | Customer-facing features, batch processing, internal tools you already own. |
| Hosted / managed agents | Attached to a persistent, versioned agent configuration, or discovered automatically from a mounted repository. | Long-running and scheduled work: overnight jobs, recurring reports, monitoring. |
Ready-made skills also exist for common document work — PowerPoint, Excel, Word, and PDF generation. Where one of those already does the job, we use it and say so rather than rebuilding it on your budget.
The engagement
What we actually do
Workflow archaeology
We sit with the person who does the job and watch them do it. Not a questionnaire — the real thing, including the undocumented judgement calls, the "oh, except when…" cases, and the checks they do without noticing. This is where the value is, and it never survives a written brief.
Decide what belongs in a skill at all
Not every workflow should be one. Tasks that run once a year, need judgement we can't articulate, or are genuinely faster done by hand get filtered out here. We'd rather ship three skills people use daily than twelve nobody trusts.
Author the skill
Write the SKILL.md, design the disclosure layers (what's in the body versus a reference file), draft the description for reliable triggering, and set the right degree of freedom — prose heuristics where judgement is needed, exact commands where one sequence is the only safe one.
Build the supporting scripts
Everything deterministic gets moved into code: validators, calculators, formatters, API calls. Each with its own tests, so the skill's reliability doesn't depend on the model having a good day.
Test against real cases
We run the skill against a set of your genuine past examples — including the awkward ones — and check two separate things: does it fire when it should (trigger accuracy), and is the output right when it does (quality). These fail for different reasons and need different fixes.
Roll out and hand over
Deploy to the right surface, run a working session with the people who'll use it, and document how to change it. We also write the maintenance guide — because a skill that nobody updates rots as fast as any other documentation.
Beyond the first skill
Building a skill library that doesn't rot
One skill is a project. Thirty skills across five departments is a system — and systems need ownership, standards, and pruning.
Standards & templates
A house format for skills: how descriptions are written, how references are structured, how scripts are tested, what belongs in a skill versus a policy document. New skills start from a template rather than a blank page.
Versioning & review
Skills changed through pull requests with a named owner. Version pinning where reproducibility matters, so updating a skill can't silently change the output of a process someone depends on.
Trigger tuning
Over-firing and under-firing are both real failures. We measure both against real transcripts and adjust descriptions — the fix is almost always in that one sentence, not in adding more rules to the body.
Rot control
Skills accumulate mitigations for problems that no longer exist, hardcoded paths that have moved, and one-off rules written after a single bad session. We run periodic audits that delete, which is the part nobody schedules.
Enablement
Training your team to author their own skills, with review from us at first. The goal is that within a couple of quarters you're producing skills without calling anyone — including us.
Access & safety
Who can publish a skill, which skills touch sensitive data, and where a human approval step is mandatory. Especially important once skills start calling internal systems rather than just writing text.
Concretely
Skills we're commonly asked to build
Illustrative of the shape and scope — every real one is specific to the client's process, terminology, and constraints.
Finance & ops
- Month/quarter close checklist with variance flagging
- Invoice and PO reconciliation against the ledger
- Board and investor update drafting from source data
- Vendor contract review against your standard terms
- Budget variance narrative writing
Sales, marketing & bids
- RFP and tender first-pass drafting with a win library
- Qualification and go/no-go scoring
- Case study writing from project notes and metrics
- Brand-voice enforcement across every channel
- Competitive teardown to a fixed internal format
Engineering & delivery
- Code review against your actual conventions
- Incident write-ups and blameless postmortems
- Release notes generated from merged pull requests
- Migration playbooks for a framework or model change
- Test-plan authoring from a specification
HR & people
- Job description writing to your levelling framework
- Structured interview guides and scorecards
- Policy Q&A that cites the handbook clause
- Onboarding plan generation per role
Legal & compliance
- First-pass contract review flagging deviations
- Policy gap analysis against a named framework
- DSAR and records-request triage
- Clause library search with citations
Customer-facing
- Support ticket triage, tagging, and routing
- Draft replies in your documented tone
- Escalation summaries for account managers
- Churn-risk signal extraction from conversations
What you get
Every skills engagement delivers
- The skill folders themselves —
SKILL.md, references, scripts, assets - Tests for every bundled script
- A trigger + quality evaluation set built from your real cases
- Deployment to your chosen surface, working end to end
- An authoring guide and house template for future skills
- A maintenance and review schedule
- A live handover session with the people who'll use it
All of it in your repository, under your licence, with no runtime dependency on us.
Common questions
How long does one skill take?
A well-scoped first skill is typically 1–3 weeks, most of which is workflow archaeology and testing rather than writing. Subsequent skills in the same organisation are considerably faster because the template, standards, and evaluation approach already exist.
Do we need engineers to use these?
To use them, no — a skill deployed to your workspace is invoked by describing what you need in ordinary language. To author them well you need someone comfortable with structured writing and version control; that's often an ops or knowledge-management person rather than a developer, and we train them.
What stops a skill from doing something dangerous?
Three layers. Explicit prohibitions in the skill body ("draft only, never post"). Approval gates on irreversible actions, so a human confirms before anything is sent, written, or deleted. And permission scoping at the tool level, so the agent simply cannot reach systems it has no business touching. We design all three in rather than bolting them on.
Isn't this just prompt engineering with extra steps?
The difference is that a prompt is a message and a skill is an asset. Skills are versioned, reviewed, tested, owned, discoverable by the agent itself, capable of carrying executable code, and loaded only when relevant. Those properties are exactly what turns one person's good prompt into organisational capability.
Are we locked into one AI vendor?
The format originates with Anthropic's Claude, and that's where support is deepest today. But the substance — the procedure, the reference material, the scripts — is plain Markdown and ordinary code. It's the most portable form your operational knowledge could be in; certainly more portable than living in someone's head.
Which workflow would you clone first?
Bring the process only one or two people can do properly. Thirty minutes, and you'll leave knowing whether it's a good candidate — and roughly what it would take.