How to Teach Claude a Task With Examples and Instructions

Teaching Claude a task does not mean repeating it in chat until the model learns: each new session starts without memory of earlier conversations. What it actually means is writing a clear instruction with examples that you can load at the start of any session and get a consistent result.

Tools like fenbs let you store approved task instructions and the lessons from testing them, so every AI app you connect reads the right version rather than whatever you happen to retype that day.

Why conversational training does not work

Claude is a large language model. Chatting with it does not change its weights or add to its memory. At the end of a session, any correction you gave it is gone. The next time you open a chat, you are working with the same model you started with.

Claude Projects can hold shared instructions that persist across sessions, but even there the model itself is not altered. What persists is the text in the instruction field. The practical result: a good task instruction is always text you can read, copy, and improve.

If the task runs inside Claude Code, the difference between tasks and to-dos matters for how you structure the work. The post on claude code tasks vs todos covers that distinction separately.

What a task instruction needs

A reliable task instruction has three parts: what the task is, what the output should look like, and any constraints on how to do it. Leaving out any one of these is the most common reason an instruction produces inconsistent results.

• Task: the job in one sentence ("Summarize the following support email into three bullet points").
• Output shape: exactly what you expect back ("Each bullet starts with a verb; none exceeds fifteen words").
• Constraints: what to include or leave out ("Do not add opinions or recommendations; flag anything missing from the original").

Keep the first version short. A long instruction is harder to test and harder to maintain. Add detail only after you know where the short version breaks down.

How to add examples that sharpen the result

Examples show the standard more clearly than descriptions can. One or two input-and-output pairs let Claude infer the pattern without you needing to describe every rule.

Label them clearly: "Example input:" and "Expected output:" work well. If a particular case keeps going wrong, add a corrected version of it as an example rather than trying to explain the rule behind the correction in words.

Two specific, well-chosen examples usually outperform five vague ones. Pick inputs that cover the main variation you see in practice, not every possible edge case.

Testing and improving the instruction

Paste the instruction into a fresh chat and give it three different real inputs. Check whether each output meets your standard without any follow-up from you. If you need to correct it, the instruction is not finished.

1. Run the instruction on three real inputs from your work.
2. For each output that missed the mark, note exactly what you would correct.
3. Add that correction to the instruction or examples, not to a follow-up message.
4. Open a fresh chat and retest. Repeat until all three inputs pass without a follow-up.

Keep a record of each change and why you made it. That record is the lesson: it tells the next person or AI app what traps exist in this task and why the instruction is written the way it is. Stored in fenbs, those lessons appear before similar work begins.

Common mistakes that hurt consistency

• Assuming Claude recalls the last session. It does not. Every context it needs must be in the instruction.
• Describing the task without describing the output. Describe what "done" looks like, not just what to do.
• Adding too many constraints at once. Add one at a time and test after each.
• No fail case. When the input does not match what the instruction expects, tell Claude what to say rather than letting it guess.

For tasks that run in the background without a person watching, see claude code background tasks. Those tasks need the fail case written explicitly into the instruction.

How to do this with fenbs

1. Create a free account and open the project the task belongs to.
2. Add the instruction to Skills and prompts in fenbs with a short name that describes the task.
3. After testing, record what inputs broke the first version and what fixed them in Lessons learned, linked to this task.
4. When you refine the instruction later, update the Skill and add a new lesson noting what changed and why.
5. Connect your AI app over MCP from Integrations so it reads the current instruction at the start of each session rather than relying on whoever happens to remember the right wording.

When to rebuild rather than patch

Rebuild the instruction when the task has changed enough that your examples no longer match what you actually need. A patched instruction grows confusing faster than a clean rewrite, and confusing instructions produce unpredictable output.

Keep the old version until the new one passes the same test inputs. That comparison usually shows which constraint was doing most of the work and which lines you can safely drop.

For instructions that need to run on a schedule, claude code scheduled tasks covers how to attach an instruction to an automated run so the tested version is always the one that executes.