BioClaw: a WhatsApp chat front end for BLAST, PyMOL and PubMed

The problem BioClaw targets: tool switching, not missing tools

The README frames the motivation around fragmentation. Biomedical data, tools and literature have grown faster than any one researcher's familiarity with them, so a person moves between command-line bioinformatics programs, visualization software, databases and literature search engines, often on different machines. BioClaw's answer is to put the entry point in a chat window. You message @Bioclaw in a WhatsApp group, or use the local web UI, and the assistant decides which tool to invoke. The listed capabilities are sequence analysis (BLAST against NCBI databases, BWA or minimap2 alignment, variant calling), quality control (FastQC reports with interpretation), structural biology (fetching and rendering PDB structures with PyMOL), plotting (volcano plots, heatmaps, expression figures from CSV), PubMed literature search, and interpretation of wet-lab images such as gel or blot photos uploaded from a phone camera. Results come back into the same chat as images, plots or structured reports. The intended user is a working group where several people share a workspace and where at least some of them would rather describe the analysis than assemble the command. That is a real audience, and it is narrower than the phrase AI-powered research assistant suggests.

What sits between the chat message and the tool call

BioClaw is TypeScript and is built on the OpenClaw architecture, with the README naming NanoClaw as the specific lineage and the Claude Agent SDK as the model-facing layer. Bioinformatics tools and skills come from the STELLA project. The README does not publish a request-level sequence diagram, so the following is what the repository layout and the command list support rather than a traced call path. A message arrives through a channel adapter (WhatsApp or the local web UI), is associated with a thread, and is handed to an agent loop that selects from installed skill modules. Each skill wraps a tool: a BLAST invocation, a FastQC run, a PyMOL render, a PubMed query. Output is captured and returned to the originating thread. Threads carry their own state. The release notes describe multiple web chats each with its own memory, and a per-thread working directory set with /dir, so two threads can operate in different subdirectories of the workspace without overwriting each other. Commands such as /status, /doctor, /threads, /new, /use, /rename, /archive, /workspace, /provider and /model are handled in chat and manipulate that thread state directly. The agent also has a host-side SSH escape hatch: typing ssh <host-alias> or ssh <host-alias> -- <command> runs the command from the host using aliases you configured outside BioClaw. That is the most consequential design detail in the whole project, because it means the chat interface is not sandboxed to the skill list.

Getting it running: npm, .env, and the OpenRouter check

The README points people who are not comfortable with Docker, .env files, workspaces, allowlists or mounts at docs/BEGINNER_G..., which is where the truncated excerpt stops; the full beginner guide is in the repository. The visible operational surface is npm-based. Configuration lives in a .env file, and the README gives one concrete diagnostic: npm run check:openrouter sends a small test request using the current .env so you can confirm the key works before debugging the application. That single command is worth running first, because a bad provider key otherwise surfaces as a confusing agent failure rather than an authentication error. Provider and model are selectable per thread with /provider and /model, which implies at least two provider paths, one of them OpenRouter. Skills are listed with /skills, and preferred skills can be marked for a thread or agent. Recurring prompts can be saved with /commands and /alias. The README also describes a promotion path for new skills: they can be developed directly in BioClaw or in a separate Bioclaw_Skills_Hub repository used as a staging area, and once stable they may be merged into the main repository, which you then pick up with git pull. That is a plain git-based upgrade model with no package registry in between.

The skill hub split is a governance choice with a cost

Splitting skill development between BioClaw and Bioclaw_Skills_Hub gives contributors a low-friction place to iterate, and the README is explicit that hub skills are provisional and may later be integrated into BioClaw itself. The cost is that the boundary between supported and experimental is defined by which repository a skill currently lives in, not by any versioning or test signal described in the material. The README tells you to git pull to get newly promoted skills and other updates, which means upgrades arrive as unreviewed diffs against your local checkout unless you pin a commit. For a research group this matters more than usual: a plotting skill that changes its default output format between pulls will silently change figures that may already be in a manuscript. There is also no plugin manifest or capability declaration described, so /skills is the only inventory you get. If you run BioClaw for a lab, pinning to the v0.1.1 tag rather than tracking main is the safer default, and the README does not discuss that trade-off at all.

