BMG1 開発の完了処理を一貫して実行する。Linear報告→ドキュメント更新→E2Eテスト→動作確認→コードレビュー→PRマージ→デプロイ後E2E→worktree削除→Linear最終報告。"/bmg-finalize"、"BMG完了処理"、"BMGシップ"、"BMG開発完了" などで起動する。
BMG1 プロジェクトの開発完了処理を一貫して実行する。Linear 報告からworktree 削除まで、10 ステップの完了フローを自動化する。
/bmg-finalize
引数不要。現在の worktree とブランチから Linear issue を自動判定する。
feature/BMG-123-some-feature）# 現在のディレクトリとブランチ
pwd
git branch --show-current
# 未コミットの変更がないか確認
git status
# 最近のコミットを確認
git log --oneline -10
ブランチ名から Linear issue ID を抽出する（例: feature/BMG-123-description → BMG-123）。
抽出できない場合はユーザーに確認する:
AskUserQuestion: "対象の Linear issue ID を教えてください"
main（または develop）との diff からバックエンド変更を判定する:
# main との差分ファイルを確認
git diff main --name-only
以下のいずれかに該当するファイルが含まれていればバックエンド変更ありと判定:
amplify/ 配下の変更packages/backend/ や packages/api/ 配下の変更amplify/data/resource.ts の変更schema.graphql の変更判定結果をユーザーに提示して確認する:
バックエンド変更: あり / なし
変更ファイル概要: {主要な変更ファイル}
バックエンド変更の有無に応じた実行フローをユーザーに提示する:
バックエンド変更あり:
1. Linear に着手報告
2. docs ドキュメント更新
3. E2E テスト作成/更新
4. Sandbox でテスト（pnpm sandbox:once → dev:sandbox:app / dev:sandbox:admin）
5. /simplify + /build-fix-review + /bug-trend-review review + /structured-output-review でレビュー
6. PR 作成 → コンフリクト確認 → Lint 確認 → Sentry bot レビュー確認 → マージ
7. デプロイ完了後、stg で E2E テスト
8. Worktree 削除
9. Linear に完了報告
バックエンド変更なし:
1. Linear に着手報告
2. docs ドキュメント更新
3. E2E テスト作成/更新
4. ehime-stg でテスト（dev:app:ehime-stg / dev:admin:ehime-stg）
5. /simplify + /build-fix-review + /bug-trend-review review + /structured-output-review でレビュー
6. PR 作成 → コンフリクト確認 → Lint 確認 → Sentry bot レビュー確認 → マージ
7. Worktree 削除
8. Linear に完了報告
ユーザーの承認を得てから進める。
ToolSearch で Linear MCP ツールをロードし、issue にコメントを追加する:
ToolSearch: "+linear create_comment"
mcp__linear__create_comment(
issueId: "${LINEAR_ISSUE_ID}",
body: "## 完了処理を開始\n\n開発完了処理フローを開始します。\n- ドキュメント更新\n- E2Eテスト\n- コードレビュー\n- PR作成・マージ"
)
Glob: docs/**/*.md
変更内容に関連するドキュメントを特定する:
docs/usecase/docs/screen-design/docs/testcase/docs/ 配下今回の変更内容を反映する形でドキュメントを更新する。新規機能の場合は新規ドキュメントを作成する。
更新対象:
git add docs/
git commit -m "docs: update documentation for ${FEATURE_NAME}"
Glob: e2e/**/*.{ts,spec.ts}
今回の変更に対応する E2E テストを作成または更新する。
e2e/ ディレクトリに配置git add e2e/
git commit -m "test: add/update E2E tests for ${FEATURE_NAME}"
pnpm sandbox:once
Sandbox のデプロイ完了を待つ。
# アプリ側
pnpm dev:sandbox:app
Playwright MCP またはブラウザで動作確認を行う。
# 管理画面側
pnpm dev:sandbox:admin
Playwright MCP またはブラウザで動作確認を行う。
E2E_ENV=sandbox pnpm exec playwright test --config e2e/playwright.config.ts
pnpm dev:app:ehime-stg
pnpm dev:admin:ehime-stg
E2E_ENV=ehime-stg pnpm exec playwright test --config e2e/playwright.config.ts
テスト失敗があれば修正し、全件 Pass になるまで繰り返す。 3 ラウンドで解決しない場合はユーザーに相談する。
/simplify スキルを使ってコードレビューを実行する:
Skill: simplify
レビュー結果に指摘事項があれば修正し、再度テストを通す。
/build-fix-review スキルで過去のビルドエラーログと差分を照合し、既知のリスクパターンがないか確認する:
Skill: build-fix-review
CRITICAL / WARNING レベルの指摘があれば、該当箇所を修正してからコミットする。
/bug-trend-review review スキルで過去のバグ傾向レポートと差分を照合し、同じパターンのリスクがないか確認する:
Skill: bug-trend-review review
CRITICAL / WARNING レベルの指摘があれば、該当箇所を修正してからコミットする。
差分に Zod スキーマや LLM 呼び出しコード（generateObject, z.object, schema.ts 等）が含まれている場合、/structured-output-review スキルでモデル別の structured output 制約との互換性をチェックする:
# 差分に Zod スキーマ / LLM 関連の変更があるか確認
git diff ${baseBranch}...HEAD --name-only | grep -E "(schema|z\.object|generate|llm)" || true
該当ファイルがある場合:
Skill: structured-output-review <対象ファイルパス>
主なチェック項目:
.optional() が単体で使われていないか（OpenAI でエラー）→ .nullable() に変更.min() / .max() が OpenAI で無視されることを認識しているか.describe() が付いているかCRITICAL レベルの指摘があれば修正してからコミットする。
git push -u origin $(git branch --show-current)
gh pr create --title "${LINEAR_ISSUE_ID}: ${FEATURE_NAME}" --body "$(cat <<'EOF'
## Summary
- {変更概要}
## Linear Issue