Module 2 · Tools, Knowledge, Memory & Research Design · scripted

Exercise: Build a Skill

40 minoutcomes: tool-design, context-engineering, knowledge-systems

The goal: onboard one brilliant employee

You have just seen what a skill is: the folder handed to a brilliant employee on their first day. Now build a real one — for a recurring task in your own research world. Not a toy: pick something you actually do more than once and wish you never had to re-explain. Coding a transcript against your scheme. Writing the recruitment email for a study. Reviewing a manuscript with your field's checklist. Turning raw instrument output into the table your papers use. If you have explained it twice to a student, it's a skill.

What you are building

your-skill/
SKILL.mdname + when-to-use + a table of contents
references/knowledge to READ (your scheme, your checklist)
scripts/steps or code to RUN (only if truly warranted)
assets/things to USE (a template with placeholders)

The test of success: a fresh conversation that has NEVER met you completes the task with nothing but this folder.

Where to build it

Open the Skill Builder → — an agent interviews you about the task and writes the package with you: it drafts, you correct, the files appear in the tree as you talk, and you can download the finished skill as a zip. The Agent tab shows exactly how that interviewer works, if you want to peek. Prefer an LLM of your choice? Ask it to interview you one question at a time about a task you want to package as an agent skill, then write SKILL.md plus supporting files in the standard layout — and assemble the folder yourself.

The interview, flipped

You are not writing documentation. You are being INTERVIEWED by the future employee's advocate:

"What do you actually do first?"
"You said 'clean the data' — what does clean mean here?"
"What does a finished one look like? Can I have a real example?"

Answer concretely. Every vague answer becomes a stumble on someone's first day.

Step 1 · The catalog line

Before any content: the name and the description — the one line the agent reads while deciding whether to open your folder at all. Write it trigger-style ("Use this skill when…"), and add a counter-example only if you can name the actual neighbor it disambiguates from. Then stress-test it: give the line to the Skill Builder agent (or your LLM) with three task descriptions — one clearly inside, one clearly outside, one borderline — and ask which ones it would open the skill for.

Capture — end of Step 1

The catalog line, verbatim: name + when-to-use description.
The borderline task, and whether the line routed it correctly.

Step 2 · The package

Build the body through the interview. Keep SKILL.md a genuine table of contents — pointers, not payload — and push the weight down into the folders: at least one reference (the knowledge you'd hand a newcomer), one worked example (a real input with its real finished output — examples are the facet your field most neglects), and one template with placeholders (the starting point that carries your structure). Add a script only if the task genuinely warrants one — remember the substrate: your employee has eyes and judgment, not just a shell.

Capture — end of Step 2

Your SKILL.md, verbatim.
The one decision the interview forced that you would never have
written down on your own — the "what does clean MEAN here?"
moment.

Step 3 · The acid test

Now the first day actually happens. Open a fresh conversation — one that has never met you — hand it only the skill and a task, and watch. In the Skill Builder, start a new chat and point it at your saved skill; with your own LLM, upload the zip to a clean session. Do not coach. Where the employee stumbles, resist the urge to answer in chat — that fix evaporates when the conversation ends. Fix the folder instead, and run the test again.

Capture — end of Step 3

Where the fresh conversation stumbled on its first attempt.
Which facet was missing — knowledge, example, template, steps,
or the catalog line itself.
The file change that fixed it, and what happened on attempt two.

Deliverable

Three captures plus the skill itself (the zip, or the folder). At the end we compare: the catalog lines read aloud as a catalog — would you know when to open each other's skills? — the interview moments that surfaced knowledge people didn't know they had, and the acid-test stumbles, tallied by facet. The tally is the point: it is a map of what our fields leave undocumented.

As you compare
  • Whose acid test survived attempt one? What did their folder have that yours didn't?
  • What did you fix in the FOLDER that you were tempted to fix in the CHAT — and why does that difference matter for the next hundred first days?
  • Look at the catalog as a whole: which two skills would an agent confuse? Whose counter-example earns its place?