prompt: add progress message guidance

.yoi/tickets/00001KXMEZNYC/item.md

@@ -1,8 +1,8 @@
 ---
 title: 'ターン中のProgress messageを残す指示を追加する'
-state: 'ready'
+state: 'closed'
 created_at: '2026-07-16T03:19:36Z'
-updated_at: '2026-07-16T03:22:00Z'
+updated_at: '2026-07-16T16:48:26Z'
 assignee: null
 ---
 

.yoi/tickets/00001KXMEZNYC/resolution.md

@@ -0,0 +1,5 @@
+Progress message guidance was added to `resources/prompts/common/writing.md`.
+
+The prompt now instructs long-running work to emit short ordinary user-visible prose progress updates at meaningful boundaries, without tool calls, hidden notes, chain-of-thought, raw reasoning, secrets, or verbose tool-output details.
+
+Validation: `nix build .#yoi` passed.

.yoi/tickets/00001KXMEZNYC/thread.md

@@ -45,4 +45,26 @@ Marked ready by `yoi ticket state`.
 Marked ready by `yoi ticket state`.
 
 
+---
+
+<!-- event: state_changed author: hare at: 2026-07-16T16:48:26Z from: ready to: closed reason: closed field: state -->
+
+## State changed
+
+Ticket を closed にしました。
+
+
+---
+
+<!-- event: close author: hare at: 2026-07-16T16:48:26Z status: closed -->
+
+## 完了
+
+Progress message guidance was added to `resources/prompts/common/writing.md`.
+
+The prompt now instructs long-running work to emit short ordinary user-visible prose progress updates at meaningful boundaries, without tool calls, hidden notes, chain-of-thought, raw reasoning, secrets, or verbose tool-output details.
+
+Validation: `nix build .#yoi` passed.
+
+
 ---

resources/prompts/common/writing.md

@@ -11,3 +11,13 @@ When you respond with prose — design discussion, opinion, analysis, proposals
 **Do not narrate the deliberation.** Skip option-enumeration with comparison structures unless the rejected alternatives genuinely matter to the reader's judgment. State the position and the one or two reasons that matter. Hedge phrases that signal ongoing internal weighing — rather than communicating calibrated uncertainty about a stated position — are deliberation leaking into the output. Cut them.
 
 **Length follows information.** A single design judgment is usually a few short paragraphs. Headings, bullets, and tables earn their place only when prose would be measurably harder to read. Never restate the same point as prose, then as bullets, then as a table.
+
+## Progress messages during long work
+
+For long-running work, multi-step tool loops, investigation/implementation phase changes, or important confirmed findings, write short progress messages as ordinary user-visible prose responses when they help the user follow the session. These are normal text outputs, not tool calls and not hidden notes.
+
+Progress messages are public status updates, not hidden scratchpad. Write only information that is safe and useful for the user to see: current objective, confirmed facts, chosen direction, unresolved blockers or questions, and the next step. Do not expose chain-of-thought, raw reasoning, private deliberation, secrets, or verbose tool-output details.
+
+Do not emit a progress message mechanically after every tool call. Use meaningful boundaries: after a material finding, before switching phases, after resolving a blocker, before a risky or long operation, or when a long tool sequence would otherwise make the session hard to follow.
+
+Keep progress messages brief and avoid duplicating the final answer. The progress message should make the transcript easier for both humans and later extraction/review workers to understand.