/task-to-skill

---
name: task-to-skill
description: >-
  Turn a task the user repeats every week or month (the monthly report, the
  client update, the expense check, the pipeline review) into a working
  Claude skill: interview them about how they really do it, capture the
  rules they never wrote down, write the SKILL.md with a strong trigger
  description, test it on a real past example, and package it as a zip
  ready to upload. Use this skill whenever the user says "make this a
  skill", "turn this into a skill", "I do this every week", "can Claude
  remember how I do this", "automate my report", "build me a skill for",
  or keeps pasting the same long instructions into new chats. Do NOT use
  for one-off tasks, for tasks that need live access to a system Claude
  cannot reach, or to copy someone else's paid skill.
---

# Task to skill

Every professional has a handful of tasks they explain to AI again and
again: the same context, the same rules, the same corrections. "Use our
fiscal year. Never round revenue. The CFO hates bullet points." Each
re-explanation costs ten minutes, and each forgotten rule costs a redo. A
skill writes those rules down once, so Claude starts every run already
knowing them.

The hard part is not the file format. It is getting the rules out of the
user's head. People describe their task the way they think they do it, not
the way they actually do it. The real rules show up in their corrections:
"no, not like that". This skill interviews for those corrections, and
tests the skill against a real past example before calling it done.

## Workflow

### 1. Check it is worth a skill

A task earns a skill if at least two are true:

- It repeats (weekly, monthly, per client).
- It has rules or a format that must be the same every time.
- The user has corrected AI output on it more than once.
- Someone else could do it if they had the instructions.

If not, say so and suggest a saved prompt instead. A skill for a one-off
task is clutter.

### 2. Interview in two rounds

Round 1, the task (ask 4 to 5 at once, numbered):

1. What is the task, and what triggers it (a date, an email, a file)?
2. What goes in (files, data, notes) and in what format?
3. What comes out, and who reads it?
4. Paste or upload one finished example you were happy with.
5. Paste one AI attempt you had to fix, and say what was wrong.

Round 2, the hidden rules (shaped by round 1):

6. What do you always check before sending?
7. What words, formats or habits are banned?
8. What does the reader complain about when it goes wrong?
9. When should the skill NOT run (similar tasks that need something else)?
10. What should it ask you before starting, if anything?

The good example and the fixed bad example are worth more than all the
other answers. Insist on them, kindly.

### 3. Write the SKILL.md

Structure:

```
---
name: [kebab-case, verb-noun, e.g. monthly-client-update]
description: >-
  [What it does in one sentence. When to use it, with the real phrases the
  user says. ALSO when to use it proactively. Do NOT use for: the
  look-alike tasks from question 9.]
---

# [Title]

[Why this task matters and how it goes wrong: 1 short paragraph. Claude
follows rules better when it knows what they protect.]

## Workflow
[Numbered steps, in the order the user actually works.]

## Output format
[The exact template, from the good example.]

## Rules
[The hidden rules from round 2, each with its reason.]

## Example
[A short before/after from the bad and good examples.]
```

Writing rules for the skill itself:

- **The description does the triggering.** Claude decides to use a skill
  from its description alone. Put the user's real trigger phrases in it,
  and the "do NOT use" cases, so it fires when it should and stays quiet
  when it should not.
- **Explain the why.** "Never round revenue, because the board compares it
  to the audited figure" works better than "NEVER round revenue".
- **Short beats complete.** Under about 150 lines. If it needs more, move
  reference material (a glossary, a long checklist) into a separate file
  in the skill folder and point to it.
- **No secrets.** No passwords, keys, client names or personal data in the
  skill. Use placeholders.

### 4. Test on a real case

Run the new skill on the input from a past example the user already did
by hand. Compare the result with their finished version, line by line.
Report what matched and what did not, fix the skill, and run again. Two
rounds is normal. Stop when the user says the output needs no edits they
would not make anyway.

### 5. Package and install

Create a folder named exactly like the `name:` field, put `SKILL.md` (and
any reference files) inside, and zip the folder. Then tell the user, step
by step, how to install it in the app they use. For the Claude app:
Settings, then Capabilities, check that Skills is on, then upload the zip
in the Skills section. Menu names change between versions, so tell them to
look for "Skills" if the path differs.

## Judgment rules

**Their way, not the textbook way.** If the user's process is unusual but
works for their reader, encode it. The skill should sound like their team.

**One skill, one job.** If the interview reveals two different tasks
(the monthly report and the board version of it), make two skills.

**Version it.** Add a line at the bottom: "v1, [date]: built from [example]".
When the user later says "it got this wrong", update the skill, not just
the output.

## Example

A controller pastes the same 300-word instructions every month for the
client cost report. The interview finds two rules the instructions never
mention: the client's year starts in April, and "savings" must only
include signed contracts. The first test run gets the period wrong anyway,
because the description of the input never says which column holds the
month. One line fixed it. The second run matched the controller's own
report. Ten minutes a month saved, and one recurring mistake gone.