workflow-automation

ワークフロー自動化

このスキルは、リポジトリにおけるルーティング優先の定期的なワークフロー自動化の起点として使用します。

目的は、巨大な Makefile やシェルスクリプトの寄せ集め、フック設定、CI YAML の塊をそのまま出力することではありません。 目的は次のとおりです。

1. 定期的なワークフローを分類する
2. 主な自動化モードを1つ選ぶ
3. ローカルのエントリーポイント、フック、CI のミラー、定期メンテナンスが、それぞれの範囲に忠実であるようにする
4. 明確な振り分け先を示した、再利用可能なパケットを1つ出力する

最初に次の参考ドキュメントを読んでください。

• references/automation-modes.md
• references/mode-packets-and-route-outs.md
• references/handoff-boundaries.md

主な要望が次のいずれかの場合：

• マシン／ランタイムのプロビジョニング、ローカルサービス、devcontainer、またはマシン間での再現性 → system-environment-setup を使用します
• デプロイのロールアウト、ホスト型 CI/CD アーキテクチャ、プレビュー／ステージング／本番環境への昇格、またはロールバック設計 → deployment-automation または vercel-deploy を使用します
• ブランチ／リベース／復旧／プッシュの安全性 → git-workflow を使用します
• テストの深さ／マージゲートのポリシー → testing-strategies を使用します
• ランタイムのテレメトリ／アラート／本番環境の可視性 → monitoring-observability を使用します

このスキルを使用する場合

• README に散在するコマンドを、リポジトリで管理する反復可能なコマンドインターフェースに置き換える
• パッケージスクリプト、Make、just、Task、シェルのエントリーポイント、フック、CI ラッパー、メンテナンスボットから選ぶ
• リポジトリ向けに setup、bootstrap、dev、test、lint、verify、ci コマンドを設計する
• ローカルのワークフロー用コードとホスト型 CI による強制との境界を明確にする
• 繰り返し発生する雑務をフック、タスクランナー、定期的な自動化のどこに置くべきか判断する
• ドキュメント、スクリプト、フック、CI YAML に散らばった煩雑なワークフローレイヤーを診断する

このスキルを使用しない場合

• 本当の障害が、マシンのセットアップ、サービスのトポロジー、ツールチェーンの固定、コンテナ／devcontainer の再現性にある
• 本当の障害が、リリース／デプロイのアーキテクチャやクラウドランタイムの自動化にある
• 本当の障害が、リポジトリのコマンド設計ではなく、Git のコラボレーション／復旧にある
• 本当の障害が、コマンドの公開方法ではなく、テスト戦略のポリシーにある
• コマンドがすでに明確で、必要なのが単純な実装だけである

手順

ステップ1：要望を正規化する

まず、次の形式で要望を記録します。

workflow_intake:
  primary_goal: task-entrypoints | bootstrap-onboarding | local-ci-parity | hook-guardrails | repo-maintenance | workflow-diagnosis | hybrid
  repo_shape: single-app | app-plus-services | monorepo | library-cli | docs-content | game-project | unknown
  current_surface: package-scripts | make-just-task | shell-scripts | ci-workflows | hooks | bots-schedules | mixed | none | unknown
  main_pain:
    - command-sprawl
    - onboarding-drift
    - local-vs-ci-mismatch
    - interactive-script
    - cross-platform-friction
    - duplicated-logic
    - hook-friction
    - bot-noise
    - unclear-owner
    - unknown
  blast_radius: local-dev-loop | repo-plus-ci | multi-team-repo | unknown
  confidence: high | medium | low

要望が曖昧な場合は、最小限で明白なリポジトリ内の定期ワークフローとして解釈し、その前提を明記します。

ステップ2：主なモードを1つだけ選ぶ

今回の実行に使うモードを1つ選びます。

1. task-entrypoints — 人が定期的に実行する作業のための、覚えやすい単一のコマンドインターフェース
2. bootstrap-onboarding — 初回セットアップ、シード／初期化、またはリポジトリの繰り返しの初期化
3. local-ci-parity — CI の重要なチェックを反映する、ローカル検証用の単一コマンド
4. hook-guardrails — コミット／プッシュ前に実行する、高速なローカルの衛生チェック
5. repo-maintenance — 依存関係の更新、定期的なクリーンアップ、リリース準備の雑務、古くなった項目の自動処理
6. workflow-diagnosis — ワークフローレイヤーが煩雑で、自動化を追加する前に簡素化が必要な状態

リポジトリに現在、入口が多すぎて新しい標準モードを選ぶ前に簡素化する必要がある場合は、workflow-diagnosis を使用します。

ステップ3：最小限の自動化インターフェースを選ぶ

次の既定値を使用します。

• 人が使うエントリーポイント層には、パッケージスクリプト／Make／just／Task
• 高速で決定的なガードレールに限り、フック
• 強制、マトリックス、スケジュール、シークレットが必要な作業には、ホスト型 CI
• プッシュ前のフィードバックを速めることが目的なら、ローカル CI ラッパー
• 人が毎日入力するコマンドではなく、定期的なメンテナンス作業なら、ボット／スケジュール

リポジトリの自動化によって、環境のプロビジョニングやデプロイのアーキテクチャを暗黙のうちに取り込まないでください。

