Skills — how I work with AI

Skills

The instructions I write for AI agents, the way I organise their work, and the tools I use along the way. This setup keeps changing as I find out what helps and what doesn’t.

Agent skills

Skills I wrote for AI

A skill gives an AI instructions for a particular kind of work. Here are three examples from my projects: a general handbook, a document tool, and a set of agent roles.

max-workflow

Global skill · always available

6 files · 721 lines

The handbook I give agents before they start: what to check, how to divide up the work, and what to leave for the next session.

I keep a short rules file for every session, but a rule like “verify the result” leaves a lot unsaid. This skill fills in the steps, provides templates, and explains why a check is there.

The first step is to decide how much process the job needs. A small fix should stay small. A project that spans several sessions needs enough notes for someone to pick it up without guessing.

Five reference files cover coordination, archiving, sub-agents, choosing skills, and past mistakes. The agent opens them as needed, so a simple task does not begin with reading the whole handbook.

seal-stamper

Project skill · single capability

1 file · 203 lines

A skill for placing a company seal on a contract or spreadsheet, using a company name, a party label, or a specified position.

I wanted the agent to work from the document and the placement instructions without stepping through a menu. The skill finds the right location, then passes it to a single command.

Most of the writing is about the details that are easy to get wrong: how to identify the right party, which placement method to use, and what to check in the result.

A ten-agent team

Agent definitions · one production site

10 agents · 1,412 lines

Ten agent roles for a live commercial site, covering coordination, architecture, front-end and back-end work, testing, research, and design critique.

Each of the three front-end agents takes one interface. Giving them separate areas to work in made it easier to avoid overlapping edits and to see who needed to review a change.

The architect looks after shared code, and I work through a lead agent that coordinates the others. The role files also specify the model and reasoning settings so I can check what is actually running.

File counts and sizes are from September 2026. The source files include local paths and client details, so I share the structure here. Email me if you would like to know more about one. [email protected]

The workflow — four layers

How I keep track of the work

These four parts help me carry a project from one session to the next. The counts below describe the archive as it stood in September 2026.

  1. 01

    The ground rules

    130 lines · loaded into every session

    A short file I load into each session: find the cause of a bug, look for other places it occurs, and run the relevant checks before reporting success. These are the reminders I have needed most often.

  2. 02

    The handbook

    A skill that turns the rules into steps

    The handbook puts the work in order and explains the checks along the way. I add notes when something goes wrong, while I can still remember what caused it.

  3. 03

    The archive

    22 projects · 1,023 notes

    The archive has a familiar place for project overviews, technical notes, daily logs, decisions, coordination, versions, and bugs. When I reverse a decision, I keep the old note and explain the change. That history helps the next session understand how the project got here.

  4. 04

    The coordination protocol

    A shared task board and clear ownership

    Before starting, each agent reads the board, checks for overlapping work, and claims a small piece it can verify. Shared identifiers are reserved in advance. If two claims overlap, the later one gives way. It is a way to make parallel work easier to follow and combine.

Lessons from the work

Things I had to change

The workflow took shape through mistakes. These are a few that changed how I work with agents.

Agree on the agent count and budget first.
One session launched four rounds of parallel work: around twenty agents and roughly 7.13 million tokens. It used ninety percent of a week’s budget in an afternoon. Two rounds stopped halfway, leaving changes that had not been checked. That led me to require an agreed count, estimate, and model before a large run.
Check which model will run.
In one setup, leaving the model field empty used a different default from the one I expected. I noticed only after reviewing the work. Now I check the settings instead of assuming that a sub-agent inherits them.
Run the check before saying it passed.
A confident “fixed” is hard to trust when the check has not been run. I want the result and its limits in the handoff, including anything that still needs testing.
Finish the agreed task and make scope changes explicit.
A bug can show up in several places, so I ask agents to search for related cases. If they find a separate problem, it belongs in a note or a new task. I need to be able to review what changed and why.
Leave a way to check the current state.
Handoffs with a commit hash but no way to check it went stale between sessions. Work was missed three times in two days. I now include both the observed state and the command that lets the next session verify it.

Toolbox

Tools I use

The tools and techniques behind these projects, with a rough self-assessment of my familiarity. Each group links to an example.

Depthlearningworkingfluentfluent in 12 · working in 8 · learning 0

AI & agents

Writing instructions, dividing up work, and checking what the agents produce.

see the work
  • LLM agents & toolingfluentplanning work across agents, keeping shared records, and checking results
  • Prompt evaluationworkingkeeping versions of instructions and comparing the results
  • TypeScriptfluentcomponents, data, and application logic across this site

Sound & DSP

My own tracks, and the player, effects, and audio analysis behind the Sound page.

hear it
  • Compositionfluentwriting and mixing my own tracks in FL Studio — the finished tracks, demos and samples on the Sound page
  • Web Audiofluentbrowser playback, effect routing, and AudioWorklets for real-time processing
  • Time-stretch & pitch (WSOLA)fluentthe DJ console’s key shifter, processing audio in 128-frame blocks
  • Algorithmic reverb (FDN)workingfeedback-delay networks for the player’s reverb effect
  • Spectral analysis (FFT)fluentoffline precompute, spectrograms, onset and BPM detection
  • Audio library toolingworkingtranscoding, analysing, and publishing tracks to the self-hosted library

Graphics & motion

The opening painting, page transitions, and visuals that respond to sound.

see the homepage
  • WebGL / GLSLfluentpainting effects, transitions, and visuals that respond to audio
  • Three.jsworkingscenes, textures, and custom materials
  • GSAP & ScrollTriggerfluentscroll animations, page transitions, and moving type
  • Generative artworkingusing code to make changing patterns and images
  • Creative codingfluentsmall visual experiments that grow into parts of the site

Web & infrastructure

Building pages, publishing them, and keeping the site running.

read the log
  • React & Vitefluentpage components, route loading, and the production build
  • Node & build toolingfluentimage processing, prerendered pages, feeds, and API catalogs
  • Cloudflare Workersworkingrequest handling and OAuth 2.1 authorization for agents
  • Linux, Caddy & tunnelsworkinghosting the site at home, with a way to roll back a release
  • Media pipelines (ffmpeg)workingpreparing audio files and analysis data for the player
  • Performance & accessibilityfluentchecking contrast, supporting reduced motion, and making controls easier to use