Foundry Q & A
← The Foundry Pattern · August 13, 2026 ↗
The questions
"Missing” is two different failures
The discover-or-author branch
The Tool Shed’s lexical index does not reliably match an underscored tool-id token. integron_finder returns
nothing; integron finder and integron both score.
So the skill derives query variants first — strip the owner prefix, split on _ and -, try the bare
significant word. A no-hit on the raw token alone is a search artifact, not evidence the tool is absent.
This is exactly the kind of caveat that rots in a hand-written skill and survives in a note that many Molds cite.
Every cast declares its own tools
{
"tool": "gxwf",
"origin": "npm",
"package": "@galaxy-tool-util/cli",
"package_version": "^1.8.1",
"invoke_fallback": "npx --yes --package @galaxy-tool-util/cli@1.8.1 gxwf",
"availability_check": "gxwf --help | grep -q draft-validate",
"implied_by": ["gxwf tool-revisions", "gxwf tool-search"]
}_required_tools.json, generated from the CLI commands the Mold actually cites — install line, ephemeral
fallback, and a check the agent can run before it starts.
“What’s the process to contribute? Start to finish — say I noticed a gap. If that’s a gap in upstream docs too, then what? Are certain community resources canon and others not? Can I write notes into the Foundry directly?”
Two prompts, and a lot of threads to pull on
/test-pipeline nextflow-to-galaxy XThose two queries trigger a whole lot of work and self-evaluation. Your agent builds and tests a workflow, and hands you the threads.
The run files feedback on the Foundry while it runs
An opt-in ledger the run appends to as it goes. Not unmet requirements of the workflow being built — those go in the run’s open-requirements ledger — but gaps, defects, friction, and wishes about the Foundry’s own Molds and references.
You noticed a gap. The route.
/review-mold, /refine-mold, /cast.npm run validate — schema plus cross-file resolution. Errors block.What counts as canon
The Foundry adds value by connecting, explaining, and operationalizing upstream knowledge. It should not compete with upstream as the canonical home of it.
So upstream material is pinned, licensed, and framed
- local: content/research/galaxy-xsd/galaxy.xsd
source: $GALAXY/lib/galaxy/tool_util/xsd/galaxy.xsd
pinned_ref: 7765fae934fbfdee77e3be5f5b235e43735273ae
framing: content/research/galaxy-xsd/index.md
license: MIT
license_file: LICENSES/galaxy.LICENSEA license attaches at the point of sync, and the sync script asserts the license file exists. Where upstream ships both a structured source and a rendered form: agents read the structure, humans read the prose.
If the gap is upstream too, that’s two contributions.
This is not a hypothetical — it is most of what the Foundry has produced. Every serious run surfaces something that
belongs in Planemo, gxwf, the IUC standards, or Galaxy itself.
Write the note so the Foundry stops tripping over it. Then file the issue or the PR so nobody else has to.
“What about users who don’t really want a workflow up front? The ad hoc explorers, figuring out what they need one step at a time — looking at a result before deciding what to do next.”
Being more excited about building workflows from first principles (with agents) than about extracting workflows from histories (with agents) is chasing a trend because it is trendy — instead of appreciating our crown jewel.
Why exploring beats specifying
The Foundry’s pipelines construct from intent. Nothing runs until the end.
A validated workflow that nobody has run is a strong hypothesis about an analysis. It is not the analysis.
History → Notebook → Workflow, with a step in between
computational record
rebuild it on-graph
communicative record
reusable graph
Extraction got easier because the notebook already says which outputs count — and the extracted workflow arrives with the story attached.
Rebuilding the mess so it can be extracted
Re-execute a real ad hoc history so its whole computational closure lives on the provenance graph, restructure it with collections so it generalizes to N samples, then author the Notebook.
One test, every step: can Galaxy walk backward from this artifact, through real jobs, to a logical input?
A Mold is one action. The pipeline is only an ordering.
47 Molds cast to 47 skills; the 7 pipeline harnesses just declare a spine over them. Every skill installs and invokes on its own, in the middle of whatever you were already doing.
UPDATE-INTERVIEW → GALAXY
Look at the result, say what should change, see the change as a reviewable diff. Swap a tool, bump a version, add a step, retune a parameter, expose an output.
So: do ad hoc explorers benefit from curated skills?
Yes, one skill at a time — discovery, summarization, test data, debugging, all invocable mid-session.
And they pay it back — their sessions are where patterns, exemplars, and gotchas actually come from.
Open question — what would a pipeline like that even look like?
A Mold is frontmatter plus a procedure
type: mold
name: discover-shed-tool
axis: target-specific
target: galaxy
status: reviewed
revision: 5
summary: "Search the Tool Shed for an existing wrapper, drill from hit
to a pinnable changeset, classify candidates, and recommend
or fall through."
output_artifacts:
- id: galaxy-tool-pin
kind: json
default_filename: galaxy-tool-pin.json
schema: "[[galaxy-tool-discovery]]"
references:
- kind: cli-command
ref: "[[tool-search]]"
...The procedure is prose
Discover whether the Galaxy Tool Shed already publishes a wrapper for the tool a workflow step needs, and resolve the
discovery to an (owner, repo, tool_id, version, changeset_revision) quintuple that downstream steps can
pin and cache.
This Mold is the Tool Shed leg of the discover-or-author branch in Galaxy-targeting
per-step pipelines. On a hit, the cast skill recommends a pin and exits successfully. On a miss (or a low-quality
hit), it falls through to [[author-galaxy-tool-wrapper]]. The branch itself is harness logic; this Mold
owns only the discovery half.
No prompt engineering, no XML scaffolding, no tone. Prose a maintainer can read and argue with — then
## Inputs, ## Outputs, ## Procedure, and the wiki-links resolve at cast time.
Every reference carries its own decisions
references:
- kind: research
ref: "[[galaxy-collection-semantics]]"
used_at: runtime
load: on-demand
mode: verbatim
evidence: corpus-observed
purpose: "Choose Galaxy collection input shapes (File / list / paired /
list:paired / record) from the source's per-sample, paired,
grouped, or nested data descriptions."
trigger: "When the summary describes paired reads, per-sample groups,
nested or grouped inputs, or any input that should become a
Galaxy dataset collection."trigger is required when load is on-demand; verification is required when evidence is still hypothesis. The schema refuses the shortcut.Three decisions decide how a reference is packaged
triggerThis is progressive disclosure as a compile-time contract. discover-shed-tool gets its
output schema upfront and its four notes on demand — so the Tool Shed indexing gotchas cost nothing until search
results actually look wrong.
evidence rides on the same entry — so one line says what a reference is, when it loads, how it lands, and how much we trust it.Casting is per-kind dispatch
references/Which path a kind takes is not knowledge the caster holds. Each kind declares its own cast: block —
resolve strategy, default mode, slug field — in reference_contract.yml.
What actually lands in the bundle
casts/claude/skills/discover-shed-tool/
SKILL.md rendered from the Mold, never hand-edited
_provenance.json what was cast, from where, at which hash
_required_tools.json the CLI it needs, and how to check for it
_verify.json how to validate what it emits
references/
schemas/ loaded upfront
cli/ sidecars, loaded on demand
notes/ loaded on demandThe build log, in full
"mold": {
"name": "discover-shed-tool",
"revision": 5,
"content_hash": "05c99cbac2ec6a4d130b0620...",
"commit": "0f259e8516b9dfb282362c7dc98b7a47ac39884f"
},
"refs": [{
"kind": "cli-command", "mode": "sidecar",
"src": "content/cli/gxwf/tool-revisions.md",
"dst": "references/cli/tool-revisions.json",
"evidence": "corpus-observed", "source": "deterministic",
"src_hash": "82061af5970f0f...", "dst_hash": "db0b13f2b925..."
}]separate project.
pixi.toml on the L0–L4 portability ladder. No Foundry required to use it.
L1–L3 are decidable from the lockfile. L4 needs a publication candidate that was actually observed, so it cannot be assigned offline.
How it reaches the Foundry
The TDA Bioinformatics Foundry — the third instance — consumes Biopixi as a typed note kind. An Environment is a note, and its portability grade is a field on that note.
A writeup of a tool is not knowledge about the tool until something can run it. Building those environments surfaced
unsolvable dependency closures, absent channels, a build needing cmake <4, and a package name already
taken by something unrelated — none of which reading would have found.
The grade is about the environment. It is not the Foundry’s scientific acceptance check — those stay separate on purpose.
How it reaches Galaxy
The ladder’s top rung is a community-published, observed BioContainer — which is the road a Galaxy tool’s dependencies already travel. Biopixi grades how far along that road a method has actually gotten, and a conda recipe is written where the public channels carry nothing recent enough.
So: not a Galaxy component, and not part of the Foundry Pattern. A shared rung that a Foundry can type and Galaxy can consume.
A gap gets named rather than filled in — in a ledger entry, in a draft step, in a portability grade, in an evidence tier, in an upstream issue.