atelier-greenfield

Greenfield

最初のコミットから atelier 標準に準拠した、まっさらなリポジトリを作成します。メインの標準がすでに完了しているものとして扱う、たった一つの時点であるリポジトリの誕生を支援するスキルです。素材となる、バリアントごとのブートストラップチェックリストとコピーして使えるゲート用アセットはすでに揃っています。このスキルはそれらを順序立てて実行し、機能コードを1行も書く前に、新しいリポジトリがすべてのゲートに合格し、高速な pre-commit フックと CI 一式がローカルで実行できる状態にします。

常時有効な atelier 標準を補完する、目的を絞った4つのオンデマンドスキルの1つです。atelier-grill-me は意思決定前の段階、atelier-greenfield はリポジトリの誕生時、atelier-review-me はレビューと既存リポジトリへの導入、atelier-distill はメモリの圧縮を担当します。

対話とエージェントの規律：メインの atelier スキルの「Interaction」セクションに従います（簡潔に、まず回答し、em dash を使わず、推奨案を軸に質問は1回にまとめ、最後に次のステップを示す）。次の2つのゲートも適用します。ユーザーの許可なしにコミットやプッシュをしないこと、既存のテストに手を加えないこと（ルール24～25）。

使うタイミング

• 新しい Bun/TypeScript スクリプトリポジトリ、Next.js モノレポ内の新しいパッケージ、または新しい Java（Quarkus）サービスを始めるとき。
• ユーザーが「新しいリポジトリ（またはパッケージ）を標準に沿ってスキャフォールド／ブートストラップ／セットアップして」と依頼したとき。
• 準拠したリポジトリにする必要がある、空またはほぼ空のディレクトリがあるとき。

Greenfield のみを対象とします。すでにコードがあるリポジトリには、メインの atelier スキルを適用してください。内容があるディレクトリにこのスキルを実行しないでください。スキャフォールドによって既存の内容と衝突します。依頼に合わせて作業の強度を調整してください。使い捨ての試作にゲート一式は不要なので、その場合は不要だと伝え、最小限の範囲を提案してください。

実行方法

