Watch the workflow run. Keep the full record after the terminal closes. Click the dashboard for the walkthrough.

⭐ If this is how you think coding-agent workflows should work, click Star in the top-right to keep Crewplane in your toolbox — and help more developers find it.

Try it without API keys  ·  Inspect a real 8-agent run  ·  Read the documentation

Your agents are automated. Your workflow usually isn't.

Coding-agent CLIs can plan, write, test, and review code. But the process around them often still lives across prompts, terminal tabs, copy-paste, and memory.

You decide what runs next. You carry plans and findings between tools. You make sure review actually happens. When a later step fails, you reconstruct what already worked.

Crewplane turns that manual coordination into a workflow your repository owns. Make review a gate, not a promise buried in a prompt. If a later stage fails, Crewplane keeps the completed work it can validate instead of making you start over.

Eight agents. One comparison. Every receipt.

Crewplane Lab publishes reproducible experiments with the workflow definition, generated responses, comparison output, telemetry, manifests, and provider logs.

Eight Codex model and reasoning configurations. One algorithm challenge. Watch them work it in parallel—then follow every saved output into a dedicated comparison stage.

Explore the complete recorded experiment →

Inspect the evidence: workflow · eight responses · comparison · complete run record

Quick start

Install Crewplane and run the generated workflow inside any project. The first run lets you see the workflow and its run record before spending a token:

uv tool install crewplane

cd path/to/your-project
crewplane init
crewplane validate
crewplane run

Inspect the resulting run record:

.crewplane/
├── execution-results/<run-key>/   # findings and final results
└── execution-stages/<run-key>/    # inputs, outputs, logs, events, and manifests

The output is mocked. The workflow machinery is not. The run-record structure is the same one used for provider-backed workflows, so you can see how Crewplane validates stages, passes work forward, and records the run before connecting a real agent.

Ready to put the CLIs already installed on your machine behind the workflow?

crewplane onboarding
crewplane run

crewplane onboarding finds the supported provider CLIs already installed on your machine, lets you choose one or more, and configures Crewplane to use them. Crewplane does not install provider software or manage provider credentials.

.crewplane/
├── execution-results/                  # final outputs you care about
│   └── <run-key>/
│       ├── review.project-findings.md  # findings from the review node
│       └── review.project-result.md    # final result from the review node
├── execution-stages/                   # per-stage raw artifacts
│   └── <run-key>/
│       ├── preflight/                  # plan, dependency graph, render plans
│       ├── logs/                       # events.ndjson, summary
│       └── review.project/             # per-node rendered input, output, logs
├── workflows/                          # your workflow definitions, preloaded with example workflows
│   └── single-agent-review.task.md
└── config.yml                          # provider wiring and settings

Prefer to watch? Jump to the full demo walkthrough →

Build the workflow your work actually needs

Crewplane does not prescribe a lifecycle. It gives yours a home in the repository, whether that means one focused stage or a longer workflow with several agents and checkpoints.

For example:

• Deliver a change with independent checks. Brief → plan → implement → test → review → handoff.

• Compare approaches before choosing one. Ask several agents to explore the problem in parallel, then bring their proposals together for comparison and approval.

• Audit a codebase from several angles. Combine security, performance, architecture, and maintainability reviews into one consolidated result.

• Carry a complex change through controlled checkpoints. Inventory → design → migrate → validate → report.

• Turn a recurring team process into a reusable workflow. Keep the stages, agent assignments, handoffs, and review rules in the repository instead of rebuilding the process from terminal history.

These are examples, not built-in stages. Name the steps yourself, use one agent throughout, or assign different CLIs wherever their strengths fit best.

What a workflow looks like

A Crewplane workflow is Markdown you can read in a code review: YAML frontmatter declares the execution graph, and ordinary Markdown defines the instructions for each stage.

This is the real thing, not a hello-world toy: one file, three stages, explicit handoffs, and a review loop you can rerun.

---
schema_version: "1.0"
name: "Feature Delivery"
description: "Plan, implement, review, and prepare a final handoff."

