A Skill File for Regulatory Change: Impact Assessment On Demand

Every regulator release is different. The impact assessment method is not. That mismatch is why the same scramble repeats: the release is new each time, so the work feels new each time, even though the steps a good compliance team runs are nearly identical release after release. A skill file captures those steps once, in a plain markdown file the whole team reuses, so the next release starts at your standard instead of at a blank chat window.

Part 3 of The Skill File Series: ten reusable AI skills for Australian professional teams, two for every domain we cover.*

This is the GRC foundation piece: it teaches the six-part skill file anatomy and ships a complete regulatory change impact assessment skill. Part 8 takes the advanced step of treating skill files as controlled documents, and if your AI workspace is not set up yet, build the room first with LM-S01: Set Up Your AI Command Centre.

What is a skill file, and why does it beat re-prompting?

A skill file is a platform-neutral markdown instruction file: one page that tells an AI exactly how your team performs one repeatable task. Write it once, load it into the platform your organisation runs, and every run of that task starts from the same method, the same output shape and the same guardrails.

The alternative is what most teams do now. A release lands, someone opens a chat and types a prompt from memory. Output quality tracks prompt quality, prompt quality tracks who typed it, and the method lives in heads. When that person is on leave, the standard goes on leave with them. Re-prompting also drifts quietly: small wording changes reshape the output until two assessments in the register look nothing alike.

The format is no longer a workaround, either. Both OpenAI and Anthropic now ship a native feature built on exactly this convention, a folder with a SKILL.md instruction file, so the artefact you write for your team is the same shape the platforms have standardised on. The install section below covers where each vendor supports it natively and how to run it everywhere else.

Regulatory change is the ideal first skill for a GRC team because the method is stable while the inputs churn. APRA's letter to industry on AI of 30 April 2026, a consultation paper, an amended standard: the releases differ, the assessment discipline does not.

The six-part anatomy

Every skill file in this series uses the same six sections, in the same order.

1. Purpose. One paragraph: what the skill produces, and for whom.
2. When to use. The trigger conditions, and just as importantly, when not to use it.
3. Inputs required. What the user must supply, written as placeholder fields.
4. Method. The numbered steps the AI follows, in order.
5. Output format. The exact structure of the deliverable, so every run is comparable.
6. Guardrails. What the skill must never do, when it stops and escalates, and what a human verifies.

The order is deliberate. Purpose and When to use are what the AI, and a colleague, read to decide whether the skill fits the request. Inputs, Method and Output format do the work. Guardrails sit inside the file rather than in a separate policy, because a rule the AI never sees is not a control.

The complete skill file

Here is the full skill, ready to adapt. Two inputs make it work: the release itself, and a small organisation context file listing your business lines, licence types, obligation register categories and control framework names. The context file is what turns a generic summary into an assessment of your obligations. Keep it short and current.

# Skill: Regulatory Change Impact Assessment

## Purpose
Turns a regulator release (letter, standard, guidance or consultation paper) into a
structured draft impact assessment for [ORGANISATION]. The output is a draft for a
human obligation owner to validate, never a final compliance position.

## When to use
Use when a new regulator release needs a first-pass impact assessment. Do not use
for legal interpretation or for drafting submissions. If the full release text has
not been supplied, stop and ask for it.

## Inputs required
- The release, pasted or uploaded in full: [RELEASE_TEXT]
- Release name and date: [RELEASE_NAME], [RELEASE_DATE]
- Organisation context file (business lines, licence types, obligation register
  categories, control framework names): [ORG_CONTEXT]
- Date of this assessment: [DATE_CHECKED]

## Method
1. Summarise the change in plain language, including who it applies to and any
   dates or deadlines stated in the release.
2. Identify which obligation register categories in [ORG_CONTEXT] the release
   touches. List only categories supported by the release text.
3. Map each affected obligation to the impacted control categories in [ORG_CONTEXT].
4. Classify each affected area as exactly one of: no impact, monitor, or change
   required, with a one-sentence reason.
5. Draft actions for every area classified monitor or change required. Mark all
   owners TBD.
6. Cite the release section, paragraph or page for every claim in steps 1 to 5.
   If a claim cannot be cited, delete it and record the gap instead.

## Output format
Exactly these sections, in order: Change summary / Affected obligations /
Impacted controls / Gap assessment / Draft actions / Sources. Stamp the header:
DRAFT. Assessed against [RELEASE_NAME] dated [RELEASE_DATE]. Checked
[DATE_CHECKED]. Requires human validation before any register entry.

## Guardrails
- Every statement must be traceable to the release text. Never fill gaps with
  general knowledge of the regulator or of other releases.
- No legal conclusions. Describe what the release says, never what the law requires.
- Nothing enters the obligations register, a risk system or a board paper until a
  human obligation owner validates it.
