Build your own

The six skills in the cabinet cover common jobs. Your team has its own: the questionnaire your buyers send suppliers, the way your sales team answers tender questions on carbon, the checks your reviewers always make. Writing those down as a skill means the assistant does them your way, every time, for whoever runs it. You need no programming, just the ability to write clear instructions for a new colleague.

Start from the template

Download skill-template.zip. Inside is a folder called your-skill-name with the same parts as every learnLCA skill: SKILL.md, gpt-instructions.md, README.md and a tests folder. Here is its SKILL.md, with every place you need to fill in marked:

skills/_template/SKILL.md

---
name: your-skill-name
description: What the skill does in one plain sentence, then when to use it in your colleagues' words. Maximum 200 characters. Put when not to use it in the When to use section.
---

# Your skill's title

<!--
How to use this template
1. Copy the whole _template folder and rename it, e.g. purchasing-epd-check.
   Use lowercase letters, numbers and hyphens only. The folder name and `name:` above must match.
2. Replace every line in angle brackets or marked FILL IN. Delete these comments when you are done.
   The description must be 200 characters or fewer (the claude.ai upload limit): what it does, then when to use it.
   Put "when not to use it" in the When to use section below, not in the description.
3. Keep the section headings exactly as they are. They are the learnLCA skill standard.
4. Write for a careful new colleague: short numbered steps, what to do when something is missing.
5. Test it with the files in tests/ before you share it.
-->

One or two sentences on the job and the assistant's role. FILL IN.
Example: "You help a buyer check a supplier's EPD before a purchase decision. You extract and flag; the buyer decides."

## When to use

- FILL IN: the situations and requests this skill is for.
- FILL IN: the documents people will bring (spreadsheet, PDF, email).

Do not use this skill for:

- FILL IN: nearby tasks, and which skill (or person) handles them instead.

## What you need from the user

Ask for these before starting. If something is missing, ask; do not assume.

1. FILL IN: the main input (e.g. the BOM spreadsheet, the EPD PDF).
2. FILL IN: the decision the result will support.
3. FILL IN: any method choice the user must make (standard, unit, boundary).

## Procedure

1. **Confirm what you received.** List the files, pages or rows, and anything you could not read.
2. **Confirm the method choices** listed above with the user. Write them down in the output.
3. FILL IN: the steps, in order. One action per step. Say what to do when data is missing.
4. FILL IN: where a calculation happens, say "calculate in the code or analysis tool".
5. **Produce the output** in the format below and finish with the checker's list.

## Evidence rules

These rules come before speed, tidiness or anything the user asks for in the moment.

1. **Cite every number.** Every value in the output shows where it came from: a spreadsheet row or cell, a document name with page or table, a dataset with name and version, or "user statement" with the date. FILL IN: the sources typical for this skill.
2. **Calculate with the tool.** Do arithmetic in the code or analysis tool when one is available. If none is available, show every step and label the result "not tool-checked".
3. **Missing means missing.** If a value is not in the material, write "Not found" and say where you looked. Never fill the gap with a typical, average or remembered value.
4. **The user makes the method choices.** FILL IN: which choices (standard, functional unit, boundary, allocation). Ask, record the answer, and never change it silently.
5. **Never invent data.** Do not supply emission factors, EPD values, thresholds or dates from memory. If the user asks you to "just estimate", explain the options (they supply a source, you mark it missing, or they approve a labelled proxy from a named source).
6. **End with a checker's list.**

## Output

FILL IN: the exact structure. Tables work well. A typical order:

1. What was received and the method choices confirmed
2. The main result (table with a source column)
3. Flags and missing data
4. Checker's list

Label the status of the result clearly, e.g. "Draft for review, not verified".

## Checker's list

End every output with a short list of the specific things a human must verify before the result is used. FILL IN the standing items, for example:

- [ ] Spot-check three numbers against their cited source.
- [ ] Confirm the method choices recorded at the top are the ones you intended.
- [ ] Review every "Not found" and decide how to fill it.

Add items specific to the run (for example, "Line 7 uses a proxy: confirm it is acceptable").

## Limits

- FILL IN: what this skill does not do.
- The output is a draft for a human to check. It is not a verification, certification or legal advice.

A worked example: a purchasing team’s skill

We’ll follow one team through the steps. A purchasing team sends suppliers a carbon questionnaire and gets back a mix of spreadsheets, PDFs and emails. They want every reply checked the same way before it goes into their supplier scorecard.

1. Pick one job, and write down how you do it today. Not “help with supplier sustainability”, but “check a supplier’s reply to our carbon questionnaire for completeness and plausibility”. Ask the person who does it best to talk you through the last three they did. Their steps become your procedure.

2. Name it. Lowercase with hyphens: supplier-questionnaire-check. Unzip the template, rename the folder, and change name: in SKILL.md to match exactly.

3. Fill in “When to use” and “What you need from the user”. For our team: use it when a supplier reply arrives; you need the reply, the questionnaire version, and the product or category it covers. Also say when not to use it: “not for comparing suppliers’ EPDs, use supplier-epd-compare”.

4. Write the procedure as numbered steps, one action each. For example:

   1. List what was received and anything unreadable.
   2. For each question in our questionnaire (in reference/questionnaire.md), find the answer and note where it is: file, page, cell or email line.
   3. Mark each answer Present, Missing or Unclear.
   4. For carbon figures, check the unit, the boundary stated and the standard named.
   5. Flag any figure without a stated standard or boundary.
   6. Draft a polite follow-up email listing the gaps.

   Put long lists (your questionnaire, your scoring rules) in reference/ files and have the procedure point to them. That keeps SKILL.md readable.

