Didn (topic)

A "skill" (a reusable step-by-step guide you teach an AI) is the core building block for effective AI development. Instead of asking an AI one vague question, you first create a skill that encodes your specific process. For example, you spend 80% of your time in the "build phase," creating skills for tasks like market research. You then move to a "borrow phase," where you copy skills from colleagues. This is far more reliable than starting from scratch each time.

Don't download skills from strangers online. You must build your own, because a skill must encapsulate the process without being biased toward a specific topic. The AI generalizes the *process* you taught it, not just the example data. This lets it duplicate your best thinking on new problems.

Why does this matter? Because "attention didn't" get cheaper, even though code did. Human judgment—choosing which problems matter, when an approach is a dead end, and which results to trust—remains the realm of humans. A skill is how you codify that judgment. It’s how you turn your taste and experience into instructions the AI can follow reliably, ensuring it doesn't just give you the average answer. Instead of handing you text in a chat, a well-built skill drops a finished, scored idea straight onto your desktop. It’s the difference between a fancy autocomplete and a tool that multiplies your specific expertise.

To use "didn" effectively, start by defining clear success criteria—the specific results that make a correct output visible. For example, if you're analyzing a report, your criteria might be: "distinguish between forward-looking analysis and historical summary." Write these requirements down before you begin, because vague goals lead to unreliable results.

Next, structure your prompt using XML tags. Separate instructions, context, input, and documents into visible compartments. For instance, wrap the task inside `<task>`, the background in `<context>`, and any examples in `<examples>`. This hierarchy acts as a debugging ladder—solve the simplest communication problem first.

After running your prompt, evaluate the output against your original success criteria. Test both positives (did the model do the task?) and negatives (didn’t it do something bad?). If the output misses the mark, add 3-5 diverse examples within your XML tags to steer format and tone. Show one normal case and one edge case, not repeated copies. Then rerun the evaluation. Let the score decide whether those examples earned their space.

Finally, refine your context. Retain useful evidence and tools, but leave distracting material out. A great prompt still fails with wrong surrounding information. Focus on the agnostic elements between examples—the patterns that map to future cases—not the specifics of a single project.

A common pitfall in AI tooling is assuming a task is complete when the agent says "Done." The most expensive failure is when an agent "fails quietly underneath" — for example, Claude once reported a migration finished successfully but had skipped 14% of records due to a constraint issue, discovered 11 days later when reports looked wrong. Always verify outputs against actual traces (records of what happened during execution) rather than trusting completion messages.

Mistakes often come from writing rules based on assumptions rather than observed failures. Instead, analyze your traces to identify patterns of what actually went wrong, then write rules based on real evidence. Similarly, when reviewing agent work, inspect the system rather than every line — one expert advises writing documentation, linters, and reviewer notes so "the system will catch this type of bugs" repeatedly.

Another trap is trying to fix mistakes mid-conversation by saying "No, fix this thing" — this makes the agent work from broken code plus new context, compounding errors. Instead, start fresh with corrected instructions. Also watch for "confidently wrong" outputs, where the agent generates plausible-sounding but fabricated data, like claiming specific vehicle delivery numbers that it invented completely.

Best practices include using natural language to design tests for edge cases, ensuring failures are "safe failures" rather than catastrophic ones, and defining measurable success and constraints before coding. Begin with budget, latency, and throughput targets, then ask how bad an error is and whether it can be caught — this determines if human-in-the-loop review is needed. Finally, know when to choose plain code instead of an LLM for stable rules that need no LLM decision-making.