Skills
A skill in GARS is a wrapper around one pipeline or one analysis step. Each has a SKILL.md in the format ClawBio's skills use (the same metadata.openclaw block) and one small Python file that checks the inputs before anything runs, writes the run files, and afterwards checks the outputs by their content. Each is pinned twice: to one version of the pipeline or tool it runs, and by the hash of its SKILL.md, with a review status; GARS's pin check refuses a skill file that is unreviewed or has changed.
How a new skill gets in
- A content gate. The scaffold will not generate a wrapper until its spec marks the output whose content must show every sample came through. A check that a file merely exists once passed a complete results table whose identifier column had been silently dropped.
- A lint that is tested itself.
conformchecks a wrapper's shape: one module, the standard library only, the three verbs, the exit codes, the outputs registered, theSKILL.mdcomplete. Every shipped wrapper passes this shape check, as a test in GARS's suite, and most of its rules are mutation-tested: break one on purpose and the lint must fail. - One number checked against something outside the wrapper. A published result, a second implementation, or a plain calculation from the same inputs, with the comparison written down. This one is a checklist step for the skill's author, not code: in the authoring guide's words,
conform“cannot prove the answer is right.”
The method is written down in decision 0040.
Why the third step exists
GARS first ran ClawBio's RNA-seq skills, and decided to replace them with its own wrappers after three recorded defects. Checking the replacement found a fourth, silent like the third. Checked against fold-changes computed directly from the normalized counts, the ClawBio skill's published fold-changes correlated 0.330; the wrapper that replaced it correlates 0.992. One gene with an adjusted p-value near 1e-12 was reported as a 1.04× change when the change in the counts was about 70×.
That skill carried its library's highest maturity tier and passed its own CI: its tests checked that the code did what its author wrote, not that the answer was right. GARS reported the defects upstream, where both issues are now closed (ClawBio#333, #365).
The numbers and the comparison: decision 0029, “Numerical validation”; the maturity tier and the CI: decision 0040.
There is no shared community repository of GARS skills yet. The 10 wrappers live in GARS's own repository, and no skill from outside it has been contributed. A shared registry is on the roadmap.
The registry
Skills are how stage 02 stays rigorous. Each one is a closed contract — what it consumes, what it produces, what it needs — checked before dispatch, so the agent routes work instead of improvising it. A lab can register its own in-house analysis as a skill, which is then dispatched, checked and refused by the same machinery as the built-ins. What registering takes is the authoring toolkit's own five-step list, given below: it includes a row in a markdown map and a row in a Python module.
Maturity, skill by skill
Every skill the registry lists, in every assay, with the recording step, test or registry row its label rests on; the rule, and the commits it is read at, are in the line at the foot of this page.
consumes
produces
maturity
verified by test
Write your own — in-house analysis, dispatched like the built-ins
The map above is not a menu, it is a registry, and a lab can add to it. The authoring toolkit scaffolds one directory — a SKILL.md and one script — and then prints five next steps for its author, which are, in its own order:
- Fill every
TODO(author)in the script — they mark where judgment is genuine. - Paste the rows it prints into
workspace.PIPELINESand_references/assay_stage_skill_map.md. - Write the sub-stage
CONTEXT.mdagainst_references/contract_standard.md's eight sections. - Run
conformon the wrapper directory until it passes. - Add an offline test to
tests/run_tests.py, then a real-profile testrun.
workspace.PIPELINES is Python: a dictionary in gars/_system/workspace.py, so step 2 is one change to code and one to the markdown map. A registered skill is dispatched like the nf-core wrappers: preconditions checked before dispatch, outputs declared in the closed vocabulary, refusals when a consumed type is not yet available. A recording of this road, an in-tree one, is withdrawn from this site for now.
The router refuses to dispatch any skill until its consumed types exist.
A skill kept outside the GARS tree: what works today, and what does not
There is a second road — a skill kept entirely outside the GARS tree, on $GARS_WRAPPERS — and the toolkit that scaffolds one is public at the commit this page is generated at: gars/_system/authoring@d6963f7. The variable is overridable at that commit, d6963f7 — gars-env.sh exports it as ${GARS_WRAPPERS:-…/wrappers}, so a value exported beforehand wins — and two limits go with it. There, 0 of the 10 published sub-stage contracts invoke a wrapper through the variable; the rest give a literal in-tree path in the command they run. 10 of 10 do name the wrapper through the variable in the same file, under Inputs — so exporting it is not inert, it is worse: the contract declares your copy as the input while the command runs the vendored one. And the registry row still lands in a file inside the tree that a workspace session is denied writing, so the toolkit prints that row for a person to paste. A worked out-of-tree example is not published yet, so this page names none. What a clean clone at that commit does let a reader check is the toolkit itself: its scaffold run on the published example_spec.json, then conform on the result, and the engine's own SkillAuthoringTests. A scaffolded skill carried through registration and dispatch is not published.
The commands, from gars/_system/authoring, at that commit:
python3 create_bioinformatics_skill.py scaffold --spec example_spec.json --out ./scaffold-check python3 create_bioinformatics_skill.py conform ./scaffold-check/nfcore-myassay-wrapper
And the authoring tests alone, from the root of the clone:
python3 tests/run_tests.py SkillAuthoringTests
What an engine update does to a skill registered either way. The engine keeps no upgrade command: decision 0016 removed it, and updating a workspace is git pull. Decision 0022 lists _system/ and _references/ among the template directories that are “updated by git pull, never by a session”, and decision 0040 calls the skill map a shared, reviewed file. The toolkit's five steps can touch an in-tree skill's wrapper under _system/wrappers/, the PIPELINES row in _system/workspace.py, the map row under _references/, the sub-stage directory under gars/02_bioinformatics/<assay>/ that holds its CONTEXT.md, and the test under tests/; an out-of-tree skill's rows sit in the same two files. Either way, registering is a local change inside directories the engine's own updates also change, so each pull meets it as ordinary git work in the lab's checkout. None of the three decisions describes a step beyond that.
Generated from GARS's own references at commit d6963f73291b (committed 2026-10-03), an ancestor of the public repository's main, so these references are browsable there. Ancestor, not head: main moves, and a page claiming headship goes stale the next time anything lands on it. The live lane runs an older commit, and the two projects on the memory page name the commits their runs cite; this page reads neither. Not hand-maintained: a page that could drift from the system it describes would eventually lie about it — and it did once, for four days, missing the two modalities v2 added; regenerated since. The assays, sub-stages, skills, sources, types and requirements are read at GARS commit d6963f73291b, on the public repository's main branch; a registry-only cell links the skill's row in the map at that commit, and a recording's step counts only while the skill's wrapper files are byte-identical at the recording's engine commit and at this one. The maturity cells read the engine's tests at the same commit, d6963f73291b; each test id prints it, and each recording step prints the engine version in that recording's own header. A skill's label is the first that holds: demonstrated, when a shipped recording's step carries a sub-stage STATUS reading COMPLETE, written during the recording by that skill's wrapper collect or verify; the test label, when a test at the evidence pin runs the wrapper on a fixture it builds and asserts on the wrapper's output, and a test that skips without an installed pipeline does not count; registry-only otherwise. Every receipt and test found is listed, not only the one that decides.
How GARS is built — and why it holds
GARS is a filesystem agent for genomics built on one division of labor, learned the hard way and written into every layer: the agent orchestrates, code computes. The checks that protect the science — the helpers that refuse bad inputs, validate a design and write each sub-stage's STATUS — are deterministic, tested code; what the agent adds is a governed natural-language operating layer — intent routing, gate-keeping dialogue, and a procedure that is enforced, not merely documented.
The methodology: contracts, not vibes
Every stage is a markdown contract the agent executes literally: scope boundaries, fixed response templates, human gates at the decisions where science lives. State is the filesystem itself — numbered stage directories, STATUS files as the single authority, machine-owned files at mode 0444.
advantage
A procedure in a wiki gets skipped under pressure; a contract hands the steps the science depends on to helpers and branches on their exit codes — the stage-02 wrappers run a preflight, and each sub-stage's helper writes its own STATUS — and the fixed templates make “what did the operator actually do” answerable after the fact. The run's history is kept partly by hand: stage 00's helper writes its own dated entry, and from stage 01 on the contract has the agent append the entry the helper prints. Resumability and auditability come free with the filesystem — no server and no database; the data stays wherever the workspace sits. An unconstrained agent, by contrast, has receipts here: in early live tests one analyzed a colleague's unrelated experiment and another deleted 112 symlinks to satisfy a validation rule — written up in the decision records that produced the negative scope and the data model (decision 0002, 0003).
Bioinformatics skill wrappers: pipelines that cannot half-run
Each assay runs through a GARS-authored wrapper on one shared core (wrapperlib.py): preflight check that refuses bad inputs before a cent of compute, an audited params.yaml, a generated submit.sh with a requeue guard, and a collect exit gate that checks content, not existence — every sample must appear as a column of the merged matrix, or the run does not pass.
advantage
The wrappers read facts (samplesheet columns, parameters, output paths) from the pinned pipeline checkouts rather than from memory, and validation is numerical. That discipline caught a real upstream defect before retirement of the old dependency: a published DE table whose fold-changes correlated 0.33 with the actual data (the GARS wrapper's: 0.99) — a gene at padj ≈ 1e-12 reported as a 1.04× change that was really ~70× (decision 0029). Silent defects like that pass every “file exists” gate ever written.
Custom skills: in-house methods become first-class citizens
A lab's own method gets the same machinery as nf-core: the skill-authoring toolkit (create-bioinformatics-skill) scaffolds a wrapper from a spec, a conform linter checks it against the wrapper rules mechanically, and the result runs through the same doors — preflight, executor, exit gate, provenance.
advantage
Extensibility without losing governance. In most frameworks a custom script is where rigor ends; here it is where the same rigor begins. The custom-analysis stage (03) adds the missing piece for one-off work: it opens an analysis PLAN as a reviewable file, and its contract has the run stop at that gate for a person before the analysis runs; verify then checks the outputs against the plan and records each by type. (The recording that showed this stage is withdrawn for now; see the recordings page.)
Memory: multi-project state a person can walk away from
GARS's memory is the workspace itself, kept legible by code: a generated per-project index, per-assay progress (project_state.py renders how far each project got, which scientific decisions are still unmade, and the last HISTORY entries — at every session boot), append-only HISTORY.md with the template and model version stamped per stage, and an artifact registry that resolves inputs by type (counts_gene, de_results) rather than by remembered paths.
advantage
A bioinformatician running many projects resumes any of them cold — or hands one to a colleague — because the state is readable without the person who left it. Web platforms offer this with servers and data movement; GARS does it local-first, where the data already lives, with nothing to host — a design none of these recordings shows running on a cluster.
The demo is candid about its limits: the analysis rigor comes from nf-core and deterministic code, the agent's contribution is the governed interface — and the recorded runs on this site are the evidence, not a claim. Where a recording's own narration overreads its table, the reading note beside it says so; the recordings themselves are never edited. the notes →
How a run works
The same language as the replay: emerald is the agent, amber a gate, red a refusal, sky a person.
the filesystem is the state machine, the model is the navigator
- stage contract
- A markdown file the agent executes literally: what the stage may touch, the shape of the reply it must give, and the gates it may not pass. This site serves the ones the recordings ran under, from the runtime it vendors.
- helper
- A small program the agent runs instead of doing the work itself. Its exit code refuses the step or lets it continue, which is what puts the refusal below the model rather than inside it.
- wrapper
- The code that runs one assay's pipeline, usually an nf-core pipeline: it checks the inputs before any compute, records the parameters it used, and holds an exit gate that reads the contents of what came back rather than checking that a file exists.
- receipt
- The thing a number points back at — a job id, an object key and its ETag, or a recording's own event log — so a figure on this site can be followed to the artifact it was read from.