From harness
Use when user says 'breezing', 'do everything', 'run the whole plan', 'team run', 'full auto', or wants all tasks executed end-to-end with parallel workers. Do NOT load for: single-task implementation, planning, code review, release, or setup. Team execution mode — runs Plans.md tasks with full parallel team orchestration. High-level alias for harness-work in team mode.
npx claudepluginhub tim-hub/powerball-harness --plugin harnessThis skill is limited to using the following tools:
> **Backward-compatible alias**: Runs `harness-work` in team execution mode.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Backward-compatible alias: Runs
harness-workin team execution mode.
breezing # Ask for scope before executing
breezing all # Complete all tasks in Plans.md
breezing 3-6 # Complete tasks 3 through 6
breezing --codex all # Complete all tasks via Codex CLI
breezing --parallel 2 all # Complete all tasks with 2 parallel workers
breezing --no-discuss all # Complete all tasks, skipping planning discussion
breezing --auto-mode all # Try Auto Mode rollout on a compatible parent session
| Option | Description | Default |
|---|---|---|
all | Target all incomplete tasks | - |
N or N-M | Task number/range specification | - |
--codex | Delegate implementation to Codex CLI | false |
--parallel N | Number of parallel Implementers | auto |
--no-commit | Suppress automatic commits | false |
--no-discuss | Skip planning discussion | false |
--auto-mode | Explicitly opt in to Auto Mode rollout. Only considered when the parent session's permission mode is compatible | false |
This skill delegates to harness-work. Run harness-work with the following settings:
harness-work--auto-mode is accepted as a rollout flag for compatible parent sessionsharness-work| Aspect | harness-work | breezing (this skill) |
|---|---|---|
| Parallelization | Automatic splitting based on need | Lead/Worker/Reviewer role separation |
| Lead's role | Coordination + implementation | Delegation only (coordination focused) |
| Review | Lead self-review | Independent Reviewer |
| Default scope | Next task | All tasks |
| Role | Agent Type | Mode | Responsibility |
|---|---|---|---|
| Lead | (self) | - | Coordination, command, task distribution |
| Worker xN | claude-code-harness:worker | bypassPermissions (current) / Auto Mode (follow-up)* | Implementation |
| Reviewer | claude-code-harness:reviewer | bypassPermissions (current) / Auto Mode (follow-up)* | Independent review |
*If the parent session or frontmatter specifies
bypassPermissions, that takes precedence. The distributed template currently usesbypassPermissions, so Auto Mode is a follow-up rollout target and not the default behavior.
--codex)A mode that delegates all implementation to Codex CLI via the official plugin codex-plugin-cc:
# Task delegation (writable)
bash scripts/codex-companion.sh task --write "task content"
# Via stdin (for large prompts)
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# Write task content
cat "$CODEX_PROMPT" | bash scripts/codex-companion.sh task --write
rm -f "$CODEX_PROMPT"
breezing [scope] [--codex] [--parallel N] [--no-discuss] [--auto-mode]
│
↓ Load harness-work with team mode
│
Phase 0: Planning Discussion (skipped with --no-discuss)
Phase A: Pre-delegate (team initialization)
Phase B: Delegate (Worker implementation + Reviewer review)
Phase C: Post-delegate (integration verification + Plans.md update + commit)
The Lead outputs progress in the following format each time a Worker completes a task:
📊 Progress: Task {completed}/{total} done — "{task_subject}"
Example output:
📊 Progress: Task 1/5 done — "Add failure re-ticketing to harness-work"
📊 Progress: Task 2/5 done — "Add --snapshot to harness-sync"
📊 Progress: Task 3/5 done — "Add progress feed to breezing"
Design intent: Breezing often involves long-running execution. This allows users to see "how far along things are" at a glance when checking the terminal. The task-completed.sh hook outputs equivalent information via systemMessage, complementing the Lead's output.
Even in Breezing mode, reviews follow the unified policy of Codex exec first → internal Reviewer fallback.
See the "Review Loop" section of harness-work for details.
cc:done [{hash}]After all tasks are complete, the Lead generates a rich completion report with the following steps:
git log --oneline {base_ref}..HEADgit diff --stat {base_ref}..HEADcc:TODO / cc:WIP tasks from Plans.mdharness-work's "Completion Report Format"The Lead generates this report, not Workers or hooks. The Lead reads git + Plans.md during Phase C to produce it.
Before executing all tasks, verify plan health with the following 3 questions.
All are skipped when --no-discuss is specified.
Q1. Scope confirmation:
"Executing {{N}} tasks. Is the scope appropriate?"
If too many, suggest narrowing by priority (Required > Recommended > Optional).
Q2. Dependency confirmation (only when Plans.md has a Depends column):
"Task {{X}} depends on {{Y}}. Is the execution order correct?"
Read the Depends column and display the dependency chain. Error if circular dependencies exist.
Q3. Risk flag (only when [needs-spike] tasks exist):
"Task {{Z}} is [needs-spike]. Should we spike it first?"
If there are incomplete [needs-spike] tasks, confirm whether to run the spike first.
If all 3 questions pass, proceed to Phase A (designed to complete in 30 seconds total).
When Plans.md has a Depends column (v2 format), tasks are executed following the dependency graph:
- first. If multiple independent tasks exist, they can be spawned in parallelNote: The "Worker complete → review → cherry-pick" cycle for each task is sequential. Only the Worker spawn portion of independent tasks (Depends is
-) can be parallelized.
Codex uses native subagents.
Key control surfaces are spawn_agent, wait, send_input, resume_agent, close_agent.
Claude Code vs Codex communication API (SSOT: API mapping table in
team-composition.md):
- Claude Code:
SendMessage(to: agentId, message: "...")to send fix instructions to Workers- Codex:
resume_agent(agent_id)to resume Workers →send_input(agent_id, "...")to send instructionsPseudo-code in harness-work is written in Claude Code syntax. Translate to the above when running in a Codex environment.
harness-work — From single tasks to team execution (core)harness-sync — Progress synchronizationharness-review — Code review (auto-triggered within breezing)