setup-ci-automation について
プロジェクトの CI を調査し、プルリクエストを通じて QA 自動化ワークフローを追加するスキルです。CI の適切な設定、実装前の承認、変更を CI 設定に限定することを重視します。
主な機能
- 01CI のトリガーとジョブの一覧化
- 02承認用ワークフロー図の作成
- 03CI 固有の構文による自動化の追加
- 04CI 設定ファイルのみの変更
- 05プルリクエストでのワークフロー提出
活用シーン
- 01QA 自動化の追加前に既存 CI を確認
- 02リポジトリイベントに応じたタスク実行
- 03ワークフローのマージ前にシークレットを準備
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ testomatio/ skills --skill setup-ci-automationインストール後、Claude Code で/setup-ci-automationを入力して読み込まれたか確認します。
詳細
CI 自動化の設定
プロジェクトの CI を調査し、現在実行されている内容を把握して説明したうえで、リポジトリのイベントに応じて QA タスクを自動化する新しいワークフローを追加します。新しいワークフローで 何を行うか は、そのタスクを担当するスキルが決めます。このスキルが担当するのは、CI に正しく組み込むことです。
重要な制約
- CI 設定ファイルのみを変更してください — ソースファイルやテストファイルには触れないでください。
- ジョブが実行するコマンドを決して捏造しないでください — タスクを担当するスキル、またはユーザーから提供された内容を使用してください。
- 完成した成果は PR を通じて CI 設定を届けることです — デフォルトブランチに直接プッシュしてはいけません。
- シークレットは CI のシークレットストアに保存し、設定ファイルには記述しないでください。
ワークフロー
ステップ 1 — CI を調査する
- リポジトリの CI 設定ファイルを読み、CI システムを特定してください。複数ある場合、または何もない場合は、どれを対象にするか確認してください。
- 既存のワークフローを一覧にします。それぞれのトリガー、ジョブ、目的を確認してください。新しい自動化は既存のものと連携させ、重複や問題を起こさないようにする必要があります。
- CI が提供する機能を確認します。シークレットストア、ジョブ間およびパイプライン間での値の受け渡し、パイプライン間のトリガー、デプロイイベントなどです。
ステップ 2 — 図で説明する
環境で Mermaid をレンダリングできる場合は、既存または提案中のワークフローをフローチャートで示してください。トリガー → 動詞から始まるアクションブロック → 結果の順にします。分岐はひし形の質問として示し、設定の詳細はブロックにせず、図の下のテキストに記載してください。
- 図だけを投稿してはいけません。ワークフローの内容と、ユーザーが決めることを短い段落で続けてください。
- 提案するワークフローの図は承認の関門です。ユーザーが承認するまでは、何も組み込まないでください。
ステップ 3 — 新しいワークフローを設計する
- トリガーとなるイベント、実行するタスク、その結果の出力先を明確にしてください。
- タスクのコマンドは、そのタスクを担当するスキルから取得します(下記の案を参照)。このスキルが行うのは CI の配線だけです。
- タスクを AI エージェントが実行する場合、CI でそのエージェントを実行できる必要があります。❓ プロジェクトでエージェントを CI 上でどのように実行するか確認してください。インストール方法を捏造してはいけません。
- 設定ファイルを書く前に、図を使って設計を確認してください(ステップ 2)。
ステップ 4 — ワークフローを作成する
- 対象の CI 独自の構文を使用してください。別の CI のファイル形式をコピーしてはいけません。
- 各ジョブにはタスクのコマンドと CI 標準の機能だけを含めます。ログの解析、シェルの厳格モードを設定する前置き、コマンドを囲む bash のラッパーは使用しないでください。
- 差分の取得や履歴の走査を行うジョブでは、CI のチェックアウト機能にある全履歴取得オプションを使用してください。手動で
fetchコマンドを実行してはいけません。 - マージされた変更に反応するジョブでは、メインラインに取り込まれた正確なリビジョンをチェックアウトしてください。後続のマージが行われると、ブランチ先端が移動するためです。
- 自動化ジョブによって PR をブロックしたり、マージやリリースのパイプラインを失敗させたりしてはいけません。
ステップ 5 — シークレットを用意する
- Testomat.io のプロジェクト API キーは、CI のシークレットストアに
TESTOMATIO_<project-slug>という名前で保存し、必要なすべてのジョブでTESTOMATIO環境変数に割り当ててください。 - このリポジトリで使用する CI のシークレットストアの場所と、入力する正確な名前を示して、各シークレットを追加する場所をユーザーに伝えてください。
- ❓ ワークフローの PR がマージされる前に、シークレットが設定済みであることをユーザーに確認してください。シークレットがないと、初回実行時に失敗します。
ステップ 6 — PR で提出する
- CI 設定をブランチにコミットし、プロジェクト標準の手順で PR を作成してください。
- PR の説明には、ワークフロー図、自動化する内容、マージ前にレビュアーが用意する必要のあるシークレットや前提条件を記載してください。
- CI が PR トリガーのワークフローをブランチから実行する場合、この PR で新しいワークフローが動作することを明記してください。
自動化のアイデア
CI イベントに連動させる価値のあるタスクです。名前付きスキルが各タスクの内容を担当します。
| イベント | 自動化 | タスクの担当スキル |
|---|---|---|
| PR の作成 | PR の差分からテストケースを生成 | pull-request-diff-analyzer + qa-write-test-cases |
| Issue の作成 | 機能を QA 分析します — エッジケース、受け入れ条件 | qa-thinking |
| デプロイ完了 | 対象を絞ったテスト実行を作成し、影響を受けるテストを開始 | setup-change-aware-pr-testing |
| スケジュール | 重複または重なり合うテストケースを検出 | detect-duplicate-test-cases |
関連スキル
setup-change-aware-pr-testing(このスキルを基盤に構築された、カバレッジ主導の PR テストワークフロー)、run-tests-with-testomatio-reporter(実行関連ジョブ用のレポーターコマンド)、testing-workflow(QA タスクを担当するスキルに振り分けます)。
コメント
Markdown 対応