Agent Config Adapter

---
name: Autonomous Dev Work
description: End-to-end autonomous development workflow. Plan in outer Claude Code, then delegate implementation to YOLO sandbox. Use when user says "dev work", "implement", "build", "develop", provides a GitHub ticket/issue, or describes a feature/bug to fix.
allowed-tools: Bash, Write, Read, Edit, Grep, Glob, Task, WebSearch, WebFetch, Skill, SlashCommand, Task, mcp__jina__*, Bash(gh:*)
---

# Autonomous Dev Work

**Flow:** Plan → Independent Review → YOLO Sandbox → Cleanup

## Trigger Phrases

- "Dev work on [task]", "Implement [feature]", "Fix [bug]"
- GitHub refs: `#123`, `GH-123`, ticket URLs
- Parallel: "Dev work on #42, #43, #44", "parallel work", "batch"

---

## PHASE 0: RECONNAISSANCE

For the work, decide if taskNotes is already created or not. If they are
created, start with PHASE 3. ELSE proceed to PHASE 1.

## PHASE 1: PLANNING

Run this in Task tool with subagent_type='general-purpose'.

```bash
/codePlanner {github-ticket-id | task-description}
```

Creates `taskNotes/{task-name}/taskFindings.md` with requirements, complexity,
implementation plan.

**CRITICAL:** Do NOT ask user to review. Do NOT wait for approval. Proceed
immediately.

---

## PHASE 2: PLAN DIGEST & HUMAN CHECKPOINT

Extract key signals from the plan for quick human review.

### Extract Signals

Read the plan at `{taskFindings.md path}` and extract ONLY these signals. No
opinions, no recommendations — just extract facts.

Understand that the plan must have `Origina Ask` h2 section.

The rest of the plan is the plan and Original Ask is my requirements.

Ultrathink and analyze the plan against Original Ask to extract these signals:

- Any gaps
- Edge Case
- Potential Bugs
- Can the plan be simplified while still meeting Original Ask?

Respond in this EXACT format:

---
**📋 Plan Digest: {task-name}**

| Signal | Value |
|--------|-------|
| Complexity | Score and summarized reason |
| Gaps found | {list} OR "None" |
| Edge cases | {list} OR "None" |
| Potential bugs | {list} OR "None" |
| Simplifications possible | {yes/no} + brief explanation |
| External deps added | {list} OR "None" |
| Highest risk | {single riskiest part of the plan} |
| Files touched | {count}: {comma-separated list} |
| New abstractions | {count}: {names} OR "None" |
| Existing code modified | {Yes — what / No — additive only} |

**Rejected alternatives:** {what simpler approaches were considered but skipped, and the stated reason — or "None mentioned"}

**Watch for:** {flag anything unusual: schema migrations, auth changes, new patterns, broad refactors — or "Nothing unusual"}
---

### Present & Wait

Display the extracted digest to user. Then show:

```
Ready? [g]o · [t]weak: {feedback} · [r]eject/show full plan
```

**WAIT for user input. Do not proceed autonomously.**

### Handle Response

| Input                                  | Action                                                                |
| -------------------------------------- | --------------------------------------------------------------------- |
| `g`, `go`, `yes`, 👍                   | Proceed to Phase 3 (YOLO)                                             |
| `t: {feedback}` or `tweak: {feedback}` | Update taskFindings.md per feedback, re-run extraction, present again |
| `r`, `reject`, `plan`, `show`          | Display full taskFindings.md, wait for further input                  |
| `stop`, `cancel`                       | Abort workflow                                                        |

## PHASE 3: DELEGATE TO YOLO

### Single Task

For single task run YOLO with:
`/startWork {taskFindings path}, branch: {branch-name}, mode: autonomous`

### Multiple Parallel Tasks

Use git worktrees to isolate each task. Each container mounts its own worktree
directory, preventing git conflicts.

#### Step 1: Create Worktrees

```bash
# Create worktrees with separate branches for each task
/tree feat/task-1,feat/task-2,feat/task-3
```

This creates:
- `trees/feat/task-1/` → branch `feat/task-1`
- `trees/feat/task-2/` → branch `feat/task-2`
- `trees/feat/task-3/` → branch `feat/task-3`

#### Step 2: Spawn Parallel Containers

