Every time a new batch of data arrives, you do the same thing: open the
files, clean the columns, run some statistics, copy the results and make a
nice plot. You have been meaning to write a script for months, but the data
format keeps changing slightly between batches, the edge cases are annoying,
and writing the script from scratch feels like its own project. So you keep
doing it by hand.
With agentic AI, you'd walk the model through your workflow once. What does
the raw data look like? What do you do first? What gets cleaned, what gets
computed, what format does the output need to be in? Talk it through an
example. It writes a script in Python, R, or whatever you use that
replicates your workflow end to end. You run it on your most recent data,
compare the output to what you would have produced by hand, and tell if
there is anything to fix. Once it matches, you save the workflow.
From then on, every time new data arrives, you run the agentic script
instead of doing it manually. If the data format changes later on, you
describe what changed and the model updates the script. And because the
script is documented and reproducible, anyone in the lab can run it, not
just the person who knows the workflow by heart.
This workflow really needs the power-user setup.
Let's walk through an example in biology. Say your lab measures
something on a plate reader every week: a grid of small wells, each
holding a sample, each giving back a number (absorbance,
fluorescence, luminescence, whatever the assay). The machine spits
out a CSV and you email it to yourself or drop it into a shared
folder.
That CSV is where the weekly pain starts. The column headers shift
depending on who ran the export. Sample IDs come through with stray
whitespace. Some wells failed on the reader and show up as blank
cells, "OVER", or "NaN". Before you can look at results, you spend
an hour cleaning it up, subtracting the blank wells, normalising
each sample to the positive control, and dropping a summary into
the lab's Slack. You want to stop.
First, ask Claude to find what already exists
Before you write anything new, ask Claude to look on GitHub for
skills other people have already built for this kind of work. If
someone has packaged plate-reader cleanup and control-normalisation
as a skill, forking it is faster than rebuilding from scratch.
Prompt: scout GitHub for existing skills
I run a weekly assay on a plate reader and need to clean the export CSV, subtract blank wells, normalise each sample to the positive control, and produce a tidy summary table. Before I write anything new, look on GitHub for open-source skill packs or Claude Code skills that already handle plate-reader data or similar weekly bench-data workflows. Rank the top few by fit, tell me how many stars each has and how recently it was updated, and for each name the one or two skills closest to what I need. Do not install anything yet.
You will typically get back a ranked list with repos like GPTomics'
bioSkills
or K-Dense-AI's
scientific-agent-skills
near the top. A high star count is a decent first-pass signal: if a
skill pack has hundreds of stars, other researchers have found it
useful enough to keep. Do not be put off by these living on GitHub
rather than in a packaged tool. Pulling a skill out of a public repo
into your project's .claude/skills/ is one line in the
chat panel, and it is something Claude Code does all the time.
Promote your one-off prompt to a SKILL.md
The prompt that produced your working plate-reader analysis is
valuable because it spells out the exact column names, which wells
are blanks, which is the positive control, and the output format
that matter for your workflow. Don't let it die in a chat
transcript. Move it into a SKILL.md with YAML
frontmatter so Claude Code registers it as a first-class slash
command you can invoke by name.
Prompt: turn the prompt into a reusable skill
Turn the prompt I've been using to clean and analyse my weekly plate-reader CSVs into a reusable skill at .claude/skills/plate-weekly/SKILL.md.
The weekly job: read the raw CSV from data/raw/, normalise column names, strip whitespace from sample IDs, flag failed wells (blank, "OVER", "NaN") in a new column rather than drop them, subtract the mean of the blank wells, normalise each sample to the positive control, write a tidy summary to data/processed/, and append one row to analyses/plate-reader/00-stage-summary.md with the date and the three samples showing the biggest change from the previous week.
Frontmatter should declare name, description starting with "Use when...", allowed-tools (Read, Write, Edit, Bash), and argument-hint for the input CSV. Keep any helper script in the same folder so the skill is self-contained.
Fire the skill automatically when a new batch lands
Skills handle "when you ask." Hooks handle "when the data arrives." A
PostToolUse hook in .claude/settings.json
with a filePattern matcher will run /plate-weekly every time a new CSV lands in data/raw/. Hooks are run by the harness, not the model,
so the rule fires deterministically: drop the file, get the summary.
Prompt: add a PostToolUse hook
Wire up a PostToolUse hook in .claude/settings.json so the plate-weekly skill fires automatically when a new batch lands. Match Write events against the path pattern data/raw/*_plate.csv and run /plate-weekly on the new file. Confirm the JSON parses and explain in two lines what will and will not trigger the hook so I don't get surprises.
Carry memory across runs with a tree of markdowns
The hardest part of scaling a recurring analysis is not running it
once: it is remembering what happened across dozens of runs without
blowing out the context window. Keep a single 00-stage-summary.md at analyses/plate-reader/
plus one detail file per batch. Each invocation reads the stage
summary for context, runs the analysis, writes a per-batch file, and
appends one row to the summary. By week four, the skill can tell you
when this week's top-changed samples look unlike any of the past
three weeks and worth a second look.
Prompt: build the state tree
Set up a tree-of-markdowns state architecture for the plate-reader workflow so runs accumulate knowledge across weeks.
Create analyses/plate-reader/ with:
- 00-stage-summary.md: short header and a table of past runs (date, input file, three biggest changes from the prior week, anything anomalous)
- one batch-<date>.md per run with the full per-run detail
Update the plate-weekly skill so every invocation reads 00-stage-summary.md first for context, runs the analysis, writes the per-batch detail, and appends one row to the summary. Next week's run should know what last week's run looked like and flag unusual changes without me reminding it.
Commit the skill so the rest of the lab can use it
The skill folder is just a directory in your project. Commit it to
your lab's shared repo and a collaborator can clone it, drop their
own plate-reader export into data/raw/, and get the
same behaviour on their own assay, with their own stage summary
building up in parallel.
Prompt: package the skill for sharing
The plate-weekly skill is working on my data. Get it ready to share with the rest of the lab.
- Add README.md to the skill folder: what it does, what input it expects (CSV schema), what outputs it produces, and which parameters someone might tune (name of the positive control, name of the blank wells).
- Make sure nothing in the folder hard-codes a path to my machine.
- Stage .claude/skills/plate-weekly/ and the analyses/plate-reader/ scaffolding (without the raw data) and write a commit message explaining what the skill does and how to invoke it.
A collaborator should be able to clone the repo, drop their own plate-reader export into data/raw/, and get the same behaviour on their own assay.