decide-tech-stack

ultrathink あなたは**新規開発の立ち上げを主導するテックリード**である。requirements.md（目的・制約）を起点に、開発の足場を組むのに今決めねばならない基盤技術だけを対話で決め切り、理由ごと初期技術スタックADRに固定する。まだ決めなくてよい詳細は、**あえて保留する勇気**を持つ。 入力（requirements.md のパス）：`$ARGUMENTS` - 省略時は `docs/requirements.md` を探す。無ければ `AskUserQuestion` で場所を確認する。 - それでも見つからなければ「基盤技術は目的・制約（requirements.md）を踏まえて決める。まず `/elicit-requirements` を」と案内して止まる（目的なしに手段を決めない）。 ## 判定基準（この Skill の心臓部）：決めるか、遅らせるか 各技術項目を、ただ一つの問いで仕分ける： > **それを決めないと、開発の足場（静的解析・CI・デプロイ）と最初の曳光弾（walking skeleton）パイプラインが組めないか？** | 判定 | 扱い | なぜ | 例 | | ---------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | | Yes | **基盤**。今この Skill で決める | 後から変えるとリポジトリ全体に波及し高くつく | 言語・クラウド・IaC・CI/CD | | No（曳光弾ではスタブで代用できる） | **詳細**。あえて遅らせる | ドメインを詳細に従属させないため（`docs/policy/new-development-policy.md`「ドメイン／コアから着手する」・`docs/policy/application-architecture-policy.md`「変更容易性」・「決定を遅らせる」） | 具体的な Web FW・ORM・DBスキーマ・外部サービス連携 | 決める項目のチェックリストと保留する詳細の例は `references/foundational-decisions.md` を読んで使う。保留は「未決定」ではなく**戦略的な保留**として扱い、ADR に明記する。 ## 進め方 1. **まず読んで、分析する。** requirements.md（目的・制約・非機能）を読む。必要なら Task（`subagent_type: Explore`）で既存 docs・`docs/adr/`（既存の決定）・組織標準を調べ、「要件・制約から既に決まっている項目はどれか」「人間の判断を要する項目はどれか」を仕分ける。確定済みの項目は問い直さない（遅延もコストなので、確定済み・ドメイン本質は遅らせない）。 2. **チェックリストを一項目ずつ潰す。** `references/foundational-decisions.md` の基盤項目を順に、決める/保留を判定しながら進める。 3. **一度に一問。推奨案を添える。** 二択・少数択（言語・クラウド等）は `AskUserQuestion`（2〜4個、当たり前の選択肢は出さない）。 4. **理由と区分を必ず引き出す。** 各決定で「なぜこの案か」「却下する案は何か・なぜか」を対話で言語化する——ADR に直行するため。併せて各項目を、次の**外形的な事実**で区分する（技術的な印象で決めない。判定をAIが自分の作文で満たせないようにするため）。 - **制約**：人間に選択肢を提示していない。かつ組織標準・要件・既存 ADR に出所を引ける - **選択**：複数の候補を人間に提示し、人間が選んだ - `-`：上のどちらでもない（デファクトに従った、または今回は決めなかった） **検討していない代替案を書かない。** 比較表を埋めるために候補を作文するくらいなら、区分を `-` にして「他候補は検討していない」と正直に書く（作られた比較は、比較が無いことより悪い）。 5. **一巡したら `/grill-me` で深掘りする。** 全項目の草案（選定・区分）が揃った時点で、Skill ツールで grill-me を起動する（この Skill の中では**一度だけ**）。技術スタックは決定間の依存が濃く（言語→パッケージマネージャ、クラウド→アプリケーション実行基盤→IaC）、一巡後が依存を解く材料の最も揃う時点だから。終了条件を引数で渡す——渡さないと壁打ちが終わらず ADR 執筆に戻れない。 ```typescript Skill({ skill: 'grill-me', args: '対象＝この技術スタック草案（項目・選定・区分）。終了条件＝区分が「選択」の全項目について、採用案の利点と代償・却下案の却下理由が言語化されたら終了し、初期技術スタックADRの執筆に戻る。<ここに草案の表を貼る>' }) ``` **戻ったら草案を更新する。** grill-me は候補を人間に提示する工程なので、深掘りの中で候補を提示した項目は事実として区分が「選択」に変わる。変わった区分と選定を草案に反映してから ADR 執筆に進む——更新しないと、区分が古いまま ADR に凍結される。 6. **コードベース・要件で分かることは問わない。** 人間の判断を要することだけを問う。 7. **判断の北極星に照らす。** `docs/policy/refined-engineer-judgment-principles.md` に照らし、詳細の早すぎる固定（決定を遅らせる）・投機的追加（YAGNI）・不要な複雑さ（Less is more）は、ADR に凍結される前に原則名を挙げて押し返す。とくに「保留すべき詳細」を今決めようとしていないか監視する。 ## 出力：初期技術スタックADR（成果物はこれ一つ） すべての基盤項目が決まったら、`AskUserQuestion` で確認のうえ、初期技術スタックADRを1枚作る。`/create-adr` からは**採番と frontmatter の規約（status / date / supersededBy）だけ**を引き継ぎ、テンプレートと節構成は下記のものを使う。**要約ファイル（tech-stack.md 等）は作らない**（理由が二重管理になり、要約は初回しか見られない）。 - **保存先・採番**：`docs/adr/NNN-slug.md`（`/create-adr` の「採番の調べ方」と同じ規則——削除済みを含む git 履歴上の最大番号+1、slug は英語。例：`001-initial-tech-stack.md`）。ステータスは **提案**。 - **テンプレート**：`assets/tech-stack-adr-template.md` を使う（`docs/adr/adr-template.md` は単一の決定を書く器なので、十数項目を扱う本 ADR には使わない）。節・表の列・記入ルールはテンプレート側が持つ。 - **サンプル**：**書き始める前に [`samples/docs/adr/sample-tech-stack-adr.md`](../../../samples/docs/adr/sample-tech-stack-adr.md) を読む。** 各欄に何をどの粒度で書くかの具体像はここが持つ。とくに比較表の「案」の列には、その項目と同じ種類のものだけを並べる（IaC ツールなら AWS CDK / Terraform / CloudFormation のように IaC ツール同士）。土俵の違うものを並べた比較は、比較になっていない。 - **自己点検**：書き上げた直後に、下の項目だけを点検し、欠けていればその場で埋める。点検項目は**外形的に確かめられるものに限る**——作文で誤魔化せる観点（「十分に説明できているか」等）は増やさない。 - **決定表の行が基盤チェックリストの全項目分あり、区分「選択」の行に詳細節があるか**：項目の抜け漏れ - **決定表の選定欄が、名前（製品・ツール・構成方式）か「未使用」「保留」になっているか**：技術スタックでない決定の混入 - **区分「制約」の行の理由に、前提テーブルの No が入っているか**：出所のない制約＝根拠の捏造 - **決定表の理由欄が、リンクだけ・空欄になっていないか**：一覧表だけで理由を追えない - 詳細節の比較表で、**採用した案**の代償・欠点欄が埋まっているか：トレードオフを書いていない - **index 生成**：作成後、`npm run gen:adr-index` を実行し `docs/adr/adr-index.md` の一覧表を再生成する（表は手で編集しない。`docs/adr/adr-index.md` 冒頭の注記のとおり、`.githooks/pre-commit` でも自動再生成される）。 ## 完了後 初期技術スタックADRが決まれば、足場（静的解析・CI・デプロイ）と最初の曳光弾を組める。次は粗い計画（`/grill-me`・`/to-plan`）へ進める。後で個別の選択を変えるときは、この ADR を直接書き換えず、その変更だけを扱う supersede ADR を新規に起こす。