1. バリアントと対象ディレクトリを確認します。推奨を添えて、質問は1つだけにします。 ディレクトリの構成から判断します。近くに next.config.ts がある packages/* ワークスペースなら Next.js パッケージ、pom.xml があるか Java の指定が明示されているなら Java（Quarkus、Maven：Java の各ゲートは Maven プラグインまたは pom のチェックであるため、Gradle ビルドは対象外です）、それ以外なら Bun スクリプトです。判断内容を伝え、何かに手を加える前に確認します。

2. atelier のアセットを特定します。 ゲートスクリプトとヘルパーは、インストール済みの atelier スキルの assets/ ディレクトリにあります（通常は ~/.claude/skills/atelier/assets/）。そのパスを解決して報告します。見つからない場合は作業を中止し、まず atelier スキルをインストールするようユーザーに伝えます。atelier-greenfield はそこからコピーするものであり、コピーを独自に同梱しているわけではありません。

3. 該当するブートストラップチェックリストに逐語的に従います。 バリアントに対応する番号付きチェックリストを読み、実行します。設定を独自に変更してはいけません。

   • Bun スクリプト → インストール済みの atelier スキルにある references/bun-typescript.md（§ ブートストラップチェックリスト）：レイアウト、tsconfig、フラット ESLint 設定、Result ＋ Logger のポート／アダプター／フェイク、アセットのコピー、カバレッジゲート、Stryker、2つの Git フック、CI ワークフロー（assets/ci.yml と assets/check-commit-messages.sh、--no-verify による回避を検出するルール23の再チェック、およびスコープを限定した CVE ウォッチドッグである assets/audit.yml）、bunfig.toml。
   • Next.js → インストール済みの atelier スキルにある references/nextjs-monorepo.md（§ ブートストラップチェックリスト）：パッケージのレイアウト、tsconfig／eslint／postcss／next.config、simple-git-hooks、globals.css、src/components/{atoms,molecules,organisms} ＋ src/page ＋ src/lib ＋ src/config のツリー、および呼び出すスクリプトとともに CI ワークフロー（assets/ci-next.yml、assets/audit.yml）。
   • Java → インストール済みの atelier スキルにある references/java-quarkus.md（§ ブートストラップチェックリスト）：Maven ラッパー付きの Quarkus スキャフォールド、標準の pom と Quarkus の追加分、domain／usecases／infra／api／composition パッケージ、sealed Result、Flyway、およびそのリファレンスの「Gates and hooks」のコピーブロックにあるすべてのフック、CI、ゲート用アセット。手書きせず、全体をそのままコピーします（一部だけのコピーではフックまたは CI の最初のステップで失敗します）。 すべてのチェックリストで assets/gitattributes を .gitattributes にコピーし、すべてのマシンでテキストが LF でチェックアウトされるようにします（Git for Windows のシステム全体の core.autocrlf=true のもとでは、チェックアウト時に CRLF になり、フォーマッターがすべてのファイルで失敗します）。 すべてのチェックリストでは、本人確認ゲートと、3つのガードを備えた規律ラッパー（check-identity.sh、check-disciplines.sh、check-pii-channels.sh、check-io-deadlines.sh、check-data-lifecycle.sh。ルール26、27、29、30）もコピーします。フックはステージされた行に対してこれらを実行し、CI は --all 付きで実行します。分離ガード（check-isolation-tests.sh、ルール28）はオプトインです。リポジトリがテナントまたはオーナーにサービスを提供する場合はこれをコピーし、ラッパーの隣で呼び出します。すべてのチェックリストでは、返信ゲート（check-reply.py を scripts/ に、claude-settings.json を .claude/settings.json に）もコピーします。これは Git フックではなく Claude Code の Stop フックであり、「Interaction」セクションの機械的なルールに反する返信を1回だけ書き直します。また、すべてのチェックリストでは、ルール38のウォッチドッグ（check-branches.sh、check-host.py、host-ruleset.json を scripts/ に、branches.yml を .github/workflows/ に）もコピーします。リポジトリは main から開始します（まだリポジトリではないディレクトリでは git init -b main）。オーナーの承認を待って最初のプッシュが完了した後、python3 scripts/check-host.py --apply を提案し、承認を得たら実行します。オーナーの管理者トークンを使って main をデフォルトブランチにし、保護を設定して、リベースのみのマージとヘッドブランチの削除を有効にします（references/workflow.md、ブランチのライフサイクル）。 両方のフック機構をインストールしてはいけません。Bun スクリプトでは高速ゲート用の .githooks フック、Next.js では simple-git-hooks を使います。Java のバリアントでは独自のゲートチェーンを備えた .githooks を再利用します。

4. バージョンを適切に固定します。 すべての依存関係を bun add／bun add -d で追加し、具体的な ^X.Y.Z に解決されるようにします。"latest" や "*" を手書きしてはいけません（ルール19：ゲート2で拒否されます）。Java では pom に正確なバージョンを指定し、範囲指定や SNAPSHOT 依存関係を使いません（エンフォーサーがブロックします）。

5. ファイルの内容に本人情報を含めないようにします（ルール26）。 コミットメタデータには通常の本人情報が含まれるため、対応は不要です。スキャフォールドされたファイルには本人情報を一切含めません。コメント、LICENSE の権利者行、package.json の author フィールド、フィクスチャに、個人名、雇用主名、クライアント名を書かないでください。権利者文字列が構造上必要な場合は、中立的なハンドル名（例：atelier）を使います。プッシュ後に言及を消すには、git filter-repo による履歴の書き換えと強制プッシュが必要になるため、この段階で検出します。同梱の check-identity.sh は最初のコミットからこれを支えます（フックはステージされた行に対して、CI は --all 付きで実行します）。Git 設定からコミッターの名前とメールアドレスを取得し、雇用主名またはクライアント名は環境変数 IDENTITY_DENYLIST を通じてのみ認識するため、そのリポジトリ用に構築する場合はこの変数を設定します。プライベートリポジトリでは、最初のコミットで内容が private の .github/visibility をコミットします。これによりゲートはブロックせず警告し、CI はホスト側の設定とファイルを照合します。

6. セッションメモリ、README、標準のポインターを用意します。 セッション間のジャーナルが最初のコミットから機能するよう、ヘッダーだけを含む .claude/LESSONS.md を作成します（lessons.md の「最初の実際の教訓とともに作成する」というルールに対する唯一の例外です）。インストール手順、git config core.hooksPath .githooks、および CI ドキュメントのステップが実行するエントリーポイントを記載した ## Verify ブロック（ガイドライン5、references/governance.md）を含む README を作成します。また、メインスキルに同梱されている標準ブロックを使って、リポジトリの CLAUDE.md を作成します。そうすることで、今後のすべてのセッションで標準が決定論的なリポジトリコンテキストに含まれます。スキルの起動はフォールバックであり、仕組みそのものではありません。これは主要な配布手順であり、単なる気の利いた追加ではありません。スキルを一度も起動しないセッションにも標準を適用できます。

   { printf '# CLAUDE.md\n\n'; cat <skill>/assets/claude-md-pointer.md
     if [ -f CLAUDE.md ]; then printf '\n'; sed '1{/^# CLAUDE\.md$/d;}' CLAUDE.md; fi
   } > CLAUDE.md.new && mv CLAUDE.md.new CLAUDE.md
   

   このブロックが上に置かれ、既存の CLAUDE.md（bun init が書き込むもの、または既存のリポジトリ固有のもの）はその下に残り、上書きされることはありません。 このブロックのテキストは assets/claude-md-pointer.md にのみ記載されています。コピーし、再入力しないでください（2 つのコピーは内容がずれていきます。ルール 23 のフックと同じ理由です）。その後、/init を提案し、コードベース固有のドキュメントをファイルに追加します。ポインターブロックは先頭に残します。

7. 最小限のウォーキングスケルトンを用意します。 すべてのレイヤーに触れる、最も薄いエンドツーエンドのスライスです（インストール済みの atelier スキルの references/architecture.md § ウォーキングスケルトンを参照）。Bun スクリプトのリポジトリでは、主要ポート、ブランド化された入力、および確認済みのテストを通じて Result.ok を返すユースケースを 1 つ用意します（ルール 24 に従い、テストを提案して承認を得てから作成します）。Next.js では、単一のアトムをレンダリングするページシェルにテストを組み込んだ、src/lib の純粋関数を 1 つ用意します。Java では、ポートを通じて Ok を返すアプリケーションサービスとその JUnit テストに加えて、401 拒否を含む REST Assured テストを備えたリソースを 1 つ用意します。これは推測に基づくコードではありません。実際にカバレッジとミューテーションテストを通過させ、TDD のループが機能することを示すものです。絶対最小限に留め、何もないスキャフォールドの場合は省略を提案します。

8. グリーンを確認してから、レッドを確認します。 内部ループを実行し、各項目がクリーンであることを確認します。Bun 系の各バリアントでは bun test --randomize（test スクリプト、ルール 36）、bun run lint、bun run typecheck を実行します。Bun スクリプトのバリアントでは bun run coverage と bun run mutate も追加します（Next.js にはカバレッジやミューテーションのゲートはなく、確認には bun run build を使います）。Java では、スケルトンに対して ./mvnw spotless:check verify と PIT を実行します。次に、ゲートが失敗することを確認します（canon 15.10。グリーンしか見たことのないゲートは仮説にすぎません）。それぞれ、ゲート自体を実行し、そのゲート固有の理由でレッドになることを確認します。.githooks/commit-msg は不正な件名を含むファイルを使って実行し、拒否することを確認します（Next では同じファイルで commitlint を実行します）。ゲート 2 は仕込んだ "latest" 依存関係を拒否します。ステージ済み lint ゲートは仕込んだ違反を拒否します。複雑度上限はガード節が 10 個ある関数を仕込み、拒否することを確認します（ルール 35、複雑度 11。Java 側では pmd:check）。TypeScript の各バリアントでは、スタイル禁止ルールが src/domain に仕込んだ class を拒否し（ルール 1）、レイヤーゾーンがドメインへの ../infra インポートを拒否します（ルール 37。静的な Next.js パッケージでは、アトムから分子へのインポート）。Next.js のサーバーパッケージでは、ゾーンが src/domain 内の node:fs を拒否します（ルール 20）。Java では、LayerRulesTest がユースケースをインポートするドメインクラス（ルール 37）または java.nio.file 経由で読み込むクラス（ルール 20）を仕込んで拒否し、PMD が仕込んだ System.out を拒否します（ルール 4）。すべてのバリアントで、IDENTITY_DENYLIST を通じて仕込んだ名前を持つステージ済みファイルは、ID ゲートによって拒否されます（ルール 26。一語だけの Git 名と noreply メールアドレスは除外されるため、コミッターだけでは何も証明できません）。また、クエリー文字列に仕込んだ個人識別子は、規律ラッパーによって拒否されます（ルール 27）。インライン抑制を仕込んだ場合も拒否されることを確認します（ルール 15。TypeScript の各バリアントでは lint が // eslint-disable-next-line を拒否し、Java では check-no-suppressions.sh がステージ済みの @SuppressWarnings を拒否します）。さらに、すべてのバリアントで、ルール 38 のタグを持つマージコミットは範囲ゲートに拒否されます（1 コミットのサイドブランチを git merge --no-ff でマージし、bash scripts/check-commit-range.sh HEAD~1 を実行します）。返信ゲートについては、箇条書きで始まる返信を持つ Stop イベントに bold-lead-in タグを付けると、終了コード 2 で終了することを確認します（echo '{"hook_event_name": "Stop", "last_assistant_message": "- **Plan.** Done."}' | python3 scripts/check-reply.py --hook）。仕込んだものはそれぞれ元に戻します。レッドを確認したあとにグリーンで終わらないブートストラップは、完了していません。

9. 最初のコミットの前に止まります。 スキャフォールドはゲート 1 の上限（10 ファイル、300 行）を超えるため、Conventional Commits のメッセージを添えた最大 10 ファイルずつのスライス（ツールチェーンと設定、ゲートとフック、CI ワークフロー、ウォーキングスケルトン）に分けて反映することを提案し、ユーザーから明示的な承認を得るまで待ちます（ルール 25）。ユーザーが 1 つのコミットを希望する場合、初期スキャフォールドだけは例外として認められた回避策です。ステップ 8 ですべてのフックゲートを手動で実行した後、本文に正当化の理由を記載して git commit --no-verify を実行します（references/workflow.md の「決して回避しない」を参照）。自動でコミットしてはいけません。

出力

すべてのゲートを通過するリポジトリと、1画面で確認できる概要を作成します。選択したバリアント、コピーしたアセット（コピー元も含む）、設定したフック、ファイル内容の同一性チェック（ルール 26）、追加したスクリプト、ウォーキングスケルトンの単一シナリオ、内側ループの結果、確認待ちの最初のコミットメッセージを記載します。

適合する、最もシンプルな、グリーンで実行できるリポジトリをスキャフォールドします。ウォーキングスケルトンは1つのスライスであり、機能ではありません。その先はすべて、メインのアトリエ標準に従い、テストファーストで後から構築します。ここでは、既存リポジトリへのブラウンフィールド導入、デプロイパイプライン、Docker、Web フレームワークの選定は対象外です。CI ゲートのワークフローは対象に含まれます。assets/ci.yml／assets/ci-next.yml／assets/ci-java.yml はブートストラップに含めます（正式なゲート一式です）。ゲートの範囲を超えるもの（デプロイ、環境）のみ対象外です。

このスキルは、標準に沿った舗装路（ゴールデンパス）です。これを使って生まれたリポジトリは、後から準拠を目指すのではなく、最初からすべてのゲートを通過します。手順ではなく、実際の成果物を用意します。最速で始める方法が、そのまま準拠した方法です。新しいリポジトリで個人データを扱う場合、複数のテナントにサービスを提供する場合、または AI モデルを呼び出す場合は、まとめの概要で適用される本番環境向けの規律（アトリエルール 27〜34）を明記し、最初の機能からそれらを考慮して設計できるようにします。