Workflow conversion knowledge does not fit in one prompt.
Converting a paper, Nextflow pipeline, or CWL workflow into a validated Galaxy workflow is a chain of tasks — understand, reshape, select tools, implement, validate, test, debug — and each step touches different facts and different kinds of authority.
A monolithic skill can feel convenient at first, but it tends to become brittle. It mixes Galaxy patterns with CLI details, upstream schema contracts, project rationale, examples, caveats, and operational procedure. When something changes, there is no clean boundary to update. When an agent uses it, there is no obvious path from the runtime instruction back to the source record that justified it.
The Foundry keeps knowledge inspectable, then casts it into action.
The Foundry separates source knowledge from runtime artifacts. The knowledge base stays rich: patterns explain observed Galaxy idioms, research notes capture background, CLI docs describe tool surfaces, schemas define contracts, and best practices preserve the design rationale. That source material is meant to be read, reviewed, linked, and improved.
Casting is the bridge. A Mold names one workflow-construction action and declares the references that action needs. Casting reads that Mold and produces a portable cast artifact for a target runtime. A generated skill is smaller and more executable than the full knowledge base, while the knowledge base remains the durable source of truth.
A Mold is an action-sized source artifact.
Molds are not just prose pages. A Mold is a typed reference manifest with a procedural body. It can point at patterns, CLI docs, schemas, examples, prompt fragments, and research notes, and each reference kind has its own casting behavior. A schema can be copied verbatim, a CLI page can become a sidecar, a pattern can be condensed, and an evaluation plan can stay Foundry-only.
This gives each action a shape the validator and the casting pipeline can reason about.
summarize-nextflow extracts
processes, channels, and container references from a source tree.
implement-galaxy-tool-step
turns an abstract step into a concrete gxformat2 step.
validate-galaxy-step
interprets gxwf results inside the per-step loop and routes failures back to
authoring.
discover-shed-tool
searches the Tool Shed before the harness falls through to
author-galaxy-tool-wrapper.
run-workflow-test
executes assembled tests via Planemo. These are different actions, so they deserve
different Molds.
The structure decides what loads now and what waits.
Progressive disclosure is not only a site-navigation idea here. It is part of the runtime contract. Mold references can say whether a source is needed at cast time, runtime, or both; whether it should load up front or on demand; and whether it should be copied, condensed, or turned into a sidecar. That keeps the generated skill focused without cutting it off from richer knowledge when the task actually needs it.
Casts are frozen, portable, and traceable.
A generated skill should not need the whole Foundry at runtime. It should load with the condensed instructions, copied schemas, structured sidecars, and examples it needs to do one job. That makes the artifact portable across runtimes: Claude skills are one target, web artifacts and generic bundles are other possible targets.
The cast is also traceable. Each generated skill records which Mold and references produced it, so a reviewer can ask why a skill says what it says and follow the trail back to the source. Casting can be LLM-assisted, but its inputs and outputs stay explicit enough to diff.
The Foundry lets tools enforce what tools can enforce.
Galaxy workflow authoring has failure modes that should not be handled as folklore.
Parameter names, collection shapes, and workflow-test assertions are better checked by
deterministic tools than by a paragraph of warnings. The Foundry leans on
gxwf, Planemo, JSON Schema, and
tests for that work.
That posture pays off harder for Galaxy than for the text-based workflow languages it sits
next to. gxwf lifts Galaxy's static checks out of the browser and validates
gxformat2 workflows against typed parameter schemas for the 10,000+ tools in
the Tool Shed — no server required. In milliseconds it catches not just misspelled output
names but invalid select options, broken conditional branches, and incompatible
collection-type connections: the kind of error that would otherwise surface mid-run, or
worse, run silently to a wrong result. Nextflow, Snakemake, and WDL don't validate at this
depth without running the workflow.
That changes the agent loop. The goal is not "author and hope." The loop is author, validate, fix, validate — and because per-parameter error reports are structured, they replace trial-and-error execution cycles instead of triggering them. Molds describe how to use the rails; the rails keep the artifacts honest.
Pipelines compose Molds into journeys.
Pipelines are the journey surface of the Foundry. A pipeline such as
nextflow-to-galaxy
orders the Molds a harness would run: summarize the source, shape the data flow, make a
template, compare against IWC exemplars, discover or author tools, implement steps,
validate, test, and debug.
Some pipeline phases are Molds. Some are harness-level routing, such as the discover-or-author branch that tries an existing Tool Shed wrapper before falling through to new wrapper authoring. Keeping that distinction visible lets Pipelines act as both navigation and build artifact without pretending orchestration is itself a Mold.
The Foundry synthesizes; upstream owns the facts.
IWC owns its workflows. Tool Shed and Galaxy APIs own tool metadata. CLI projects own their behavior. Schema packages own validation contracts. The Foundry should not mirror all of that as if it were the new source of truth. It cites, vendors, or copies only where the cast artifact needs a stable runtime reference.
This is why IWC evidence appears as citations and selective excerpts rather than a generated mirror of every workflow. Patterns stay corpus-grounded, but the corpus remains upstream. The Foundry's job is cross-reference, synthesis, and operationalization.
The same source can be read by humans and acted on by agents.
The landing page gives the abstract. This story page explains the architecture. The rendered design docs preserve the source record. Underneath them, Molds and Pipelines make the knowledge actionable. That is the Foundry's core bargain: keep the reasoning visible, but still produce static skills an agent can actually use.