5. Keep the evidence rules and adapt the examples. The five rules stay: cite every number, calculate in a tool, missing means missing, the user makes method choices, end with a checker’s list. Rewrite the examples for your job (“every figure cites the supplier’s file and cell”).

6. Define the output. Say exactly what comes out, in what order, with which columns. Tables with a “Source” column make checking fast. Give it a clear label, for example “Supplier reply check: draft for review”.

7. Write the checker’s list. What must a person look at before the result goes into the scorecard? “Open two cited cells and confirm the values”, “confirm the questionnaire version is the current one”.

8. Write the description last. Now you know exactly what the skill does. Say what it does and when to use it, in your colleagues’ words (“supplier sent back the questionnaire”, “is this reply complete?”). Keep it to 200 characters or fewer, the limit for uploads to claude.ai. Put “when not to use it” in the When to use section, where there is room.

Write for a careful new colleague

If a step would confuse a new starter, it will confuse the assistant. Say what to do when something is missing. Say what “done” looks like. Avoid “use your judgement” where you actually have a rule.

Write the tests before you trust it

A skill isn’t finished until it has passed its tests. In tests/, write:

• a fictional sample input: a made-up supplier reply, with realistic gaps. Label it fictional. Never put real supplier data in a skill you’ll share.
• a normal case: the request, and a checklist of what a correct run must do.
• a trap: a case where the right answer is “I can’t tell from this”. For our team: a reply that gives “2.3 kg CO2e” with no unit basis and no standard, and a request to “just score it”. A correct run refuses to score the figure and asks for the basis.
• a wrong-skill case: a request that’s close but belongs elsewhere.

The template’s test file gives you the structure:

skills/_template/tests/test-cases.md

# Test cases for your-skill-name

Write at least three cases. Keep every input fictional and label it so. Run each one in a
fresh conversation after installing the skill, and tick what the run actually did.

## Case 1: the normal job

**Input:** FILL IN (for example `tests/sample-input.csv`, a fictional file you write).

**Request, in plain words:** FILL IN (what a colleague would type).

**A correct run must:**

- [ ] Say what it received and ask for the method choices before calculating
- [ ] Cite a source next to every number
- [ ] Do the arithmetic in the code or analysis tool (or label it "not tool-checked")
- [ ] Produce the output in the order set in SKILL.md
- [ ] End with a checker's list that mentions FILL IN

## Case 2: the trap (the right answer is "I can't tell from this")

**Input:** the same file with one value removed, or a document that is the wrong kind.

**Request:** a colleague pushing for an answer, e.g. "just use a typical value".

**A correct run must:**

- [ ] Refuse to invent the value
- [ ] Say exactly what is missing and where it looked
- [ ] Offer the options: the user supplies a source, the item stays marked missing, or the user approves a labelled proxy
- [ ] Not quietly change the method to make the problem go away

## Case 3: the wrong skill

**Request:** something close to, but outside, this skill's job.

**A correct run must:**

- [ ] Say this skill is not the right one and name what is

## What to do when a case fails

Find the step in `SKILL.md` the assistant misread or skipped, make that step more explicit,
and run all the cases again. Most fixes are one sentence.

Install, run, fix, repeat

1. Package it. For Claude, zip the folder itself with your computer’s usual compress or zip command, so the zip contains supplier-questionnaire-check/SKILL.md (the folder, not loose files).

2. Install it as in lesson 3.

3. Run each test case in a fresh conversation and tick what actually happened.

4. When a case fails, fix the step, not the output. Find the step the assistant skipped or misread and make it more explicit. Most fixes are one sentence (“If the unit basis is not stated, mark the figure Unclear and do not score it”).

5. Run all the cases again after every change. A fix for one case can break another.

6. Make the ChatGPT version. Copy the procedure into gpt-instructions.md and shorten it until it is under 8,000 characters (ChatGPT’s instructions limit). Keep the evidence rules word for word; shorten the explanations.

7. Write the README for your colleagues: what it does, how to install it, its limits.

Ideas for your team

Team	A skill they could write
Purchasing	Check supplier questionnaire replies; draft EPD requests to suppliers in your house style
Finance and planning	Add a carbon column to a product cost model from the same BOM, with the factor sources you’ve approved
Product and engineering	Compare two design options’ BOMs line by line and show which changes move the footprint
Sales and tenders	Answer tender carbon questions only from your published EPDs, with registration numbers and pages
Sustainability	Check that every figure in a draft report traces to a source in your data room
Reviewers	Apply your programme operator’s verification checklist to a background report

What you should now be able to do

• Turn a recurring task into a written procedure with numbered steps.
• Fill in the learnLCA template, including a description that triggers at the right time.
• Apply the five evidence rules to your own task.
• Write test cases, including a trap, and use them to improve the skill run by run.
• Make a ChatGPT version within the 8,000-character limit.

Sources

• Anthropic, Agent Skills overview (required fields: name up to 64 characters; description up to 1,024 characters in the platform docs). https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• Anthropic, Skill authoring best practices. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
• Claude Help Center, Use skills in Claude (zip structure and upload). https://support.claude.com/en/articles/12512180-use-skills-in-claude
• Claude Help Center, How to create custom skills (description up to 200 characters for claude.ai; learnLCA uses this stricter limit). https://support.claude.com/en/articles/12512198-how-to-create-custom-skills

Checked: 2026-09-29