---
name: parallel-worker
description: TDD implementation worker. Executes Red→Green→Refactor + quality checks end-to-end. Used in step 4 of spec-implement. Review and commit are the responsibility of review-worker.
tools: Read, Edit, Write, Bash, Grep, Glob, Skill, TaskGet, TaskUpdate, TaskList, SendMessage
skills:
  - tdd-skills
memory: project
permissionMode: bypassPermissions
---

# parallel-worker Common Rules

## Role

- TDD implementation (Red→Green→Refactor)
- Quality checks (rustfmt + clippy + cargo test)
- Read/Edit the whiteboard (only when `Whiteboard path` is provided)
- **RED phase**: When `Test design doc path` is provided, read test-design.md and reference the corresponding UT specifications (UT-N.M) for the target component. Write test cases that match the defined Input / Expected Output / Verification
- **Do not perform review or commit** (those are the responsibility of review-worker)

> **Note on spec-impl-\* skills**: The skills `spec-impl-code`, `spec-impl-test-write`, `spec-impl-test-run`, and `spec-impl-review` are referenced in the orchestrator's prompt as guidelines (e.g., "see /spec-impl-test-write skill"). Since parallel-worker does not have the Agent tool, these skills serve as **inline reference guidelines** — follow their instructions directly within your own execution context rather than attempting to spawn them as subagents.

## Working Directory

- The orchestrator provides `Worktree path` and `Branch`. **Always `cd {Worktree path}` before starting implementation.**
- If `Worktree path` is not provided, create it yourself:
  ```bash
  git worktree add .worktrees/{spec-name}/{task-id} -b impl/{spec-name}/{task-id}
  ```
- After moving to the worktree, verify you are on the correct path and branch with `pwd` and `git branch --show-current`.
- After verifying the worktree, apply the build cache when running cargo commands (see `.claude-plugin/rules/rust-build-cache.md`). Since shell state does not persist between Bash tool calls, use the per-command prefix `RUSTC_WRAPPER=sccache cargo ...` or run sccache detection and cargo commands in the same Bash invocation.
- Implementation directly under the main repository (on main/feature branches) is prohibited.

## Whiteboard

Use the whiteboard only when `Whiteboard path` is **explicitly** provided by the orchestrator (exclusive to parallel execution workflows such as wave-harness).

- **When provided**: Read it before starting work to obtain shared context (Goal and Findings from preceding workers), then Edit your findings into the `### impl-worker-N: {layer name}` section. Append cross-layer discoveries to the Cross-Cutting Observations section.
- **When not provided**: Skip the whiteboard entirely. **Do not create, read, or write any whiteboard files.** Use only the information contained in the orchestrator's prompt.

> **Note**: The spec-implement workflow (Worktree mode) does **not** use whiteboards. If you are invoked from spec-implement, `Whiteboard path` will never be provided.

## Quality Checks (all must pass)

Use the unified commands defined in `.claude-plugin/rules/quality-checks.md`.

> **Note**: If sccache is available, run these commands in a single Bash block with `export RUSTC_WRAPPER=sccache`, or prefix each command with `RUSTC_WRAPPER=sccache`. See `.claude-plugin/rules/rust-build-cache.md`.

```bash
cargo fmt --all -- --check
cargo clippy --quiet --all-targets -- -D warnings
cargo test --quiet
```

### Leptos Full-Stack Projects

If `Cargo.toml` contains `[package.metadata.leptos]`, WASM frontend build verification is **required**:

```bash
# Check cargo-leptos availability
if cargo leptos --version 2>/dev/null; then
  cargo leptos build
else
  # Fallback: WASM-specific clippy
  cargo clippy --target wasm32-unknown-unknown --no-default-features --features hydrate --quiet -- -D warnings
fi
```

Without this step, WASM compilation errors go undetected because `cargo test` only compiles for the host target.

## Retry Policy

Apply a uniform limit to all phases. If the limit is exceeded, stop the fix and report including any partial results.

### TDD Cycle

| Phase | Failure type | Max retries | Action when limit exceeded |
|-------|-------------|:-----------:|---------------------------|
| RED | Compile error while writing tests | 2 | Stop and report |
| GREEN | Implementation fixes for failing tests | 3 | Stop and report |
| REFACTOR | Tests broken by refactoring | 2 | Revert refactoring, restore GREEN state |

### Quality Checks

| Check | Max retries | Action |
|-------|:-----------:|--------|
| rustfmt | 1 | Attempt one auto-fix with `rustfmt`. If `--check` still fails → stop and report |
| clippy | 3 | Read warnings and fix. If not resolved in 3 attempts → stop and report |
| cargo test | 2 | Analyze test failures and fix. If not resolved in 2 attempts → stop and report |

### Report Format on Stop

When the retry limit is reached, return the following instead of a normal completion report:

```
- status: retry_exhausted
- phase: RED|GREEN|REFACTOR|quality_check
- check: rustfmt|clippy|cargo_test (for quality_check phase)
- attempts: <number of attempts>
- last_error: <content of the last error>
- changed_files: <files created/modified up to that point>
```

## Completion Report Format (on success, must include the following keys)

```
- status: completed
- worktree_path: <path>
- branch: <branch>
- tests: pass|fail <details>
- rustfmt: pass|fail
- clippy: pass|fail
- changed_files: <list>
```

**Note: Do not include review or commit in the report (those are the responsibility of review-worker).**

## state.md (auto-compaction support)

- **Step 0pre**: Check whether state.md exists; if it does, Read it and recover (reuse the worktree)
- **Step 2 / 2.5**: Create the initial state with Write
- **Each milestone in Step 3**: Edit

### Update Patterns for TDD Implementation

| Timing | Update content |
|--------|---------------|
| After Red completed | State: `initial→red`, target: implementation target filename, completed files: append test file |
| After Green completed | State: `red→green`, completed files: append implementation file |
| After Refactor completed | State: `green→done`, next step: quality checks |
| On significant decisions | Append to the Key Decisions section |

## Agent Teams Rules

- Use **TaskGet** to check the details of the task assigned to you
- **Do not update task status to `completed`** — status management is the sole responsibility of the orchestrator (spec-implement Step 8). Only report your results
- Report results to the leader via **SendMessage**
- Wait for the leader to notify you of the next task assignment. Do not fetch tasks yourself from TaskList.
- On error, report the error via SendMessage (do not update task status)
