Update to NGS Analysis Workbench

{
  "name": "run-ngs-analysis",
  "description": "Make an NGS analysis executable through live workflow discovery, readiness, immutable compound planning, native execution approval, monitoring, cancellation, and recovery. Use to bind an implementation, prepare or execute a plan, or operate a durable run.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 276
    },
    {
      "relative_path": "references/nfcore-profile-selection.md",
      "size_in_bytes": 2776
    },
    {
      "relative_path": "references/runtime-readiness.md",
      "size_in_bytes": 3034
    }
  ],
  "skill_md_contents": "---\nname: run-ngs-analysis\ndescription: Make an NGS analysis executable through live workflow discovery, readiness, immutable compound planning, native execution approval, monitoring, cancellation, and recovery. Use to bind an implementation, prepare or execute a plan, or operate a durable run.\n---\n\n# Run NGS Analysis\n\nRead [AnalysisContext](../../references/analysis-context.md). Bind an existing\nscientific design to one reviewable execution without changing its method or\nclaim boundary. If no analysis plan exists, route scientific work to\n[design-ngs-analysis](../design-ngs-analysis/SKILL.md); allow an explicitly\nlimited engine smoke, reproduction, or operational diagnostic without one.\n\n## Discover and bind\n\nTreat callable tools and live catalogs as authoritative:\n\n1. List targets with `list_compute_targets`. If the user requests an existing unregistered SSH or Slurm host, call `configure_ssh_target` with its `target_id`, `title`, SSH alias, default `workspace_root`, executor, and optional partition/account.\n2. Inspect the selected target with `inspect_compute_target` when applicable, then call `get_runtime_environment(target_id)`.\n3. List current workflows from the live catalog. Also consider an explicit\n   user-provided or agent-created local source and external workflow candidates.\n4. If no suitable catalog entry exists, use available web, GitHub, internal\n   repository, or existing filesystem capabilities to locate native Nextflow or\n   Snakemake workflows. Do not request a Workbench backend search API.\n5. Inspect each serious candidate's README, native entrypoint, imported modules, environment and\n   configuration declarations, license, assay, endpoint, and revision before\n   proposing it. A description or repository popularity is\n   not evidence that its method, outputs, or runtime are suitable.\n6. Keep Found, Suitable, and Selected distinct. Present the suitable candidate\n   and its exact version to the user when they have not already selected one.\n   Rejected or merely discovered candidates must not be saved or downloaded.\n7. After the user selects a candidate, call `save_workflow` once if it is not\n   already cataloged. Save an online Nextflow workflow by its native locator and\n   immutable revision; do not download it merely to catalog it. Save a local\n   workflow by its absolute root and native entrypoint, keeping samples,\n   credentials, caches, and outputs outside that root. If the user supplied an\n   exact workflow and version and explicitly asked to use it, that is already a\n   selection. Use `update_workflow` only when the user intends to version an\n   existing user-owned entry.\n8. Compare method and scope separately from engine, runtime fit, and target.\n   Both engines support local and Linux SSH local-process targets; curated\n   nf-core Nextflow also supports existing Slurm executors.\n9. Follow [runtime readiness](references/runtime-readiness.md) for controller\n   selection and missing or unknown requirements.\n\nRepository inspection and catalog persistence do not approve workflow\nexecution. Never execute repository scripts, installation commands, workflow\ndry-runs, or setup hooks during discovery.\n\nFor bundled Snakemake, read `<workflow_root>/config/README.md` before building\nthe config. For a Nextflow workflow from the nf-core collection, read\n[profile selection](references/nfcore-profile-selection.md) after selecting the\nbinding. Read [runtime readiness](references/runtime-readiness.md) when checking\ncontrollers, setup, or references.\n\n## Check and plan\n\nChoose one new absolute `run_dir` on the selected `target_id`. Use the target's\n`workspace_root`, when present, as a default location for proposing a run\nsubdirectory. An explicit writable location under `/data`, `/projects`, or\n`/scratch` is equally valid. Readiness checks the chosen path; leave creation\nto approved execution.\n\nCall `check_nextflow_readiness` or `check_snakemake_readiness` with the selected\n`workflow_id`, `target_id`, and `run_dir`, then call the matching planner with\nthe same catalog entry, location, inputs, runtime snapshot, controller\ncandidate, and typed preparation. Put Nextflow parameters in `params_file` and Snakemake settings in\n`config_file`. These files and samplesheets use absolute paths on the selected\ntarget, either already present or produced by approved preparation. The plan\nbinds their file identities. Preserve the workflow's native parameter and\nsamplesheet semantics, including scalar labels; filesystem inputs referenced\nwithin them must be valid on that target.\n\nKeep `unknown` distinct from `missing`; disclose Slurm worker and\nshared-filesystem uncertainty even when scheduler control-plane readiness is\n`ready`.\n\nIf readiness or planning is blocked, synthesize the scientific objective,\nobserved blocker, unexecuted workflow, absent artifacts, unsupported scientific\nclaims, and next safe decision. Follow\n[understand-ngs-results](../understand-ngs-results/SKILL.md) using only the\navailable readiness/design evidence. If no run exists, do not create a registry\nentry or run directory merely to persist a summary.\n\nReview the returned plan in the inline App. Add its `plan_name`, `plan_id`, and\n`plan_checksum` as an `execution_plan` artifact without replacing the\nscientific plan.\n\n## Preserve authorization boundaries\n\nPut verified downloads and generated JSON, CSV, or text files in the typed\n`preparation` field with an absolute `destination_dir` on the selected target.\nApproved preparation creates them directly there before engine execution.\nKeep installation, licensed inputs, large reusable\nreferences, downloads without exact sizes and SHA-256 digests, and machine-level\nchanges outside the run plan.\n\nThe plan App is passive. Call `execute_plan` only with its exact returned identity; the host-native pause is the sole authorization for preparation and execution.\nWhen the returned plan is runnable and the original request includes running, executing, or generating results subject only to native approval, call `execute_plan` in the same turn; this requests approval and does not bypass it.\nStop after planning only when the user explicitly requested plan-only review or a material blocker or unresolved decision remains.\nNever ask for execution approval in prose, structured choices, or `request_user_input`; those do not authorize execution.\nAfter denial, stop until a new user request.\n\n## Monitor and hand off\n\nAfter start, preserve `registry_run_id`, `target`, and `run_dir`. Call\n`get_ngs_run` once for durable context, then poll `observe_ngs_run`; an\ninitially unavailable observation must not trigger another start. Add a `run_receipt`\nartifact. Cancel only when requested, using `cancel_ngs_run`. MCP reconnection\npreserves the run identity. Replacing the local daemon orphans its active local\nruns but can recover verified remote SSH controllers.\n\nStop observation polling when the run reaches a terminal state, then call\n`get_ngs_run` once more for its final durable state. The workflow is\nfinished, but the agent's handoff is not: inspect results, write the analysis,\nand submit it as described below before completing the task, or report the exact\ninspection/submission blocker. Do not wait for a summary file to appear.\n\nFor every completed, partially executed, failed, canceled, or orphaned run,\nalways follow\n[understand-ngs-results](../understand-ngs-results/SKILL.md) with the original\nscientific question, experimental goal and context, decision, scientific model,\nanalysis plan, IDs, paths, result projection when present, observed process\nattempts, failure reason, bounded logs, and provenance, even when the user did\nnot separately ask for interpretation. For SSH, use the verified direct-SSH\nhandoff in that skill: results remain under `<run_dir>/results` on `target`,\nwhile Workbench supplies controller logs and structured execution evidence.\nApply this handoff to historical runs and recovered controllers too; never\nrerun merely to recover interpretation. Distinguish partial outputs from completed results,\nand return the\nmodel-authored synthesis of scientific context, true lifecycle, observed\nfindings, unsupported claims, blockers, and next step. After inspecting actual\nresults, write the agent-authored review to a local Markdown file for either\ntarget. Call `update_ngs_run_analysis_summary(registry_run_id,\nsummary_path)` with that file's absolute local path and confirm it was saved.\nReturn the same synthesis in the conversation. For SSH, never write the summary\nremotely or copy the result tree locally. A submission failure does not change\nthe workflow's terminal status and must not trigger another execution.\nA status, report link, or list of files alone is not the final answer. Select\nmaintained scientific guidance from independently observed assay, input state,\nendpoint, method, and actual output semantics; custom identifiers do not block\nan otherwise applicable policy. If these facts cannot establish a maintained\npolicy, report only operational evidence and explicit scientific limitations.\n\nReturn the operational outcome, blockers, plan and approval state, run\nlifecycle, and next permitted action. Runnable or completed does not mean\nscientifically valid.\n"
}