aif-build-automation

ビルド自動化ジェネレーター

あらゆるプロジェクト向けに、ビルド自動化ファイルを生成または拡張します。Makefile、Taskfile.yml、Justfile、Magefile.go に対応しています。

2 つのモード：

• 生成 — ビルドファイルが存在しない場合 → ベストプラクティスのテンプレートを使って一から作成します
• 拡張 — ビルドファイルがすでに存在する場合 → 不足点を分析し、欠落しているターゲットを追加し、アンチパターンを修正して、既存の作業を保持します

---

ステップ 0：プロジェクトのコンテキストを読み込む

利用可能な場合は、プロジェクトの説明を読み込みます。

Read .ai-factory/DESCRIPTION.md

後のステップで使用できるように、プロジェクトのコンテキスト（技術スタック、フレームワーク、アーキテクチャ）を保存します。ファイルが存在しない場合も問題ありません。ステップ 2 であらゆる情報を検出します。

.ai-factory/skill-context/aif-build-automation/SKILL.md を読み込みます — ファイルが存在する場合は必須です。

このファイルには、パッチ、コードベースの規約、技術スタックの分析から /aif-evolve によって蓄積された、プロジェクト固有のルールが含まれています。 これらのルールは、現在のプロジェクトに合わせたものです。

skill-context ルールの適用方法：

• このスキルの一般的な指示に対するプロジェクトレベルの上書き設定として扱います
• skill-context のルールが、この SKILL.md に記載された一般的なルールと矛盾する場合は、skill-context のルールを優先します（より具体的なコンテキストが優先されます。ネストされた CLAUDE.md ファイルと同じ原則です）
• 矛盾がない場合は、SKILL.md の一般ルールと skill-context のプロジェクトルールの両方を適用します
• skill-context のルールがこのスキルの既定値に反しているように見えても、無視しないでください — そのルールは、プロジェクトでの経験から既定値が不十分だと判明したために存在します
• 重要： skill-context のルールは、このスキルのすべての出力（生成されるビルドファイル（Makefile、Taskfile、justfile、magefile）を含む）に適用されます。このスキルのテンプレートは基本構造です。 skill-context のルールに「ビルドファイルにターゲット X を必ず含める」または「規約 Y に必ず従う」とある場合は、必ず従ってください。 skill-context のルールに違反するビルド自動化を生成することはバグです。

適用の確認： 出力成果物を生成した後、すべての skill-context ルールに照らして検証してください。 ルールに違反している場合は、ユーザーに提示する前に出力を修正してください。

---

ステップ 1：既存のビルドファイルを検出し、モードを決定する

1.1 既存のビルドファイルをスキャンする

まず、プロジェクトにビルド自動化ファイルがすでに存在するか確認します。

