| 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. 收錄規則（裁決即落檔）
使用者每做一次品味裁決（選案、改措辭、否設計、糾正語氣），收工前追加判例到對應段落（沒有就開新節）：
- 三要素齊備才收：修改前（真實原文，不造稻草人）／修改後（使用者裁決的版本）／判斷點（可遷移的原則）。
- 判斷點寫不出可遷移原則 → 那是一次性偏好，不入庫。
- 收錄時查與既有判例是否矛盾；矛盾＝品味漂移，留新的、刪舊的並註記日期。
