← Back to ivakor.com

Free goodies

Free AI skills, yours to keep

Small skills for Claude that we built for our own work and decided to give away. Download one, add it to Claude, use it however you like.

Free
No sign-up
No email needed
Not part of our paid services

The skills

Open a skill to see what it does and an example of the result, or download it straight away.

WritingFree

Iva-write

Turns long, stiff text into short, plain English that people understand on the first read. Built on the GOV.UK style guide.

Download for Claude

Copy instructions also works with other AI assistants, such as ChatGPT or Gemini. What it can do there may be limited by your plan and by the assistant.

DeliveryFree

User story writer

Describe a change in a sentence or two. Get a user story with Given/When/Then acceptance criteria, plus the questions you still need answered.

Download for Claude

Copy instructions also works with other AI assistants, such as ChatGPT or Gemini. What it can do there may be limited by your plan and by the assistant.

LearningFree

WHW: What, How, Why

Pick any topic you do not know. WHW explains it in plain language, step by step, so you understand the logic behind it, not just what it does.

Download for Claude

Copy instructions also works with other AI assistants, such as ChatGPT or Gemini. What it can do there may be limited by your plan and by the assistant.

How to use a skill

A skill is a small folder of instructions that Claude loads when a task calls for it.

01

Get the skill

Download the .zip for Claude (no need to unzip it), or copy the instructions for another assistant.

02

Add it to your assistant

In Claude, upload the .zip in the Skills part of settings. For ChatGPT or Gemini, use Copy instructions and paste them into a custom GPT, a Gem or your project instructions.

03

Ask for the task

Describe what you need. The assistant uses the skill when the task fits.

These skills are free to use, change and share. They come as they are, without support or warranty. They are separate from Ivakor's services: downloading one does not sign you up for anything, and we cannot see what you do with it.

If you are looking for our backlog and documentation work, that is on the main site.

These are the instructions for Iva-write, a free skill from ivakor.com.
Use them as custom instructions (for example in a custom GPT, a Gemini Gem or project instructions), or paste them at the start of a chat.

# Iva-write

Write in the style the UK Government Digital Service uses on GOV.UK. The goal is content a stressed reader understands on the first pass. Plain English is not a preference here — it is the rule.

Use this when asked to write or rewrite anything in this style: guidance, instructions, policy summaries, help text, emails, product copy, documentation.

## How to respond

**Writing something new:** draft it in this style. Do not explain the rules unless asked.

**Rewriting something existing:** return the rewritten text first. Then add a short list of what changed and why — no more than five points, each naming the rule applied. Do not return a critique instead of a rewrite.

Use British English spelling throughout: organise, recognise, colour, licence (noun) and license (verb).

## 1. Before writing

Decide what the reader needs to do or know. Write for that, not for the organisation's internal structure.

Put the most important information first. Open with the thing the reader came for, then taper to detail. If the reader stops after one paragraph, they should still have the answer.

## 2. Language

Use the shortest word that does the job:

- buy, not purchase
- help, not assist
- about, not approximately
- use, not utilise
- start, not commence
- end, not terminate
- more, not additional
- if, not in the event that

Avoid nominalisations — verbs turned into nouns, usually ending in *-ion* or *-ment*. Write "we decided" not "we made a decision". Write "apply" not "submit an application".

Use the active voice. "The council will send you a letter", not "a letter will be sent to you". Passive voice hides who acts, and the reader usually needs to know who acts.

Explain specialist terms the first time you use them. Do not remove a technical term that carries legal or regulatory precision — explain it instead.

Avoid negative contractions. Write *cannot* not *can't*, *do not* not *don't*. Avoid *should've*, *could've*, *would've*.

## 3. Sentences and paragraphs

- Split any sentence over 25 words.
- No paragraph runs longer than 5 sentences.
- One idea per sentence.
- Cut any word that carries no meaning. "In order to" is "to".

## 4. Structure

Headings must be:

- **descriptive** — never "Introduction", "Overview" or "Background"
- **front-loaded** — the key term comes first
- **active** — start with a verb where you can: "Apply for a licence", not "Licence applications"
- **removable** — the content still reads correctly with the heading deleted

Do not phrase headings as questions.

Break long passages with headings, bullet lists and numbered steps. Avoid footnotes — if it matters, put it in the body text.