- If the release appears incomplete, superseded or unclear, say so and stop.
- Keep the draft stamp on every version of the output.

Note what the guardrails do. They force every claim back to the release text, ban legal conclusions, and make human validation a stated precondition for anything reaching the register. That is the human involvement APRA's AI letter expects for high-risk decisions, written into the tool itself rather than left in a procedure document nobody opens mid-task.

Before and after: the prudential letter test

Consider a de-identified scenario. A prudential letter lands at [ORGANISATION], a mid-sized regulated entity, on a Tuesday morning. Under the old pattern, an analyst skims it for 40 minutes, sends a summary upward, the manager asks two clarifying questions by email, someone else searches the obligations register, and by Thursday there is a thread holding three partial views and no single document. Nothing cites the letter. Nothing is stamped.

With the skill installed, the analyst pastes the letter and the context file and runs it once. The draft comes back in the six-section shape: change summary, affected obligations, impacted controls, a gap assessment classifying each area, draft actions with owners marked TBD, and a sources section citing the letter paragraph by paragraph. The obligation owner validates it the same morning, downgrades one classification the model overcalled, upgrades another where it missed a licence condition, and the validated assessment enters the register with its citation trail and draft stamp intact.

The point is not that the AI got it perfectly right. It did not, and the file assumes it will not. The point is that the human spent the morning on two judgement calls instead of on assembling a document.

The five-prompt build chain

The file above is a strong start, but the version your team runs is the one built from your own workflow. These five prompts do that. Run them in order; each output feeds the next.

You are helping a GRC team turn their regulatory change process into a reusable
skill file. Interview me one question at a time. Cover: the regulators and release
types we monitor; what a good impact assessment contains here; our obligation
register categories; our control framework names; who validates an assessment
before action; what has gone wrong with past assessments; and the classification
labels we use. Do not draft anything yet. When you have enough, play my answers
back as a numbered list and ask me to confirm or correct each point.

Using my confirmed answers, draft a skill file in markdown with exactly six
sections: Purpose, When to use, Inputs required, Method, Output format, Guardrails.
The skill turns a regulator release into a draft impact assessment. Require a
citation to the release for every claim, a classification per area of no impact,
monitor or change required, action owners marked TBD, and a draft stamp carrying
the release name, release date and date checked. Guardrails must ban legal
conclusions, ban filling gaps with general knowledge, and require human validation
before anything enters the obligations register. Output only the file.

Stress-test the skill file above. Sample release: [PASTE A RELEASE OR A REALISTIC
EXCERPT]. Organisation context: [PASTE ORG_CONTEXT]. Apply the skill exactly as
written. Then critique your own output against the file: list every place the
output broke a rule in the file, every citation that is missing or wrong, and
every ambiguity in the file's instructions that let you drift. Do not fix the
file yet. Report the failures as a numbered list.

Revise the skill file to fix each numbered failure from the test. For every
change, show the section amended, the old wording, the new wording, and the
failure it fixes. Do not add capabilities the test did not expose. Prefer
tightening instructions over lengthening them. Output the full revised file,
followed by the change list.

Run the scheduled review of this skill file. Check that the obligation register
categories and control framework names still match the current [ORG_CONTEXT],
that the classification labels are still the ones we use, that no guardrail has
proved too loose or too strict in recent assessments, and that the release types
we monitor have not changed. Ask me for anything you cannot check yourself.
Output a dated review note listing what was checked and what changed, plus the
updated file if anything did.

Installing it in ChatGPT and Claude

In ChatGPT, projects are available on every plan, including Free. Create a project for regulatory change, paste the skill file into the project instructions, which override account-level custom instructions inside that project, and upload the organisation context file as project knowledge. File limits run from 5 files on Free to 25 on Go and Plus and 40 on Pro, Business, Enterprise and Edu, and a new project can be set to project-only memory so the work stays separate from outside chats. One practical note: ChatGPT uses project files as retrieval-based reference material rather than guaranteed full reads, so the method and guardrails belong in the instructions field, with the context file as knowledge. On Business, Enterprise, Healthcare and Edu plans, ChatGPT also offers a native Skills feature as of July 2026: reusable, shareable workflows built as a folder with a SKILL.md manifest that loads only when relevant, created in chat, in the Skills editor, or uploaded.

In Claude, the same artefact installs as a first-class skill. A Claude skill is a folder with a SKILL.md file, YAML frontmatter carrying a name and description with the instructions below. Claude reads only the name and description up front and pulls in the full instructions when a request matches, so write the description to say what the skill does and when to use it. To install in the Claude apps, enable Code execution and file creation under Settings > Capabilities, then upload the skill folder as a ZIP, folder at the ZIP root, via Customize > Skills. Skills are available across Claude plans, including Free per the Claude help centre, with code execution enabled, and the same format works across the Claude apps, Claude Cowork, Claude Code and the API, installed separately on each surface. On Team and Enterprise plans an organisation owner can provision a skill for everyone, which is how a validated compliance skill becomes the team standard rather than one analyst's setup. Where a native install is not on offer, run it as a Claude project: projects exist on every plan, including Free with a cap of five, with a per-project instructions field and knowledge uploads.

