The third chat starts with the same explanation again: which details belong in the briefing, which terms does the team use and what should happen when something is missing? Repetition is a good sign that you can write a way of working down. A skill turns it into a reusable instruction that you apply deliberately and keep maintaining.
For Claude Code, the official skills documentation describes a SKILL.md with metadata and instructions. It can be used when a task fits or when invoked explicitly. This changes the instruction for the work, not the trained model weights. The files below are our own illustrative draft, not a report on a run that was carried out.
First the decision, then the file
Our example is a monthly repair evening. An internal briefing is to be produced from organisational notes. In it, the helpers need the confirmed arrangements, the tasks and the open decisions. That is a smaller assignment than planning the entire event.
Write down an input contract beforehand. Every detail needs a value and a status. “Start 18:00, confirmed” is different from “Start 18:00, suggestion”. The AI should preserve that difference. If the venue is missing, that is an open question; a plausible-sounding substitute address would break the assignment.
Keep the SKILL.md short and unambiguous
One possible project-level location is .claude/skills/reparaturbrief/. It could contain the following working instruction of your own. The metadata explains when it is needed; the text below it describes what it should deliver.
---
name: reparaturbrief
description: Creates internal briefings for repair evenings from organisational notes.
---
Record confirmed details and suggestions separately.
Do not invent venues, dates, names or commitments.
If there are contradictions: state both details and phrase a follow-up question.
Output:
1. Confirmed arrangements
2. Tasks with confirmed responsibility
3. Open decisions with a reference to the input
4. Next coordination stepA description such as “helps with everything to do with organisation” would say less. It makes it hard to see where the skill fits and when a different way of working is appropriate. A clear boundary also makes later maintenance easier.
A sample hand-over with a real gap
Use artificial notes: the room is confirmed, the start time is still only a suggestion, and materials will only be ordered once the budget has been approved. State these conditions directly. An expected output may contain a task “Clarify the budget”. “Materials ordered”, on the other hand, would be a new, unsupported claim.
A helpful additional instruction reads: “For every open decision, state which part of the input triggers it.” This creates a link between the gap and its source. The skill does not have to repeat the entire original text; it should make the disputed detail easy to find.
Keep a stylistic preference separate from the substantive rules. An example of short task descriptions can serve as a supporting file. Event details that change frequently, by contrast, belong in the individual assignment. That way, the general instruction does not go out of date with the next date.
Three cases reveal different weaknesses
In the first case, you provide complete, consistent details. In the second, the date is missing and two budget notes contradict each other. In the third, you ask for something outside the skill’s field, such as travel planning. This lets you look at structure, handling of uncertainty and the limits of use separately.
For each case, note what absolutely must be preserved. Judge an answer by that first and only then by its style. Elegant wording does not make up for an invented date. Equally, a follow-up question is not an error if exactly that decision is missing from the input.
Maintaining a small working instruction
When a problem recurs, change one specific rule and repeat the existing cases. Add a new case that was not yet known when the change was written. This makes it easier to see whether the rule merely reproduces a single example.
Record the reason for the change and its status. At first, that does not require any large infrastructure. A short note such as “Budget conditions must be preserved in the task list” is easier to follow than a complete rewrite without a reason. A skill is worthwhile when its rules make the next real hand-over easier to understand.
Sources and documentation status: 25 October 2026.