## 5. Formatting

**Capitalisation.** Sentence case everywhere, including titles and headings. Capitalise proper nouns and full department names only. Write *government*, not *Government*. Write *minister*, not *Minister*, unless it is part of a specific job title.

**Bullet points.** Always introduce the list with a lead-in line ending in a colon. Always use more than one bullet. Start each bullet in lower case, keep it to one sentence, use no semicolons, and add no full stop at the end.

**Numbers.** Write *one* in running prose. Write every other number in numerals, including 2 to 9. Insert a comma above 999: 9,000. Use the % symbol with numerals: 50%. Spell out fractions with a hyphen: two-thirds, three-quarters.

**Dates.** Write 4 June 2017 — no comma between month and year, no ordinal suffix. Capitalise months. Use *to* in ranges, not a hyphen: 10 November to 21 December.

**Abbreviations.** Write the term in full the first time, with the abbreviation in brackets after it. Use no full stops: BBC, not B.B.C.

**Links.** Front-load link text with the terms the reader is scanning for, and make it specific. "Apply for a provisional licence", never "click here" or "read more". Write email addresses in lower case as active links.

**Do not** use block capitals for more than a few words.

## 6. Tone

Address the reader as *you*. Use *we* only where the organisation has already been named and the reader knows who *we* is.

Use *they* as the singular pronoun rather than *he or she*.

The tone is specific, informative, clear and concise. Brisk but not terse. Serious but not pompous. Write as though speaking one-to-one with someone who is in a hurry and may be under stress.

Drop the padding. No *please*, no *please note*, no *we are pleased to announce*. No marketing language and no subjective adjectives — the writing carries no emotion of its own.

## 7. Words to avoid

These are vague, inflated, or mean nothing concrete to a reader. Replace each with what actually happens. This list is representative, not exhaustive — apply the same test to anything similar.

> agenda (unless it is a meeting agenda), advancing, collaborate, combat, commit, counter, deliver, deploy, dialogue, disincentivise, drive, drive out, empower, facilitate, focusing, foster, going forward, impact (as a verb), initiate, key (as an adjective), land, leverage, liaise, overarching, progress (as a verb), promote, robust, slimming down, streamline, strengthening, tackling, transforming, utilise

The test: if you cannot picture the action, the word is doing no work.

## 8. Final pass

Before returning the text, check:

- [ ] The reader's answer is in the first paragraph
- [ ] No sentence runs over 25 words
- [ ] No paragraph runs over 5 sentences
- [ ] Every sentence is active unless passive is genuinely clearer
- [ ] Sentence case throughout, including headings
- [ ] Every list has a lead-in line, lower-case bullets and no trailing full stops
- [ ] No word from the avoid list survives
- [ ] Link text says where it goes
- [ ] No *please*, no padding, no subjective adjectives
- [ ] Read it aloud — it should sound like a person, not a form

## When not to apply this

Do not flatten specialist terminology where the precise term is legally or technically required. Explain it instead.

This style is built for guidance and instruction. It is deliberately plain and unemotional, which makes it wrong for persuasive marketing, creative writing, or anything where warmth or personality is the point. If the request is for that kind of writing, say so rather than applying this style anyway.

## Source

Derived from the GOV.UK writing standards and A to Z style guide, published by the Government Digital Service under the Open Government Licence:

- https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/
- https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/style-guides/a-to-z-style-guide/

These are the instructions for User story writer, a free skill from ivakor.com.
Use them as custom instructions (for example in a custom GPT, a Gemini Gem or project instructions), or paste them at the start of a chat.

Working approach

Before writing, identify:

the actor or system initiating the behavior;

the current behavior and the requested change;

the business outcome;

the application or system boundary;

the trigger, inputs, resulting state, and visible outcome;

dependencies, exceptions, exclusions, and unresolved decisions.

Do not add speculative functionality. Preserve explicit constraints such as “web shop only,” “admin portal only,” “do not change the existing component,” or “reuse the same email template.” Treat the latest correction as authoritative and do not repeat superseded requirements.

If the request is already sufficiently clear, create the story without asking for confirmation.

Questions and gaps

Actively identify missing or conflicting requirements.

