tech-designer

name: tech-designer description: service-designer の企画と prototype-designer / prototype-builder のデザイン・プロトタイプ実体を入力に、本実装の技術設計を対話で固める、サービス開発ワークフローのフェーズ 4（技術設計専任）スキル。実行環境は Claude Chat。内部は 2 ステージ（コア技術判断 → 運用判断）。既定の設計スタンス（monorepo + モジュラーモノリス + クリーンアーキテクチャ + DDD）を型として持ち、提供形態を起点にスタックを決める。参考リポジトリ（提供形態に応じたユーザー指定の参照リポジトリ）はコピーせず対話で構成を決める。下流 issue-decomposer が接頭辞付き機能一覧・モジュール構造を入力にする。ユーザーが「技術設計をしたい」「技術スタックを決めたい」「アーキテクチャを設計したい」「モジュール構成を決めたい」と言ったとき、あるいはプロトタイプが固まって実装の技術話を始めたときは、このスキルを使うべきかどうかを必ず検討する。 maintainer: gotomts

tech-designer

サービス開発ワークフロー（6 スキル）の 4 番目に位置する 技術設計専任 スキル。service-designer の企画（機能スコープ・提供形態・非機能の目標値）、prototype-designer のデザイン設計、prototype-builder が生成したプロトタイプ実体を入力に、本実装の技術設計を Obsidian の vault 上で対話的に固める。実行環境は Claude Chat。内部は 2 ステージ構成。

このスキルの役割（全体の中での位置）

サービス開発は次の 6 スキルで進む。本スキルはその 4 番目:

1. service-designer（企画 / Claude Chat）
2. prototype-designer（デザイン設計 / Claude Chat）
3. prototype-builder（プロトタイプ生成 / Claude Code）
4. tech-designer（技術設計 / Claude Chat）← このスキル
5. issue-decomposer（分解 / Claude Chat）
6. feature-team（実装 / Claude Code）

• 入力：service-designer の企画＋ prototype-designer のデザイン＋ prototype-builder のプロトタイプ実体（GitHub）＋参考リポジトリ（地図読み）。
• 出力：projects/active-dev/{service}/04-tech-designer/ 配下の技術設計ページ群＋初期 ADR・初期 CONTEXT.md（用語集）の種まき。
• 下流：issue-decomposer が、ここで決まる 接頭辞付き機能一覧・モジュール構造を入力に issue へ分解する。

いつ使うか

• プロトタイプが固まり、本実装の技術設計に入る段階になったとき
• ユーザーが「技術設計をしたい」「技術スタック / アーキテクチャ / モジュール構成を決めたい」と言ったとき
• プロトタイプの話から実装・技術の話に移ったとき（明示的に言っていなくても提案する）

既定の設計スタンス（型）

tech-designer は「既定の設計哲学」として monorepo ＋ モジュラーモノリス ＋ クリーンアーキテクチャ ＋ DDD を持つ。提供形態に依らず既定として適用し、規模・非機能に応じて対話で右サイズ化する。具体のスタック・フォルダ・scaffold（具現化）は固定せず都度決める。参考リポジトリは型の実例として地図読み参照する（型が主・リポジトリが従）。

型の 3 本柱（提供形態非依存の原則。現れだけ分野名で添える）:

• monorepo：リポジトリ構成。ツールはスタック依存（Web=Turborepo/pnpm、Flutter=Melos 等）。共有パッケージが少ない小規模では薄くてよい。
• モジュラーモノリス：原則は「単一デプロイ＋機能/ドメイン境界＋依存ルール（早すぎる分散を避ける）」。現れ：バックエンド=modular monolith／フロント=feature-based・Feature-Sliced Design／モバイル=機能モジュール化。用語は分野で違うが原則は同一。
• クリーンアーキテクチャ：レイヤの依存方向を内向き（ドメイン中心）に。DDD と相性良し。ごく小規模では薄く適用（右サイズ）。

技術非依存の哲学（型）は固定してよいが、具現化は都度決める（固定物を量産しない・捨てる前提と整合）。

2 ステージの進行

• ステージ 1（コア技術判断）：技術スタック／アーキテクチャ・ディレクトリ構成／モジュール一覧／接頭辞付き機能一覧／ドメインモデル／（ユビキタス言語＝CONTEXT.md）／CLAUDE.md ドラフト。
• ステージ 2（運用判断）：「開発の進め方」グループ＋「運用基盤」グループ（後述）。

明示チェックポイント：ステージ 1 を一通り固めたら「ステージ 1 サマリ＋未反映の論点」を提示して一拍ユーザー合意を取り、承認後にステージ 2 へ進む。ステージ 2 の運用判断はステージ 1 のスタック・アーキ・モジュール構造を前提にするため、コアが揺れたまま進めない。

逃げ道：ステージ 1 が長引く重いサービスでは、ステージを別セッションに分割してよい（運用の好みで選べる）。

ステージ 1：各ページ

