jungho-git/workflow

Workflow

• Shared examples and formatting reference: references/EXAMPLE.md.
• Keep new guidance, snippets, and edits aligned with that file.

---

Scope

Use this rule when:

• the task is multi-step
• the change touches multiple files, layers, contracts, schemas, config, or runtime paths
• verification needs more than direct inspection
• delegation, re-planning, or staged progress reporting may reduce risk

Workflow keeps work phase-ordered, evidence-driven, and bounded.

---

Required Phase Order

• Plan
• Explore
• Implement
• Verify
• Finalize

Do not skip a phase for non-trivial work. Compress a phase only when the task is small and evidence is already clear.

---

Plan

• Define the requested outcome and success criteria.
• Identify likely files, contracts, data paths, generated artifacts, and validation surface.
• Consider two to four in-scope approaches when the work is non-trivial.
• Choose the simplest approach that satisfies correctness, robustness, maintainability, and task fit.
• Decide whether delegation shortens the critical path.
• Set a stop condition for exploration and validation.

Plan should be short. It is a control surface, not a design essay.

---

Explore

• Read only the context needed to implement safely.
• Apply the boundary skill before broad searches or file reads.
• Map entry points, callers, dependencies, schemas, configs, tests, and contract edges when they affect correctness.
• Prefer direct source files over generated or cached outputs.
• Stop when the changed surface and required follow-through are clear enough to implement.
• Re-plan when evidence changes scope, dependencies, risk, or assumptions.

Exploration should answer what must change and what must not change.

---

Implement

• Apply the execution skill.
• Apply the matching language or format skill before authoring code or structured content.
• Apply the comments skill when adding or materially changing declarations or section comments.
• Make the smallest coherent change that fully solves the request.
• Include required coupled updates, but avoid unrelated cleanup.
• Preserve unrelated user changes.

Implementation should follow evidence gathered in Explore.

---

Verify

• Apply the validate skill after substantive changes.
• Validate the directly changed surface first.
• Re-run the original failing path when fixing a bug and execution is available.
• Validate coupled contracts, schemas, generated artifacts, or callers when risk is real.
• Report checks that were not run or could not run.

Verification should produce evidence, not confidence wording.

---

Finalize

• Apply the response skill unless a higher-priority final shape is required.
• Summarize changed surface, checks run, blockers, residual risk, and changed files.
• Distinguish edited, inspected, validated, inferred, and unverified states.
• Keep the final answer aligned with the newest user request.

Finalize should be short and grounded in actual work.

---

Re-Plan Triggers

• New evidence changes the target files or required coupled updates.
• A command fails in a way that changes the suspected cause.
• A contract, schema, generated artifact, or external dependency becomes relevant.
• User sends a newer instruction that changes scope.
• Validation exposes a different failure than the one being fixed.

Re-plan before continuing implementation when any trigger changes the path.

---

Delegation Rules

• Delegate read-only exploration, failure isolation, or review when it shortens the critical path.
• Give subagents raw artifacts and task-local context, not conclusions to confirm.
• Keep implementation ownership in the parent unless a worker has a narrow confirmed task.
• Close agents when their result is no longer needed.
• Synthesize agent findings; do not paste them unexamined.

Delegation should reduce uncertainty or parallelize safe discovery.

---

Working Notes

• Maintain a compact state for multi-step tasks: target files, decisions, open risks, and pending checks.
• Update task status when a checklist is visible.
• Compress prior steps into a short state summary when context grows.
• Stop and report partial state instead of retrying blindly at an iteration, time, or cost ceiling.

Working notes should support continuity without becoming user-facing noise.

---

Boundaries

• Do not treat exploration as permission for broad refactoring.
• Do not implement after the contract surface becomes unclear.
• Do not claim verification that did not run or direct inspection that did not happen.
• Do not end with required tool sessions still running.
• Do not let an older request override a newer user message.