​

docs-snorbe — Claude Code 作業ルール

​

リリースノート執筆ルール（最重要）

​

鉄則：ユーザー目線で「何ができるようになるか」を書く

​

1. 開発者用語・内部名を使わない

​

2. プロダクト名の固有名詞は残してOK

• ✅ Snorbe / Snorbe-Fast / Snorbe-Medium / Snorbe-Quality
• ✅ ナレッジグラフ / 比較表 / 調査レポート / ホワイトスペース
• ✅ カスタムビュー / Visual Map / 計画モード / 自動更新
• ✅ Claude Opus 4.8 / Kimi K2.7 Code / Gemini 3.5 Flash 等のモデル名
• ✅ J-PlatPat / arXiv / PubMed 等の固有データソース名

​

3. タイトルの書き方

• 「何の機能が」「どうなったか」を 動詞 + 結果 で書く
• ❌ 「AgentRun の操作強化（停止・削除・キャンセル）」← 内部クラス名
• ✅ 「実行中の調査を途中で止める・削除できるボタン」
• ❌ 「メンション機能の Fan-out-join モード」← 開発者用語
• ✅ 「複数エージェントに一度に依頼する新モード」

​

4. 本文の構造（既存フォーマット踏襲）

（プロダクトの観点で1〜2文の導入。ユーザーが何ができるようになるかをまず伝える）

### 何が変わったか

- 箇条書きで具体的な変化を3〜5項目
- 内部実装の話ではなく、画面・操作・成果物の変化を書く

### こんな場面で役立ちます

- ユーザーの業務文脈での使いどころを2〜3項目

​

5. snorbe-app コミットからの翻訳手順

1. snorbe-app の git log で技術的な feat/fix を収集する
2. 各コミットについて「これでユーザーは何ができるようになるか」を1文で書き出す
3. その1文をベースにタイトルと本文を組み立てる
4. 内部名・クラス名・関数名・ファイル名・URLパス（POST /api/... 等）を本文から取り除く
5. ただし 公開 API エンドポイント（POST /agent/run/{runId}/export 等で外部利用者がいるもの）は最後の一文で軽く触れる

​

6. NG表現が混入していないかの自己点検

grep -nE "AgentRun|tRPC|SSE|fan-out|HITL|sandbox|migration|JIT|RBAC|Organization|楽観的|サンドボックス|ピギーバック|ゴーストノード|ネスト|FK cascade|merge プロンプト|N-way|エントリーポイント|フォロアップ" ja/release-notes/*.mdx

​

用語統一（用語置換ルール）

​

ファイル構成

• ja/ — 日本語ドキュメント（主要）
• en/ — 英語ドキュメント
• ja/release-notes/YYYY.mdx — 年単位のリリースノート