菜单
Lint a pipeline.yaml — schema check, DAG acyclicity, referenced-skill existence, precondition kind registration. Pure linter — prints a report, writes no files. Heartbeat does not require validation to have run; this is a developer convenience.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Abilityai/abilities --skill validate-pipeline命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | validate-pipeline |
| description | Lint a pipeline.yaml — schema check, DAG acyclicity, referenced-skill existence, precondition kind registration. Pure linter — prints a report, writes no files. Heartbeat does not require validation to have run; this is a developer convenience. |
| argument-hint | <pipeline-slug> |
| allowed-tools | Read, Bash, Glob, Grep |
| user-invocable | true |
| metadata | {"version":"1.3","created":"2026-05-23T00:00:00.000Z","author":"Ability.ai","changelog":["1.3: Stages with agent: <name> (remote playbook, add-pipeline 1.7) skip the local skill-existence check","1.2: Step 2 no longer hard-requires the legacy heartbeat.skill field (it failed the canonical template, which ships heartbeat.name/cron/message) — now requires heartbeat.message + heartbeat.name; Step 7 notes an uninstalled-skill message fails loudly as SKILL_NOT_FOUND at runtime (trinity#1410)","1.1: Heartbeat sanity matches the fixed schema (heartbeat.name/cron/message; 5-field cron — Trinity's scheduler format). heartbeat.pre_check now raises a WARNING: the pre-check hook is removed (Trinity's agent-global hook has no fire vocabulary — any stdout replaces the calling schedule's message); legacy skill/schedule_name fields get a rename note","1.0: Initial version — read-only pipeline.yaml linter checking schema, DAG acyclicity, referenced-skill existence, and precondition kinds; writes no files"]} |
ℹ️ 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.changelogabove — e.g.validate-pipeline vX.Y — recent: <summary>. Then proceed.
Read-only linter. Verify a pipeline.yaml is structurally sound. Surfaces errors and warnings; writes no files.
Run this:
pipeline.yaml/add-pipeline and /add-pipeline-stageThe heartbeat (pipeline-tick) reads pipeline.yaml directly each tick. It does not require this skill to have run. If you ship a broken pipeline.yaml, the heartbeat will fail loudly on the next tick — running the linter just gets you that feedback sooner.
Expect <pipeline-slug> as the single positional argument. If missing, list pipelines and prompt.
Validate projects/<slug>/pipeline.yaml exists.
Required top-level keys: schema_version, pipeline_id, name, stages, heartbeat.
PIPELINE_FILE="projects/$SLUG/pipeline.yaml"
SCHEMA=$(yq '.schema_version // 0' "$PIPELINE_FILE")
[ "$SCHEMA" = "1" ] || error "schema_version must be 1 (got: $SCHEMA)"
ID=$(yq '.pipeline_id // ""' "$PIPELINE_FILE")
[ "$ID" = "$SLUG" ] || error "pipeline_id ($ID) doesn't match directory slug ()"
STAGE_COUNT=$(yq )
[ -gt 0 ] || error
yq >/dev/null || error
yq >/dev/null || error
yq >/dev/null || error
Collect all errors and report at the end — don't stop on the first one.
For each stage in .stages[]:
yq '.stages[] | [.id, .skill, .timeout_seconds, (.retry.max_attempts // 1), (.on_failure // "escalate")] | @tsv' "$PIPELINE_FILE"
Verify per stage:
^[a-z][a-z0-9-]{0,40}$, unique across all stages.claude/skills/<skill>/SKILL.md exists (warn, don't fail — the skill may be authored after the pipeline is defined). If the stage carries agent: <name>, the playbook lives on that fleet agent — skip the local check and only require agent to be a non-empty slugmax_attempts - 1 (so each retry has a backoff)advance | retry | escalate | haltBuild the dependency graph from depends_on + explicit transitions. Run topological sort:
# Implemented inline (no external deps). Pseudocode:
visited = {} # node -> 'visiting' | 'done'
def visit(node):
if visited.get(node) == 'visiting': raise CycleError(path_to_here)
if visited.get(node) == 'done': return
visited[node] = 'visiting'
for dep in graph[node]: visit(dep)
visited[node] = 'done'
for node in graph: visit(node)
If a cycle is found, show the path: collect → curate → synthesize → collect and stop. Cycles are a hard fail.
v1 supports sequential transitions only — branching is expressed by having a stage skill emit next_stage in its output JSON, and the heartbeat respects it.
For each transition entry, if a condition field is present, hard fail:
Transition <from> → <to> has a `condition` field. Conditional transitions are
not supported in v1. To branch, have the stage skill emit `next_stage` in its
output JSON — pipeline-tick will route accordingly.
Recognized kinds (from the spec):
credential_presentfile_existsexternal_reachablesubscription_activestage_output_presentFor each precondition in stages[].preconditions[]:
kind is in the registered set → okStage "<id>" uses precondition kind "<x>" that pipeline-tick does not know about. The heartbeat will treat unmet preconditions of this kind as permanently unsatisfied. Either rename to a registered kind or extend pipeline-tick.heartbeat.cron is a parseable 5-field cron expression (Trinity's scheduler format).heartbeat.message names an installed skill (default Run /pipeline-tick; warn if the referenced skill directory is missing under .claude/skills/ — and note it's no longer a soft failure at runtime: a schedule whose message names an uninstalled skill finalizes FAILED with SKILL_NOT_FOUND and raises an Operating Room item, trinity#1410).heartbeat.skill / heartbeat.schedule_name get an info-level note to rename to message / name. heartbeat.pre_check gets a warning: the pre-check hook is removed (Trinity's agent-global hook contract has no fire vocabulary — any stdout replaces the calling schedule's message). Delete the field, and if ~/.trinity/pre-check still contains an add-pipeline block, re-run /add-pipeline's Step 6 migration to strip it.If validation passed with no errors, refresh the read surface so the heartbeat picks up the latest yaml:
cp "$PIPELINE_FILE" "$HOME/.trinity/pipelines/$SLUG.yaml"
date -u +%Y-%m-%dT%H:%M:%SZ > "$HOME/.trinity/pipelines/$SLUG.last_synced"
If validation failed, do not sync — the heartbeat keeps reading the previous good copy.
If validation passed:
✅ Pipeline `<SLUG>` validated.
Stages: <N> (order: collect → curate → synthesize → publish → measure)
Transitions: <M>
Preconditions: <P>
Estimated cycle time (sum of timeouts): <S>s
Read surface synced: ~/.trinity/pipelines/<SLUG>.yaml
Warnings:
- <list — empty if none>
If validation failed:
❌ Pipeline `<SLUG>` has <N> errors. Read surface NOT synced — pipeline-tick will keep using the previous good copy until you fix and re-validate.
Errors:
1. <error>
2. <error>
…
Warnings:
- <list>
Fix pipeline.yaml and re-run /validate-pipeline <SLUG>.
| Situation | Action |
|---|---|
| Pipeline doesn't exist | Refuse, suggest /add-pipeline |
| pipeline.yaml syntactically invalid (yq parse error) | Report parse error verbatim |
| Cycle detected | Show cycle path, fail |
Transition with condition field | Fail with v1-limitation message |
| Unknown precondition kind | Warn, pass |
| Missing skill referenced by stage | Warn, pass — gives flexibility to scaffold skills after defining the pipeline |
~/.trinity/pipelines/<slug>.yaml on a clean pass.pipeline.yaml is the only source of truth; the heartbeat reads it directly.