SKILL.md file into your workspace describing a convention — how sign-in works, what your domain terms mean, how your team writes flows — and the agent reads it whenever it takes on work that convention covers.
Skills are additive. The agent keeps doing what it normally does and applies your conventions on top, preferring yours wherever they differ from its defaults. The payoff is tests that match how your app actually behaves — the right sign-in path, the right terms for the right elements, your team’s conventions — without anyone re-explaining it each time.
These are skills stored in your QA Wolf workspace, for QA Wolf’s own agent. To connect an external coding agent like Claude Code or Codex, see the QA Wolf MCP guide.
Write a skill
A skill is a Markdown file with frontmatter that names and describes it, and a body holding the knowledge.name and a description. Both are required, and each name should be unique — two skills sharing a name leaves only one of them active.
Describe when your skill applies
A skill only improves a test if the agent has it in hand at the moment it’s writing that test. Thedescription is what decides that — the agent matches the task against it to choose which skills to read. Four moves make one specific enough to land:
1
Say what the skill covers
Open with the subject in plain terms — “How to sign in to Acme,” “Knowledge base for our billing API,” “Checklist for reviewing a checkout flow.”
2
Name the specifics
List the actual topics inside, using the words your team uses. “SSO-only login, seeded test users, and the difference between quotes, members, and subscribers” gives the agent far more to match against than “domain terms.”
3
Say when to read it
Name the work it should shape: “Read this before creating or editing any Acme flow.” Include the symptoms, too — an error message like
invalid credentials or mail is not defined is often how the agent first meets the problem your skill solves.4
Say when not to, if something's nearby
When another skill covers adjacent ground, draw the line: “Not for billing flows, which have their own skill.” This keeps each skill from being pulled into work it doesn’t cover.
A long description is fine. It’s an index entry the agent scans, not prose anyone reads start to finish.
What belongs in the body
Anything you would otherwise repeat across many prompts:- Domain vocabulary and what each term maps to in the UI
- Environment quirks, such as which login method works and which test users are seeded
- Team conventions, such as structuring flow headers around AAA
- Links to deeper documentation the agent should fetch when it becomes relevant
Where skills live
ASKILL.md file works anywhere in your workspace. Giving each one its own folder keeps them easy to find:
FAQ
The agent isn’t following a convention I documented.
The agent names the skill it read as it works, so check whether yours came up. If it didn’t, revise the description: name the work it should shape and the specific terms your team uses. Selection happens on the description alone, so that’s where it’s decided.My skill isn’t showing up at all.
Check the frontmatter. A file missingname or description, or with malformed frontmatter, is skipped silently rather than reported. Also confirm no other skill shares the same name.