If your organisation runs Microsoft 365 Copilot instead, the same file adapts directly: paste its contents into an agent's Instructions field in Agent Builder, which caps at 8,000 characters, noting Copilot's uploaded knowledge accepts .txt and .docx but not .md.

The guardrails that make it defensible

Three disciplines separate a defensible AI-assisted assessment from a liability.

Human in the loop, by design. The skill classifies; a person validates. The draft stamp restates it on every output, and no classification touches the register until an obligation owner confirms it. APRA's AI letter names human involvement for high-risk decisions among its minimum expectations, and an assessment that shapes register entries is squarely that kind of use.

An evidence trail per claim. Every statement cites the release section or page, and the output carries the release version and the date checked. When a release is reassessed after amendment, the stamps show which analysis saw which version. Retain the outputs: the validated assessment plus its citation trail is the record that the change was assessed, by what method, against what text.

The file itself is a record. Your skill file documents your method, so it belongs in the AI use-case inventory APRA's letter expects regulated entities to keep. And once a skill file shapes work a regulator cares about, it needs versioning, an owner and an approval step, which is Part 8's territory. For an entity subject to CPS 230, which commenced on 1 July 2025, the connection is direct: the assessment process this skill supports sits inside the operational risk and control environment that standard governs.

Bottom line

Regulatory change assessment is a stable method applied to unstable inputs, which makes it the best first skill file a GRC team can build. Encode the method once in the six-part anatomy, force citations and a draft stamp inside the file itself, keep a named human validating every classification, and build your own version with the five-prompt chain rather than adopting anyone else's file unexamined.

Do this Monday

1. Write your organisation context file. One page: business lines, licence types, obligation register categories, control framework names. Thirty minutes, and it powers everything else.
2. Adapt the skill file above. Change the classification labels and output sections to match how your register actually works, or run the five-prompt chain and build it from your team's answers.
3. Test it on the last release you assessed. You already know what a good assessment of that release looks like, so compare the skill's draft against what your team produced and note every gap.
4. Name the validator. Decide which obligation owner signs off assessments before register entry, and write that into your procedure, not just into the file's TBD field.

Take it with you

The blank template, and the five prompts that build any skill on it.

# Skill: [Name]

## Purpose
[One paragraph: what this skill produces, and for whom.]

## When to use
[Trigger conditions. When NOT to use it.]

## Inputs required
[What the user must supply, as placeholder fields.]

## Method
[Numbered steps the AI follows, in order.]

## Output format
[The exact structure of the deliverable.]

## Guardrails
[What the skill must never do. Escalation rules. Verification requirements.]

• Interview. One question at a time; extract the team's real method before anything gets drafted.
• Draft. Turn the confirmed answers into the six-part file; output only the file.
• Test. Apply the file to a sample release and make the AI report every rule it broke.
• Refine. Fix each numbered failure from the test; tighten wording rather than lengthening it.
• Maintain. A scheduled review that checks the file still matches your register categories, control names and labels.

The Skill File Series

Ten parts, two for every domain we cover, publishing 27 July to 7 August 2026. Links go live as each part publishes.

1. Your First Skill File: A Decision Memo On Demand
2. An HR Skill File That Answers From Your Policies, Not the Internet
3. A Skill File for Regulatory Change: Impact Assessment On Demand (this article)
4. The Safety Comms Skill File: Alerts Workers Actually Read
5. A Claim Chronology Skill File Built for De-Identification
6. Who Owns Your Team's Skill Library?
7. An Investigation Chronology Skill File With Fairness Built In
8. Skill Files Are Controlled Documents. Treat Them Like It
9. An Incident Triage Skill File That Never Decides Notifiability
10. A Determination Evidence-Check Skill File Under Section 14

Content disclaimer: This article is for general educational and informational purposes only. It does not constitute legal advice, regulatory guidance, or a substitute for professional compliance judgement. Regulatory obligations vary by entity type, licence, and circumstance. Always refer to primary source guidance from APRA or the relevant regulatory authority.

Primary sources

• APRA, Letter to Industry on Artificial Intelligence (AI), 30 April 2026. https://www.apra.gov.au/news-and-publications/apra-letter-industry-artificial-intelligence-ai
• APRA, Prudential Standard CPS 230 Operational Risk Management, commenced 1 July 2025. https://www.apra.gov.au/operational-risk-management