Claude Skills for Analysts: Turning Repeatable Analysis Into Tooling

A Claude Skill is a folder holding a SKILL.md instruction file plus the references and scripts it needs, which the model loads only when a task matches its description. For an analyst it is the way to stop retyping the same careful prompt: the method you use to write pacs.008 test cases becomes a file, version controlled, reviewed, and identical for everyone who runs it.

Most analysts using a language model are stuck at the prompt stage. You work out, over several attempts, a genuinely good instruction for turning a message specification into a test suite. It works. Then the conversation ends, and next month you rebuild it from memory, slightly worse, and your colleague builds their own version, differently. The capability existed and was never captured, which is the same retention failure that a second brain solves for knowledge, applied to method.

A skill is the capture step for method. It also solves the harder problem: a general model knows what ISO 20022 is in the abstract and knows nothing about your scheme’s usage guideline, your truncation rules, or the fact that your upstream system sends a name field padded to 35 characters. A skill can carry those references with it.

The wider landscape of putting AI into delivery work, MCP, retrieval, and agents, is covered in AI at Work.

What exactly is a skill?

A skill is a directory. At minimum it contains one file.

iso20022-test-cases/
├── SKILL.md                    the instructions and the method
├── references/
│   ├── pacs008-usage-guide.md  our scheme's field rules, extracted
│   └── reason-codes.md         the codes we actually return
└── templates/
    └── test-case-format.md     the house output format

SKILL.md starts with YAML frontmatter carrying a name and a description of when the skill applies. That description is the only part the model reads up front. When a task looks like a match, the full body loads, and the body can point at the reference files, which load only when needed. The effect is that you can bundle a great deal of material without spending the model’s attention on it until the moment it is relevant.

That mechanism, a short description deciding whether a longer instruction loads, is worth understanding because it determines whether your skill ever fires. A description that says “helps with testing” competes with everything. A description that says “generates ISO 20022 payment message test cases, including negative cases and expected reason codes, for pacs, pain, and camt messages” fires precisely when it should.

What does a real analyst skill look like?

Here is the core of a skill that generates test cases for a payment message type, the task most payments analysts do repeatedly.

---
name: iso20022-test-cases
description: Generates test cases for ISO 20022 payment messages (pacs.008,
  pacs.002, pacs.004, camt.056) to the house format, including negative cases
  with expected reason codes. Use when asked to write, review, or extend test
  cases for a payment message type or a message field.
---

# ISO 20022 test case generation

## Method

1. Identify the message type and the scheme. If the scheme is not stated,
   ask, and do not assume. Field rules differ per scheme.
2. Read `references/pacs008-usage-guide.md` for the field rules that apply.
   This file is authoritative. Where it disagrees with general knowledge of
   the standard, it wins.
3. Produce test cases in four groups, in this order:
   - Structural validity: mandatory fields, cardinality, data types.
   - Business rules: amount limits, currency and country constraints,
     the debtor and creditor agent combinations the scheme allows.
   - Negative cases: one per rejection rule, each asserting the exact
     reason code from `references/reason-codes.md`.
   - Lifecycle: the status progression the payment should follow.
4. Format every case using `templates/test-case-format.md`.

## Rules

- Every test case that asserts a field rule cites the section of the usage
  guide it came from, as `[UG 4.2.1]`. A case you cannot cite is marked
  `UNVERIFIED` and listed at the end under "Needs analyst confirmation".
- Never invent a reason code. Use only codes present in the reference file.
- Use synthetic identifiers only. Test IBANs from the reserved ranges,
  never a real IBAN, name, or account number, even if one appears in the
  conversation.
- Negative cases outnumber happy path cases. If the output has fewer than
  two negative cases per business rule, it is incomplete.

## Output

A Markdown table per group, then the "Needs analyst confirmation" list.
Do not summarise the test cases in prose afterwards.

Four things in that file are doing the real work, and they are the same four in every good analyst skill.

The description is specific about trigger conditions. It names message types, which means the skill fires on “write test cases for camt.056” and stays quiet on a general question about testing.

The references are declared authoritative. The instruction that the bundled usage guide beats general knowledge is the single most useful line in the file, because the failure mode of a model on a standards question is confident recall of the generic standard rather than your scheme’s constraints on it.

Citation is mandatory and uncertainty is surfaced. The UNVERIFIED list is what makes the output reviewable in ten minutes instead of an hour. You are not checking sixty test cases; you are checking the four the skill could not source.

The safety rule is in the file, not in your memory. Synthetic identifiers only, stated as a rule the skill carries, so it applies whoever runs it.

Feed that skill a message specification and you get the same structure as hand-written pacs.008 test cases in a fraction of the time, with the judgement calls flagged for you rather than buried.

Which skills should an analyst build first?

The test is simple: you have done the task at least five times, and you could write the method down. That rules out genuine analysis and rules in most of the surrounding work.

