service-design-builder

name	service-design-builder
description	Obsidian の vault 配下にサービス設計ドキュメントを段階的に積み上げて構築する（Obsidian MCP が使えない環境では Notion に退避）。新規サービス（個人開発・業務問わず）の設計セッションを最初から最後まで支援するときも、既存サービスの情報を整理して体系化するときも、このスキルを使う。ユーザーが「サービス設計したい」「サービス設計のドキュメントを作りたい」「既存サービスを整理したい」「設計ドキュメントの体系を作りたい」と言ったとき、あるいはサービスのアイデア・コンセプトを話し始めたときは、たとえ「設計」という言葉が使われていなくても、このスキルを使うべきかどうかを必ず検討する。

service-design-builder

サービス設計を「ノート単位で段階的に積み上げる」進め方を再現するスキル。保存先は Obsidian の vault をプライマリ、Notion をフォールバック退避先 とするデュアル構成。スマホからの利用時など Obsidian MCP が使えない環境でも壁打ちを継続できる。

このスキルの目的

サービス設計の議論は、論点が多くて散らかりやすい。anttt（海外開発ニュースを日本語化するサービス）の設計セッションで確立した進め方を、他のサービスにも適用できる形にしたのがこのスキル。

具体的にやること:

1. Obsidian vault の指定フォルダ配下に、サービス設計のドキュメントを「ノート単位で」積み上げる（Obsidian MCP が使えなければ Notion に退避）
2. コア共通骨格（どのサービスでも必要な論点）は最初に対話で埋める
3. 運用系共通骨格と実装ドキュメントは、フェーズに応じて追加する
4. サービス固有の論点は対話の中で察知して、ノート化するか提案する
5. 新規サービス設計でも、既存サービスの情報整理でも使える
6. Notion に退避していた設計を後で Obsidian に取り込む「移行コマンド」も持つ

いつ使うか

このスキルは以下の場合に発動する:

• ユーザーが「○○というサービスを作りたい」「サービス設計したい」と言ったとき
• ユーザーが「サービスの設計をまとめたい」「Obsidian / Notion に設計を残したい」と言ったとき
• ユーザーが「既存のサービスを整理し直したい」と言ったとき
• サービスのアイデアやコンセプトを話し始めたが、明示的に「設計」と言っていないとき（積極的に提案する）
• ユーザーが「Notion から Obsidian に移行して」と言ったとき（移行モード、後述）

ノートのカテゴリ分類

ドキュメントは 4 つのカテゴリに分かれる:

A. コア共通骨格（12 ノート）

どんなサービスにも必須の論点。サービス設計セッションの最初に固める。

1. サービス憲章
2. ペルソナ
3. 使用シーン
4. 機能スコープ
5. 技術スタック
6. アーキテクチャ・ディレクトリ構成
7. ロードマップ
8. 計測ツールとKPI
9. 法務 / 利用規約 / プライバシー
10. セキュリティ・運用
11. 開発プロセス
12. エレベーターピッチ

B. 運用系共通骨格（3 ノート）

公開・運用フェーズに入るなら必須。Phase 1 の終盤〜 Phase 2 で追加するイメージ。

13. 非機能要件（パフォーマンス、可用性、スケーラビリティ目標）
14. 管理者機能（管理画面の機能設計）
15. インフラ・IaC（Terraform などの構成管理）

C. 実装ドキュメント（オプション、必要に応じて）

実装フェーズで作ると役立つドキュメント。サービスの複雑さによる。

• 機能一覧（実装すべき機能の網羅リスト）
• パス設計（URL ルーティング）
• モジュール一覧（コードのモジュール構造）
• ドメインモデリング（エンティティ・関連）
• ユビキタス言語（ドメイン用語集）
• ワイヤーフレーム（UI 設計）
• CLAUDE.md（Claude Code 向け開発指示）

D. サービス固有論点（可変）

そのサービス特有の論点。対話の中で察知してノート化する。anttt の例:

• カテゴリ設計（記事に付けるカテゴリの設計）
• 要約品質基準（LLM 要約の文字数・口調）
• 重複記事の扱い（複数ソースから来た同じ記事の扱い）
• クロール頻度・コスト管理
• 翻訳プラン設計・マネタイズ
• ソース定義

詳細は references/service-specific-prompts.md を参照。

進め方の基本原則

対話的に積み上げる

一気に全ノート作るのではなく、論点ごとに対話で詰めながら、合意できたものから保存先（Obsidian vault または Notion）にノートとして書き出していく。

ノートのタイトルには 2 桁の連番を付ける