Glob: Makefile, makefile, GNUmakefile, Taskfile.yml, Taskfile.yaml, taskfile.yml, justfile, Justfile, .justfile, magefile.go, magefiles/*.go

結果から EXISTING_FILES のリストを作成します。

1.2 モードを決定する

モード A — 既存ファイルを拡張（EXISTING_FILES が空でない場合）：

• MODE = "enhance" を設定します
• 検出されたファイルから TARGET_TOOL を自動的に設定します（Makefile → makefile、Taskfile.yml → taskfile など）
• 複数のビルドファイルが存在し、かつ $ARGUMENTS で 1 つ指定されている場合は、その引数で拡張するファイルを選択します
• 複数のビルドファイルが存在し、引数が指定されていない場合は、どのファイルを拡張するか尋ねます。

AskUserQuestion: This project has multiple build files. Which one should I improve?

Options (dynamic, based on what exists):
1. Makefile — Enhance the existing Makefile
2. Taskfile.yml — Enhance the existing Taskfile
...

• 既存ファイルの内容を読み込みます — これを拡張のベースラインとします
• EXISTING_CONTENT として保存します

モード B — 新規生成（EXISTING_FILES が空の場合）：

• MODE = "generate" を設定します
• $ARGUMENTS を解析してツールを決定します。

引数	ツール	出力ファイル
makefile または make	GNU Make	Makefile
taskfile または task	Taskfile	Taskfile.yml
justfile または just	Just	justfile
mage または magefile	Mage	magefile.go

• $ARGUMENTS が空、または一致するものがない場合は、ユーザーに対話形式で尋ねます。

AskUserQuestion: Which build automation tool do you want to generate?

Options:
1. Makefile — GNU Make (universal, no install needed)
2. Taskfile.yml — Task runner (YAML, modern, cross-platform)
3. justfile — Just command runner (simple, fast, ergonomic)
4. magefile.go — Mage (Go-native, type-safe, no shell scripts)

選択したツールを TARGET_TOOL として保存します。

---

ステップ 2：プロジェクトを分析する

Glob と Grep を使ってリポジトリをスキャンし、プロジェクトのプロファイルを検出します。すべての技術スタックで同じフローを使用します： 主な言語 → パッケージマネージャー／ビルドのエントリーポイント → フレームワーク → Docker → CI → マイグレーション → テスト → リンター → モノレポ、続いて Summary オブジェクト。JVM プロジェクトも、別のパイプラインではなく、これらのステップの中で処理します。

2.1 主要言語

以下のファイルを確認します (下表の順で最初に一致したものが優先されます)。Java / Kotlin (JVM) の場合は、ビルドファイルから言語を推測します。デフォルトは Java ですが、Kotlin プラグイン / kotlin("jvm") / 支配的な .kt のレイアウトがあれば Kotlin を示唆します。

ファイル / シグナル	言語
go.mod	Go
package.json	Node.js / JavaScript / TypeScript
pyproject.toml または setup.py または setup.cfg	Python
Cargo.toml	Rust
composer.json	PHP
Gemfile	Ruby
JVM: Gradle ルートまたはラッパー (§2.2 を参照)	Java / Kotlin (JVM)
JVM: pom.xml	Java / Kotlin (JVM)
*.csproj または *.sln	C# / .NET

2.2 パッケージマネージャーとビルドエントリポイント

ロックファイルとラッパー (package-lock.json → npm と同じ考え方):

ファイル	パッケージマネージャー / ツール
bun.lockb	bun
pnpm-lock.yaml	pnpm
yarn.lock	yarn
package-lock.json	npm
poetry.lock	poetry
uv.lock	uv
Pipfile.lock	pipenv
gradle/wrapper/gradle-wrapper.properties	./gradlew
.mvn/wrapper/maven-wrapper.properties	./mvnw

Java / Kotlin (JVM) — Gradle と Maven の比較: Gradle は 1 回のバッチ のチェックで検出します (以下のパスに対する単一の Glob、または並列の存在チェック — 冗長な逐次探索は避けてください):

• settings.gradle、settings.gradle.kts、build.gradle、build.gradle.kts (リポジトリルート)、gradle/wrapper/gradle-wrapper.properties

いずれかの Gradle シグナルが一致すれば → Gradle が使われています。pom.xml は Maven を示します。この表から PROJECT_PROFILE.java_build.build_tool を設定します:

条件	build_tool	備考
Gradle シグナルが存在する	gradle	ターゲットを以下の Gradle コマンドに接続します。
Gradle がなく、pom.xml が存在する	maven	ターゲットを以下の Maven コマンドに接続します。
Gradle かつ pom.xml	gradle	java_build.mixed_maven_gradle: true を設定し、PROJECT_PROFILE.warnings に 警告 を追加します (両方のビルドが存在する。レシピは Gradle に従う — ユーザーが正式なビルドを確認する)。

具体的な JVM エントリポイント: ラッパーの存在に基づいて、検出されたエントリポイントを PROJECT_PROFILE.build_entrypoint に保存します:

• build_tool が gradle の場合: gradlew または gradle/wrapper/gradle-wrapper.properties が存在すれば ./gradlew を使用し、そうでなければ gradle にフォールバックします。
• build_tool が maven の場合: mvnw または .mvn/wrapper/maven-wrapper.properties が存在すれば ./mvnw を使用し、そうでなければ mvn にフォールバックします。

信頼できる唯一の情報源: 上記の述語は、JVM テンプレートがシェルで実装している 同じルール です (ENTRYPOINT / entrypoint — ./gradlew または gradle/wrapper/gradle-wrapper.properties をテストし、./mvnw または .mvn/wrapper/maven-wrapper.properties をテストします)。ビルドファイルを生成または拡張するときは、PROJECT_PROFILE.build_entrypoint をそれらのテストが示す 結果 (./gradlew 対 gradle、./mvnw 対 mvn) に設定してください。ユーザーが上書きしない限り (例: Makefile の ENTRYPOINT=…)、その述語とは異なるエントリポイント文字列を出力しないでください。テンプレートはレシピの実行時に再解決されるため、クローンは編集なしで正しいままです。

バージョンカタログ: gradle/libs.versions.toml が存在する場合は、java_build.has_version_catalog を設定し、役立つ場合はコメントで PROJECT_PROFILE.build_entrypoint / カタログの使用法を文書化します。

接続するコマンド (JVM 用の Makefile / Taskfile / Just へ。他のスタックにおける npm run build / pytest と同じ役割。Windows では gradlew.bat を使用します):

目標	Gradle	Maven
完全なコンパイルとチェック	<build_entrypoint> build	<build_entrypoint> verify
単体テスト／統合テスト	<build_entrypoint> test	<build_entrypoint> test
検証（テスト＋設定されている場合は静的解析）	<build_entrypoint> check	<build_entrypoint> verify
パッケージ化のみ	<build_entrypoint> assemble（または jar ／ bootJar）	<build_entrypoint> package
開発サーバー — Spring Boot（§2.3 を参照）	<build_entrypoint> bootRun	<build_entrypoint> spring-boot:run
開発サーバー — Quarkus	<build_entrypoint> quarkusDev	<build_entrypoint> quarkus:dev
開発サーバー — Micronaut	<build_entrypoint> run	<build_entrypoint> mn:run
開発サーバー — Vert.x	<build_entrypoint> vertxRun	<build_entrypoint> vertx:run
Spring Boot — 実行可能 JAR	<build_entrypoint> bootJar	<build_entrypoint> package（spring-boot repackage）
クリーン	<build_entrypoint> clean	<build_entrypoint> clean
マルチモジュール	<build_entrypoint> :subproject:build	<build_entrypoint> -pl module -am package

dev ターゲット（テンプレート＋生成ファイル）： §2.3 と同じ手がかりから、固定の優先順位（最初に一致したものを採用）でフレームワークの開発タスク／ゴールを特定します：Quarkus → Micronaut → Vert.x → Spring Boot。Gradle： build.gradle、build.gradle.kts、settings.gradle、settings.gradle.kts、gradle/libs.versions.toml を、§2.3 で使用するものと同じ grep -E パターン（quarkus ／ io.quarkus、micronaut ／ io.micronaut、Vert.x Gradle プラグイン — vertx-plugin または io.vertx.vertx、Spring Boot — フォールバック）でスキャンします。Maven： pom.xml のみをスキャンします。Vert.x Maven は vertx-maven-plugin または io.reactiverse です。リポジトリのルートがアグリゲーターで、検出に失敗する場合は、テンプレートの開発タスク変数（JVM_MODULE と同じ考え方）を上書きします。

テンプレート： JVM Makefile／Taskfile／Just には、固定カタログが用意されています：lint → Gradle check ／ Maven verify、fmt → spotlessApply ／ spotless:apply、lint-checkstyle、lint-spotbugs、lint-pmd、lint-spotless（Taskfile の lint:*）、db-migrate-liquibase、db-migrate-flyway（Taskfile の db:migrate:*）。マルチモジュールでは、JVM_MODULE とともに module-* を使用します。ステップ 5 では、リポジトリに組み込まれていないカタログ項目を削除します（JVM テンプレートのルールを参照）。

2.3 フレームワークの検出

Node.js プロジェクトでは、package.json の依存関係を確認します。

• next → Next.js
• nuxt → Nuxt
• @remix-run/node → Remix
• express → Express
• fastify → Fastify
• hono → Hono
• @nestjs/core → NestJS

Python プロジェクトでは、pyproject.toml またはインポートを確認します。

• fastapi → FastAPI
• django → Django
• flask → Flask

PHP プロジェクトでは、composer.json の require を確認します。

• laravel/framework → Laravel
• symfony/framework-bundle → Symfony
• slim/slim → Slim
• cakephp/cakephp → CakePHP

Go プロジェクトでは、go.mod を確認します。

• gin-gonic/gin → Gin
• labstack/echo → Echo
• gofiber/fiber → Fiber
• go-chi/chi → Chi

Rust プロジェクトでは、Cargo.toml（ワークスペースメンバーと[dependencies]／[workspace.dependencies]）を確認します。

• axum → Axum
• actix-web → Actix Web
• rocket → Rocket
• warp → Warp

Ruby プロジェクトでは、Gemfile を確認します。

• rails → Ruby on Rails
• sinatra → Sinatra
• hanami → Hanami
• roda → Roda

Java／JVM プロジェクトでは、依存関係とプラグインについてpom.xml、build.gradle*、およびgradle/libs.versions.toml（存在する場合）を確認します。Node.js のpackage.jsonと同じ深さで検出します。

• spring-boot、spring-boot-starter、spring-boot-parent → Spring Boot
• grpc、protobuf、spring-grpc、またはリポジトリ内の*.proto → gRPC／protobuf
• quarkus、io.quarkus → Quarkus
• micronaut → Micronaut
• vertx／Vert.x スタック → Vert.x
• 依存関係またはdb.changelog*内のliquibase → Liquibase（§2.6 を参照）
• pom.xml、build.gradle*、またはgradle/libs.versions.toml内の Flyway org.flywaydb／flyway-core／flyway-maven-plugin／Flyway Gradle プラグイン → Flyway（§2.6 を参照）
• Java 9 以降／Spring Boot 3 以降ではJakarta（jakarta.*）を優先します。両方が見つかった場合は、レガシーなjavax.*の移行が必要であることを示します。

検出結果をframework／java_buildフラグ（spring_boot、grpc、liquibase、flyway）に反映します。他のエコシステムで Express と NestJS を区別するのと同様です。

2.4 Docker（詳細スキャン）

Glob: Dockerfile, Dockerfile.*, docker-compose.yml, docker-compose.yaml, compose.yml, compose.yaml, .dockerignore

いずれかが存在する場合は、HAS_DOCKER=trueを設定し、より詳細な分析を行います。

Dockerfile を読み取り、以下を検出します。

• マルチステージビルド（dev／prodのステージを分離） → DOCKER_MULTISTAGE=true
• 公開ポート → DOCKER_PORTS（例：3000、8080）
• ベースイメージ → DOCKER_BASE（例：node:20-alpine、golang:1.22）
• エントリーポイント／CMD → コンテナ内でアプリを起動する方法を把握します

docker-compose／compose ファイルを読み取り、以下を検出します。

• サービス名 → DOCKER_SERVICES（例：app、db、redis、worker）
• ボリュームマウント → 開発環境と本番環境のセットアップを把握します
• プロファイル（存在する場合） → dev、production、test
• 依存サービス（postgres、redis、rabbitmq など） → DOCKER_DEPS

DOCKER_PROFILEとして保存します。

• has_compose：ブール値
• has_multistage：ブール値
• services：サービス名のリスト
• deps：インフラストラクチャサービス（db、cache、queue）のリスト
• ports：公開ポート
• has_dev_stage：ブール値（Dockerfile にdevまたはdevelopmentステージがあるか）

2.5 CI/CD

Glob: .github/workflows/*.yml, .gitlab-ci.yml, .circleci/config.yml, Jenkinsfile, .travis.yml

使用中の CI システムを記録します。

2.6 データベースとマイグレーション

マイグレーションツールを検索します。

Grep: prisma|drizzle|knex|typeorm|sequelize|alembic|django.*migrate|goose|migrate|atlas|sqlx|liquibase|flyway

以下を確認します。

• prisma/schema.prisma → Prisma
• drizzle.config.ts → Drizzle
• alembic/ディレクトリ → Alembic
• migrations/ディレクトリ → 汎用マイグレーション
• Liquibase — db.changelog*、Gradle／Maven 内のliquibase、またはリソース → Liquibase（JVM など）。**java_build.liquibase: true**を設定します
• Flyway — pom.xml、build.gradle*、またはgradle/libs.versions.toml内の依存関係またはプラグイン（org.flywaydb、flyway-core、flyway-maven-plugin、Flyway Gradle プラグイン）。**java_build.flyway: true**を設定します

2.7 テストフレームワーク

言語	確認項目
Node.js	package.json 内の jest、vitest、mocha、ava
Python	pyproject.toml／requirements 内の pytest、または unittest のインポート
Go	Go には組み込みのテスト機能があります。go.mod 内の testify を確認してください
Rust	組み込みです。統合テスト用ディレクトリ tests/ を確認してください
Ruby	Gemfile 内の rspec → RSpec、minitest／minitest- gems → Minitest、それ以外の場合、Rakefile が存在すればデフォルトの rake test
Java／Kotlin（JVM）	Gradle／Maven／libs.versions.toml 内の junit-jupiter、junit-jupiter-api、JUnitPlatform、JUnit5、testcontainers、mockito、rest-assured、cucumber

2.8 リンターとフォーマッター

フォーマッター／リンターの設定をスキャンします（EditorConfig、JVM の Checkstyle、ESLint／Prettier／Biome、Python ツール、PHP、Go、Rust、Ruby）。

Glob: .eslintrc*, eslint.config.*, .prettierrc*, biome.json, biome.jsonc, .golangci.yml, .golangci.yaml
Glob: checkstyle.xml, .checkstyle.xml, config/checkstyle/checkstyle.xml, .editorconfig
Glob: ruff.toml, .ruff.toml, .flake8, phpcs.xml, phpcs.xml.dist
Glob: rustfmt.toml, .rustfmt.toml, clippy.toml, .rubocop.yml, .rubocop_todo.yml, .standard.yml
Grep in pyproject.toml: ruff|black|flake8|pylint|isort
Grep in build.gradle*, pom.xml: spotless|spotbugs|pmd|errorprone|checkstyle (when not covered by config files alone)

JVM の一致項目を正規化された ID（例：checkstyle、spotless、spotbugs、pmd、errorprone）として PROJECT_PROFILE.linters に統合し、Step 5 で lint／fmt ターゲットを設定するときに使用します。

2.9 モノレポの検出

Glob: turbo.json, nx.json, lerna.json, pnpm-workspace.yaml

まとめ

次の内容を含む PROJECT_PROFILE オブジェクトを作成します。

• language：主要な言語
• package_manager：検出された PM（npm、pnpm、Gradle、Maven、…）
• build_entrypoint：検出された正確なエントリーポイントコマンド（例：./gradlew、mvn、npm、cargo）
• framework：検出されたフレームワーク（存在する場合）。JVM フレームワークも NestJS や Django と同じ方法でここに設定します
• warnings：任意の文字列配列（例：§2.2 にある Maven と Gradle の混在）
• java_build：任意。language が JVM の場合：{ build_tool: "gradle"|"maven", mixed_maven_gradle?: boolean, has_version_catalog: boolean, spring_boot: boolean, grpc: boolean, liquibase: boolean, flyway: boolean }
• has_docker：ブール値
• docker_profile：DOCKER_PROFILE オブジェクト（has_docker が true の場合）
• ci_system：検出された CI（存在する場合）
• has_migrations：ブール値とツール名
• test_framework：検出されたテストランナー
• linters：検出されたリンターのリスト
• is_monorepo：ブール値
• has_dev_server：ブール値（開発サーバーを備えたフレームワーク）

---

Step 3: ベストプラクティスを読む

選択したツールのベストプラクティスに関するリファレンスを読みます。

Read skills/aif-build-automation/references/BEST-PRACTICES.md

TARGET_TOOL に該当するセクションに注目します。

• Makefile → Section 1
• Taskfile → Section 2
• Justfile → Section 3
• Magefile → Section 4

標準ターゲットについては、「Cross-Cutting Concerns」セクションも読みます。

---

Step 4: テンプレートを選択して読み込む

language と TARGET_TOOL に基づいて、最も近いテンプレートを選択します。

ツール	Go	Node.js	Python	PHP	Rust	Ruby	Java / JVM	その他
Makefile	makefile-go.mk	makefile-node.mk	makefile-python.mk	makefile-php.mk	makefile-rust.mk	makefile-ruby.mk	makefile-gradle.mk または makefile-maven.mk	最も近いものを使用
Taskfile	taskfile-go.yml	taskfile-node.yml	taskfile-python.yml	taskfile-php.yml	taskfile-rust.yml	taskfile-ruby.yml	taskfile-gradle.yml または taskfile-maven.yml	最も近いものを使用
Justfile	justfile-go	justfile-node	justfile-python	justfile-php	justfile-rust	justfile-ruby	justfile-gradle または justfile-maven	最も近いものを使用
Magefile	magefile-basic.go	magefile-full.go	magefile-full.go	該当なし（Makefile を使用）	該当なし（Makefile を使用）	該当なし（Makefile を使用）	該当なし（Makefile を使用）	該当なし（Makefile を使用）

Java / JVM の場合は、PROJECT_PROFILE.java_build.build_tool に基づいて Gradle または Maven のテンプレートを選択します。

上記の表にある Go、Node.js、Python、PHP、Rust、Ruby、Java / JVM 以外の language の場合は、構造上のフォールバックとして Node.js テンプレートを使用し、検出された build_entrypoint と言語の慣例（例：dotnet build）に合わせて調整します。

Magefile の場合は、HAS_DOCKER または has_migrations が true なら magefile-full.go を、それ以外の場合は magefile-basic.go を使用します。

PHP、Rust、Ruby、または Java/JVM と Magefile の組み合わせの場合、Mage は Go 固有であり、これらのスタックには通常適していません。このようなプロジェクトでユーザーが明示的に mage を指定した場合は、その旨を説明し、最も近い代替手段として Makefile を提案します（汎用的で、インストール不要です）。Makefile に切り替えて進めるかどうかを AskUserQuestion で尋ねます。

選択したテンプレートを読み込みます。

Read skills/aif-build-automation/templates/<selected-template>

---

Step 5: ファイルを生成または強化する

モード B — 新しいファイルを生成する

PROJECT_PROFILE、ベストプラクティス、テンプレートを参考にして、カスタマイズしたビルドファイルをゼロから生成します。

生成ルール

1. ツールに必要なプリアンブルから始めます（ベストプラクティスを参照）
2. 選択したテンプレートの標準ターゲットをすべて含めます（help/default、build、test、lint、clean、dev、fmt、ci）。JVM：テンプレートは完全な一覧です。モード B では Step 5 の JVM ルールに従ってターゲットを絞り込みます（その場限りの lint レシピを作成しないでください）。
3. プロジェクトプロファイルに基づいて、条件付きターゲットを追加します。
   • Docker ターゲット → has_docker が true の場合のみ
   • データベースターゲット → has_migrations が true の場合のみ（JVM 以外）。**JVM：**対応する java_build フラグが true の場合に限り、正規の db-migrate-liquibase / db-migrate-flyway（または Taskfile の db:migrate:*）を使用し、もう一方は省略します
   • デプロイターゲット → CI/CD が検出された場合のみ
   • Generate ターゲット → コード生成が検出された場合のみ
   • Typecheck ターゲット → TypeScript または mypy が検出された場合のみ
4. 正しいパッケージマネージャーを使用します — PROJECT_PROFILE（§2.2）に合わせます。JVM → <build_entrypoint>（§2.2 から取得）、Node → npm/pnpm/yarn/bun、Python → uv/poetry/pip、Go → go、Rust → cargo、Ruby → Bundler（bundle、bundle exec）。誤ったエコシステムのものに置き換えないでください（例：Gradle のみのリポジトリで npm スクリプトを使う）。
5. CI 集約ターゲットを含めます — デフォルトの ci は JVM では clean + build とします（すでに check/verify を実行します）。絞り込み後も lint / fmt ターゲットが残る場合のみ、これらを ci に追加します。
6. 整理とグループ化にはテンプレートの構成に従います
7. 変数名を実際のプロジェクトに合わせます（モジュール名、バイナリ名、ソースディレクトリ）。JVM のマルチモジュールリポジトリでは、module-* ターゲット用に JVM_MODULE を設定します（§2.2）。
8. git を使ってバージョン／コミット／ビルド時刻の検出を含めます。
9. Docker 対応ターゲット — has_docker が true の場合は、専用の Docker セクションを生成します（以下を参照）。 JVM テンプレートカタログ（名前は固定。Mode B では未使用のツールを削除してください） — 信頼できる情報源は skills/aif-build-automation/templates/*gradle* および *maven* です。ビルドファイルで同じプラグインに別の正式なタスク名が使われている場合を除き、生成ファイルでは常に以下の Gradle／Maven タスク名をそのまま使用してください（その場合は、レシピの隣にコメントで記載してください）。

対象（Make/Just）	Taskfile のタスク	Gradle コマンド	Maven コマンド
lint	lint	check	verify
fmt	fmt	spotlessApply	spotless:apply
lint-checkstyle	lint:checkstyle	checkstyleMain	checkstyle:check
lint-spotbugs	lint:spotbugs	spotbugsMain	spotbugs:check
lint-pmd	lint:pmd	pmdMain	pmd:check
lint-spotless	lint:spotless	spotlessCheck	spotless:check
db-migrate-liquibase	db:migrate:liquibase	liquibaseUpdate	liquibase:update
db-migrate-flyway	db:migrate:flyway	flywayMigrate	flyway:migrate
dev	dev	§2.2 の dev タスクおよびテンプレートの DEV_GRADLE_TASK リゾルバー（§2.3 の優先順位を参照）を参照	§2.2 の dev ゴールおよびテンプレートの DEV_MAVEN_GOAL リゾルバー（§2.3 の優先順位を参照）を参照

• Mode B（生成）： テンプレートからカタログをコピーし、ツールが存在しない対象を削除してください。例：checkstyle が linters に含まれない場合は lint-checkstyle を削除し、該当する ID がない場合は lint-spotbugs／lint-pmd を削除し、spotless が linters に含まれない場合は fmt と lint-spotless を削除し、java_build.liquibase でない場合は db-migrate-liquibase を削除し、java_build.flyway でない場合は db-migrate-flyway を削除してください。プロジェクトに Java プラグインのライフサイクルが実際に存在しない場合（まれです）を除き、必ず lint（= check／verify）を残してください。lint の代わりに verify -DskipTests や check -x test を使ってはいけません。dev については、テンプレートがビルドファイルからタスク／ゴールをすでに解決します。拡張時に誤った定数 bootRun／spring-boot:run が使われている場合は、PROJECT_PROFILE に基づく正しいフレームワークコマンド（テンプレートのリゾルバーと同じ文字列）に置き換えてください。
• Mode A（拡張）： アドホックな名前よりも、欠けているカタログ対象を優先してください。java_build／linters と矛盾するレシピは削除してください。

Docker 対応ターゲットの生成

has_docker が true の場合、コマンドを2 層生成してください。

第 1 層 — コンテナーのライフサイクル（Docker を検出した場合は常に生成）：

ターゲット	目的
docker-build または docker:build	Docker イメージをビルドする
docker-run または docker:run	コンテナーを実行する
docker-stop または docker:stop	実行中のコンテナーを停止する
docker-logs または docker:logs	コンテナーログを末尾から表示する
docker-push または docker:push	イメージをレジストリにプッシュする
docker-clean または docker:clean	イメージと停止済みコンテナーを削除する

第 2 層 — 開発環境と本番環境の分離（compose またはマルチステージを検出した場合）：

##@ Docker — Development
docker-dev:          ## Start all services in dev mode (with hot reload, mounted volumes)
docker-dev-build:    ## Rebuild dev containers
docker-dev-down:     ## Stop dev environment and remove volumes

##@ Docker — Production
docker-prod-build:   ## Build production image (optimized, multi-stage)
docker-prod-run:     ## Run production container locally for testing
docker-prod-push:    ## Push production image to registry

生成ロジック：

• has_compose の場合は、docker-compose ではなく docker compose コマンドを使用します
• compose にプロファイルがある場合は、--profile dev／--profile production を使用します
• has_multistage の場合は、開発ビルドに --target dev を使用し、本番ビルドではターゲットを指定しない（または --target production を使用する）でください
• docker_profile.deps（db、redis など）がある場合は、アプリを含めずにインフラサービスのみを起動／停止する infra-up／infra-down ターゲットを追加します
• compose を検出した場合、docker-dev は正しいプロファイル／サービスを指定して docker compose up を実行する必要があります
• compose がなく Dockerfile がある場合、docker-dev は docker build --target dev と、ボリュームマウントを指定した docker run を実行する必要があります

第 3 層 — コンテナー上で実行するコマンド（ホストコマンドをコンテナー経由で実行）：

プロジェクトが Docker ベースの場合、Docker ですべてを実行するユーザーも同じターゲットを使えるよう、コンテナー実行用のバリエーションも生成してください。

# Run tests inside the container
docker-test:         ## Run tests inside the Docker container
  docker compose exec app [test command]

# Run linter inside the container
docker-lint:         ## Run linter inside the Docker container
  docker compose exec app [lint command]

# Open shell in the container
docker-shell:        ## Open a shell inside the running container
  docker compose exec app sh

プロジェクトが Docker ファーストと思われる場合（compose ファイルがソースコードをボリュームとしてマウントしている、またはローカルの言語ランタイム環境が見当たらない場合）に限り、docker-* の exec バリエーションを生成してください。

プロジェクトプロファイルに基づくカスタマイズ

• JVM（java_build／Gradle または Maven）：すべてのツール呼び出しで、§2.2 の概要にある PROJECT_PROFILE.build_entrypoint を使用します。品質と DB： JVM テンプレートカタログ（Step 5 の表）の正式なターゲット名とタスク名のみを使用します。拡張する場合は、独自の推測で決めるのではなく、java_build と linters に合わせてレシピを追加・削除します。
• バイナリ名：go.mod、package.json、またはディレクトリ名から実際のプロジェクト名を使用します
• ソースディレクトリ：実際の src ディレクトリ（例：src/、app/、cmd/）を使用します
• 開発サーバーのコマンド：フレームワークに合わせます（例：next dev、uvicorn --reload、air。JVM の場合は build_entrypoint に、検出されたスタックの§2.2 の開発タスクを組み合わせます — Quarkus は quarkusDev／quarkus:dev、Micronaut は run／mn:run、Vert.x は vertxRun／vertx:run、Spring Boot は bootRun／spring-boot:run）
• テストコマンド：検出されたテストランナー（§2.7）に合わせます
• Lint コマンド（JVM）：不要なものを削除した後も、lint は check／verify のままにします。ツールごとの行には Step 5 のカタログ表を使用します
• マイグレーションコマンド（JVM）：java_build に応じて db-migrate-liquibase と db-migrate-flyway（または Taskfile の db:migrate:*）を使用します
• ポート番号：フレームワークのデフォルトを使用します（Node は 3000、Python は 8000、Go は 8080）

モード A — 既存ファイルの拡張

MODE = "enhance" の場合、ファイルを最初から置き換えてはいけません。代わりに、ファイルを分析して必要な箇所を改善します。

5A.1 既存ファイルの分析

EXISTING_CONTENT を PROJECT_PROFILE およびベストプラクティスと照合します。ギャップ分析を作成します。

前文／設定の不足 — ファイルに推奨される前文があるか確認します。

• Makefile：SHELL := bash、.ONESHELL、.SHELLFLAGS、.DELETE_ON_ERROR、MAKEFLAGS
• Taskfile：version: '3'、output:、dotenv:
• Justfile：set shell、set dotenv-load、set export
• Magefile：//go:build mage、適切な import

標準ターゲットの不足 — 次のうち、欠けているものを確認します。

• help／default（自己文書化）
• build、test、lint、clean、dev、fmt、および JVM カタログのターゲット（lint-checkstyle、db-migrate-flyway、…）。テンプレートの不要な部分を削除した後に確認します
• ci（集約ターゲット）

プロジェクト固有のターゲットの不足 — PROJECT_PROFILE に基づき、次の項目を確認します。

• Docker ターゲット（has_docker があるのにファイルに Docker ターゲットがない場合）
• データベース：java_build に合致する正式な db-migrate-*／db:migrate:*
• 型チェックターゲット（TypeScript／mypy が検出されているのに、型チェックターゲットがない場合）
• 生成ターゲット（コード生成ツールが検出されている場合）
• カバレッジターゲット（テストターゲットはあるものの、カバレッジ用のバリエーションがない場合）
• JVM：java_build が設定されている場合、build／test／check が <build_entrypoint> に委譲していること（汎用シェルや誤ったエコシステムだけを使用していないこと）
• JVM のマルチモジュール：リポジトリが Gradle マルチプロジェクトまたは Maven リアクターで、モジュールごとのコマンドが有用な場合は、module-build／module-test／module-check（または Taskfile の module:*）

品質上の問題 — ベストプラクティスに反するパターンがないか確認します。

• JVM： Step 5 のカタログ表にないレシピ（または Flyway のみのリポジトリで Liquibase タスクを使うなど、レシピに誤ったツールが使われている場合）。カタログの名前に置き換えるか、削除します
• 説明／ドキュメントのないターゲット
• .PHONY 宣言の不足（Makefile）
• 変数にすべきツールパスのハードコード
• バージョン／コミットの検出漏れ
• 自己文書化するヘルプターゲットがない

5A.2 変更内容の計画

実施する具体的な変更のリストを作成します。

CHANGES = [
  { type: "add_preamble", detail: "Add .SHELLFLAGS and .DELETE_ON_ERROR" },
  { type: "add_target", name: "docker-build", detail: "Dockerfile detected but no docker target" },
  { type: "add_target", name: "help", detail: "No self-documenting help target" },
  { type: "fix_quality", detail: "Add ## comments to 3 targets missing descriptions" },
  { type: "add_variable", detail: "Add VERSION/COMMIT detection via git" },
  ...
]

5A.3 変更を適用する

• 既存の構成を維持する — ユーザーの順序、命名、スタイルを維持します
• 既存のターゲットを正確に維持する — 明らかなバグの修正や、説明の不足を補う場合を除き、動作しているターゲットは変更しないでください
• 新しいターゲットは適切なセクションに追加する — 既存のグループ分けに従います（ファイルに ##@ セクションがある場合は該当するセクションに追加し、セクションがない場合は論理的な位置に追加します）
• 不足している前文を追加する — 既存の内容より前の先頭に追加します
• 不足している変数を追加する — 既存の変数宣言の近くに追加します
• 新しいターゲットの構文はテンプレートを参考にしつつ、ファイルにすでに記述されているスタイルに合わせて調整します（例：既存の Makefile がタブとシンプルなレシピを使っている場合、複雑な複数行スクリプトは導入しません）

品質チェック（両モード共通）

ファイルを書き込む前に、次の項目を確認してください。

• すべてのターゲットに説明またはドキュメントがある（## コメント、desc:、[doc()]、ドキュメントコメント）
• 変数にすべきパスがハードコードされていない
• パッケージマネージャー／ビルドのエントリーポイントの検出方法がリポジトリと一致している（Gradle/Maven ラッパー、npm/pnpm など）
• 自己文書化するヘルプターゲットが含まれている
• ファイルではないすべてのターゲットに .PHONY 宣言がある（Makefile のみ）
• 危険な操作には確認（Justfile）または警告がある

---

ステップ 6：ファイルを書き込み、結果を報告する

6.1 ファイルを書き込む

モード B（新規生成）：

Write ツールを使って生成した内容を書き込みます。

ツール	出力先パス
Makefile	Makefile
Taskfile	Taskfile.yml
Justfile	justfile
Magefile	magefile.go

モード A（既存ファイルを拡張）：

既存ファイルが見つかった場所と同じパスに、拡張した内容を書き込みます（元のファイル名の大文字・小文字と配置を維持します）。ファイルはその場で更新されます。置き換えではなく改善のため、上書きの確認を求める必要はありません。

6.2 概要を表示する

references/SUMMARY-FORMAT.md の形式に従って概要を表示します。ターゲットの表、使用したプロジェクトプロファイル、モード B（生成）のクイックスタートコマンド、またはモード A（拡張）での変更点と新規／既存ターゲットを表示します。ツールのセットアップが必要な場合は、インストール方法も含めます。

---

ステップ 7：プロジェクトドキュメントとの統合

ビルドファイルを書き込んだ後、クイックコマンドをプロジェクトのドキュメントに統合します。 詳しい統合手順（README、AGENTS.md、既存の Markdown）については、references/DOC-INTEGRATION.md を読みます。

概要：既存のコマンドセクションを確認し、クイックリファレンスを更新または追加します。AGENTS.md がない場合は、その作成を提案します。

成果物の所有権と設定ポリシー

• 主な所有対象：生成または拡張されたビルド自動化ファイル（Makefile、Taskfile.yml、justfile、magefile.go）。
• 付随して更新可能なもの：生成されたビルドワークフローに直接関連する場合の、既存ドキュメントまたは AGENTS.md 内のクイックコマンドのスニペット。
• 設定ポリシー：設定に依存しない設計です。このスキルでは config.yaml ではなく、リポジトリの検出と固定の AI Factory コンテキストファイルを使用します。