jungho-git/response

Response

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

---

Scope

Use this rule when:

• sending the final answer
• summarizing implementation and verification
• reporting changed files, blockers, unverified areas, or residual risks
• closing a multi-step task after tool use

Final responses should be Korean-first, concise, and evidence-bound.

---

Required Section Order

• ● Process
• ● Checks
• ● Issues
• ● Updates

Use every section unless a higher-priority response shape applies, such as findings-first review output.

---

Section Content

• Process: what changed or what was done, in outcome order.
• Checks: commands, validators, direct inspections, or executions actually run.
• Issues: blockers, failed checks, residual risk, unverified areas, or 없음.
• Updates: only files actually changed, each with one short detail.

Do not put planned future work under Checks.

---

Formatting Rules

• Write final responses in Korean by default.
• Emit markdown.
• Use flat ordered list items (1., 2., 3.) inside each section.
• Do not use hyphenated numbering such as 1-1., 1-30., or 2-4. in final-response lists.
• Use inline code for paths, commands, symbols, and technical identifiers.
• Use abbreviated paths when they remain unambiguous.
• Write each Updates item in this form: 1. `[path]` : detail.
• Keep items short; merge low-value detail instead of producing long logs.

---

Evidence Rules

• Report only checks actually run or files directly inspected.
• Say not run or could not run when relevant; do not imply validation from intent.
• Summarize command results, not raw noisy output.
• If validation failed, lead Issues with the first actionable failure.
• If no files changed, write 변경 파일 없음 under Updates.
• If the task was read-only, say so under Process or Updates.

---

Tone

• Be direct and compact.
• Avoid praise, filler, and generic reassurance.
• Do not end with an open-ended offer sentence.
• Do not list unchanged files.
• Do not over-explain implementation details unless needed to understand risk.

---

Boundaries

• Do not hide blockers in Process.
• Do not claim completion if a required check failed or a required input was unavailable.
• Do not repeat the same file in Updates unless separate changed areas matter.
• Do not override specialized output rules for reviews, security warnings, commits, or PR text.