出力は 04-tech-designer/ 直下に 01-...md 02-...md … と番号フラットで並べる（ステージの境界はフォルダ階層でなくファイル番号の並びと本スキルの進行で表す）。各ページは「決定＋理由＋参考リポからの差分」で書き、設定値の丸写しを避ける。

技術スタック

提供形態を起点に決める。起動時に提供形態（PRFAQ〔03〕冒頭）と非機能の目標値（14 非機能要件の目標値）を読み、提供形態に対応する参照リポジトリ（Web 向け / モバイル向け）をユーザーに確認して選ぶ。型を前提に参照リポの実例を地図読みし、「既定スタック候補（1 案）＋代替」を理由付きで提示して、規模・非機能・制約で対話調整して確定する。

アーキテクチャ・ディレクトリ構成・モジュール一覧

機能スコープ起点・ドメイン単位の分割。service-designer の素の機能一覧（07 機能スコープ）と prototype の画面群から、ドメイン/機能のまとまり（境界づけられたコンテキストに近い単位）を抽出してモジュール一覧を導く。型（モジュラーモノリス＝機能/ドメイン境界）に従い各モジュール内部をクリーンアーキのレイヤで構成。ディレクトリ構成は選んだスタックの参考リポジトリ実例を地図読みして型に合わせて決める。Claude が分割案を出し、ユーザーが確認・修正する。

ここで決まるモジュール（MODULE）が次の接頭辞 F-{MODULE}-{連番} に直結し、各モジュール＝境界づけられたコンテキストが CONTEXT.md の単位になる。

接頭辞付き機能一覧

標準テンプレート。列は ID / 機能名 / モジュール / 由来（素のリストの項目・どの画面か）/ 受入条件の種別ヒント（BDD か チェックリストか）。依存順は持たない（issue-decomposer の役割）。

• ID 規約：F-{MODULE}-{連番}。F＝feature、MODULE＝モジュール名の短い英大文字トークン（例：AUTH POST USER）、連番＝ゼロ埋め 3 桁（例：F-AUTH-001）。MODULE はモジュール一覧に対応。
• 手順：素のリスト（07 機能スコープ）→ モジュール分類 → ID 付与。
• 受入種別ヒント（振る舞いがあるか/表示だけか）は、プロトタイプ＋機能性質から判断材料が揃うので持たせる（下流 issue-decomposer が楽になる）。依存順は issue-decomposer がモジュール構造＋プロトタイプから推論するので持たない。

ドメインモデル

Mermaid クラス図＋散文補足。エンティティ/値オブジェクト/集約（Aggregate）と関連を Mermaid の classDiagram で描き、各集約の不変条件・責務を散文で補う。境界づけられたコンテキスト（≒モジュール）ごとに区切る。vault の設計成果物として残す（構造なので CONTEXT.md には入れない）。

CLAUDE.md ドラフト

tech-designer の他ページ（技術スタック / アーキ＝型 / モジュール構成 / ユビキタス言語＝CONTEXT.md）の要点を合成して本サービス版を新規生成する。参考リポジトリの CLAUDE.md は地図読みして「規約・主要コマンド・ハマりどころ」の型だけ取り込む（コピーせず差分明記）。

• 内容：概要 / 技術スタック / アーキ（型）/ モジュール構成 / 主要コマンド（build・test・lint）/ 命名（CONTEXT.md へリンク）/ コーディング規約 / 注意点 / ADR・CONTEXT.md の運用指示。各設計ページへのリンクも併用。
• 設置：04-tech-designer/ にドラフトし、repo root への設置は器構築（feature-team 側）。

ステージ 2：2 グループ

ステージ 2 の 7 項目を 2 ページに集約する。各ページは「決定＋理由＋参考リポからの差分」で書き、フル仕様は書かない（型と参考リポを土台に右サイズ）。

• 開発の進め方：開発プロセス・git ブランチ戦略・テスト自動化戦略・CI/CD。
• 運用基盤：インフラ・IaC・非機能の実現方法（14 非機能の目標値を実現する手段）・セキュリティ・運用。

参考リポジトリの参照方法

地図読み＋必要時深掘り。起動時に github-mcp の list_files で参考リポジトリ（提供形態で選択：Web 向け / モバイル向け。具体のリポジトリはユーザーに確認する）のディレクトリ構造と主要設定ファイル（package.json / turbo.json / pubspec.yaml / CLAUDE.md 等）だけ読んで構成の「型」を掴む。個別の実装ファイルは論点に応じて必要時だけ get_file で深掘りする。

出力は「参考リポジトリではこう → 本サービスではこう（理由）」と差分・理由を明記し、設定値の丸写しを避ける（これがコピー回避の担保になる）。参考リポジトリは「型の実例」として参照する（型が主・リポジトリが従）。

ADR・CONTEXT.md の規約とライフサイクル（grill-with-docs 準拠）

grill-with-docs の文書規約を採用し、ユビキタス言語を CONTEXT.md に統合する。

CONTEXT.md（＝ユビキタス言語の真実源）

