golden-examples

name	golden-examples
description	Use when writing a git commit message, Japanese UI copy or app strings (ボタン/エラーメッセージ等の文言), code review comments, or a completion report, especially when tone, formality, verbosity, or review phrasing is uncertain.

🌐 English version · 繁體中文（正本 / canonical）

品味樣本庫（golden-examples）— 骨架

這是骨架版。品味樣本庫的價值全在「你自己的真實裁決」——別人的樣本不能替你定調， 所以本檔只保留機制（用法、收錄規則、格式），§1–4 的內容留白給你填。

用法：動筆前先讀對應段落，模仿「修改後」的形態。每例附判斷點——那是規則寫不出來、 只能從範例吸收的部分。「修改前」要取自真實歷史，不是稻草人。

下面每節的範例都是 <placeholder> 佔位示意，標了「（示意，請替換）」。 用你自己在真實任務裡收到的裁決把它們換掉——第一次收錄前，先把該節的示意例刪掉。

1. Commit message

一句話說明：commit 訊息的讀者是「三個月後查 git blame 的人」；動詞＋對象＋目的才可檢索。

格式示意（請替換）

• 修改前：<被使用者否掉的原始 commit 訊息，例如 "更新程式碼">
• 修改後：<使用者認可的版本，例如 "refactor: 把 X 模組的冗長註解整理成一致風格">
• 判斷點：<這次裁決能遷移到下次的原則——一句話>

2. UI 文案（本 skill 以日文文案為主要場景，見 frontmatter）

一句話說明：UI 文字要合乎目標語言的母語慣例；錯誤訊息兩段式（發生什麼＋使用者能做什麼），error code 進 log 不上畫面。

格式示意（請替換）

• 修改前：<機翻感或口語感的原始字串>
• 修改後：<使用者改成的地道版本>
• 判斷點：<可遷移原則，例如「按鈕用名詞＋動詞、避免片假名直譯」>

3. Code review 評語

一句話說明：評語三要素＝位置＋失敗情境（什麼輸入→什麼壞結果）＋建議；說不出失敗情境的評語降級為 nit 或不提。

格式示意（請替換）

• 修改前：<模糊評語，例如「這裡可以再加強」>
• 修改後：<具體評語，例如「file:line catch 後只 log 沒通知呼叫端，失敗時使用者看到永遠轉圈的 spinner；建議把 Result 傳回上層顯示 error state」>
• 判斷點：<可遷移原則>

4. 對使用者的回報

一句話說明：回報三要素＝做了什麼＋機器證據（編譯/測試輸出、read-back）＋改動範圍；沒有證據的「應該可以」禁止出現。

格式示意（請替換）

• 修改前：<無證據的回報，例如「已修改完成，應該可以正常運作了」>
• 修改後：<有證據的回報，例如「已加入設定，release 級編譯通過（輸出末 5 行如下），只動了設定檔一個檔案」>
• 判斷點：<可遷移原則，例如「先結論後細節；『複雜』『理論上』是遮掩詞，出現代表還沒驗完」>

5. 收錄規則（裁決即落檔）

使用者每做一次品味裁決（選案、改措辭、否設計、糾正語氣），收工前追加判例到對應段落（沒有就開新節）：

• 三要素齊備才收：修改前（真實原文，不造稻草人）／修改後（使用者裁決的版本）／判斷點（可遷移的原則）。
• 判斷點寫不出可遷移原則 → 那是一次性偏好，不入庫。
• 收錄時查與既有判例是否矛盾；矛盾＝品味漂移，留新的、刪舊的並註記日期。