Crewplane
Define reviewable, resumable coding-agent workflows in Markdown; Crewplane runs the graph while Claude Code, Codex, Gemini and other agents do the work — with every handoff saved on disk.
- Source repo
- crewplaneai/crewplane
- Stars
- ★ 44
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 73/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A team that wants its brief → plan → implement → test → review → handoff process versioned in the repo instead of living in terminal habits
- Not a fit if
- Developers on native Windows without WSL (explicitly unsupported)
- Teams wanting a hosted service or web UI rather than a local CLI
- Users who don't want workflow files committed to their repository
- Source review
- 73/100 · Some gaps
What does this agent do, and when should you use it?
Crewplane is an open-source workflow runner (Apache-2.0, Python 3.13+) that turns the manual coordination around coding-agent CLIs into a Markdown workflow owned by your repository. YAML frontmatter declares the execution graph — nodes, dependencies, parallel or sequential modes — while ordinary Markdown defines each stage's instructions, and placeholders like {{plan.output}} create explicit handoffs. It invokes the coding-agent CLIs you already run, including Claude Code, Codex CLI, GitHub Copilot CLI, Gemini CLI, Kilo Code, Pi, DeepSeek Harness, and OpenCode, without taking over their models, tools, or permissions. Review can become a hard gate in a sequential node: executor and reviewer roles can approve a candidate or send blocking feedback into a bounded fix loop. Every run writes a full record under .crewplane/ — execution-results and execution-stages with inputs, outputs, logs, events, manifests, and provider-reported token usage — and completed stages Crewplane can validate survive later failures for resumption. A first run uses a deterministic mock provider so you can see the whole workflow machinery before spending a token.
crewplane init generates .crewplane/config.yml and a default workflow in your project; crewplane validate checks the workflow graph; crewplane run compiles an execution plan and schedules nodes as a DAG, handing rendered instructions to the configured agent CLIs. Nodes support parallel and sequential modes, needs declares upstream dependencies, providers can be assigned per stage, and sequential nodes can define executor and reviewer roles where the reviewer approves or blocks with a bounded fix attempt. crewplane onboarding discovers supported provider CLIs already installed on your machine (including Ollama servers and text models) and wires them in, without installing provider software or managing credentials. Artifacts are written to .crewplane/execution-results/<run-key>/ and .crewplane/execution-stages/<run-key>/, containing rendered inputs, outputs, events.ndjson logs, manifests, and provider-reported usage. When tmux is available, a live dashboard shows DAG progress and log tails (--no-live disables it); identical re-runs print "Identical context detected" and reuse the saved result, while --force starts fresh.
- A team that wants its brief → plan → implement → test → review → handoff process versioned in the repo instead of living in terminal habits
- Engineers who want several agents to explore a problem in parallel, then converge their proposals into one comparison and approval stage
- Developers auditing a codebase from security, performance, architecture, and maintainability angles and merging the findings into one result
- Anyone who, after a late-stage failure, wants to resume from validated completed work rather than replay the whole workflow
- Engineers driving complex migrations through controlled checkpoints: inventory → design → migrate → validate → report
- Evaluators who want to see the full workflow machinery with the zero-cost mock provider before connecting real agents
How do you install or deploy this agent?
The recommended installation is via uv; Python 3.13+ is required, with support for Linux, macOS, and WSL (native Windows is not supported):
uv tool install crewplaneOther documented paths include pip, pipx, Homebrew, an install script, an npm wrapper, and a local source checkout. Update and confirm the version:
crewplane --update
crewplane --versionHow do you use this agent?
Initialize and run the first workflow in any project. The first run uses Crewplane's deterministic mock provider: no provider CLI, no API key, no account, no token spend, and no configuration changes.
cd path/to/your-project
crewplane init
crewplane validate
crewplane runInspect the run record:
.crewplane/
├── execution-results/<run-key>/ # findings and final results
└── execution-stages/<run-key>/ # inputs, outputs, logs, events, manifestsConnect the real agent CLIs already on your machine:
crewplane onboarding
crewplane runFor the live dashboard, install tmux (macOS: brew install tmux; Ubuntu/Debian: sudo apt install tmux); use crewplane run --no-live to omit it. Use crewplane run --force to start a fresh run instead of reusing saved results.
What are this agent's strengths and limitations?
- The workflow is readable, reviewable, versioned Markdown in your repository, not a process hidden in prompts and terminal scrollback
- Review is a structured gate: executor/reviewer roles can approve or trigger a bounded fix loop instead of a promise buried in a prompt
- Every run leaves a complete on-disk record — inputs, outputs, logs, events, token usage — and completed stages can be resumed after later failures
- A zero-cost mock provider lets you exercise the full workflow machinery first; Crewplane Lab publishes reproducible experiments with complete artifacts
- Requires Python 3.13+ and only supports Linux, macOS, and WSL; native Windows is currently unsupported
- It does not install, authenticate, or sandbox provider CLIs — agents run with whatever configuration and permissions exist in your environment, so security boundaries are yours to manage
- Its value depends on multi-stage, multi-agent scenarios; for a quick question or one-off patch, using a coding agent directly or a shell script is lighter
- Connecting real providers requires each CLI to be installed and authenticated separately; Crewplane does not manage credentials
How does this agent compare with similar options?
The README positions Crewplane as the "control plane around your coding-agent CLIs" and advises choosing the lightest tool: use a coding agent directly for quick questions or one-off patches, a shell script for disposable automation, and Crewplane for reliable, reviewable, reusable multi-stage agent workflows.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Crewplane This agent | 73 · Some gaps | CLIFree + model costs | ★ 44 | today | Python | Codex · Claude Code |
| Agentic Plugin Marketplace | 66 · Some gaps | Agent plugin / skillFree + model costs | ★ 42k | 1d ago | Python | Codex · Claude Code |
| Delegatus Agent Workbench | 55 · Major gaps | CLI | ★ 33 | today | TypeScript | Codex · Claude Code |
| Plannotator | 78 · Good | CLIFreemium | ★ 9.6k | today | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows restraint: {{file:}} is project-root bounded by default, symlinks resolved before checks, external paths require explicit allowlisting, workspace isolation is opt-in, and recognized secret options are redacted from run files — data_flow_transparency earns 3. Deductions: Crewplane explicitly does not sandbox provider CLIs (they run with native environment permissions), no explicit user-confirmation gate before real provider runs is documented, and the actual dependency manifest is not in evidence, so least_privilege, user_confirmation, external_effects get 2 and dependency_security gets 1. Rollback means resume/worktree lineage/cleanup, not undoing agent edits — rollback 2. Source attribution via run manifests and per-node records is good but agent-edit attribution is indirect — 2.
Docs are internally consistent (mock default, signature-based skip/resume, run locks), and troubleshooting lists exact expected output phrases with per-symptom paths — failure_messages 3. self_consistency and dependency_availability stay at 2: no source/tests in evidence to corroborate, and Python 3.13+ is a demanding floor.
Audience and scenarios are explicit (review gates, parallel comparison, audits, composition) — audience_and_scenarios 3; capability boundaries are stated plainly in 'Where Crewplane fits' (no replacement of provider permissions, no sandboxing) — 3. trigger_precision is only inferred from workflow discovery rules — 2; environment_fit documents Linux/macOS/WSL and explicitly excludes native Windows — 2.
Information architecture is excellent with layered getting-started/guides/reference docs and exhaustive install/uninstall/update coverage (3); the LICENSE file contains full Apache-2.0 text (3). Deductions: no CHANGELOG in evidence (versioning_changelog 1); no maintainer identity or update commitment visible and publisher is unverified (maintenance_responsibility 1); examples and troubleshooting exist but no FAQ and README is promotional-heavy, so examples_and_faq and known_limitations get 2.
Outputs are ordinary on-disk artifacts users can diff and archive — output_usability 3. Marginal value is argued convincingly against ad-hoc agent sessions or shell scripts but the comparison table is partly marketing — 2. Cost controls (token budgets, usage reporting) exist but estimates are character-based and no real cost data is shown — cost_benefit 2.
Headline claims link to concrete artifacts in the separate crewplane-lab repository — claim_traceability 2; configuration fields and error phrases corroborate across README and reference docs — 2; docs mostly separate fact from advice, but determinism/mock claims are asserted without executable evidence and promotional language is present — fact_inference_separation 2.
- Crewplane does not sandbox provider CLIs: agents run with the native filesystem, network, and credential permissions of your environment; actual agent permissions depend entirely on each CLI's own configuration — tighten them yourself.
- This is a static source review with low confidence; runtime claims such as deterministic mock behavior and resume were not executed or tested.
- No dependency manifest or CHANGELOG appears in the evidence; dependency vulnerability posture and release history cannot be verified.
- Native Windows is unsupported and Python 3.13+ is required; after a crash, lock recovery may require manually deleting the lock directory.
- Publisher identity is unverified; maintenance responsibility and long-term update path are unclear.