Claude Code skills

The engine's repo is also a Claude Code plugin marketplace. Its agentic-pipelines plugin brings three skills, so you can work on a data repo in your own words: describe a pipeline and get its pipeline.yaml, ask for a change and get the smallest one, ask how things are going and get the same answer as the dashboard.

They answer in the language you write in.

Install the plugin

In Claude Code, add the marketplace and then install the plugin from it:

/plugin marketplace add startcat/agentic-pipelines/plugin install agentic-pipelines@startcat

From a terminal, one command does both:

claude plugin install agentic-pipelines --marketplace startcat/agentic-pipelines

A clone of pipelines-starter needs none of this: its .claude/settings.json registers the marketplace and enables the plugin, so opening it in Claude Code and accepting the folder trust prompt is enough. Without folder trust, or in a cloud session, use the commands above.

Install it once in your Claude Code and it works in any data repo. Open Claude Code inside the data repo: the skills find it the way the CLI does, with pipelines status --json, and say which repo they are going to write in before the first file.

The skills use the pipelines command if it's on your PATH (bun link in the engine's folder puts it there), or else bun run ~/agentic-pipelines/src/cli/index.ts, where the starter's README puts the engine. They read that engine's docs/reference.md, so what they write matches the version that validates it.

new-pipeline: from a sentence to a green pipeline

Tell it what should happen, how often and what you want out of it. It looks at the data repo first, so it reuses the agents in agents/, the channels in pipelines.yaml and the way your other pipelines are written. Then it asks what it still needs, one question per message, each with a proposal you can just say yes to ("Mondays at 07:00, machine time — does that work?"). It skips whatever your description already answers and stops at about six questions; for anything still open it picks the safe default and says so.

What it asks about is what's easy to forget when you write a pipeline by hand:

• When: the cadence, as a cron in the machine's time zone, and a throttle or changed guard when repeating the work would cost money or send the same notice twice.
• What it needs: binaries, secrets (by name only), MCP servers and hosts it must reach.
• Where it works and what the agent may do: the folder it can write in, what it can only read, its tools, and whether it may push, comment or publish. It proposes the minimum.
• How much it may spend: a max_cost_usd for each agent step, with a figure for the task.
• What it delivers and who it tells: the outputs of each step, the notify channel and stale_after, so days without a good run raise a notice.
• If it fails: a retry for passing errors, or a pipelines resume by hand.
• Params: whatever changes per machine or per person goes in params, never hardcoded.

It sums it all up in one paragraph (what it does, when, what it reads and writes, what it may send out and the most it can cost per run) and waits for your yes. Then it writes pipelines/<name>/pipeline.yaml, the prompt of each agent step and, only if no existing one fits, a new agent, and runs pipelines validate <name> until it passes, explaining each fix. A pipeline isn't run, installed or committed while validate is red.

After that it proposes, one at a time and each with your permission: pipelines doctor, a test run with what it can cost, pipelines install if it has a schedule (with --dry-run first if you want to see what it writes), and a commit.

edit-pipeline: the smallest change

It finds the pipeline, reads it and changes only what you asked, keeping the file's style and comments. When the change touches what the pipeline may do or spend (an agent's tools or MCP servers, max_cost_usd, cwd or additional_dirs, or anything that acts outside the repo), it shows you the diff and waits for a yes. Then it validates until green.

Changing the YAML doesn't change the job the scheduler already has, so it keeps the installation coherent:

• If the pipeline is installed and the change touched triggers, requires.bin, mcp_servers or a throttle guard, it proposes pipelines install <name> again. Until then the dashboard shows it as drifted and the old job keeps running.
• A param of an installed pipeline changes with pipelines install <name> --set key=value, with paths written out in full. Never by editing .params.local.json.
• If the change removes the schedule, it proposes pipelines uninstall <name>: the old job would otherwise keep firing.
• A prompt, a step's run, its outputs or notify are read at every run and need no reinstall. If what an agent does has changed, it proposes a test run.

pipelines-status: how it's going

It reads pipelines status --json, the same overview as the dashboard, and answers with the headline first and then one line per pipeline, worst first: its verdict, its last run and when it runs next, in your machine's time.

• Why a run failed: it reads the run record with pipelines show and the end of the failed step's log, and names the cause: something missing on the machine, a guard that held it back, a tool the sandbox denied, the spending cap, a shell step, or an agent that didn't deliver its contract. Then it proposes the fix, or a pipelines resume if it was a passing problem.
• Spend: this month's total, its runs and how many had an agent step, and last month's. Only what agent steps measure counts.
• Stop and start: stopping is pipelines uninstall <name>, which takes the job off the schedule and keeps the pipeline's files, params and history; starting is pipelines install <name>. Both only after a yes. It can't cut short a run that is already going, and says so.

What they never do without asking

• They never read, print or write .env. If a secret is missing, they say which variable and that it goes in the data repo's .env; you write it.
• They never edit the files the engine generates (the launchd plist, the systemd units, .params.local.json) and never call launchctl or systemctl themselves.
• pipelines doctor isn't pre-approved either: it starts the pipeline's MCP servers and checks the network, so Claude Code asks you first.
• They propose a commit, without .env, .params.local.json or .runs/, and push only if you ask.

Call a skill by name

The skills start on their own when what you ask fits them. To call one by name:

/agentic-pipelines:new-pipeline/agentic-pipelines:edit-pipeline/agentic-pipelines:pipelines-status

status --json

pipelines status --json prints the dashboard's overview as one JSON object (verdicts, next runs, month spend) and is what the skills read; its fields are in Commands.

A team on one data repo

A data repo is a git repo of YAML and prompts, so a team works on it like on any other code: everyone clones it, a new pipeline or a change goes through a pull request, and the review reads a diff of pipeline.yaml that says what the agent may touch and spend. To give everyone the same three skills without anyone installing them, commit a .claude/settings.json like the starter's:

{  "extraKnownMarketplaces": {    "startcat": {      "source": { "source": "github", "repo": "startcat/agentic-pipelines" },      "autoUpdate": true    }  },  "enabledPlugins": { "agentic-pipelines@startcat": true }}

Whoever wants it off for themselves sets "agentic-pipelines@startcat": false in .claude/settings.local.json, which isn't committed.

What isn't shared stays on each machine: .env, .params.local.json and .runs/ are gitignored, and a scheduled job lives on the machine that installed it. The skills know it: if you change a pipeline that runs on a colleague's server, edit-pipeline tells you that the job there only picks up the change when pipelines install <name> runs again on that machine, and pipelines-status won't claim a pipeline is stopped everywhere because it isn't installed on yours.