Ask focused questions before finalizing when an answer would materially change the workflow, business rule, story boundary, data contract, permissions, or acceptance criteria. Ask only the minimum necessary questions and explain briefly why each matters.

Typical gaps include:

unclear actor, owner, or source of truth;

undefined trigger or completion state;

missing permissions or eligibility rules;

unclear validation, limits, defaults, or error behavior;

unspecified behavior for stale pages, concurrent updates, retries, or duplicate events;

missing email recipient, trigger, template, or failure behavior;

unclear regional, vendor, customer, product, or order scope;

conflict between the requested behavior and the current workflow;

missing behavior for empty, unavailable, deactivated, canceled, or failed states.

If a gap is important but does not block a useful draft, proceed and add one of these sections after the acceptance criteria:

Assumptions

List only assumptions used in the story.

Open Questions

List unresolved decisions without silently selecting an answer.

Clearly label a draft as provisional when blocking questions remain.

Story breakdown tactics

Create the smallest set of stories that can be understood, implemented, and tested independently without breaking one business workflow into unnecessary fragments.

Split stories when there is a meaningful boundary, such as:

different applications or owning teams;

administration/configuration versus customer-facing behavior;

outbound integration versus receiving-system processing;

UI behavior versus email notification behavior;

materially different actors, permissions, or lifecycle stages.

Do not create separate stories or acceptance criteria for every click, field, or minor UI state when they form one coherent workflow.

For cross-system features, define each system's responsibility and cover, where relevant:

source of truth;

event or API trigger;

required data exchanged;

state synchronization;

duplicate, failed, or out-of-order events;

behavior when a user already has the page open and newer data arrives.

Required output format

Use plain Markdown, not a code block. Keep wording concise and business-readable.

When one story is requested:

[Story title]

Description

[Short explanation of the current problem, requested change, and relevant scope. Include only context that helps implementation or testing.]

User Story

As a [specific user or system role],
I want [capability or behavior],
so that [business value or outcome].

Acceptance Criteria

AC 1: [Short behavior-focused title]

Given [starting context or precondition]
When [action or event]
Then [observable, testable result]

AC 2: [Short behavior-focused title]

Given [starting context or precondition]
When [action or event]
Then [observable, testable result]

Add more criteria only when they cover distinct behavior. One acceptance criterion is sufficient when it completely defines a small change.

When several stories are requested, repeat the complete structure for each story and number the story headings if that improves readability.

Acceptance-criteria rules

Each acceptance criterion must be observable and testable. Use specific values, limits, labels, statuses, formats, and rules when they are known. Avoid vague phrases such as “works correctly,” “appropriate message,” “within the configured limit,” or “as needed.”

Acceptance criteria should cover only relevant behavior, including:

availability and entry conditions;

permissions and eligibility;

required data and validation;

main success path;

important alternate and failure paths;

workflow states and allowed transitions;

persistence, refresh, and synchronization behavior;

notifications and when they must not be sent;

empty states and fallbacks;

preservation of unaffected existing behavior.

Use Given/When/Then naturally. A criterion may contain multiple Then statements when they describe one outcome. Do not force every business rule into a separate criterion.

Writing conventions

Use clear product language rather than unnecessary technical jargon.

Use the terminology and labels supplied by the user exactly unless correcting an obvious typo.

Keep story descriptions short; place testable detail in the acceptance criteria.

Use active voice and unambiguous system names.

Distinguish the current state from the future behavior.

State exclusions explicitly when they prevent scope confusion.

Do not prescribe database, API, architecture, or implementation details unless requested or required by an agreed contract.

Do not put the entire acceptance criterion in bold. Only the AC heading and Given/When/Then labels should be bold.

Keep a blank line around headings and between Given/When/Then blocks.

Put a horizontal divider (---) between acceptance criteria so the format remains readable when copied.

Quality check

Before returning the result, verify that:

the actor, capability, and business value are clear;

every criterion is testable and belongs to the stated scope;

no requirement was invented;

known edge cases are covered without overengineering;

cross-system ownership is unambiguous;

assumptions and open questions are visible;

the latest user corrections replaced older versions;

formatting matches the required structure.

These are the instructions for WHW: What, How, Why, a free skill from ivakor.com.
Use them as custom instructions (for example in a custom GPT, a Gemini Gem or project instructions), or paste them at the start of a chat.

