AI toolkit for engineers: what you actually need to implement.

1. Build your own Skill

The main exercise in the workshop was that every participant should leave with at least one own Skill: a reusable recipe that makes the AI solve a recurring task exactly the way you want it solved, every time, without re-explaining yourself.

Technically, a Skill is just a folder with one file, SKILL.md, plus optional helper files (scripts, templates, reference documents). The file has two parts: a short YAML header the AI uses to know when the skill is relevant, and an instructions section explaining how the task should be solved. The format was created by Anthropic and is now an open standard supported by Claude Code, Claude.ai, Claude Cowork, and several other AI tools.

Notice the structure: the skill does not say "be a good engineer". It locks in a concrete, repeatable working pattern you already know works. That's the difference between a Skill and a regular prompt: a prompt is forgotten when the conversation closes, a Skill sits ready the next time someone needs the same task solved.

1. 01

   Pick one task you do often

   Don't start broad. Take one concrete, recurring task from the workshop's workflow mapping, something you can describe in three sentences.

2. 02

   Write down today's best practice, step by step

   What does the sharpest person on the team do differently from everyone else when solving exactly this task? That's what goes into the skill.

3. 03

   Ask the AI to build the skill with you

   You don't need to write the YAML format yourself. Describe the task in plain language and ask Claude to structure it as a Skill (Anthropic's official skill-creator does exactly this).

4. 04

   Test it on a real case, not a made-up example

   Run the skill on an actual case from last week. Check whether the result is something you'd genuinely send onward without editing.

5. 05

   Share it with the team, not just yourself

   A Skill that only sits with one person saves one person time. Shared across the team, the same quality level becomes the standard for everyone, not just the sharpest person.

2. Get the AI to remember your company: CLAUDE.md

Skills solve individual tasks. But you also want the AI to remember things that apply across everything: how you write, which systems you use, what's forbidden without approval. That's the job of a CLAUDE.md file: a simple text file the AI always reads first, in every project or every conversation.

Five rules that actually make a difference, drawn from Anthropic's own recommendations and established community practice:

• Keep it short. Under 200 lines is recommended, and some teams manage with 50–60. Anything over ~300 lines and the AI starts losing precision because the instructions drown in noise.
• Be specific, not general. "Write clearly" helps nothing. "Always use a table for numeric comparisons, never prose" is something the AI can actually follow consistently.
• Only write what applies everywhere. Rules that only apply to one project belong in that project's own file, not in the main file every other task also has to read through.
• Don't over-structure. One good file beats five nested subfolders of rules overriding each other.
• Use HTML comments for notes to humans. <!-- like this --> gets stripped automatically before the AI sees it, so it's safe for internal explanations without spending the AI's context.

3. Memory and context drift

Most modern AI tools now have some form of memory: information carried between conversations without anyone pasting it in again each time. Used well, it saves enormous amounts of time. Used badly, it fills the context with stale information the AI never checks is still true.

• Save decisions and preferences, not raw data. "We always use 14% employer tax in calculations" is good memory material. An entire report pasted in "just in case" is not.
• Never put sensitive information in memory. Passwords, personal ID numbers, contract terms under NDA: these belong in access-controlled systems, not an AI memory.
• Clean up memory regularly. Old, conflicting notes are the most common reason an AI suddenly "forgets" something it should have known — because it actually found two conflicting notes and guessed wrong.

4. Check a Skill before you trust it

A Skill is, in practice, code and instructions someone else wrote, given permission to steer how the AI behaves. That makes it useful, and it makes it a real attack surface if you download one from an unknown source. Independent reviews have found malicious content in a non-trivial share of publicly shared skills, ranging from data theft to backdoors.

Use a Skill security tool before installing anything from outside your team, for example NVIDIA SkillSpector or a similar community skill-scanning tool. They check for hidden data collection, prompt injection and other suspicious patterns, and give you a concrete assessment before the skill gets access to anything.

5. 20 tasks, 20 tools

These are the most frequent tasks we see engineers and technical teams actually use AI for, with the tool or type of Skill we'd recommend for each. Some are official Anthropic skills, some are well-established community skills, some are tools you probably already have access to, and some you should build yourself in the workshop.

"Official" means a skill published by Anthropic itself. "Community, established" means an openly shared skill with significant use and a good track record — but review it yourself with a security tool (point 4) before adopting it. "Existing tool" is not a Claude Skill, but something you probably already have access to.

Next steps

You've now identified a concrete opportunity in the workshop, and the tools above to actually do something about it. Two ways forward:

• Test internally. Take the pilot brief from the workshop and the skills you built, and see how far the team gets on its own over the coming weeks.
• Build the pilot together with ETD. We'll help you take the selected use case further into a working prototype, with the same quality assurance as the rest of our deliveries.