> ## Documentation Index
> Fetch the complete documentation index at: https://docs.snorbe.deskrex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# CLAUDE

# 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. 本文の構造（既存フォーマット踏襲）

```
（プロダクトの観点で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 で確認する。

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

ヒットしたら平易な表現に置き換える。

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

| 元の用語              | 統一後           |
| ----------------- | ------------- |
| 観点マトリクス           | 比較表           |
| 構造化レポート           | 調査レポート        |
| Human-in-the-Loop | 人とAIの協働（HITL） |
| ホワイトスペース          | そのまま（耳馴染みあり）  |
| ナレッジグラフ           | そのまま          |

## ファイル構成

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

リリースノート以外のページも同じ「ユーザー目線」ルールを適用する。