After the AI workshop

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

This isn't a list of AI prompts. It's the concrete tools, Skills and habits that make what you learned in the workshop actually stick — week after week, not just the day we were there.

Reading time: ~18 min Audience: engineers and technical teams Prerequisite: access to Claude (the Skills feature)

Why this document exists

Most "AI workshops" end with an idea list nobody acts on. This page is meant to be read after the workshop, by you, and actually implemented in your day-to-day work. Everything below is something we actively use ourselves, not theory.

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.

--- name: offset-well-comparison description: Used when someone needs to compare historical well data before a recommendation. Triggered by "offset well", "compare wells". --- # Offset well comparison When you get historical well data, always do this: 1. List the wells in a table: date, depth, parameters. 2. Flag deviations >10% from the average, with a source reference. 3. Write a short recommendation, mark uncertain numbers clearly. 4. Never strip source references, even if the answer gets long.

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.

Tip

Before building a skill from scratch: check whether someone has already made a good one. There are large, curated collections of ready-made Skills (including Anthropic's own anthropics/skills collection and community collections like ComposioHQ's awesome-claude-skills). Reusing a proven skill is almost always faster than polishing your own from scratch — see point 4 for how to check it's actually safe first.

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.
Practical trick: detect when the AI has taken on too much context

A long, technical conversation over time fills up the context window, and quality degrades gradually without it being obvious. A simple trick: add a standing instruction that the AI should always start every reply with a specific phrase, for example "here's my answer, [your name]".

As long as the phrase (and the name) comes through correctly every time, the AI is still actively following instructions. If it starts forgetting the phrase, forgetting the name, or suddenly replies in a different language than the conversation, that's a reliable signal it's lost sharpness, and you should start a new session instead of pushing on in the same one.

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.

Two good reasons to use a tool like this

1) You're wondering whether a skill you found is safe to use. 2) You're considering building something yourself, but want to first know whether an established, vetted skill already does the job, so you don't reinvent the wheel.

5. Connect the AI to the systems you already use

So far we have talked about giving the AI good instructions. The next step is giving it access to the information. A connector links the AI tool directly to a system you already use, such as Jira, Confluence, SharePoint, Google Drive, GitHub or a database. Instead of copying and pasting, the AI can search, read and pull the information together itself when you ask.

Most connectors are built on MCP (Model Context Protocol), an open standard Anthropic launched in 2024 that is now supported by most major AI tools. Claude has ready-made connectors for Atlassian (Jira and Confluence), Microsoft 365, Google Drive and GitHub, among others, and you can build your own for internal systems.

What it makes possible

  • Finding things in a large organisation. "Have we solved a similar problem before?" is hard to answer when the answer is spread across hundreds of Confluence pages and thousands of Jira issues. With a connector, the AI can search across them, read the relevant issues and give a summary with links to the sources.
  • Analysing data. Give the AI access to a spreadsheet, an export from a business system or a database, and ask it to find trends, outliers or relationships. It can calculate, make charts and explain what it found. Ask it to show its calculations so you can check them.
  • Making better decisions on a solution. Before you choose a technical solution, the AI can pull earlier decisions from Confluence, known problems from Jira and relevant requirements, and set the options against each other with pros, cons and risks. You still make the decision, but on a better basis.
  • Keeping track of projects. "Which issues in this project have been stuck for more than two weeks, and why?" is something the AI can answer directly from Jira, instead of someone going through the board by hand.
Before you connect anything

A connector uses the login of the person using it, so the AI only sees what that person already has access to. Still, start with read access rather than write access, and agree with IT which systems and which data can be connected. Always ask the AI to link to the sources it used, so you can check that the answer is right.

6. 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.

TaskRecommended toolType
Finding information scattered across Confluence/JiraAtlassian connector in Claude (see section 5) or Atlassian RovoExisting tool
Stress-testing a technical decision before you commit"grill-me" skill (asks critical questions until you have a shared picture)Community, established
Writing meeting notes from a transcript or bullet pointsA custom skill with a fixed template per meeting typeBuild in the workshop
Code review before mergingBuilt-in code-review skillOfficial
Systematic debugging of a bug or deviationSystematic-debugging skillOfficial
Security review of code or changesSecurity-review skillOfficial
Structuring a technical plan before you buildWriting-plans / brainstorming skillOfficial
Creating or editing Word documents (contracts, reports)Anthropic's docx skillOfficial
Creating or cleaning up Excel sheetsAnthropic's xlsx skillOfficial
Creating presentationsAnthropic's pptx skillOfficial
Reading and analysing PDFs (specs, contracts)Anthropic's pdf skillOfficial
Building your own reusable AI recipesAnthropic's skill-creatorOfficial
Checking whether a skill is safe before installingNVIDIA SkillSpector / skill-security-scanExisting tool
Visualising data as charts or dashboardsDataviz skillOfficial
Drawing architecture or process diagramsArtifact-diagramming skillOfficial
Having a finished report waiting each morningClaude Cowork on a fixed scheduleExisting tool
Working on several parallel technical threads without mixing them upUsing-git-worktrees skillOfficial
Getting a critical second opinion on your own work before deliveryRequesting/receiving-code-review skillOfficial
Keeping the AI consistent across sessions and projectsCLAUDE.md + memory architecture (see points 2–3)Own practice
Cleaning up a memory that's become messy over timeAnthropic's consolidate-memory skillOfficial

"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.

Ready to discuss the pilot further?

Get in touch