| name | service-design-builder |
| description | Obsidian の vault 配下にサービス設計ドキュメントを段階的に積み上げて構築する（Obsidian MCP が使えない環境では Notion に退避）。新規サービス（個人開発・業務問わず）の設計セッションを最初から最後まで支援するときも、既存サービスの情報を整理して体系化するときも、このスキルを使う。ユーザーが「サービス設計したい」「サービス設計のドキュメントを作りたい」「既存サービスを整理したい」「設計ドキュメントの体系を作りたい」と言ったとき、あるいはサービスのアイデア・コンセプトを話し始めたときは、たとえ「設計」という言葉が使われていなくても、このスキルを使うべきかどうかを必ず検討する。 |
service-design-builder
サービス設計を「ノート単位で段階的に積み上げる」進め方を再現するスキル。保存先は Obsidian の vault をプライマリ、Notion をフォールバック退避先 とするデュアル構成。スマホからの利用時など Obsidian MCP が使えない環境でも壁打ちを継続できる。
このスキルの目的
サービス設計の議論は、論点が多くて散らかりやすい。anttt（海外開発ニュースを日本語化するサービス）の設計セッションで確立した進め方を、他のサービスにも適用できる形にしたのがこのスキル。
具体的にやること:
- Obsidian vault の指定フォルダ配下に、サービス設計のドキュメントを「ノート単位で」積み上げる（Obsidian MCP が使えなければ Notion に退避）
- コア共通骨格（どのサービスでも必要な論点）は最初に対話で埋める
- 運用系共通骨格と実装ドキュメントは、フェーズに応じて追加する
- サービス固有の論点は対話の中で察知して、ノート化するか提案する
- 新規サービス設計でも、既存サービスの情報整理でも使える
- Notion に退避していた設計を後で Obsidian に取り込む「移行コマンド」も持つ
いつ使うか
このスキルは以下の場合に発動する:
- ユーザーが「○○というサービスを作りたい」「サービス設計したい」と言ったとき
- ユーザーが「サービスの設計をまとめたい」「Obsidian / Notion に設計を残したい」と言ったとき
- ユーザーが「既存のサービスを整理し直したい」と言ったとき
- サービスのアイデアやコンセプトを話し始めたが、明示的に「設計」と言っていないとき（積極的に提案する）
- ユーザーが「Notion から Obsidian に移行して」と言ったとき（移行モード、後述）
ノートのカテゴリ分類
ドキュメントは 4 つのカテゴリに分かれる:
A. コア共通骨格（12 ノート）
どんなサービスにも必須の論点。サービス設計セッションの最初に固める。
- サービス憲章
- ペルソナ
- 使用シーン
- 機能スコープ
- 技術スタック
- アーキテクチャ・ディレクトリ構成
- ロードマップ
- 計測ツールとKPI
- 法務 / 利用規約 / プライバシー
- セキュリティ・運用
- 開発プロセス
- エレベーターピッチ
B. 運用系共通骨格（3 ノート）
公開・運用フェーズに入るなら必須。Phase 1 の終盤〜 Phase 2 で追加するイメージ。
- 非機能要件（パフォーマンス、可用性、スケーラビリティ目標）
- 管理者機能（管理画面の機能設計）
- インフラ・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 が使えるかを判定 する。
obsidian:vault_list（または同等の Obsidian MCP ツール）を試す- 成功 → Obsidian モード（プライマリ）
- ユーザーに「vault 内のどのフォルダに置くか」を vault 相対パスで聞く（例:
Projects/anttt）
- そのフォルダ配下に直接ノートを並べる
- 失敗（ツールが存在しない / エラー）→ Notion 退避モード（フォールバック）
- Notion ルートページは既定値
https://www.notion.so/socialcoffeenote/36d4bdc8accc8089a70fd0dd379fe586 を使う（ユーザーから別途指定があればそちらを優先）
- サービス名を聞いてから、ルートページの直下に「サービス名」サブページを
notion-create-pages で作成する
- その「サービス名」サブページの下に各ノートを並べる（Obsidian の
<フォルダ>/<サービス名>/ 構造と一対一対応させ、後の移行を楽にするため）
- 最初の応答で必ずモードを明示する（後述のテンプレート参照）
Step 1: サービスの素描を聞く
最初に以下を聞く:
- サービス名（仮でも OK）
- 一行で言うと何のサービスか
- なぜ作りたいか / 何の問題を解くか
- 誰のためか（ざっくり）
これは「01. サービス憲章」を埋めるための情報。詳細は次のステップで詰める。
Step 2: コア共通骨格を順番に埋める（A）
references/common-skeleton.md を読んで、各ノートのテンプレートを参照する。
基本順序は:
- サービス憲章
- ペルソナ
- 使用シーン
- 機能スコープ
- 技術スタック
- アーキテクチャ
- ロードマップ
- KPI / 計測
- 法務
- セキュリティ・運用
- 開発プロセス
- エレベーターピッチ
各ノートは Obsidian モードなら obsidian:vault_write、Notion 退避モードなら notion-create-pages で作る（詳細は後述「ノート作成の作法」）。一度に全部作らず、対話で合意できたものから順次作成する。
エレベーターピッチについての注意: 憲章とペルソナが固まったタイミングで書く。書いた結果「ターゲットの定義が憲章と合っていない」のようなズレが見つかったら、憲章やペルソナに戻って整合性を取る。完璧を 1 回で目指さず、何度か書き直すことを前提にする。
Step 3: サービス固有論点を察知する（D）
対話の中で次のような兆候があったら、ノート化を検討する:
- ユーザーが特定の論点について何度も話す
- 1 つの論点で複数の選択肢を比較している
- 数値（料金、頻度、サイズ、品質基準など）の決定をしている
- 他のサービスにはあまり当てはまらない、このサービス固有の判断をしている
察知したら以下のように提案:
「この『○○』、けっこう重要な論点ですね。独立したノートとして残しておきますか?」
ユーザーの YES/NO を待つ。
Step 4: 運用系共通骨格を追加（B）
Phase 1 の機能設計が固まったら、運用系の論点を追加する:
これらは「実装に着手する前 / リリース前」に固めておくと、後で慌てないで済む。
Step 5: 実装ドキュメントを必要に応じて作る（C）
実装フェーズに入るタイミングで、以下のうち必要なものを作る:
- 機能一覧
- パス設計
- モジュール一覧
- ドメインモデリング
- ユビキタス言語
- ワイヤーフレーム（UI が重要な場合）
- CLAUDE.md（Claude Code を使う場合）
詳細は references/wireframe-workflow.md（ワイヤーフレーム）と references/implementation-docs.md（その他）を参照。
Step 6: 既存サービスの整理モード
ユーザーが「既存サービスを整理したい」と言った場合は、以下の流れ:
- 既存サービスの情報源を聞く（README、Obsidian、Notion、ドキュメント、Slack、口頭説明など）
- ユーザーから情報を引き出して、共通骨格にマッピングしていく
- 既存の決定事項を「決定済み」として記録、不明な点は「TBD」として残す
- 必要に応じてサービス固有論点もノート化
ノート作成の作法
ファイル名 / ノートタイトルの命名規則（両モード共通）
<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）
手順
notion-fetch で Notion ルートページ配下の「サービス名」サブページを取得- そのサブページの全子ノートを
notion-fetch で順に取得し、Markdown 化
- 各ノートを Obsidian vault の
<移行先フォルダ>/<サービス名>/ 配下に同名 .md で obsidian:vault_write する
- ファイル名はノートタイトル +
.md（例: 01. サービス憲章.md）
- H1 はそのまま
# <絵文字> <連番>. <タイトル> の形式で先頭に挿入する（Notion 側に icon があったらその絵文字を流用）
- テキスト参照の wikilink 自動変換:
- 各ノート内の
『(\d{2}\. [^』]+)』を参照 形式を [[$1]] を参照 に置換
- パターンに合致しないテキスト参照（連番なしの『〜』など）はそのまま残し、ユーザーに「手動で wikilink にしてください」と通知
- 移行が終わったら結果サマリ（書き出したファイル数、自動変換した参照数、未変換で残った参照）をユーザーに報告
- 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 退避どちらで動いているか把握できるようにする
