プロジェクトをセットアップする、スライスごとに
1回の呼び出しにつき1スライス、次の固定ループを通じて実行します：
参照 → 調査 → 配線 → 計画 → 実行 → ローカルゲート → 調整 → プロダクションゲート → 調整 → 手動手順をユーザーに引き渡す → コミット
slices/ ファイルは参照であり、スクリプトではありません。これらは、セットとして検証されたスタックと、より価値のあるものとして、実際に時間を浪費したトラップ（pnpm initが書き込むdevEnginesブロックをcorepackが拒否する、create-next-appがapps/web内で2つ目のpnpmワークスペースを開くなど）をエンコードしています。その推論は維持されます。その周辺のバージョン固定、CLIフラグ、APIの形状は維持されません。参照からスライスをそのまま実行すると、変更された部分で失敗します。
したがって、実行する計画は参照そのものではありません。それは、参照と、調査によって現在真であると判明した情報に基づいて、このプロジェクトのためにプロジェクト内に新たに書き込まれた計画です。そして、その計画は証明される前に書かれるため、ループはゲートがグリーンになった時点で終了しません。計画が、それが存在する両方の場所で実際に機能したものと一致するように修正され、ユーザーが人間にしか確認できないチェックの短いリストを受け取った時点で終了します。
スタックは固定です：pnpmワークスペース · Next.js on Cloudflare Workers via OpenNext · GraphQL Yoga Worker · Drizzle + Postgres（ローカルはDocker、本番はHyperdrive経由のNeon） · Tailwind + shadcn · オプションでResend、Better Auth、Stripe。ユーザーが異なるスタックを希望する場合は、その旨を明確に伝えてください — このスキルには異なるスタックはありません。
0. ディスパッチ
/setup-project [slice] は1つのスライスを構築します。引数はオプションで、スライスを番号または名前（01、web shell、database、auth）で指定します。reference/slices.md に対して解決します。一致するものがなければ、その旨を伝え、推測ではなく名前をリストアップします。
ls docs/setup/ 2>/dev/null # このプロジェクトが実際に構築したスライス
git status --short # ダーティなツリーは、最後のスライスが未完了である可能性を示す
docs/setup/ は構築されたものの記録であり、将来の予測ではありません。 スライスファイルが存在するのは、そのスライスが構築され、グリーンになったからです。したがって、最も番号の大きいファイルが「現在地」への答えであり、同期を保つための別個のマーカーはありません。
スライスが指定されていない場合 — 推奨する前に必ずカタログを表示します。 reference/slices.md のすべてのスライスを番号、名前、および docs/setup/ が構築済みかどうかとともにリストアップし、1つを推奨して、実行前に確認を得ます。これは最初の実行時にも適用されます。最初にプロジェクト名（§1）を確定し、次にカタログを表示し（すべて未構築、次のスライスは00）、構築前に確認します。次のステップが明白に思えても、カタログまたは確認をスキップしないでください。
| 状態 | 何をすべきか |
|---|---|
docs/setup/ がない | 初回実行：プロジェクト名を確定（§1）、カタログを表示、スライス00を確認 |
| スライスが指定されている | それを構築する |
| スライスが指定されていない | カタログを表示、最も番号の大きい構築済みスライス+1を推奨し、確認 |
スライス99はこの計算の対象外です。 これはセキュリティ監査です。何も構築せず、スライス00のみを必要とし、チェーンの一段階としてではなく、存在するものに対して再実行されます。したがって、docs/setup/ 内の 99-security-audit.md はチェーンが完了したことを意味しません。「最も番号の大きい構築済みスライス + 1」はこれを無視する必要があります — 00–05 と 99 を持つリポジトリは、次に構築するスライスが 06 であるリポジトリです。また、--through 範囲からも除外されます。範囲は構築チェーンであり、存在しないスライスの監査をインストールしても何も監査されないからです。公開サーフェスを追加するスライスの後でこれを推奨し、明示的に /setup-project 99 と指定します。
1回の呼び出しで2つのスライスを構築しないでください。スライスがコミットされたら停止します。
飛び越すスライス。 引数が構築済みのものより1つ以上進んでいる場合、飛び越すスライスとそれらが構築するものを指定し、ユーザーに決定させます。チェーンは現実です：04は02と03の両方を必要とし、05–07は以前のスライスが書き込んだファイルにパッチを適用するため、前提条件が欠けていると、警告ではなくハードな docs:check エラーになります。reference/slices.md §依存関係にその理由があります。
1. 初回のみ：プロジェクト名
小文字、数字、ハイフンのみ — npmスコープ（@name/db）およびWorkerプレフィックス（name-web、name-graphql）になります。リポジトリディレクトリ名がすでに適合する場合は、それをデフォルトにします。1回だけ尋ねます。以降のスライスはすべて package.json からそれを読み取ります。
2. 参照スライスを読む
slices/NN-*.md を、他のすべてに先立って完全に読みます。また、reference/slices.md を読んで、このスライスのゲートが何を証明し、どのアカウントが必要かを確認します。コードブロック間の散文は、その価値を保持する部分です — 推論のために読み、すべてのバージョン番号、フラグ、ファイルパスを、事実としてではなく検証すべき主張として扱います。
スライスにユーザーが持っていないアカウント（Cloudflare、Neon、Resend、Stripe）が必要な場合、今その旨を伝えます。アカウントがなくても計画の作成は妨げられませんが、ローカル側がすでにコミットされた状態で、スライスをプロダクションゲートの途中で行き詰まらせます。
後方を見て、前方は見ないでください。 プロジェクトがすでに持っているもの — docs/setup/、CLAUDE.md、以前のスライスが書き込んだスキルファイル — を読み、それらが設定した規則に従って、このスライスがそれらを再発明するのではなく適合するようにします。逆は決して起こりません。どのスライスも、後のスライス（名前の有無を問わず）が構築されることを前提としません — 構築されるかどうかは、ディスパッチ時（§0）のユーザーの判断であり、参照が当てにできるものではありません。確立された規則が、このスライスが必要とするものに対して今は間違っているように見える場合は、その旨を伝え、ユーザーに決定させます。黙って上書きしたり、黙って従ったりしないでください。
このスライスが置き換える暫定的な成果物を廃止します。 いくつかのものは、実際のものの前にメカニズムを証明するためにのみ構築されます — packages/mock が最初で最も明確なケースです。スライス0は、実際のパッケージがないときにハーネスを証明するためにそれを作成します。暫定的な成果物は、後継者に名前を決して付けません。なぜなら、どのスライスがそれを置き換えるかは、参照ではなくディスパッチ（§0）で決定されるからです。義務は逆方向に働きます：各スライスは、すでに存在するものを見て、それが冗長にするものの削除を自身の計画に組み込み、それを説明していた CLAUDE.md の行も含めます。
したがって、packages/mock がまだ存在する場合、このスライスはワークスペースが得る最初の実際のものであり、それを廃止することはこのスライスの作業の一部です。同じルールは、後のスライスが残したものすべてに適用されます — 実際のものに置き換えられる静的リゾルバー、バインディングになるプレースホルダー値など。
そのメカニズムは後継者がいる成果物に対してのみ機能するため、後継者がいないものを宣言します。 packages/mock は、実際のパッケージが明らかにそれを置き換えるため、廃止されます。sendTestEmail を明らかに置き換えるものはありません。スライス6は、それに加えて実際の検証メールを追加します。スライス7は、それをスキーマの一部として説明し、実際のメールを送信する認証されていないミューテーションが恒久的な機能として出荷されます。どのスライスも間違っていません — 削除には所有者がいません。後のスライスが気付くのを待つことはメカニズムではなく、希望です。
したがって、すべてのスライスは、「残すもの」 ブロックで終了します。このブロックは、誰かが気付いたときではなく、成果物が作成されたときに書き込まれ、2つのリストを指定します。
- 暫定的 — それが何か、なぜ存在するか、そしてそれを廃止する条件。後のスライスがその条件を満たす可能性が妥当でない場合、その行にその旨を記述します。正直な「これを廃止するものはない」が、機能するエントリです。
- 許容 — 既知のリスク、誰がそれに到達できるか、そしてその理由。後のスライスがそれを再発見するのではなく再決定できるように、そして継承されたデフォルト（本番環境でGraphiQLを提供するYoga）が選択されたものと区別できるように、書き留められます。
スライス99は、これらを相互チェックとして読みます — 決して入力としてではありません。なぜなら、台帳には誰かがすでに書き留めることを考えたものしか含まれないからです。最初にコードを読みます。
3. 現在真であることを調査する
これは参照を安全に使用可能にするステップです。意図的かつ安価に実行します。このスライスがインストールまたは設定するすべてのツールについて、参照ではなく現実を確認します。
npm view <pkg> version # ピンが実際に何であるべきか
npx <cli> --help # フラグ、およびどのプロンプトが非対話型か
次に、スライスが構造的に依存するものすべてについて、公式ドキュメントを読みます — フレームワークの現在のアダプターガイダンス、ランタイムの互換性フラグ、ライブラリの現在のAPI形状。参照によるそれらの要約よりも、ベンダー自身のドキュメントを優先し、それらが矛盾する箇所をメモします。
インストールの出力を、終了コードだけでなく読みます。 別のパッケージに統合されたり、名前が変更されたり、放棄されたりしたパッケージでも、インストールは成功し、同じ名前をエクスポートし、コンパイルも通ります — npm view <pkg> version はそれに対して健全なバージョンを報告し、参照のコードブロックはそれに対してグリーンになります。pnpm add の出力にある [WARN] deprecated … の1行だけがそれを示す唯一の場所です。スライス5はこれが発生した場所です：@react-email/components は5か月前に react-email に統合されており、他に何もそれを伝えていませんでした。
npm view <pkg> deprecated # 空でない場合、参照が死んだパッケージを説明していることを意味する
見つけたものとその場所を書き留めます。参照と現在のドキュメントの間の矛盾がこのステップの全出力であり、それらはこれから書く計画に含まれます。
3b. 既存の構築物に配線する
接続されていない状態で着地するスライスは、誰も正常に動作しているかどうかを判断できないスライスです。計画を書く前に、docs/setup/ が存在すると言っているものを見て、このスライスがどのレイヤーとシームを持つことになるかを問いかけます — そして、そのシームを、決して構築されないかもしれない後のスライスに残すのではなく、このスライスで証明することを提案します。
4つのルールにより、これがスコープクリープになるのを防ぎます。
- 後方のみ。 すでに構築されたスライスに配線します。決して存在しないかもしれない将来のスライスについて推測しないでください — これは
adapting.mdの「スライスはそれ以前の任意のスライスを引用でき、それ以降のスライスを決して引用できない」というルールと同じです。 - プローブであり、機能ではない。 基準は、シームが壊れた場合に失敗するであろう1つのもの です。製品上の決定が必要な場合、それはプローブではなく、独自のスライスです。
- 提案です。 配線はスライスを拡大するため、他のすべてとともに§4のレビューに入り、ユーザーの同意が必要です。
- ゲート行を取得するか、何も証明しません。
プローブは暫定的な成果物であり、§2のルールがすでにその削除をカバーしています：何がそれを置き換えるかについては何も述べず、それを置き換えるスライスがそれを廃止します。
4. 実行計画をプロジェクトに書き込む
node <skill dir>/scripts/install-plan.mjs \
--repo <repo dir> --name <project> --slices NN
<skill dir> は、このスキルがインストールされている場所です：~/.claude/skills/setup-project、~/.agents/skills/setup-project、またはプロジェクト自身の .claude/skills/setup-project。スクリプトはスライスを自身からの相対パスで解決するため、これらのいずれからでも正しく実行されます。
これにより、slices/NN-*.md が docs/setup/ にレンダリングされ、__PROJECT__ と __DOCS__ が解決され、それ以外は何も書きません — インデックスもソースリストもありません。docs/setup/ はスライスファイルのみを保持し、構築されたスライスにつき1つで、ls がインデックスです。何もインストール、構築、またはコミットされません。
スライスファイルがすでに存在する場合は、--force を渡さない限りそのまま残されます。なぜなら、その時点ではそれは参照のコピーではなく、このプロジェクトの実行記録だからです。
次に、それを実行する前に、それが書き込んだものを編集します — これは計画であり、参照のコピーではありません。§3の調査結果を組み込みます。ピンを修正し、移動したフラグを修正し、APIが変更されたステップを調整し、現在のドキュメントが矛盾するものは削除するか書き直します。散文の中で、ファイルの他の部分と同じように、なぜ かを説明します。
参照と比較して何を変更したか、そしてその理由をユーザーに示し、実行前に同意を得ます。計画はこの時点では未検証であり、ユーザーの注意を1分間費やす価値があります。
5. 実行
計画のブロックを順番に実行します。cd 行は、前のブロックがあなたを残した場所から書かれているため、ブロックを並べ替えたり、1つだけを孤立して実行したりしないでください。
失敗を想定してください。この計画は実行されたことがありません。ここでの失敗はループが機能していることであり、ループが壊れていることではありません — それはまさに§7が捕捉するために存在する情報です。原因を修正し、それが何であったかをメモし、続行します。
6. ゲート — 3ラウンド、この順序で
スライスは3つのパスで証明され、それらは1つのことのバリエーションではありません。2つはあなたが実行し、それに基づいて行動するためのもので、3つ目は引き継ぎです。最初の2つの各々は、計画とこのスキル（§7）を修正することで終了します — 次のものが開始する前に、壊れたものがまだ目の前にあるうちに。代わりに最後に一度だけ調整すると、ローカルでの教訓が本番での教訓に埋もれて失われます。
ラウンド 1 — 自動化、ローカル
スライスのラウンド1テーブルを、書かれたとおりに、それが指定する Where 列から実行します — typecheck とテストスクリプトはリポジトリルートから、開発サーバーと preview はパッケージから。この分割は単なる記録管理ではありません。ルートはturboを介してスクリプトをファンアウトするため、「ワークスペースはグリーンか」という質問に答えます。これはゲートが尋ねる唯一の質問です。パッケージ内で同じスクリプトを実行すると、そのパッケージの集計が得られ、別のパッケージが燃えている間もグリーンのままです。すべてのパッケージは2階層下に存在するため、cd ../.. はそれらのいずれからでも戻ります — そしてスライス本体は通常、あなたを間違った場所に置き去りにするため、各行が実行場所を指定する理由はそこにあります。
行を_指定された順序で_実行します。一部の行は、後の行が必要とするものを生成します。終了コードではなく、テストカウントを読みます — passWithNoTests は空の実行をグリーンにするため、「Tests N passed」とゲートが指定するNが唯一の証拠です。コマンドが出力するものを、返すものだけでなく読みます。非推奨通知は、§3の最悪のケースにおける全発見事項です。
失敗したものを修正し、その後今すぐ調整します（§7） — プロジェクトのスライスドキュメントとこのスキルの両方を。
ゲートがまだ1つの複合テーブルであるスライス。 一部のスライスだけがこの3ラウンドの形状を通過しています。残りは、混合されたb…
[以下、元のコンテンツが切断されているため、スライスされていました]
…
7. 調整 — 両方の場所で
調整には2つの段階があります。
-
プロジェクトのスライスドキュメント (
docs/setup/NN-*.md) — 実行計画を、実際に機能したものに更新します。間違っていたバージョン番号、変更が必要だったフラグ、追加が必要だったステップを修正します。参照を修正するのではなく、計画を修正します。ここでの目標は、このプロジェクトの正確な記録を残すことです。 -
このスキル (
slices/NN-*.md) — 参照スライスを、今回の実行から学んだことで更新します。他の人が（または将来のあなたが）このスライスを実行するときに、同じトラップに陥らないようにするためのものです。
調整のルール：
- 参照スライスは、壊れたものを修正するために変更します。プロジェクト固有の詳細（異なるパッケージ名など）を追加するためではありません。
- 変更理由を、コードブロックではなく散文で説明します。
- プロジェクトの調整を先に行います。スキルの調整はその後に、プロジェクトの調整で明らかになった教訓に基づいて行います。
8. 手動手順をユーザーに引き渡す
一部のことは人間だけが確認できます。ブラウザで実際のページを開いたり、本番環境にデプロイされたことを確認したり、認証フローをテストしたりするなどです。
このスライスで自動化されていないすべてのチェックの短いリストを提供します。これらは、どちらかと言えばQAチェックリストであり、指示ではありません。ユーザーは何を確認すべきかを知っています。
9. コミット
すべての変更を、説明的なメッセージとともにコミットします。コミットメッセージはスライス名を含める必要があります。
git add -A
git commit -m "setup: <slice name>"
これでスライスは完了です。次のスライスを推奨するため、§0に戻ります。
スライス00：プロジェクトシェル
プロジェクト構造、pnpmワークスペース、基本的な設定ファイルを作成します。何も構築せず、依存関係もインストールしません。
スライス01：Webシェル
apps/web にNext.jsアプリケーションを作成し、OpenNextの設定と基本的なルーティングを追加します。
スライス02：データベース
Drizzle ORMを使用してPostgresデータベーススキーマを設定し、ローカル開発用のDocker Compose設定と、本番環境用のNeon/Hyperdrive設定を追加します。
スライス03：GraphQL API
apps/graphql にGraphQL Yoga Workerを作成し、データベースとの基本的なクエリとミューテーションを設定します。
スライス04：認証
Better Authを使用して認証を追加します。Webアプリケーションでのサインイン/サインアップフロー、GraphQL APIでの認証ミドルウェアを含みます。
スライス05：UIコンポーネント
Tailwind CSSとshadcn/uiを使用してUIコンポーネントライブラリを設定します。基本コンポーネントとレイアウトの例を含みます。
スライス06：メール
Resendを使用してトランザクションメール（ウェルカムメール、パスワードリセットなど）を設定します。
スライス07：決済
Stripeを使用してサブスクリプションと支払い処理を追加します。Webhook処理と顧客ポータルを含みます。
スライス99：セキュリティ監査
コードベース全体をレビューし、セキュリティ上の懸念事項を特定し、推奨事項を提供します。何も構築せず、以前のスライスで導入された可能性のある問題に焦点を当てます。