workflow

name	workflow
description	Required phase order for non-trivial tasks: Plan, Explore, Implement, Verify, Finalize. Load before starting any multi-step work.

• Use references/EXAMPLE.md as the shared example and formatting reference for this skill.
• Keep new guidance, snippets, and future edits aligned with that file.

---

1. Overview

• Use this rule to keep non-trivial work phase-ordered, plan-first, and evidence-driven. The parent agent owns phase transitions, delegation choices, and final synthesis.

---

2. Use This Rule When

• the task is multi-step
• the change touches multiple files or layers
• contracts, hooks, config, runtime flow, or external behavior can change
• verification needs more than a quick local inspection

---

3. Required Phase Order

• Plan
• Explore
• Implement
• Verify
• Finalize

---

4. Core Rules

• Start in Plan for any non-trivial task.
• Stay in planning until implementation is justified by repository evidence.
• Use local code, config, docs, and call sites before editing.
• Re-plan when new evidence changes scope, assumptions, dependencies, contracts, or risk.
• Do not skip directly from Plan to Finalize unless no edit is needed.
• Pause implementation when a blocker changes the expected surface or scope.
• Keep Verify after implementation and before handoff.

---

5. Phase Guidance

5-1. Plan

• define the requested outcome
• identify likely files and coupled surfaces
• decide whether delegation shortens the critical path
• decide the minimum validation surface

5-2. Explore

• gather only enough evidence to unblock safe implementation
• identify entry points, callers, dependencies, and contract edges
• stop when the changed surface is clear enough to proceed

5-3. Implement

• apply the smallest coherent change that fully solves the request
• stay inside confirmed scope
• if comment edits are part of the implementation, apply the comments skill as a core rule
• avoid speculative cleanup, renaming, or architecture drift

5-4. Verify

• validate the changed surface at the right depth
• prefer real commands, parser checks, tests, or bounded end-to-end checks
• re-run the failing path after a fix when execution is available

5-5. Finalize

• summarize the change surface and verification
• state blockers, residual risk, and unverified areas explicitly

---

6. Validation Focus

• Confirm implementation only after repository evidence supports the changed surface.
• Validate the directly changed files, contracts, or runtime path before handoff.
• Re-run the failing path after a fix when execution is available.
• Report unverified areas instead of implying coverage.

---

7. Formatting

• Keep phase names exactly as Plan, Explore, Implement, Verify, and Finalize.
• Keep status updates short and tied to the current phase.
• Keep final synthesis separate from exploration notes.

---

8. Boundaries

• Do not treat exploration as a license for broad refactoring.
• Do not keep implementing after the contract surface has become unclear.
• Do not claim verification you did not actually run.