add-pipeline

Add Pipeline

ℹ️ First, set expectations: before anything else, print one short line with this skill's version and its most recent change — the top entry of metadata.changelog above — e.g. add-pipeline vX.Y — recent: <summary>. Then proceed.

Add a long-running, multi-stage pipeline to any Trinity-compatible agent. Implements the canonical pipeline spec: the agent owns the DAG and stage logic; Trinity owns the read surface (~/.trinity/pipelines/*.yaml + ~/.trinity/pipeline-state/**/*.json); a single heartbeat skill (pipeline-tick) owns advancement, retry, and escalation.

When to use a pipeline (and when not): reach for this when the work is a population of items that each crawl through multiple stages over many runs — or a multi-agent process where each stage is another agent's playbook (a release propagation, an onboarding chain; one instance = one run, agent: on the stage, the tick dispatches a one-line playbook call — fleet convention protocols/playbook-call.md) — and you need durable per-item state, isolated retries, and an at-a-glance "what stage is each item in" — e.g. per-customer onboarding, document ingestion, batched research crawls, especially when the whole batch can't finish in one scheduled run. If it's a single recurring task, a scheduled playbook is simpler — don't reach for a pipeline. And mind the boundary: instances are multi-instance, not multi-tenant — their state is isolated but they all run inside the same agent (same credentials, context window, and heartbeat), so for genuinely isolated or large-scale tenants, deploy one agent per tenant (Trinity fan-out) rather than one pipeline with many instances — that cross-agent layer is /add-orchestrator's domain: its /orchestrate skill does the routing, fan-out, and ephemeral roll-out/tear-down across a fleet, and its /discover-agents surfaces this agent's pipelines to the fleet map.

Keep heavy CPU jobs out of the heartbeat turn. A stage that does real compute (a FAISS/index rebuild, bulk embedding, a full bootstrap) must not run synchronously inside pipeline-tick's LLM turn. A headless run is a single agent turn and can't host a job past the ~10-min synchronous Bash ceiling — past it the harness auto-backgrounds the job, active waiting is blocked, and the turn ending reaps the backgrounded task (it fires killed, not completed; see /trinity:onboard → Long-running jobs inside a run). Model the heavy work as an OS-level job (a container cron / systemd unit or a small non-LLM sidecar writing a done-marker), and let the stage only trigger it and verify the artifact moved (mtime advanced / count > 0 — not an exit code or business_status). The heartbeat stays a cheap read-and-advance loop.

What gets installed: