Zen implement

Work the agreed brief to observable completion, then return it for review. Read the shared execution contract when coordinating a task or another agent.

1. Resolve the actual TSK UUID/ref, read its full brief and linked specification, dependencies and selected SRT. Confirm the repository, committed base and assigned worktree. Inspect existing dirty work and instructions; never reset unrelated user changes. If no task record exists, establish the brief without inventing one.
2. Load relevant applied feedback/memory and recent handoff; show influencing refs in the brief/report. Verify dependency completion from evidence, not merely a Done label.
3. If already running inside an owner-assigned task, continue with its selected CLI/model/effort and permissions. Launching another coding bot requires its authorized selection and host capability. The current Zen MCP cannot start runs: prepare for owner dispatch instead of inventing a task.run tool. Never silently fall back to a paid or different provider.
4. Trace the existing implementation and choose the smallest complete change. Proceed when clear; resolve material ambiguity using the shared decide-and-ask guidance. Keep contracts stable where possible, separate IO from testable logic and follow repository conventions. Use behavioral tests/TDD when a meaningful seam or regression warrants it; do not add implementation-mirroring tests for cosmetic edits.
5. Implement the whole accepted slice, including relevant error states, documentation and migration behavior. Preserve explicit mock/real boundaries. Unsupported integration, missing credentials or actions outside the assigned scope become a concrete limitation/needs-attention result, not simulated success.
6. Run the affected checks while iterating, then required project gates and a production build where appropriate. Inspect rendered desktop/mobile, focus, contrast and reduced motion for visual changes. Capture exact commands, exit results, revision/diff and output locations. Run actual integration acceptance only when authorized and available.
7. Inspect the final diff against every acceptance criterion. Create a linked LOG or DOC review report using the report template; current MCP has no append-event/evidence tool, so do not fabricate one. Use record.update/task.transition to Review only when warranted and after a fresh read.

Delivery

Report changed behavior, files, decisions/deviations, checks and unresolved criteria. Failed or unavailable proof remains explicit; work is not Done merely because code was written. Do not commit, push, merge, publish or mark Done automatically. A separate review compares the actual diff with the spec; Git delivery remains a concrete owner decision. When the owner later asks for delivery, follow the staging-first, branch-naming and Conventional Commits rules in zen-delivery and prepare the commit and pull request description in that format.

Skill settings

The owner's settings for this skill arrive in a "Skill settings" block. Honour them.

• addTests (default on): when on, add focused tests that describe the new behaviour or the fix. When off, do not add new tests unless the acceptance criteria require them, and state in the report that no tests were added and why.