Set up CI/CD

1. 最初に $ci-cd-pipeline を使用し、Cloudflare Workersなら続けて$cloudflare-secure-deployと$wranglerを使用する。記憶だけで進めない。
2. 対象パスの指定がなければ現在の作業フォルダを対象にする。
3. 同スキルの導入可否判定を自分で行う。未公開またはテストが1本もない場合は質問で止めず、導入しない結論、根拠、先に作る最小成果物を提示する。
4. ci-cd-pipeline/assets/detect-pm.ymlを.github/actions/detect-pm/action.ymlへ配置し、CI・Deploy・Migrateから同じ部品を呼ぶ。パッケージマネージャー（npm・yarn・pnpm）はロックファイルから自動判別し、雛形へ同じ判定処理をコピーしない。
5. package.json の scripts を実際に読み、ワークフローが呼ぶ typecheck・test・deploy・db:backup・db:migrate:remote・cf-typegen が実在するか確認する。無い処理は、ステップを削るかスクリプトを追加するかを判断し、その理由を伝える。
6. 既存の .github/workflows/ を上書きしない。実ファイルを読み、差分、重複、特に Cloudflare Workers Builds との二重デプロイを分析し、安全で重複のない構成を1つ選んでパッチを作る。
7. ci-cd-pipeline/scripts/detect-github-repository.mjsを最初に実行し、現在のgit remote・追跡remote・gh repo viewからGitHubのowner/repo/remoteを自動発見する。status: okならrecommendedを採用し、対象を短く提示してそのまま進む。質問するのはmultiple・unconfigured・gh_auth_requiredのときだけとし、資格情報を含むremote URLやTokenを貼らせない。続いてpackage manager、Wrangler package、Worker/D1/R2名、固定本番URL、既存secret名、Cloudflare/GitHubの状態を自動発見する。利用者へ調査コマンドを丸投げしない。
8. 複数Cloudflare Accountがある新規構築ではチーム用共有Accountを推奨し、既定選択する。個人Accountは明示指定時だけ。既存リソースが個人側なら勝手に複製せず移行判断で停止する。料金プラン変更は承認を得る。
9. ci-cd-pipelineのgeneratorを--autoで実行し、検出済みの推奨値からdocs/cloudflare-credentials-setup.mdと.cloudflare/setup-production.mjsを生成する。Wrangler設定の存在だけで既存resourceと判定せず、read-only照合で所有先を確認できた場合だけ--account-mode existingを渡す。未作成なら既定のteam、利用者が明示した場合だけpersonalにする。一意に決められない項目だけ明示引数で補い、推測しない。画面名だけの抽象案内は禁止し、クリック先、入力値、成功表示、停止条件、復旧を含める。
10. API Token作成と秘密値入力は所有者本人に残す。Tokenをチャットへ貼らせず、生成済みhelperを1回実行してもらう。AIは値でなく登録名だけを再確認する。既存Worker secretはローテーション承認なしに上書きしない。
11. CLOUDFLARE_*はproduction Environment secret、APP_URLはRepository variableへ登録する。Deploy/Migrate jobのenvironment: productionとmain限定を検証する。
12. スモークテストは先にローカルで通してからCIへ入れる。
13. テストを意図的に1つ失敗させてCIが赤くなることを確認し、確認後は必ず元に戻す。この検証を省略しない。
14. ブランチ保護の必須チェックにはワークフロー名ではなくジョブ名を指定する。永久に Pending となる設定を作らない。
15. DeployはmainのCI成功後に自動起動させ、対象SHA一致、30秒後・90秒後のsmokeまで監視する。手動実行でもテストを迂回させない。
16. 完了後は非エンジニア向けに、自動になったこと、利用者自身が行うことと代行できない理由、費用、自動化しなかったことと理由、技術的詳細の順で報告する。

通常は Evidence → Decide → Draft → Validate → Diff で進め、比較案の選択を利用者へ委ねない。質問してよいのは認証情報、課金、公開、本番データ変更など本人しか決められない境界だけであり、その場合もローカル検証済みの成果物を先に示す。