Run an analytical workflow
SkillDev toolsPlan and run coordinated analysis using explicit input bindings, isolated workers, run-local artifacts, and the Python workflow controller.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Run an analytical workflow skill
What this skill tells your AI
The instructions your AI receives, as published by ai-analyst-lab/ai-analyst in .claude/skills/run-pipeline/SKILL.md and read by ahel’s review.
Choose the amount of work that serves the request. A chart, investigation, validation report, and presentation have different completion conditions. Do not add presentation work to an analysis-only or validation-only request.
Inspect and propose
Read plans.md, agents/registry.yaml, and the selected worker contracts.
The registry declares coordination; contracts declare input requirements.
Do not infer required inputs from whatever happens to exist in global outputs.
Prepare a request JSON under working/requests/ with:
plan: an existing named plan.variables: concrete filename placeholder values.bindings: each worker's input values or explicit producer references.output_paths: exact paths replacing wildcard/dynamic output declarations.external_dependencies: input names replacing omitted producers.approval_gates: required approvals withid,after, andbefore.context: the exact analyticalquestion, plus optionalworker_questionswhen a worker needs a narrower framing.
For produced inputs use {"from": "worker.result"}. The first registered output
is result; later outputs are artifact_2, etc. Inspect the registry before
selecting one. For existing files supply an exact path, computed sha256,
and a purpose explaining why the file suits this question. Evaluate dataset,
scope and age as well: a hash establishes identity, not analytical suitability.
Never invent missing data, credentials, meaning, or approval. Ask only for inputs that cannot be safely supplied from the request and verified context.
When context.question is present, the controller builds a deterministic manifest and bounded
bundle for each worker from the frozen run snapshot. It attaches both as explicit inputs and blocks
on trusted-definition conflicts. The bundle records supply. Workers must cite relevant context item
IDs, and downstream validation still checks whether the work applied them.
Compile before executing
Use the active project Python environment:
import json
from pathlib import Path
from helpers.pipeline.compile_plan import compile_named_plan
from helpers.pipeline.controller import Controller
root = Path.cwd()
request = json.loads(Path("working/requests/request.json").read_text())
definition, inputs = compile_named_plan(root, request)
print(json.dumps(definition, indent=2))
Replace the request path with the actual file. Review jobs, input bindings,
handoffs, deliverables and stopping conditions before execution.
dry-run=true ends here without creating a run or launching workers. Compilation
is not model execution or proof of analytical correctness.
For custom workflows use the explicit definition format in
docs/PIPELINE-CONTROLLER.md. A list of worker names alone is not a complete
workflow contract.
Execute through the controller
After the proposed scope is authorized:
run = Controller.create(root, definition, inputs)
print(run.directory)
Then invoke python -m helpers.pipeline.controller run EXACT_RUN_DIRECTORY.
The controller uses Claude Code with claude-opus-4-6, a fresh process per job,
normal permissions, and explicit output paths. Never bypass permissions or
silently execute a blocked isolated job inline. Workers must not recursively
invoke this skill or edit controller state.
Code owns readiness, bounded retries, artifact checks, status and completion. Query logging inherits a worker-specific directory. Only validated run-local artifacts enter the handoff ledger. This is logical isolation, not an OS sandbox.
Numeric historical checkpoints in plans are not executable approvals. New gates are explicit. Record an approval only after the named person approves the actual evidence; local actor strings do not authenticate identities.
Inspect and report
Read final status and actual artifacts. An optional failure produces a degraded run, even when a deliverable exists. Missing required evidence is not success. Structural checks do not establish analytical correctness. Apply the relevant analytical methods and preserve limitations.
Presentation workers retain their own chart, storytelling and export standards. This entry point does not impose those deliverables on unrelated plans.
Resume only the explicitly identified run using /resume-pipeline. Do not copy
global artifacts into a run to make it look complete. See
docs/PIPELINE-CONTROLLER.md for migration and current limitations.
Signals
- GitHub stars
- 298
- Forks
- 137
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
run-pipeline- Source
- github.com/ai-analyst-lab/ai-analyst