Agentic Pipelines
Use the plugin

Run orchestrated /develop on your own repo.

Fire one prompt and walk away. Install once, scaffold a flow fitted to your stack, then take changes from spec to a reviewed, committed branch. New to the idea? Start with the concept.

Install → Get the most out of it
Install

Add the marketplace, install the plugin

In Claude Code, from the repo you want to set up:

  1. Add the marketplace
    /plugin marketplace add chrisjenx/cjs-orchestrator
  2. Install the plugin
    /plugin install develop@cjs-orchestrator
  3. Scaffold your flow
    /develop:init detects your stack, confirms your real gate commands with you, and writes the per-repo definitions plus safe hooks into .claude/.
  4. Use it
    /develop:run <spec | ticket | idea> per change, and /develop:flywheel periodically to tune the flow from its postmortems.

Nothing is transplanted: /develop:init reads this repo's commands and conventions and grows from a minimal core. Re-run it any time to refresh discovery: it reconciles, it doesn't clobber.

The three commands

Scaffold once · run per feature · tune periodically

Three static, portable skills. Their behaviour is fitted to your repo because they read the definitions init discovered, not because they were rewritten for you.

once /develop:init

Detects your stack, discovers the real build/test/lint/coverage commands (CI is the source of truth), and writes .claude/develop.config.json, a routing table, a starter CLAUDE.md, safe hooks, and a flywheel doc. Confirms with you before writing.

run when you set up, or to refresh discovery

per feature /develop:run

The orchestrator loop. Plans, works in an isolated worktree, dispatches one executor per phase, then runs a fixed quality tail (validate → audit → tidy → finalize) wired to your gates. Blocks the commit until they pass; hands off a branch (never pushes).

run per change: spec, ticket, or rough idea

periodically /develop:flywheel

Reads the accumulated postmortems, flags finding categories that keep escaping (or are breaking-class), and proposes the cheapest fix (a hook, gate, rule, anchor, or a new reviewer), human-gated. This is how the flow gets stronger over time.

run every few features, to tune
Get the most out of it

It's only as good as the checks you give it

The orchestrator doesn't decide "done" by judgement: it clears a phase only when a command ran and produced evidence. So the flow's ceiling is set by what your repo can mechanically verify. Point it at a repo with strong gates and it's formidable; point it at one with no checks and it can only confirm what little there is.

The leverage is in the controls, not the prompts. Discovery finds the gates you already have; the quality tail enforces them; the flywheel turns every escaped defect into a new mechanical check. None of that compounds if there's nothing mechanical to anchor to. Invest here first.

Invest in these before expecting magic

Weak checks aren't a blocker to starting: /develop:init degrades gracefully and uses whatever you confirm. But the gap between "it ran" and "it's trustworthy" is exactly the gap between a repo with strong mechanical checks and one without. That's where the payoff lives.

What it writes

Static skills, discovered definitions

The plugin ships static, portable skills and agents. /develop:init writes only the repo-specific definitions they read, so the flow is fitted without being a copy you have to maintain.

Written into your .claude/

  • develop.config.json: your gates (tagged cheap/heavy), stack, model tiers, caps
  • develop-routing.json: artifact-shape → agent (starts with a generalist fallback)
  • CLAUDE.md: a short starter from your discovered conventions
  • develop-flywheel.md: the postmortem log plus your promoted checks
  • safe hooks/: a worktree guard plus a generic command timeout

Bundled in the plugin (not copied)

  • skills: /develop:init, /develop:run, /develop:flywheel
  • agents: planner, executor, the diff-reading auditors, code-reviewer, tidy, refuter
  • references: the portable mechanism (plan anatomy, gate tokens, the quality tail, the flywheel)

Your routing table references the bundled agents by name. Specialists you add later live in your own .claude/agents/, grown via the flywheel.

In practice

The loop that tightens itself

Reuse first, defer creation to workflows: the flow prefers the skills/agents/rules you already have, and when something's missing it proposes building it, rather than quietly hand-rolling one-off helpers.

  1. Run a feature. /develop:run plans, builds, and runs the quality tail. The finalize phase logs a postmortem: what escaped, classified preventable vs irreducible.
  2. Tune periodically. /develop:flywheel reads the postmortems, and for each recurring (or breaking-class) escape proposes the cheapest lever: a hook, gate, rule, anchor, or a new or pruned reviewer.
  3. You approve; it applies. Simple deterministic levers are edited directly; building or improving an agent/skill/rule is deferred to a focused workflow. Nothing edits .claude/ without you.
  4. Next run is stronger. The new checks are enforced by construction, so that defect class stops escaping. Preventable findings trend toward zero; the irreducible floor stays.

Want the why behind all of this? The concept page walks the full pipeline, the design trade-offs, and the portable patterns.