nodes:
  - id: plan
    mode: parallel
    providers: [claude, codex]

  - id: implement
    mode: sequential
    needs: [plan]
    providers:
      - provider: codex
        role: executor
      - provider: claude
        role: reviewer

  - id: handoff
    mode: parallel
    needs: [implement]
    providers: [gemini]
---

## plan

Turn the request into a concrete plan with scope, risks, and validation steps.

## implement

Use the plan:

{{plan.output}}

<!-- crewplane:executor -->
Implement the change and run the relevant checks.
<!-- /crewplane:executor -->

<!-- crewplane:reviewer -->
Review the candidate for correctness, regressions, and missing validation.
<!-- /crewplane:reviewer -->

## handoff

Prepare a concise handoff from the reviewed implementation:

{{implement.output}}

In this example:

• needs defines which stages wait for upstream work.
• providers assigns configured agents to each stage.
• {{plan.output}} creates an explicit handoff rather than relying on hidden session context.
• The sequential executor/reviewer node can approve the candidate or send blocking feedback into a bounded fix attempt.
• The final stage receives the reviewed result, not an informal summary carried between terminal sessions.

plan, implement, and handoff are examples — not built-in lifecycle stages. Rename them, add more nodes, remove stages, fan work out, compose another workflow, or route every stage to the same CLI.

See the workflow syntax reference for the complete authoring contract.

Every run leaves receipts

A final answer tells you what an agent said. A run record tells you how the work actually happened. Crewplane keeps the answers to questions that disappear when the process lives only inside terminal sessions:

.crewplane/execution-results/<run-key>/

.crewplane/execution-stages/<run-key>/

Where Crewplane fits

Crewplane is the control plane around your coding-agent CLIs.

It does not replace their models, tools, sessions, permissions, credentials, or native execution behavior. It controls the process around them: what runs, in what order, with which context, under which review rules, and what remains afterward.

┌──────────────────────────────────────────────┐
│ Workflow owned by your repository            │
│ Markdown · instructions · policies · inputs  │  ← Markdown defines the workflow.
└──────────────────────────────────────────────┘
                    ↓
┌──────────────────────────────────────────────┐
│ Crewplane                                    │
│ validate · render · route · review           │
│ resume · observe · record                    │  ← Crewplane enforces the workflow.
└──────────────────────────────────────────────┘
                    ↓
┌──────────────────────────────────────────────┐
│ Provider-native coding-agent CLIs            │
│ Claude Code · Codex · Copilot CLI · Gemini   │  ← Agents execute the stages.
└──────────────────────────────────────────────┘
                    ↕
┌──────────────────────────────────────────────┐
│ Repository · filesystem · CI                 │
│ source · tests · logs · manifests · results  │  ← Artifacts stay on disk.
└──────────────────────────────────────────────┘

The agents do the work. Crewplane runs the declared process. Your repository remains the system of record.

Installation and updates

The recommended installation is:

uv tool install crewplane

Update the active installation and confirm its version:

crewplane --update
crewplane --version

Other supported installation paths include pip, pipx, Homebrew, the install script, an npm wrapper, and a local source checkout. See the installation guide for exact commands, update behavior, troubleshooting, and removal.

Demo walkthrough

Watch the demo below for the full setup flow: install Crewplane, initialize a project, run the first mock workflow, inspect artifacts, and onboard a real provider.

Documentation and examples

The full documentation starts at docs/index.md.

Just getting started? → follow the First Project Path to install Crewplane, run the mock workflow, inspect artifacts, and prepare a real provider.

Guided tour: → use the Guided Tutorial Track to walk through workflow runs, run records, authoring, provider roles, review loops, composition, validation, troubleshooting, and cleanup.

crewplane run --tasks .crewplane/workflows/example-templates/code-review-example.task.md

crewplane run --tasks .crewplane/workflows/example-templates/feature-implement-example.task.md

crewplane run --tasks .crewplane/workflows/example-templates/composition/review-fix-composed-example.task.md

Contributing

Contributions, workflow ideas, and real-world failure cases are welcome.

• Read Contributing.
• Set up a local checkout with the development guide.
• Ask questions or propose workflow patterns in GitHub Discussions.

Have a coding-agent workflow that you do not want to leave to a free-running loop? Describe it in Discussions and we can all work together on it.