01. サービス憲章、02. ペルソナ のように先頭に番号 + ピリオド + 半角スペース + タイトルを入れる。Obsidian のサイドバーでも Notion のサイドバーでも順序が保たれる。

番号は議論した順に振る

anttt では「コア共通骨格 → サービス固有論点 → 運用系共通骨格 → 実装ドキュメント」の順で番号を振っていた。これは「議論した順」が反映されているため。新しいサービスでも同じように「議論した順 = 番号順」で OK。後から再分類して番号を振り直す必要はない。

コア共通骨格を最初に終わらせる

サービスの種類に関わらず必要な論点（A の 12 ノート）を先に固める。順番は柔軟だが、まずこの 12 ノートが揃ってから次のフェーズに進む。

サービス固有論点は察知して提案する

対話の中で「これはこのサービス特有の重要な論点だ」と感じたら、「これをノート化しませんか?」と提案する。ユーザーが YES なら作成する。NO なら作らない。

押し付けない

ユーザーが「これは不要」と言ったらスキップする。anttt と同じ構成を強制しない。

進め方のフロー

Step 0: 保存先モードの判定とルート確認

スキル起動時に、まず Obsidian MCP が使えるかを判定 する。

1. obsidian:vault_list（または同等の Obsidian MCP ツール）を試す
2. 成功 → Obsidian モード（プライマリ）
   • ユーザーに「vault 内のどのフォルダに置くか」を vault 相対パスで聞く（例: Projects/anttt）
   • そのフォルダ配下に直接ノートを並べる
3. 失敗（ツールが存在しない / エラー）→ Notion 退避モード（フォールバック）
   • Notion ルートページは既定値 https://www.notion.so/socialcoffeenote/36d4bdc8accc8089a70fd0dd379fe586 を使う（ユーザーから別途指定があればそちらを優先）
   • サービス名を聞いてから、ルートページの直下に「サービス名」サブページを notion-create-pages で作成する
   • その「サービス名」サブページの下に各ノートを並べる（Obsidian の <フォルダ>/<サービス名>/ 構造と一対一対応させ、後の移行を楽にするため）
4. 最初の応答で必ずモードを明示する（後述のテンプレート参照）

Step 1: サービスの素描を聞く

最初に以下を聞く:

• サービス名（仮でも OK）
• 一行で言うと何のサービスか
• なぜ作りたいか / 何の問題を解くか
• 誰のためか（ざっくり）

これは「01. サービス憲章」を埋めるための情報。詳細は次のステップで詰める。

Step 2: コア共通骨格を順番に埋める（A）

references/common-skeleton.md を読んで、各ノートのテンプレートを参照する。 基本順序は:

1. サービス憲章
2. ペルソナ
3. 使用シーン
4. 機能スコープ
5. 技術スタック
6. アーキテクチャ
7. ロードマップ
8. KPI / 計測
9. 法務
10. セキュリティ・運用
11. 開発プロセス
12. エレベーターピッチ

各ノートは Obsidian モードなら obsidian:vault_write、Notion 退避モードなら notion-create-pages で作る（詳細は後述「ノート作成の作法」）。一度に全部作らず、対話で合意できたものから順次作成する。

エレベーターピッチについての注意: 憲章とペルソナが固まったタイミングで書く。書いた結果「ターゲットの定義が憲章と合っていない」のようなズレが見つかったら、憲章やペルソナに戻って整合性を取る。完璧を 1 回で目指さず、何度か書き直すことを前提にする。

Step 3: サービス固有論点を察知する（D）

対話の中で次のような兆候があったら、ノート化を検討する:

• ユーザーが特定の論点について何度も話す
• 1 つの論点で複数の選択肢を比較している
• 数値（料金、頻度、サイズ、品質基準など）の決定をしている
• 他のサービスにはあまり当てはまらない、このサービス固有の判断をしている

察知したら以下のように提案:

「この『○○』、けっこう重要な論点ですね。独立したノートとして残しておきますか?」

ユーザーの YES/NO を待つ。

Step 4: 運用系共通骨格を追加（B）

Phase 1 の機能設計が固まったら、運用系の論点を追加する:

• 非機能要件
• 管理者機能
• インフラ・IaC

これらは「実装に着手する前 / リリース前」に固めておくと、後で慌てないで済む。

Step 5: 実装ドキュメントを必要に応じて作る（C）

実装フェーズに入るタイミングで、以下のうち必要なものを作る:

