feat: flesh out do-phase skill from stub to full execution protocol

skills/do-phase/SKILL.md

@@ -1,15 +1,94 @@
 ---
 name: do-phase
-description: Use when acting as Maker in the Do phase. Defines output format and worktree commit rules.
+description: Use when acting as Maker in the Do phase. Defines execution rules, worktree protocol, commit discipline, and output format.
 ---
 
 # Do Phase
 
-Maker implements in an isolated git worktree. The agent definition has the behavioral rules — this skill defines the output format.
+Maker implements the Creator's proposal. This skill defines the execution protocol — the agent definition (`agents/maker.md`) has the behavioral rules.
 
-## Critical Rule
+## Execution Protocol
 
-**ALWAYS commit before finishing.** Uncommitted worktree changes are LOST when the agent exits.
+### 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
 
@@ -24,11 +103,65 @@ Maker implements in an isolated git worktree. The agent definition has the behav
 - M existing tests still passing
 
 ### Commits
-1. `type: description` (hash)
+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-<id>` — ready for review
+`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