Author a new Galaxy user-defined tool YAML definition when discovery yields nothing acceptable.
/plugin marketplace add jmchilton/foundry
/plugin install foundry-skills@galaxy-workflow-foundryThen invoke as:
/foundry-skills:author-galaxy-tool-wrapperProduces: 1 artifact.
Consumes: 1 artifact.
Galaxy `GalaxyUserTool` YAML definition for a tool not present on the Tool Shed.
{
"id": "galaxy-user-tool-definition",
"kind": "yaml",
"default_filename": "galaxy-user-tool.yml",
"description": "Galaxy `GalaxyUserTool` YAML definition for a tool not present on the Tool Shed."
}Source pipeline summary from [[summarize-nextflow]]; provides process command, inputs, outputs, and container or conda evidence for UDT authoring.
{
"id": "summary-nextflow",
"description": "Source pipeline summary from [[summarize-nextflow]]; provides process command, inputs, outputs, and container or conda evidence for UDT authoring.",
"inherited_schema": "[[summary-nextflow]]",
"producers": [
"summarize-nextflow"
]
}Generate a schema-shaped `GalaxyUserTool` YAML definition from missing-wrapper requirements and source-derived process evidence.
references/prompts/custom-tool-structured.mdcontent/prompts/galaxy/custom-tool-structured.upstream.prompt# Galaxy Custom Tool Generator
You are a Galaxy tool generator. Generate valid Galaxy tool definitions that match the UserToolSource schema exactly.
## Required Fields
- **class**: Must be exactly "GalaxyUserTool"
- **id**: Unique identifier, lowercase with hyphens (e.g., "my-cool-tool"). Min 3 chars, max 255 chars.
- **version**: Semantic version (e.g., "1.0.0")
- **name**: Human-readable tool name displayed in the tool menu
- **container**: Docker/Singularity image (e.g., "quay.io/biocontainers/bwa:0.7.17--h7132678_9")
- **shell_command**: Command to execute with parameter references
## Optional Fields
- **description**: Brief description displayed in the tool menu
- **inputs**: List of input parameters (see Input Parameter Types below)
- **outputs**: List of output definitions (see Output Types below)
- **license**: SPDX license identifier (e.g., "MIT")
- **help**: Help text shown below the tool interface
## Input/Output Syntax in shell_command
- Input file paths: `$(inputs.param_name.path)` for single files
- Input values: `$(inputs.param_name)` for text, integer, float, boolean
- For array inputs: `$(inputs.param_name[].path)`
- Outputs are captured via `from_work_dir` or `discover_datasets` in output definitions
## Input Parameter Types
Each input must have a `type` field. Valid types:
- **data**: File input. Set `format` for allowed file types (e.g., "fastq", "fasta")
- **text**: Text string input
- **integer**: Whole number input
- **float**: Decimal number input
- **boolean**: True/false checkbox
- **select**: Dropdown with options
Example input:
```yaml
inputs:
- name: input_file
type: data
format: fastq
label: Input FASTQ file
- name: num_threads
type: integer
default: 4
label: Number of threads
```
##
...Read process tool, container, conda, inputs, outputs, script summary, and test fixture evidence from the source pipeline summary.
references/schemas/summary-nextflow.schema.jsonpackage://@galaxy-foundry/summarize-nextflow#summaryNextflowSchema{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://galaxyproject.org/foundry/schemas/summary-nextflow.schema.json",
"$comment": "Canonical source: packages/summarize-nextflow/src/schema/summary-nextflow.schema.json in jmchilton/foundry. Mold frontmatter cites this schema via [[summary-nextflow]] wiki-links; the cast pipeline imports the `summaryNextflowSchema` runtime export and serializes it into cast bundles.",
"title": "Nextflow Pipeline Summary",
"description": "Structured per-source summary emitted by the summarize-nextflow Mold.\n\nPer-source schema by design — paper, Nextflow, and CWL each have their own summary shape; downstream Molds (data flow, templates, tool wrappers) consume any source's summary and handle the polymorphism.\n\nField names mirror gxy-sketches' SketchSource / ToolSpec / TestDataRef / ExpectedOutputRef where parity exists; see content/research/gxy-sketches-alignment.md.",
"$ref": "#/$defs/Summary",
"$defs": {
"Summary": {
"title": "Summary",
"description": "Top-level shape. Every Nextflow summary is exactly this object.",
"type": "object",
"additionalProperties": false,
"required": [
"source",
"params",
"sample_sheets",
"profiles",
"tools",
"processes",
"subworkflows",
"workflow",
"reference_assets",
"reference_rebuilds",
"test_fixtures",
"nf_tests"
],
"properties": {
"source": {
"$ref": "#/$defs/SourceRecord"
},
"params": {
"type": "array",
"items": {
"$ref": "#/$defs/Param"
}
},
"sample_sheets": {
"type": "array",
"items": {
"$ref": "#/$defs/SampleSheet"
},
"description": "Structured sample-sheet inputs. Each entry binds one `params[]` parameter to a row schema (column names, types, path-vs-meta classification, required flags, enums, patterns). Promoted from prose inside `params[].description` so downstream target translations (Galaxy `sample_sheet*` collections, CWL records-of-arrays) can choose collection variants without re-parsing the source pipeline. Empty array when no sample-sheet idiom is detected. Discovery sources: nf-schema `schema:` references, `samplesheetToList()` calls, and `splitCsv(header: true)` m
...Run the mandatory fuzzy quality review after structural validation passes.
Trigger: After the drafted `GalaxyUserTool` passes structural validation and before emitting `galaxy-user-tool.yml`.
references/prompts/custom-tool-critic.mdcontent/prompts/galaxy/custom-tool-critic.upstream.prompt# Galaxy Custom Tool Critic
You are a senior reviewer of Galaxy tool definitions. Another model has produced a tool definition that already passed structural validation -- IDs are well-formed, all referenced inputs are declared, container shape is recognized, citations are present. Your job is the **fuzzy quality** pass that validation can't do: clarity, idiomaticity, sensible defaults, helpful text.
You receive the original user request, the produced tool YAML, and you return a structured critique.
## What to flag
**Clarity issues** -- text that an end user will read:
- `description` doesn't say what the tool actually does, or is too generic ("Run the tool", "Process input")
- `name` is opaque or doesn't match the description
- Input `label` text is missing or duplicates the parameter name
- Input `help` text is missing for non-obvious parameters
- Output `label` text is missing or unclear
**Idiomaticity issues** -- shape of the tool:
- `shell_command` mixes shell quoting that won't escape correctly (e.g., bare `$(date)` instead of `\$(date)`)
- Optional parameters have no `default`, forcing the user to supply values that should be sensible
- Common analysis options aren't exposed (e.g., a BWA tool with no `-t` threads input)
- File outputs declared without `from_work_dir` or matching command output (the validator should have caught these, but flag any borderline cases)
- Container is a generic image like `ubuntu:latest` when a biocontainer for the wrapped tool exists
## What NOT to flag
- Anything the deterministic validator already catches (undeclared `inputs.X` references, container shape, citations, tool id format) -- assume it passed
- Style preferences that don't affect correctness or clarity ("I'd name this differently")
- Suggestions that would require
...Map Nextflow container/conda evidence to Galaxy UDT container and package provenance.
Trigger: When a missing Galaxy user-defined tool must be authored from a Nextflow process with container or conda directives.
references/notes/component-nextflow-containers-and-envs.mdcontent/research/component-nextflow-containers-and-envs.md---
type: research
subtype: component
tags:
- research/component
- source/nextflow
- target/galaxy
component: "Nextflow Containers and Environments"
status: draft
created: 2026-05-01
revised: 2026-05-05
revision: 3
ai_generated: true
summary: "Container URL grammar (depot, BioContainers, mulled-v2, Wave, ORAS) and conda directive resolution rules backing summarize-nextflow §5."
sources:
- "https://docs.seqera.io/nextflow/process"
- "https://docs.seqera.io/nextflow/reference/process"
- "https://github.com/nf-core/modules/blob/master/modules/nf-core/fastqc/main.nf"
- "https://github.com/nf-core/modules/blob/master/modules/nf-core/multiqc/main.nf"
- "https://github.com/nf-core/modules/blob/master/modules/nf-core/dragmap/align/main.nf"
- "https://github.com/nf-core/modules/blob/master/modules/nf-core/seqkit/sample/main.nf"
- "https://github.com/nf-core/modules/blob/master/modules/meta-schema.json"
- "https://github.com/nf-core/modules/blob/master/modules/environment-schema.json"
- "https://github.com/nf-core/tools/blob/master/nf_core/module-template/main.nf"
- "https://github.com/BioContainers/multi-package-containers"
- "https://github.com/BioContainers/singularity-build-bot"
- "https://depot.galaxyproject.org/singularity/"
- "https://biocontainers.pro/registry"
- "https://bioconda.github.io/"
- "https://docs.seqera.io/wave"
- "https://nf-co.re/events/2024/bytesize_pipeline_container_urls"
related_molds:
- "[[summarize-nextflow]]"
- "[[author-galaxy-tool-wrapper]]"
- "[[summarize-galaxy-tool]]"
related_notes:
- "[[component-nextflow-pipeline-anatomy]]"
- "[[component-nf-core-tools]]"
- "[[component-nextflow-inspect]]"
---
# Nextflow Containers and Environments
Operational grounding for `[[summarize-nextflow]]` §5 ("Build
...
# author-galaxy-tool-wrapper
Follow the procedure below and use the artifact/reference sections as the runtime contract.
## When To Use
- Author a new Galaxy user-defined tool YAML definition when discovery yields nothing acceptable.
## Inputs
- Read artifact `summary-nextflow`. Schema: summary-nextflow. Produced by `summarize-nextflow`. Source pipeline summary from summarize-nextflow; provides process command, inputs, outputs, and container or conda evidence for UDT authoring.
## Outputs
- Write artifact `galaxy-user-tool-definition` as `galaxy-user-tool.yml`. Format: `yaml`. Galaxy `GalaxyUserTool` YAML definition for a tool not present on the Tool Shed.
## Required Tools
- None declared. Procedure should not assume external CLIs are present.
## Load Upfront
- `references/prompts/custom-tool-structured.md`: prompt reference copied verbatim into the bundle. Generate a schema-shaped `GalaxyUserTool` YAML definition from missing-wrapper requirements and source-derived process evidence.
- `references/schemas/summary-nextflow.schema.json`: Schema file copied verbatim into the bundle. Read process tool, container, conda, inputs, outputs, script summary, and test fixture evidence from the source pipeline summary.
## Load On Demand
- `references/prompts/custom-tool-critic.md`: prompt reference copied verbatim into the bundle. Run the mandatory fuzzy quality review after structural validation passes. Use when: after the drafted `GalaxyUserTool` passes structural validation and before emitting `galaxy-user-tool.yml`.
- `references/notes/component-nextflow-containers-and-envs.md`: Research note copied verbatim into the bundle. Map Nextflow container/conda evidence to Galaxy UDT container and package provenance. Use when: a missing Galaxy user-defined tool must be authored from a Nextflow process with container or conda directives.
## Validation
- None declared.
## Procedure
Author a Galaxy user-defined tool (UDT) YAML definition when discover-shed-tool cannot produce an acceptable existing Tool Shed wrapper. This skill owns the author-on-fallthrough path only; do not duplicate existing wrappers unless discovery evidence is weak or missing.
The output is a single `GalaxyUserTool` YAML document, not Galaxy XML. Preserve source evidence and unresolved assumptions in the emitted artifact or companion notes rather than inventing command flags, containers, datatypes, or package names.
### Inputs
Use the source summary and branch fallthrough context to identify:
- The process or abstract step that needs a tool.
- Command intent, required inputs, expected outputs, and test fixture evidence.
- Container, Bioconda, Conda, or environment evidence from the source pipeline.
- Why Tool Shed discovery did not supply an acceptable existing wrapper.
### Procedure
#### 1. Confirm authoring is justified
Read the discovery result before authoring. Continue only when discovery returned `miss`, or when the selected hit was weak enough that the harness explicitly fell through.
If the missing tool need is under-specified, ask for clarification or emit an unresolved assumption. Do not create a plausible-looking UDT from absent command or container evidence.
#### 2. Build the UDT requirements brief
Extract the minimum executable contract:
- Tool id, version, display name, and description.
- Container image or package evidence, with confidence.
- `shell_command` intent and every referenced input/output token.
- Input parameters with Galaxy-compatible names, types, labels, defaults, help text, and datatypes when evidenced.
- Output datasets or collections with formats and `from_work_dir` / discovery rules.
Prefer BioContainers or directly evidenced containers. If only Conda/package evidence exists, record what is known and avoid guessing an image tag.
#### 3. Generate the structured draft
Use `references/prompts/custom-tool-structured.md` to generate a `GalaxyUserTool` YAML draft from the requirements brief.
The draft must use `class: GalaxyUserTool`. Every variable referenced by `shell_command` must have a declared input or output. Escape shell variables that are not Galaxy expressions.
#### 4. Validate structurally
Validate the draft against the available Galaxy user-tool validator or schema surface before critique. Treat structural validation failures as authoring failures, not critic feedback.
Fix validation errors directly. Do not run the critic until the draft passes structural validation.
#### 5. Run mandatory critic pass
After structural validation passes, use `references/prompts/custom-tool-critic.md` with the original request, requirements brief, and drafted YAML.
Apply every concrete clarity or idiomaticity issue when `should_refine` is true. Re-validate the refined draft structurally after edits. If critic feedback conflicts with source evidence, keep the source evidence and record the conflict.
#### 6. Emit the UDT artifact
Write `galaxy-user-tool.yml` with the validated and critic-reviewed `GalaxyUserTool` definition.
The artifact should be ready for the downstream harness or Galaxy runtime to load as a user-defined tool. Include unresolved assumptions only when they are truthful and actionable; otherwise fail instead of emitting a misleading tool.
### Non-goals
- **Tool Shed discovery.** Use discover-shed-tool before this skill.
- **Existing wrapper summarization.** Use summarize-galaxy-tool for Tool Shed or installed Galaxy wrappers.
- **Galaxy XML authoring.** This skill emits UDT YAML only.
- **Workflow step binding.** implement-galaxy-tool-step decides how the authored tool is used in a workflow step.
## Runtime Notes
- Do not read Foundry source files at runtime; use only files packaged in this skill bundle and user-supplied artifacts.
- Preserve declared artifact filenames unless the user or harness supplies explicit paths.
- Carry unresolved assumptions into the output artifact instead of silently inventing missing source evidence.