From 6bc5e48357458c38c1fe269006e6a710d668a772 Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Fri, 3 Apr 2026 12:25:29 +0200 Subject: [PATCH] feat: flesh out do-phase skill from stub to full execution protocol --- skills/do-phase/SKILL.md | 145 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 139 insertions(+), 6 deletions(-) diff --git a/skills/do-phase/SKILL.md b/skills/do-phase/SKILL.md index 3b47997..b4f7470 100644 --- a/skills/do-phase/SKILL.md +++ b/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: # New functionality +fix: # Bug fix within the task +test: # Test additions +docs: # 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- (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-` +- 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-` — ready for review +`archeflow/maker-` — ready for review ``` + +For writing domain: +```markdown +## Draft: + +### Scenes Written +- Scene 1: (~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