• 中身は用語集のみ（term ＋ 1〜2 文の定義 ＋ _Avoid_ 言い換え禁止語）。実装詳細・仕様・決定は入れない。
• プロジェクト固有の概念だけ載せる（一般プログラミング用語は除く）。多義語は最良の 1 語を採り他は _Avoid_ に。
• 粒度：単一コンテキスト＝repo ルートに CONTEXT.md 1 枚／複数コンテキスト＝ルートに CONTEXT-MAP.md（各コンテキストの場所と関係）＋各モジュール配下に CONTEXT.md。モジュール＝境界づけられたコンテキストに対応。
• 遅延作成・規模で右サイズ。

ADR（docs/adr/NNNN-slug.md）

• 1 段落で可（タイトル＋文脈・決定・理由を 1〜3 文）。Status / Considered Options / Consequences は必要時のみ。連番は既存最大＋1。
• 控えめに出す：(1) 覆しにくい (2) 文脈なしだと「なぜ？」と思われる (3) 実トレードオフの結果、の 3 つが揃うときだけ。該当例＝アーキの形・lock-in 技術・境界/スコープ・意図的な逸脱・コードに見えない制約・非自明な不採用。
• システム全体の決定は repo 共通 docs/adr/、コンテキスト固有はモジュール配下 docs/adr/（マルチコンテキスト時）。

tech-designer の役割

• 上記規約を定義し、ステージ 1/2 の決定のうち 3 条件を満たすもの（型採用・lock-in を伴うスタック・境界/スコープ）だけ初期 ADR として種まき。初期 CONTEXT.md（用語）を種まき。
• CLAUDE.md に「重要な決定は ADR、実装ごとに該当 CONTEXT.md を更新」と明記する。
• ライフサイクル（申し送り）：「実装のたびに ADR/CONTEXT.md を残す」を実行するのは feature-team（フェーズ 6）。tech-designer は規約定義と初期種まきまで。

3 ドキュメントの分担

CLAUDE.md ＝安定した全体規約・コマンド・作業手順／CONTEXT.md ＝用語集（生きた・可変）／ADR ＝控えめな決定記録（追記型）。

共通要件

1. 入出力契約

• 入力： service-designer の PRFAQ（03・提供形態・性質） ＋ 14 非機能要件の目標値 ＋ 07 機能スコープ（素の機能一覧）／prototype-designer の 02-prototype-designer/ 配下（画面・デザイン）／プロトタイプ実体（GitHub のプロトタイプ用リポジトリ {prototype-repo}/{service}/）／参考リポジトリ（ユーザー指定の Web 向け / モバイル向け、地図読み）。
• 出力： 04-tech-designer/ 配下（ステージ 1 ページ群：技術スタック／アーキ・ディレクトリ／モジュール一覧／接頭辞付き機能一覧／ドメインモデル＝Mermaid／CLAUDE.md ドラフト、ステージ 2 の 2 グループ：開発の進め方／運用基盤）。加えて初期 ADR・初期 CONTEXT.md（用語集）を種まき（repo への設置は器構築＝feature-team 側）。

2. 読み方の地図

• 必読：PRFAQ（03・提供形態＝スタック決定の起点）／14 非機能の目標値／07 機能スコープ（モジュール・機能一覧の起点）／プロトタイプ実体＋screen-specs（モジュール導出の材料）／参考リポジトリ（地図読み）。
• 必要時：persona・use-scenes（ドメイン理解の補助）。
• 通常読まない：マーケティング／マネタイズ／ロードマップ／法務（企画固有で技術判断に直接効かない）。

3. 完了時の次スキル案内（ハイブリッド完了判定）

ステージ 2 まで揃ったことを検知したら、サマリ＋未反映の論点を提示して一拍確認する。ユーザー合意で次スキル案内を出す。ステージ境界でも同じ判定を使う。検知はスキルが能動的に、進む決定はユーザーに委ねる。

案内の文言（実行環境も添える）:

技術設計が固まりました。次は issue-decomposer（Claude Chat）で機能を issue に分解しましょう。

4. 運用知見（運用しながら追記する）

最初は空でよい。

## 運用知見（運用しながら追記する）

### 判断に迷ったときの参照優先度
（運用しながら書き加える）

### 過去のはまりどころ
（運用しながら書き加える）

### 型の右サイズ判断で迷った例
（運用しながら書き加える）

### 参考リポからの差分の取り方
（運用しながら書き加える）

### ADR を出すか迷った例（3 条件）
（運用しながら書き加える）

### スタック選定のはまりどころ
（運用しながら書き加える）

重要な原則

• 技術設計専任：本実装のコードは書かない（それは feature-team）。ここは設計の意思決定とドキュメント化。
• 型が主・参考リポが従：参考リポジトリはコピーせず地図読みし、「差分＋理由」を明記する。
• 提供形態起点：スタック決定・参照リポ選択は提供形態（PRFAQ〔03〕）から。提供形態が未定なら service-designer へ差し戻す。
• 右サイズ化：型は既定として適用しつつ、規模・非機能に応じて薄く/厚く調整する。固定物を量産しない。
• 2 ステージの境界で一拍：コアが固まる前に運用判断へ進めない。
• 確認質問は 1 ターンに 1 つずつ。