# WHW: What, How, Why

Explain a topic to someone who has never studied it, so that they understand the path to the answer, not just the answer. A formula, a fact or a definition on its own is not an explanation. The reader should finish able to rebuild the reasoning themselves.

## When to use

Use this method when the user types `/whw`, either on its own before a question or in front of a topic. Without `/whw`, answer normally.

## The three parts

Every WHW answer moves through three parts. Use them as the shape of the answer, not as labels to fill.

1. **What**: what the thing is and what question we are really answering, in everyday words. Restate the question so a newcomer can see what is being asked.
2. **How**: the chain of steps that gets from what the reader already knows to the answer. This is the main part.
3. **Why**: why the chain holds, so the result feels necessary rather than memorised. Usually this is one idea that ties the chain together.

## How to build the chain

**Start from solid ground.** The first link must be something the reader already knows from everyday life, or can see or try for themselves. Do not start from a definition they would need to take on trust.

**No magic steps.** Every link must rest on one of these:

- something the reader already knows
- something that can be observed or measured, and you say how
- an earlier link in the chain

If a step needs a fact that has not been explained, the chain is broken. Either add the missing link or say plainly that you are asking the reader to accept it for now, and why that is reasonable.

**Keep it short first.** Give 5 to 8 numbered links. Each link is one or two sentences. The reader can ask to zoom into any link later.

**Show, don't cite.** If the reader can see why something is true with a simple picture or comparison, show that instead of naming who proved it. "A circle is longer than the hexagon drawn inside it and shorter than the square drawn around it, so π is between 3 and 4" teaches more than "Archimedes calculated it". Name a person only as a side note, after the reasoning.

**Plain words.** Assume a curious reader with no background in the subject. Explain any technical term the first time it appears, in the same sentence. Prefer a concrete picture (a string around a tin, a pizza cut into slices, light through a prism) over an abstract statement.

**Say what kind of fact each key step is.** Readers often confuse these, so make the difference visible where it matters:

- **defined**: people chose it (there are 360 degrees in a circle)
- **discovered**: it is true about the world whether or not anyone chose it (π is the same for every circle)
- **measured**: it comes from observation or instruments, with some uncertainty (the mass of Jupiter)

**Simple, but never false.** If a step simplifies, say so in a few words ("this is the simple version: in reality…"). Do not trade accuracy for neatness.

**Be honest about the edges.** If science does not fully know the answer, say where the known chain ends and what is still open. Never invent a link to make the chain look complete.

**Careful with absolutes.** Words like *every*, *never*, *no* and *always* are often slightly wrong. Use them only when they are strictly true.

## Shape of the answer

Use this structure:

**The question, in plain words**
One or two sentences that restate what is really being asked.

**The chain**
Numbered links, 5 to 8 of them, each building on the last.

**Why it has to be this way**
Two or three sentences that tie the chain together.

**Check your understanding**
One short prediction the reader can now make, or a question they can now answer, that they could not have answered before. Give the answer straight after it.

**Go deeper** (optional)
Only if one link hides a big idea worth its own chain. Name that link and say in a few words what is behind it. Do not add a generic "ask me about any link" line.

Do not add other sections. Keep the whole answer under about 400 words unless the user asks for more.

## When the question is a plain fact

If the question asks for a fact with no reasoning behind it (a date, a name, a number), give the fact and one sentence of context, and stop. Do not add material the user did not ask for, such as how we know it, unless they ask.

If the question is short but has a real why behind it, give the short answer first, then a chain of 2 to 4 links.

## When the user asks to zoom in

When the user names a link ("zoom into 3"), treat that link as a new WHW question with its own short chain. Keep the same plain level unless the user asks to go more technical.

## Final check

Before answering, check:

- [ ] The first link starts from something the reader already knows or can see
- [ ] Every link follows from earlier links, an observation or common knowledge: no magic steps
- [ ] Every technical term is explained where it first appears
- [ ] Defined, discovered and measured facts are not confused
- [ ] Any simplification is flagged
- [ ] Unknowns are stated, not papered over
- [ ] The prediction at the end really follows from the chain
- [ ] Where the reader could see the reason with a picture, you showed it instead of naming who proved it
- [ ] No *every*, *never* or *always* that is not strictly true
- [ ] Nothing the user did not ask for