Skill	What it does	Bundled references
Test case generator	Message or endpoint to a full suite	Usage guide extract, reason codes, house format
Requirement to spec skeleton	A business requirement to a structured functional spec draft	Spec template, house definition of done
Reason code mapper	Technical rejection to customer-facing message and ops action	Reason code list, tone of voice rules, ops playbook
Spec reviewer	Checks a draft against the house checklist and returns findings	Review checklist, examples of good and bad acceptance criteria
Meeting notes to decisions	Raw notes into decisions, actions, and open questions	Decision record format

The reviewer is the one analysts underrate. Turning your specification review checklist into a skill means every draft gets the same pass before a human reads it, which raises the floor across a team, and it is a use of a model that plays to its strengths: checking a document against explicit criteria rather than inventing content.

The mapper is the one that pays off fastest in payments, because mapping reason codes to customer messages is high volume, rule-based, and currently done by an analyst with a spreadsheet.

How do you keep a skill honest?

Treat skill output as a draft from a fast junior colleague who has read a lot and has never worked here. That framing produces the right controls.

Write the acceptance criteria before the skill. What does a good test suite from this skill look like? Every business rule has at least one negative case, every rule cites a source, no invented reason codes, correct house format. Those criteria are the skill’s specification, and they belong in the file. This is the same discipline as acceptance criteria for AI systems, applied to a tool you own.

Keep a golden set. Take three message types you have already covered by hand, and keep your known-good output. When you change the skill, run those three and compare. Without this you are editing instructions and hoping, which is how skills quietly get worse: someone adds a clarifying line, the output shifts, and nobody notices for a month.

Instrument the uncertainty. The UNVERIFIED list is not decoration, it is the review queue. A skill that never flags anything is not being careful, it is hiding its guesses.

Review the output the way you review a junior’s work. Spot check the cited rules against the actual usage guideline, and check the cases you did not expect. Anything asserting a scheme rule gets verified before it reaches a test plan, because the cost of a wrong reason code in a test suite is a defect raised against correct behaviour, and those burn a week of a developer’s goodwill.

The honest failure mode here is worth naming. I have seen a model produce a beautifully formatted suite of forty test cases for a payment message where three referenced a field that does not exist in that message version. The output was not wrong-looking; it was wrong. Everything above exists to make those three findable in minutes.

Where do credentials and production data fit?

They do not. This is the shortest section and the one with the least room for judgement.

Credentials never go into a prompt, a skill file, or any file a skill can read. A skill that calls the Jira API describes how to obtain the token from the environment; it does not carry a token. The mechanics of doing that properly are in API keys, PATs, and OAuth tokens, and the reason is that skill folders get committed, shared, and copied between machines exactly like the collections and vaults that leak credentials today.

Production payloads and customer data stay out. Pasting a real failed payment into a chat to ask what is wrong with it is the most common breach an analyst commits, and it is usually well intentioned during an incident. The structure is what the model needs, so mask the identifiers: a real IBAN teaches it nothing that NL91ABNA0417164300 does not. Where your organisation’s policy allows nothing at all to leave, that decision is made above you and the answer is a locally hosted model or no model.

Check what your deployment actually does with the data before you build the workflow, not after. Whether prompts leave your network, whether they are retained, and whether they train a model are three separate questions with three separate answers depending on the tier and contract.

How does this connect to the rest of the toolchain?

A skill on its own drafts text. A skill next to tools does work. When the assistant can also read your Obsidian vault, call the Jira API, and run your Bruno collection, the loop closes: generate the test cases from the message spec, write them into the vault, push them to Jira as test issues linked to the requirement, and execute the API suite that proves them.

That connection is what the Model Context Protocol standardises, giving a model a defined way to reach a tool rather than a screenshot of one. The analyst point is not the protocol, it is what becomes possible: the manual glue between tools, which is where most of an analyst’s day goes, is the part that automates.

Two guardrails hold as the loop closes. Reads are cheap and writes are not, so let automation read broadly and write narrowly, with a human approving anything that changes a ticket, a page, or a test plan. And keep the traceability intact: a generated test case still links to the requirement it verifies, or you have automated your way into an untraceable test suite, which is worse than a slow one.

The takeaway

A Claude Skill is a folder with a SKILL.md instruction file, loaded on demand when its description matches the task, that turns a prompt you keep retyping into versioned tooling your team shares. Build one for the work you have already done five times, usually test case generation, requirement-to-spec drafting, reason code mapping, or specification review.

The value is in what you bundle: your scheme’s usage guideline extract and your own reason code notes are knowledge the model does not have. Declare those references authoritative, require a citation for every rule applied, and make the skill list what it could not verify, so review is targeted. Write the acceptance criteria before the skill, keep a golden set to catch regressions, and keep credentials and production payloads out of every file the model can reach. Used that way a skill raises the floor for a whole team; used as an oracle it produces confident, well-formatted, wrong test cases.

Start with AI at Work: MCP, RAG, and AI Agents for the AI foundations, and The Technical Skills Guide for BAs for the scripting and API skills that let a skill reach your tools, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: AI, LLM, Business Analysis, Automation, Payments