Step 4: ワークフローの不変条件を明示する

以下のルールは、すべての回答で維持してください。

• 一部しかドキュメント化されていない入口を複数設けるより、明確な入口を1つ優先する
• ブートストラップのフローは、デフォルトで冪等かつ非対話型にする
• ローカルでの回避が可能なため、フックは短く、決定論的にし、CI にも同じチェックを設ける
• ローカルと CI の同等性では、ホスト型ランナーの詳細すべてではなく、重要なチェックを再現する
• 定期メンテナンスには、ボットの設定だけでなく、担当者とレビュー方針が必要
• ローカルとホスト型の自動化で意図的に異なる点を明記する

Step 5: ワークフロー自動化パケットを作成する

次の構成で返してください。

# Workflow Automation Packet

## Recommended mode
- Mode: task-entrypoints | bootstrap-onboarding | local-ci-parity | hook-guardrails | repo-maintenance | workflow-diagnosis
- Why this mode fits: ...

## Current state
- Repo shape: ...
- Current surface: ...
- Main pain: ...
- Blast radius: ...
- Confidence: high | medium | low

## Recommended surface
- Human-facing entrypoint: ...
- Supporting hooks / CI / schedules: ...
- What stays out of scope: ...

## Safest next move
1. ...
2. ...
3. ...

## Guardrails
- Idempotency / non-interactive behavior: ...
- Local vs CI boundary: ...
- Ownership / review policy: ...

## Route-outs
- `system-environment-setup` when ...
- `deployment-automation` / `vercel-deploy` when ...
- `git-workflow` when ...
- `testing-strategies` when ...

Step 6: 巨大なツールカタログではなく、モード別パケットを使う

references/mode-packets-and-route-outs.md から、正確なパケットの形式を取得してください。

ルール：

• task-entrypoints は、複数のコマンドを、見つけやすい単一の人間向けインターフェースにまとめてください
• bootstrap-onboarding は、検証コマンドで締めくくり、前提条件の境界を明示してください
• local-ci-parity は、シークレット、サービス、マトリックスの違いなど、同等性の限界を明記してください
• hook-guardrails は、コントリビューターがすぐに回避しようとしない程度に高速にしてください
• repo-maintenance は、レビューの頻度、作業のまとめ方、ノイズ抑制への期待事項を含めてください
• workflow-diagnosis は、もう1つレイヤーを提案する前に、簡素化して重複を解消してください

出力形式

短い Workflow Automation Packet または Automation Hardening Brief を返してください。

必須要件：

• ツールを推奨する前にワークフローを分類する
• 主となるモードを1つ選ぶ
• 役立つ範囲で最小限のインターフェースを優先する
• ローカルコマンド、フック、CI、スケジュールそれぞれの境界を正直に示す
• 隣接する作業をスキルに取り込まず、明示的に別の担当先へ振り分ける

例

例 1：煩雑なコマンドのインターフェース

入力：「このリポジトリには README のコマンド、古い Makefile、無造作に置かれたスクリプトがあります。開発、テスト、lint のために、再現可能な自動化レイヤーを1つにまとめたいです。」 出力の方向性：workflow-diagnosis を選び、人間向けのインターフェースを1つに統合してから、デプロイや環境に関する懸念事項を別の担当先へ振り分けます。

例 2：push 前のローカル検証

入力：「CI の失敗を知るためだけに、開発者が push する状況が続いています。問題を早く見つけられるよう、CI を十分に再現するローカルコマンドを1つ用意したいです。」 出力の方向性：local-ci-parity を選び、ci ラッパーを1つ追加して、CI を完全に再現できると約束するのではなく、同等性の限界を明記します。

例 3：オンボーディングの問題

入力：「新しいコントリビューターは、ツールをインストールし、環境ファイルをコピーし、データをシードし、ブランチを切り替えるたびにセットアップを実行する必要があります。」 出力の方向性：bootstrap-onboarding を選び、冪等なブートストラップの入口を1つ推奨して、広範なマシンやサービスのセットアップは system-environment-setup に委ねます。

例 4：リポジトリの定期作業

入力：「依存関係の更新やクリーンアップ作業が後回しになり続けています。これはスクリプト、フック、定期実行の自動化のどれで行うべきでしょうか？」 出力の方向性：repo-maintenance を選び、レビューのルールとともにボットやスケジュールを推奨して、日常の開発者向けの入口とは分けます。

ベストプラクティス

1. 好みのツールではなく、繰り返し発生するワークフローから始めてください。
2. 管理責任が曖昧なインターフェースを複数設けるより、見つけやすい入口を1つ優先してください。
3. リポジトリ内の連携処理は、環境、デプロイ、Git ポリシー、オブザーバビリティとは分けてください。
4. 対話型プロンプトは最終手段としてください。
5. ローカルと CI に違いがある場合は、どこがなぜ異なるのかを明確に説明してください。
6. 自動化を追加する前に、簡素化して重複を解消してください。

参考資料

• Task: 最新のタスクランナー
• Just プログラマーズマニュアル
• mise タスク
• pre-commit
• GitHub Actions ドキュメント
• act ドキュメント
• 開発コンテナー