Crank
Run autonomous epic delivery in waves with swarm spawning, slice gates, and JSON results for validation handoff.
Overview
crank is an agent skill most often used in Build (also Ship, testing) that executes epics wave-by-wave through /swarm and /implement with validity gates and validation handoff.
Install
npx skills add https://github.com/boshu2/agentops --skill crankWhat is this skill?
- Autonomous epic execution through waves via /swarm with runtime-native spawning
- Hard gate: wave-validity check rows must pass or slices run sequential
- Produces .agents/swarm/results/*.json plus git changes
- Consumes beads, implement, post-mortem, swarm, vibe; depends on swarm stack
- Explicit loop position 5 in AgentOps operating loop with phase-2 handoff to /validation
- Operating loop position 5 (wave execution)
- Output includes .agents/swarm/results/*.json
Adoption & trust: 833 installs on skills.sh; 384 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a validated slice plan but no disciplined way to execute parallel agent work without stomping shared files or migrations.
Who is it for?
Solo builders using AgentOps-style loops who already run swarm, vibe, and implement and want hands-off epic crank-through.
Skip if: One-file hobby tweaks with no epic plan, no beads issues, and no appetite for swarm parallelism rules.
When should I use this skill?
User invokes /crank or asks to execute epics through waves with swarm and implement.
What do I get? / Deliverables
Closed issues and wave JSON artifacts land in the repo with code changes, ready for phase-2 /validation after each wave completes.
- Git code changes across waves
- .agents/swarm/results/*.json
- Closed issues per wave
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Crank sits at operating-loop wave execution—turning planned slices into merged code—which is primarily Build execution with Ship validation gates. Epic and wave orchestration with issue closure maps to product/engineering management subphase rather than a single integration.
Where it fits
Turn a prioritized epic into wave 1 slices with distinct write scopes before spawning implement agents.
Run parallel backend slices only after migration and contract rows pass the wave-validity gate.
Feed .agents/swarm/results/*.json into validation after the last wave closes issues.
How it compares
Orchestrated multi-skill execution loop—not a single-shot “implement this feature” generator.
Common Questions / FAQ
Who is crank for?
Builders on the boshu2/agentops stack who manage epics as waves and want the agent to enforce slice validity before parallel /swarm runs.
When should I use crank?
Use during Build when executing a slice validation plan wave-by-wave, and during Ship when you need structured handoff to validation after swarm results exist.
Is crank safe to install?
Crank drives git changes and autonomous spawning; review Security Audits on this page and treat output_contract code changes as requiring your normal review before merge.
Workflow Chain
Requires first: swarm, implement
Then invoke: validation
SKILL.md
READMESKILL.md - Crank
# Crank Skill > **Quick Ref:** Autonomous epic execution. `/swarm` for each wave with runtime-native spawning. Output: closed issues + phase-2 handoff for `/validation`. **YOU MUST EXECUTE THIS WORKFLOW. Do not just describe it.** ## Loop position Move **5 (wave execution)** of the [operating loop](../../docs/architecture/operating-loop.md). Consumes the [slice validation plan](../../docs/templates/slice-validation.md); produces wave-by-wave slice completion via `/swarm` + `/implement`. Hard gate at wave start: every row of the wave-validity check must pass (distinct write scopes, no shared migration/contract/CLI surface, declared integration order, owner per slice, discard path per slice). Any failed row → run those slices sequential, not parallel. Parallelism is explicit ownership, not swarm chaos. Autonomous execution: implement all issues until the epic is DONE. **CLI dependencies:** bd (issue tracking), ao (knowledge flywheel). Both optional — see `skills/shared/SKILL.md` for fallback table. If bd is unavailable, use TaskList for issue tracking and skip beads sync. If ao is unavailable, skip knowledge injection/extraction. For Claude runtime feature coverage (agents/hooks/worktree/settings), the shared source of truth is `skills/shared/references/claude-code-latest-features.md`, mirrored locally at `references/claude-code-latest-features.md`. ## Architecture: Crank + Swarm Crank owns orchestration, epic/task lifecycle, and knowledge-flywheel steps. Swarm owns runtime-native worker spawning, fresh-context isolation, per-wave execution, and cleanup. In beads mode Crank gets each wave from `bd ready`, bridges issues into worker tasks, verifies results, and syncs status back to beads. In TaskList mode the same loop runs over pending unblocked tasks instead of beads issues. Read `references/team-coordination.md` for the full per-wave execution model, `references/ralph-loop-contract.md` for the fresh-context worker contract, and `references/worker-specs.md` for per-worker model/tool/prompt specs. ## Flags | Flag | Default | Description | |------|---------|-------------| | `--test-first` | off | Enable spec-first TDD: SPEC WAVE generates contracts, TEST WAVE generates failing tests, IMPL WAVES make tests pass | | `--per-task-commits` | off | Opt-in per-task commit strategy. Falls back to wave-batch when file boundaries overlap. See `references/commit-strategies.md`. | | `--tier=<name>` | (auto) | Force a specific cost tier (quality/balanced/budget) for all council calls. Overrides effort-to-tier auto-mapping. | | `--no-lifecycle` | off | Skip ALL lifecycle skill auto-invocations (test delegation in TEST WAVE, pre-vibe deps/test checks) | | `--lifecycle=<tier>` | matches complexity | Controls which lifecycle skills fire: `minimal` (test only), `standard` (+deps vuln), `full` (all) | | `--no-scope-check` | off | Skip scope-completion check before DONE marker (Step 8.7) | | `--skip-audit` | off | Skip bd-audit pre-flight gate (Step 3a.2) | ## Global Limits **MAX_EPIC_WAVES = 50** (hard limit across entire epic) This prevents infinite loops on circular dependencies or cascading failures. Typical epics use 5–10 waves max. ## Completion Enforcement (The Sisyphus Rule) Not done until you emit an explicit completion marker after each wave: - `<promise>DONE</promise>` when the epic is truly