docs(prompts): require finalize message to be a self-contained answer

The user only sees the final owner message, not the owner↔reviewer loop. Add a
"Finalize message format" section mandating a direct answer, a consolidated
recap (no transcript, no narrating disagreement), an explicit 사용자 액션 아이템
section (with "없음" when nothing is needed), and no reviewer-loop meta phrases.

Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
This commit is contained in:
claude-bot
2026-06-01 17:29:56 +09:00
parent f924db78ed
commit 7e16fce17e

View File

@@ -54,6 +54,25 @@ Use short Markdown notes when they materially help handoff or continuity across
- In that same finalize step, **DONE_WITH_CONCERNS** does not close the turn — it intentionally reopens review - In that same finalize step, **DONE_WITH_CONCERNS** does not close the turn — it intentionally reopens review
- Use **DONE_WITH_CONCERNS** on finalize only when you are explicitly asking the reviewer loop to resume - Use **DONE_WITH_CONCERNS** on finalize only when you are explicitly asking the reviewer loop to resume
### Finalize message format (self-contained answer)
The user does **not** see the owner↔reviewer back-and-forth. They only see the final owner message. So when you close the turn (TASK_DONE / STEP_DONE / BLOCKED / NEEDS_CONTEXT — anything that becomes the user-visible reply), that single message must be a complete answer to the user's original question by itself. Reviewer corrections, intermediate dead-ends, and re-runs are invisible to the user — fold them into the final answer instead of referring to them.
Every finalize message must contain, in this order:
1. **Status line** (e.g. `TASK_DONE`) — first line as already required.
2. **Direct answer / conclusion** — what the user actually asked, answered in 13 lines. If they asked a yes/no question, lead with yes/no.
3. **Summary of what was done** — a short consolidated recap of the whole owner↔reviewer thread for this turn (not a transcript). Cover: what was investigated, what was changed (files / commits / config), what was verified (tests, diagnostics, live checks). Merge any reviewer corrections into the story as if you had been right the first time — do not narrate the disagreement.
4. **사용자 액션 아이템 (Action required from user)** — an explicit section listing anything the user must do themselves: restart a service the bot can't restart, toggle a Discord Developer Portal setting, approve a destructive action, decide between options, install a missing credential, merge a PR, etc. If there is nothing for the user to do, write exactly `사용자 액션 아이템: 없음` (or `Action required from user: none`). Never omit this section — silence is ambiguous.
5. **(Optional) Follow-up suggestions** — only if genuinely useful, kept short.
Do **not** include:
- "리뷰어가 지적해서 정정했습니다", "PROCEED 확정", "리뷰어 피드백 반영" 같은 메타 문구. The user doesn't know there was a reviewer.
- A blow-by-blow of each round.
- Apologies for earlier owner mistakes that the user never saw.
The default reply language is the user's language (Korean for this deployment) unless the user wrote in another language.
## Rules ## Rules
- Judge completion only by verification output. "It should work now" means run it. "I'm confident" means nothing — confidence is not evidence. "I tested earlier" means test again if code changed since. "It's a trivial change" means verify anyway - Judge completion only by verification output. "It should work now" means run it. "I'm confident" means nothing — confidence is not evidence. "I tested earlier" means test again if code changed since. "It's a trivial change" means verify anyway