• 機能一覧
• パス設計
• モジュール一覧
• ドメインモデリング
• ユビキタス言語
• ワイヤーフレーム（UI が重要な場合）
• CLAUDE.md（Claude Code を使う場合）

詳細は references/wireframe-workflow.md（ワイヤーフレーム）と references/implementation-docs.md（その他）を参照。

Step 6: 既存サービスの整理モード

ユーザーが「既存サービスを整理したい」と言った場合は、以下の流れ:

1. 既存サービスの情報源を聞く（README、Obsidian、Notion、ドキュメント、Slack、口頭説明など）
2. ユーザーから情報を引き出して、共通骨格にマッピングしていく
3. 既存の決定事項を「決定済み」として記録、不明な点は「TBD」として残す
4. 必要に応じてサービス固有論点もノート化

ノート作成の作法

ファイル名 / ノートタイトルの命名規則（両モード共通）

<2 桁連番>. <タイトル> の形式。連番のあとはピリオド + 半角スペース。例:

• 01. サービス憲章
• 02. ペルソナ
• 06. アーキテクチャ・ディレクトリ構成

Obsidian モードでは末尾に .md を付けたものがファイル名（01. サービス憲章.md）。Notion 退避モードではノートタイトルそのもの。

Obsidian モードでのノート作成

obsidian:vault_write を使う。ファイルは vault 内のユーザー指定フォルダ直下に置く。

{
  "path": "<ルートフォルダ>/01. サービス憲章.md",
  "content": "# 📜 01. サービス憲章\n\n<Markdown コンテンツ>"
}

H1（ファイル先頭の見出し）には 絵文字 + 連番付きタイトル を入れる。これが Obsidian における「icon」の代替表現。

Notion 退避モードでのノート作成

notion-create-pages を使う。parent は「サービス名」サブページの ID（ルートページではない点に注意）。

{
  "parent": {"page_id": "<サービス名サブページの ID>"},
  "pages": [{
    "icon": "<適切な絵文字>",
    "properties": {"title": "01. サービス憲章"},
    "content": "<Markdown コンテンツ>"
  }]
}

Notion では icon プロパティに絵文字を直接設定できるので、それを使う（H1 に絵文字は入れない）。

ノートのアイコン（絵文字対応表）

各ノートに内容を表す絵文字を付ける。Obsidian モードでは H1 先頭に、Notion 退避モードでは page icon プロパティに使う。例:

• サービス憲章 → 📜
• ペルソナ → 👤
• 使用シーン → 🎬
• 機能スコープ → 🎯
• 技術スタック → 🛠️
• アーキテクチャ → 🏗️
• ロードマップ → 🗺️
• KPI → 📊
• 法務 → ⚖️
• セキュリティ・運用 → 🔒
• 開発プロセス → 🔄
• エレベーターピッチ → 🎙️
• 非機能要件 → ⚙️
• 管理者機能 → 👨‍💼
• インフラ・IaC → ☁️
• 機能一覧 → 📋
• パス設計 → 🛤️
• モジュール一覧 → 🧩
• ドメインモデリング → 🗂️
• ユビキタス言語 → 📖
• ワイヤーフレーム → 🖼️
• CLAUDE.md → 🤖

内容のスタイル

• 日本語で書く（ユーザーが日本語の場合）
• 「である」調または「だ」調
• 箇条書き多め、表は適切なところで使う
• 決定事項は明確に書く（曖昧にしない）
• 「TBD」や「要確認」は明示する

コードや構造図

Markdown のコードブロックを活用。例:

```
anttt/
├── apps/
│   ├── web/
│   └── crawler/
└── packages/
    └── database/
```

ノート間の相互参照

モードによって書き方が異なる:

• Obsidian モード: [[<連番>. <タイトル>]] の wikilink を使う。例: 「詳細は [[06. アーキテクチャ・ディレクトリ構成]] を参照」
• Notion 退避モード: テキスト参照にする。例: 「詳細は『06. アーキテクチャ・ディレクトリ構成』を参照」
  • Notion 上での手動リンク化は面倒なので、機械的に判別しやすい鍵括弧表現にしておく
  • 後で Obsidian に移行するとき、正規表現で 『(\d{2}\. [^』]+)』 → [[$1]] に一括変換できる

Notion → Obsidian 移行

ユーザーが「Notion から Obsidian に移行して」と言ったときの動作。Notion 退避モードで作っていた設計を Obsidian vault に取り込む。

前提

• Obsidian MCP が現在のセッションで利用可能であること（使えなければそれを先に伝えて中止）
• 移行元の Notion ルートページと、その下のサービス名サブページが存在すること
• 移行先の Obsidian vault 内フォルダパスをユーザーから受け取ること（例: Projects/anttt）

