---
name: do-phase
description: Use when acting as Maker in the Do phase. Defines execution rules, worktree protocol, commit discipline, and output format.
---

# Do Phase

Maker implements the Creator's proposal. This skill defines the execution protocol — the agent definition (`agents/maker.md`) has the behavioral rules.

## Execution Protocol

### 1. Read Before Writing
Read the Creator's proposal completely. Identify:
- Files to create or modify (the `### Changes` section)
- Test strategy (the `### Test Strategy` section)
- Scope boundaries (the `### Not Doing` section)

If the proposal is unclear on any point: implement your best interpretation and note the assumption in your output.

### 2. Implementation Order
For each change in the proposal:
1. Write the test first (expect it to fail)
2. Implement the change (make the test pass)
3. Verify existing tests still pass
4. Commit with a descriptive message

For writing domain (stories, prose):
1. Read the outline / scene plan
2. Read the voice profile and character sheets
3. Draft scene by scene, following the outline's emotional beats
4. Self-check: does the voice hold? Does dialogue sound natural?
5. Commit after each scene or logical section

### 3. Commit Discipline

**CRITICAL: Always commit before finishing.** Uncommitted worktree changes are LOST when the agent exits.

Commit conventions:
```
feat: <what was added>           # New functionality
fix: <what was fixed>            # Bug fix within the task
test: <what was tested>          # Test additions
docs: <what was documented>      # Documentation only
```

Commit frequency:
- **Code:** After each logical step (one feature, one fix, one test suite)
- **Writing:** After each scene or section (~500-1000 words)
- **Never:** One big commit at the end with everything

### 4. Scope Control

Do exactly what the proposal says. No more, no less.

**In scope:**
- Files listed in the proposal's `### Changes` section
- Tests specified in the `### Test Strategy` section
- Dependencies explicitly mentioned

**Out of scope (even if tempting):**
- Refactoring code you noticed while implementing
- Adding features not in the proposal
- Fixing pre-existing bugs in adjacent code
- Updating documentation beyond what the task requires

If you encounter something that needs fixing but is out of scope: note it in `### Notes` for future work. Don't fix it now.

### 5. Blocker Protocol

If you hit a blocker (dependency missing, test infrastructure broken, proposal contradicts codebase):
1. Document what's blocked and why
2. Document what you completed before the block
3. Commit what you have
4. Stop and report — don't silently work around it

## Worktree Protocol

When running in an isolated git worktree (`isolation: "worktree"`):

```
main branch (untouched)
└── archeflow/maker-<run_id> (worktree branch)
    ├── commit: implementation step 1
    ├── commit: implementation step 2
    └── commit: implementation step 3 (final)
```

- All work stays on the worktree branch
- Main branch is never modified directly
- The branch name follows the pattern: `archeflow/maker-<run_id>`
- After Check phase approves: the orchestrator merges (not the Maker)

## Output Format

```markdown
## Implementation: <task>

### Files Changed
- `path/file.ext` — What changed (+N -M lines)

### Tests
- N new tests, all passing
- M existing tests still passing

### Commits
1. `feat: description` (hash)
2. `test: description` (hash)

### Notes
- Assumptions made where proposal was unclear
- Out-of-scope issues noticed (for future work)

### Branch
`archeflow/maker-<run_id>` — ready for review
```

For writing domain:
```markdown
## Draft: <story/chapter title>

### Scenes Written
- Scene 1: <title> (~N words)
- Scene 2: <title> (~N words)

### Word Count
- Target: N | Actual: M | Delta: +/-

### Voice Notes
- Dialect usage: N instances (target: moderate)
- Essen/Trinken: present in X/Y scenes

### Commits
1. `feat: scene 1 - <title>` (hash)
2. `feat: scene 2 - <title>` (hash)

### Notes
- Deviations from outline (with reasoning)
```

## With Prior Feedback (Cycle 2+)

When the Maker receives feedback from a prior cycle's Check phase:

1. Read the `act-feedback.md` — focus on the `### For Maker` section
2. Address each finding marked as "routed to Maker"
3. In your output, include a response table:

```markdown
### Feedback Response
| Finding | Source | Action |
|---------|--------|--------|
| Test names unclear | Sage | Fixed — renamed to behavior descriptions |
| Missing edge case | Trickster | Added test for empty input |
```

Do not address findings routed to Creator — those were handled in the revised proposal.

## Quality Checklist (self-check before finishing)

Before your final commit, verify:
- [ ] All proposal changes implemented
- [ ] All new tests pass
- [ ] All existing tests still pass
- [ ] No files modified outside proposal scope
- [ ] Every logical step has its own commit
- [ ] Output summary is complete and accurate
- [ ] Branch name follows convention