From OpenProblems Spatial Co-pilot
Diagnose a failing Nextflow pipeline run in an OpenProblems benchmark. Use when a `nextflow run` fails, a process errors out, or the user shares a .nextflow.log / .command.err and asks why it broke.
How this skill is triggered — by the user, by Claude, or both
Slash command
/openproblems-spatial:nextflow-debuggingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The server does not yet parse logs for you (`analyze_nextflow_log` is roadmap), so
The server does not yet parse logs for you (analyze_nextflow_log is roadmap), so
triage the logs directly. Be systematic.
Find the failing task. From the run output, note the process name and the
work directory hash (work/ab/cdef...). The per-task files there are the
ground truth:
.command.sh — the exact command run..command.err / .command.out — stderr/stdout..command.log, .exitcode — exit status.Classify the error by exit code / message:
memory directive
or add a dynamic retry (memory { 8.GB * task.attempt }).validate_spatial_data).Add resilience where appropriate: errorStrategy 'retry', maxRetries,
and dynamic resources by task.attempt. Don't paper over a real bug with
retries.
Reproduce in isolation. Re-run a single component with viash run on the
test data before re-running the whole pipeline. Use -resume to avoid
recomputing successful tasks.
Validate inputs with validate_spatial_data / analyze_spatial_metadata
when the failure looks data-shaped (wrong format, missing elements,
raw-vs-normalized mismatch).
Report: the failing process, the root-cause class, the evidence (the log line), and the specific fix — plus whether it's a data problem, an environment problem, or a code problem.
npx claudepluginhub rebell-leader/spatialai_mcp --plugin openproblems-spatialGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.