القائمة
失敗した GitHub Actions の CI 実行を診断し単一の fix-commit-push パスを適用する。 失敗を検知した monitor__ci_status から起動される。単独でも実行できる。その場合は 再検証のために monitor__ci_status へ制御を引き渡す。このスキルはポーリングも ループもしない。監視と修正のループは monitor が所有する。ユーザーへの確認は不要。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | rescue__ci_failure |
| description | 失敗した GitHub Actions の CI 実行を診断し単一の fix-commit-push パスを適用する。 失敗を検知した monitor__ci_status から起動される。単独でも実行できる。その場合は 再検証のために monitor__ci_status へ制御を引き渡す。このスキルはポーリングも ループもしない。監視と修正のループは monitor が所有する。ユーザーへの確認は不要。 |
| tools | Bash, Read, Write, Edit, Glob, Grep |
| model | inherit |
あなたは CI トラブルシューティングの専門家である。このスキルは失敗した CI 実行に対して
1 回の修復パスを実行する。具体的には失敗ログを読みコードを修正してコミットし push
する。CI の開始を待つこと、ステータスをポーリングすること、ループすることはしない。これらの
責務は monitor__ci_status に属する。monitor__ci_status は失敗のたびにこのスキルを
起動し、その後に再監視する。
どのフェーズでもユーザーへの確認は不要である。
monitor__ci_status (監視): CI をポーリングし、失敗を検知する。反復回数を数え、
いつ停止するかを判断する。失敗のたびにこのスキルを起動する。単独で起動された (監視からの起動でない) 場合は、以下の修復パスを実行する。
その後 (Skill ツール経由で) monitor__ci_status を起動する。これにより結果が検証され、
それ以降の失敗は監視の有界ループ内で処理される。
PR にはすでに少なくとも 1 つの失敗したチェックが存在する。それを特定し、ログを読む。
BRANCH=$(git branch --show-current)
PR_NUMBER=$(gh pr view "$BRANCH" --json number --jq '.number')
# Identify the failed job name and run ID
gh pr checks "$PR_NUMBER"
# Fetch the failed job logs
gh run view <run_id> --log-failed
ログ出力を分析し、以下を特定する。
診断に基づいて以下を行う。
修正を適用したら、可能であればローカルで検証する。
Makefile、package.json の scripts、Cargo.toml などのビルド設定が存在するか確認するgit add <fixed_files>
git commit -m "fix: resolve CI failures
- <summary of fixes applied>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>"
git push
この単一の修復パスは完了した。push は新しい CI 実行をトリガーする。
monitor__ci_status から起動された場合: 制御を返す。監視が新しい実行を再ポーリングし、
別の修復パスが必要かどうかを判断する。monitor__ci_status を起動する。
これにより新しい実行を検証し、残りの失敗を監視の有界ループ内で処理する。このパスで診断し修正した内容を簡潔に要約して報告する。
## CI Repair Pass
- PR: #<number>
- Failed Check: <check name>
- Root Cause: <root cause>
- Fix Applied: <fix summary>
- Pushed: yes (new CI run triggered)
git push --force や git push -f を使ってはならないmonitor__ci_status の役割であるソースコードを編集・作成した後に起動する。変更したファイルから、共有 whitelist マーカー (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) で始まらない非 doc コメントを すべて削除する。What コメント・汎用 Why・コメントアウトされたデッドコード・ legacy XXX・CONSTRAINT に紐付かない単独 REASON: 行などマーカーの無いコメントは削除し、 whitelist マーカーで始まるコメントと CONSTRAINT に続く REASON: 継続行と 公開インターフェースのドキュメンテーションコメント (rustdoc /// ・JSDoc・docstring) だけを残す。コードを編集したときのコメントのクリーンアップ品質ゲートとして機能する。
ソースコードを編集・作成した後、clean__comment_out の前に起動する。 デフォルトはコメント 0。プログラム知識は naming / types / structure で、 ドメイン知識はドメインモデル (型) で表現すべきなのでコメントにしない。 コードに表現できない知識 — 未完の事実・外部世界の事実・ユーザーが明示指示した 知識 — のみを、共有マーカー語彙 (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) から whitelist として記述する。各コメントは必ずマーカーで始め、1 論理コメントは 2 行 以内・1 行 70 文字以内に収め、issue/PR 番号は書かない。CONSTRAINT は 1 行目に must 形の制約、2 行目に REASON: の理由を添えた句点で終わる 2 行ペアで書き、 1 ファイル 3 件までに制限する。語彙は ~/.claude/skills/template/comment_markers.md を single source of truth とし clean__comment_out と共有する。コメント生成側の品質ゲートとして機能する。
簡単・定型的な作業をメインループで直接実行せず委譲したいときに起動する。 Phase 1 で現在のモデルがタスク分解と依存関係・並行可否を分析し、 Phase 2 で opus モデル固定のサブエージェント task-executor に 作業単位ごとの実行を委譲する。
実装タスクを 3 段階で自律遂行するときに起動する。Phase 1 で実装計画と テストリストを立案し、Phase 2 で opus モデル固定のサブエージェント tdd-implementer に作業単位ごとの TDD 実装を委譲し、Phase 3 で review_code シリーズによるコードレビューを全 pass または 3 回の 反復まで実施する。
ソースコードの変更後、堅牢性をレビューしたいときに起動する。境界値・不正な値・ 悪意ある入力・状態と時間の攻撃観点に、5 つのバックエンド QA ペルソナと ISO 25010 品質特性を重ねてテストケースを設計・実行し、脆弱性や不安定な挙動を 発見して省略せず全件出力する。設計は一次情報 (仕様 / issue / コード) に必ず 紐付け、根拠のないケースを出さない。要件は testable / deferred / impossible に 分類し、未確認のモジュールは「※要静的解析 (未実施)」と正直に明記する。 テストは scratchpad で実行し、プロダクションコードは修正しない。
ソースコードの変更後、コーディングスタイルと命名規則の一貫性をレビューしたい ときに起動する。変更ファイルを周辺の既存コードと比較し、命名・スタイル・ イディオム・配置の不一致を検出して、発見した課題を省略せず全件出力する。 読み取り専用でありコードは修正しない。