Each container mounts its own worktree directory. Use Bash tool with
`run_in_background: true` for each container (do NOT use `&` suffix).

**Memory Planning (CRITICAL for parallel):**
| System RAM | --memory flag | Max Parallel |
|------------|---------------|--------------|
| 16GB       | --memory 2g   | 5-6 tasks    |
| 16GB       | (default 4g)  | 3 tasks      |
| 32GB       | --memory 2g   | 12-14 tasks  |

For 3+ parallel tasks, ALWAYS add `--memory 2g`:

```bash
SANDBOX="/root/.claude/skills/yolo/docker-sandbox.ts"
PROJECT="~/project"

# Each container mounts a DIFFERENT worktree
# Run each with Bash tool's run_in_background: true parameter
# Use --memory 2g for parallel execution to avoid OOM
bun $SANDBOX --claude --background --memory 2g --instance-id task-1 --auto-port \
  --prompt "/startWork taskNotes/task1/taskFindings.md, mode: autonomous" \
  $PROJECT/trees/feat/task-1

bun $SANDBOX --claude --background --memory 2g --instance-id task-2 --auto-port \
  --prompt "/startWork taskNotes/task2/taskFindings.md, mode: autonomous" \
  $PROJECT/trees/feat/task-2

bun $SANDBOX --claude --background --memory 2g --instance-id task-3 --auto-port \
  --prompt "/startWork taskNotes/task3/taskFindings.md, mode: autonomous" \
  $PROJECT/trees/feat/task-3
```

Each background Bash call returns an `output_file` path. Use `Read` tool or
`tail` to check progress. Use `TaskOutput` tool to retrieve results.

```bash
# Monitor progress
bun $SANDBOX --status
```

#### Step 3: Merge After Completion

User supervises merging using `/tree merge`:

```bash
/tree status               # Check status first
/tree merge feat/task-1    # Merge and cleanup
/tree merge feat/task-2
/tree merge feat/task-3
```

- The `mode: autonomous` argument tells the slash command to skip user
  confirmations.
- Each worktree is isolated - no git conflicts between parallel tasks.
- User supervises merging of branches after completion.

## PHASE 4: Completion

- After all tasks are implemented, run `/completeWork {task}, mode: autonomous`
  in YOLO to finalize, test, document, and commit changes.
- Exit the sandbox, notify the main process.

## PHASE 6: CLEANUP

After YOLO exits:

```bash
# Find and remove container
docker ps -a --filter "name=ai-sandbox" --format "{{.ID}}" | xargs -r docker rm -f
```

- Ask the user to test the changes once user approves or asks you to move ahead,
  create a PR with all changes made in the branch.

---

## Branch Naming (Parallel Work)

| Pattern               | Use Case         |
| --------------------- | ---------------- |
| `feat/{epic-name}`    | Epic tasks       |
| `feat/{feature-area}` | Related features |
| `batch/{date}`        | Ad-hoc batches   |

---

## Error Handling

| Phase       | Error               | Action                               |
| ----------- | ------------------- | ------------------------------------ |
| Planning    | GitHub API fail     | Retry, then ask user for details     |
| Self-Review | Missing credentials | STOP, inform user                    |
| YOLO        | Build/test fail     | Sandbox fixes and retries            |
| YOLO        | Container fails     | Report error, retry with `--rebuild` |

**NEVER implement in outer Claude Code** - always use YOLO sandbox.

---

## Anti-Patterns

**DO NOT:**

- Ask user to review plan or approve
- Ask user to run `/startWork` or `/completeWork`
- Improvise YOLO prompts - run slash commands with appropriate information
- Implement work in outer Claude Code
- Run `/completeWork` per task (run once at end)
- Mount same directory in multiple parallel containers (causes git conflicts)

**DO:**

- Plan thoroughly in outer (has GitHub, web, memory access)
- Self-review with clear criteria
- Use exact YOLO prompt templates
- Let sandbox handle full implementation
- Cleanup containers after completion
- Use `/tree` to create worktrees BEFORE parallel execution
- Mount each worktree in its own container
- Use `--background` and `--auto-port` for true parallel execution
- Monitor progress with `bun docker-sandbox.ts --status`
- Use `/tree merge` for user-supervised merging after completion

No companion files

Add companion files to enhance this skill