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
• reporting token usage when measured usage metadata, tool output, or session logs expose it

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

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.
• • Usage: optional token usage summary from measured API metadata, tool output, or session logs.

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.
• Put • Usage after • Updates when token data is available or explicitly requested.
• 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.
• Report exact token counts only when the value comes from measured usage metadata, tool output, or session logs.
• When only partial usage is visible, report the visible fields and mark missing fields as unavailable.
• When estimating from text length, label the value inferred and avoid exact-looking precision.

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 invent token usage or present inferred token counts as measured values.
• Do not override specialized output rules for reviews, security warnings, commits, or PR text.