Working up a project to get liquid handler methods in PyLabRobot generated with Claude Code. Just by referencing the PLR code base and then user specifics (machines, resources, etc), this is already pretty doable and has been with previous LLMs/agents. I’m wondering if anyone has any tips or lessons learned from stuff they have done so far, like particularly helpful CLAUDE.md instructions or Skills. This is more for the lab user side versus development.
just this “basic” setup is already super powerful for us, especially when you run claude in the directory that also contains the existing protocols / data management systems.
that said, I have worked with biomni (https://biomni.phylo.bio) to create a PLR tool in their system, which has some more specialized prompts. I haven’t really compared them side by side because the benefit of it having access to our local code outweighs the custom prompts in biomni.
Also, I was talking to Elnora which actually runs inside Claude Code and adds more scientific tools. It doesn’t yet have specialized tools for PLR, but might help with scientific understanding.
I am completely amazed by how good the claude models are. 1+ to Rick’s comment, if you run it in the PLR directory with examples, it can figure out a ton. We were trying to do this 2 years ago with ChatGPT and never got it working. Now claude can just figure it out.
I would say that pulling the docstrings for the aspirate, dispense, etc. functions into the Claude.md (or a specialized protocol_creation_instructions.md) and creating a labware_library.py file for the specific labware you use is helpful. Also, because the setup is generally static (ie carrier locations) - providing the import and setup header makes it so the generated scripts are consistent and you don’t have to spend time and tokens going over that every time.
Rick - is it possible to enable the forum’s upload feature to accept .md files?
2 Likes
done
Thanks Rick!
So I ran a little test to see if an instructions file actually helps.
I gave Claude this prompt with and without the protocol_generation.md file (and clearing the context right before each time):
use the @keyser-testing/protocol_generation.md instructions, create a protocol that does the following:0. Setup = Tecan Evo, 8x AirLiHa, MP3_Pos carrier on rail 16, 50uL SBS DiTi tipbox on carrier position 2, Eppendorf 96well 250uL Vb on position 1 as destination, Eppendorf 96well 250uL Vb on position 0 as source
-
Perform a 1:5 serial dilution in columns 1-6 of the source plate (50uL of the compound in DMSO is in column 1, 40uL of DMSO is in columns 2-6) -
Transfer 2uL of the diluted compounds into the destination plate. Create replicates in columns 1 and 7, 2 and 8 etc. The destination plate has 98uL of assay buffer already.
Write the protocol to a python file in the keyser-testing directory.
protocol_generation.md (14.8 KB)
The output is nearly the same. It uses different syntax, but does all of the steps correctly (didn’t test on the robot yet though).
With the instruction file - it took 1:18 to complete
Without the instruction file - it took 1:43, there was a lot more background searching, but it went pretty fast
I don’t know that this test proves anything other than claude is amazing. Maybe the delta would be bigger with more complex protocols and repeat use. Or maybe just giving it un-biased access to the underlying source is the best way to go.
3 Likes
Wow that is super interesting. Thanks for sharing that instructions file - my instinct is that something like this file will prevent wasting tokens/thinking on the hardcoded stuff (equipment setup w/ carriers and tips, imports). Plus there is still a lot of power in a detailed vs a generic “do a serial dilution” prompt.
I’m also thinking of some Skills that allow users to easily save/back up their new script and associate it with a given experiment or LIMS entities.
Wondering if anyone has translated the firmware reference guides into a skill for Claude etc. I have a janky version which is helpful when inspecting firmware commands sent to the Hamilton.
I tried two ways:
Python script with PyMuPDF
-
Script:
convert_pdfs_to_markdown.py -
It extracts plain positioned PDF text, sorted by page.
-
It adds a document title and
## Page Nheadings, so basic navigation works. -
It fails to reconstruct tables: command, parameter, range, default, and description columns become space-aligned text. Repeated page headers and footers remain throughout.
-
MarkItDown MCP
-
Output:
markitdown-markdown -
It produces cleaner flowing text and reconstructs some command tables as Markdown tables.
-
It fails to create a usable document hierarchy: most guides lack
#/##semantic headings, retain repeated headers/footers, and contain partially reconstructed or split table rows. -
It also does not provide skill routing metadata such as a
SKILL.mdor a module/version index.
-
PyMuPDF preserved navigation but damaged structure; MarkItDown improved structure somewhat but removed navigation and still needs cleanup.
I feel like I’m probably repeating work.,…
for hamilton specifically, we are already very complete so most of what I do is take individual snippets/pages and just paste a screenshot
for other documents, why not just ask codex to read the pdf on your computer? I havent experienced problems with it. astra is able to read it straight from the pdf and probably other models can do it too
also what would this skill do exactly? just information retrieval? that’s already solved
for sending robot commands, the firmware documents a specific layer of that stack but PLR is not just a python translation of it, you need more like resource positioning, command/response reading/sending and matching, knowing the order of commands to send, state, fixing the occasional bug in the fw docs, etc. essentially the reasons @CamilloMoschner is a busy person
2 Likes
I’ll be honest, I am deciphering un-commented fw commands from a third party vendor in Venus, I just thought this might be the place to ask since its a bit more AI forward than the other forum.
We’re parsing traditional Hamilton COM trace logs to understand what has changed between a Hamilton/Vendor supplied library.
Having this as a skill has had a few additional benefits:
- I don’t have to point a firmware guide to get ingested every time it sees a COM log, it either triggers automatically or I start my prompt with /hamilton-fimware and it triggers
- I can share the skill to all my co-workers so that any computer we open, in the lab etc. already has the firmware as a skill and when reading logs it just triggers and knows where to look.
- I think its a bit more deterministic and less prone to hallucinations but yeah parsing .pdf is pretty good
I have the skill pre-install on our vscode instances
lol
1 Like
watching myself buy this 5 years ago