手順

1. notion-fetch で Notion ルートページ配下の「サービス名」サブページを取得
2. そのサブページの全子ノートを notion-fetch で順に取得し、Markdown 化
3. 各ノートを Obsidian vault の <移行先フォルダ>/<サービス名>/ 配下に同名 .md で obsidian:vault_write する
   • ファイル名はノートタイトル + .md（例: 01. サービス憲章.md）
   • H1 はそのまま # <絵文字> <連番>. <タイトル> の形式で先頭に挿入する（Notion 側に icon があったらその絵文字を流用）
4. テキスト参照の wikilink 自動変換:
   • 各ノート内の 『(\d{2}\. [^』]+)』を参照 形式を [[$1]] を参照 に置換
   • パターンに合致しないテキスト参照（連番なしの『〜』など）はそのまま残し、ユーザーに「手動で wikilink にしてください」と通知
5. 移行が終わったら結果サマリ（書き出したファイル数、自動変換した参照数、未変換で残った参照）をユーザーに報告
6. Notion 側の元ノートは削除しない。ユーザーが手動でアーカイブ / 削除する想定。Notion 削除を提案するときは明示的に確認を取る

参照ドキュメント

• references/common-skeleton.md - 共通骨格（コア + 運用系）の各ノートのテンプレート
• references/implementation-docs.md - 実装ドキュメント（機能一覧、パス設計、ドメインモデリング等）のテンプレート
• references/service-specific-prompts.md - サービスタイプ別の固有論点ヒント
• references/interview-questions.md - 各ノートを埋めるための質問例
• references/anttt-example.md - anttt の実例（ノート構成と固有論点）
• references/wireframe-workflow.md - ワイヤーフレーム作成の流れ

新しいセッションが始まったら、まず references/common-skeleton.md を読んで進め方を確認すること。

ユーザーへの最初の応答テンプレート

Step 0 で判定したモードに応じて、以下のどちらかで応答する。

Obsidian モードの場合

サービス設計のセッションを始めましょう。
（現在 Obsidian モードで動いています。vault に直接ノートを作っていきます。）

進め方の確認:
- 指定された vault フォルダ配下にノート単位で設計を積み上げていきます
- まずコア共通骨格（憲章、ペルソナ、機能スコープ、エレベーターピッチなど 12 ノート）を対話で固めます
- サービス固有の論点は、対話の中で出てきたら「ノート化しますか?」と提案します
- 運用系（非機能要件・管理機能・インフラ）と実装ドキュメントは後のフェーズで追加します

最初に確認したいこと:
1. vault 内のどのフォルダに置きますか?（vault 相対パスで。例: Projects/anttt）
2. これは新規サービスの設計ですか?それとも既存サービスの整理ですか?
3. サービス名（仮でも OK）を教えてください

Notion 退避モードの場合

サービス設計のセッションを始めましょう。
（現在 Obsidian MCP が使えないので、Notion 退避モードで動いています。
 後で「Notion から Obsidian に移行して」と言えば、PC から vault に取り込めます。）

進め方の確認:
- 既定の Notion ルートページ配下に「サービス名」サブページを作り、その下にノート単位で設計を積み上げていきます
- まずコア共通骨格（憲章、ペルソナ、機能スコープ、エレベーターピッチなど 12 ノート）を対話で固めます
- サービス固有の論点は、対話の中で出てきたら「ノート化しますか?」と提案します
- 運用系（非機能要件・管理機能・インフラ）と実装ドキュメントは後のフェーズで追加します

最初に確認したいこと:
1. これは新規サービスの設計ですか?それとも既存サービスの整理ですか?
2. サービス名（仮でも OK）を教えてください

シンプルな質問から始める。確認質問は 1 ターンに 1 つずつ（複数並べない）。

重要な原則

• ユーザーのペースに合わせる: 一気に進めず、各ノートの合意を取ってから次へ
• anttt と同じ構成を強制しない: サービスによって必要なノートは違う
• 「TBD」を恐れない: 全部の決定を一気に出さなくていい、後で埋めればいい
• ユーザーの否定を尊重する: 「それは不要」と言われたらスキップ
• 押し付けがましくしない: 「これも作りますか?」は提案、強制ではない
• 番号を完璧に整える必要はない: 議論した順に番号を振って OK、後で整理し直さない
• モードは最初に明示する: ユーザーが Obsidian / Notion 退避どちらで動いているか把握できるようにする