docs-snorbe — Claude Code 作業ルール
Snorbe のユーザー向けドキュメント。読者は開発者ではなく一般のビジネスユーザー（R&D 企画 / 知財 / 新規事業 / マーケ等）。リリースノート執筆ルール（最重要）
リリースノートを書くとき・更新するとき、以下を必ず守る。鉄則：ユーザー目線で「何ができるようになるか」を書く
開発者目線の「何を実装したか」を書かない。読者が画面で気づく変化 / 業務で何が楽になるか を書く。1. 開発者用語・内部名を使わない
snorbe-app のコミットメッセージは開発者向け。そのままタイトル・本文にしない。ユーザー向けに翻訳する。| ❌ NG（内部名・開発者用語） | ✅ OK（ユーザー向け表現） |
|---|---|
| AgentRun | エージェントの実行 / 調査タスク |
| Fan-out-join モード | 複数エージェントに一度に依頼するモード |
| HITL（補足なし） | 人とAIの協働（HITL） / 計画段階で人が介入 |
| SSE / WebSocket | 通信 |
| tRPC API / REST API | API |
| JIT プロビジョニング | 初回ログイン時に自動でアカウントが作られる |
| Better Auth に移行 | 認証基盤を強化（実装詳細は省略） |
| Organization をテナント境界として導入 | 組織単位での管理（実装詳細は省略） |
| LLM ベースの識別解決 / N-way 統合 | AIが同じものとして判定して 1 つにまとめる |
| 楽観的 UI 挿入 | クリック直後にすぐ反映 |
| RBAC | 役割ベースの権限管理 |
| FK cascade | 関連データの自動削除 |
| マイグレーション | （省略可） |
| サンドボックスに自動マウント | 次のスキルから自動で参照できる |
| 指数バックオフ | 自動リトライ |
| エントリーポイント | どこから起動されたか |
| ゴーストノード | グラフに薄く表示される関連ノード |
| ピギーバック | 一緒に取得 |
| ネスト形式のピッカー | 階層型の選択UI |
| TDD / プロンプト / プロバイダ | （省略するか、ユーザー向け文脈で言い換え） |
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. 本文の構造（既存フォーマット踏襲）
5. snorbe-app コミットからの翻訳手順
- snorbe-app の
git logで技術的な feat/fix を収集する - 各コミットについて「これでユーザーは何ができるようになるか」を1文で書き出す
- その1文をベースにタイトルと本文を組み立てる
- 内部名・クラス名・関数名・ファイル名・URLパス（
POST /api/...等）を本文から取り除く - ただし 公開 API エンドポイント（
POST /agent/run/{runId}/export等で外部利用者がいるもの）は最後の一文で軽く触れる
6. NG表現が混入していないかの自己点検
書き終えたら以下を grep で確認する。用語統一（用語置換ルール）
| 元の用語 | 統一後 |
|---|---|
| 観点マトリクス | 比較表 |
| 構造化レポート | 調査レポート |
| Human-in-the-Loop | 人とAIの協働（HITL） |
| ホワイトスペース | そのまま（耳馴染みあり） |
| ナレッジグラフ | そのまま |
ファイル構成
ja/— 日本語ドキュメント（主要）en/— 英語ドキュメントja/release-notes/YYYY.mdx— 年単位のリリースノート