Where BioClaw is the wrong tool

Three failure modes are visible from the material. First, the SSH passthrough. Running ssh <host-alias> -- <command> from a chat box means anyone who can post in the group, or anyone who reaches the web UI, can execute commands on a host you configured. The README mentions allowlists and mounts as concepts a beginner must understand, which suggests some access control exists, but it does not document what the allowlist constrains or whether the SSH path is subject to it. Treat that as unverified and test it before exposing the bot to a group with more than a handful of trusted members. Second, reproducibility. The interface is a conversation; the README describes /commands and /alias as shortcuts for repeated prompts, not as a pipeline definition format. There is no mention of a run manifest, a lockfile for tool versions, or an exported provenance record. If your work needs to be replayed exactly for a reviewer, the chat transcript is not that artifact. Third, the licence. The repository metadata reports NOASSERTION while the README carries an MIT badge and links to a LICENSE file. Those two statements disagree, and the material does not resolve which is authoritative. Do not plan commercial redistribution around the badge alone; read the LICENSE file and, if it matters, get a human to look at it. I am not giving legal advice here, only flagging that the two signals conflict.

How it differs from a notebook-based or pipeline-based approach

The obvious alternative for the same job is a Jupyter notebook with Biopython and a plotting library, or a workflow manager such as Snakemake or Nextflow, depending on whether you want interactive exploration or a re-runnable pipeline. The difference is not the tool list; BioClaw calls the same BLAST, BWA, minimap2, FastQC and PyMOL binaries. The difference is where the state lives. In a notebook, the state is the cell history and the kernel, and it is yours to save as an artifact. In a workflow manager, the state is a rule graph and a set of output files keyed by content, which is what makes reruns cheap and audits possible. In BioClaw, the state is a thread: a memory attached to a chat, a working directory set by /dir, and a set of preferred skills. That is convenient for a group that wants to ask a question and see an answer in the same place they are already talking. It is a poor fit for anything that has to run unattended, be reviewed by someone who was not in the chat, or produce identical output six months later. The honest framing is that BioClaw lowers the cost of the first analysis and raises the cost of the tenth, because nothing in the described command set captures what was done in a form you can diff.

Maintenance cost and what to check before you commit

The upgrade path is git pull against a repository whose skill set is expected to grow, with a second repository acting as a staging area. That is a low-ceremony model, and the ceremony it skips is the one that tells you what changed and whether it breaks your existing threads. Budget for reading diffs, or pin to the v0.1.1 release tag and move deliberately. The v0.1.0-windows-x64 release in April 2026 alongside v0.1.1 suggests the packaging story is still settling; the material does not describe what the multi-platform build covers beyond that tag name, so verify your platform is actually in it rather than assuming. On licence, the repository reports NOASSERTION and the README claims MIT. Reconcile that before you build anything you intend to distribute. The practical first hour with BioClaw is: read docs/BEGINNER_G in the repository, set up .env, run npm run check:openrouter, then send one PubMed query and one FastQC job through a thread before you connect it to a group chat that other people can post in.

Editorial conclusion

Adopt BioClaw if your group already runs BLAST, BWA or minimap2, FastQC and PyMOL on a host you control, and the bottleneck is that people keep asking each other which command to type. Do not adopt it if you need a reproducible pipeline: the chat transcript is the interface, not a workflow file, and the repository carries a NOASSERTION licence even though the README badge says MIT. Before installing, resolve that licence discrepancy against the LICENSE file, confirm the pinned version in package.json matches the v0.1.1 release, and run npm run check:openrouter to verify the OpenRouter key works before you debug anything else.

Official sources

1. Issues
2. README
3. Releases
4. Runchuan-BU/BioClaw on GitHub