claude-archeflow-plugin/skills/do-phase/SKILL.md

name, description

name	description
do-phase	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

## 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:

## 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:

### 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