PR 提出前にコードオーナー視点でフルレビューする。WHY の理解 → 設計 → AST/基盤型 → 実装（複数 Agent の順次レビュー）の順に、各フェーズでユーザーと対話しながら指摘を修正し、品質に問題がなくなるまで繰り返す。「/full-code-review」「フルレビュー」「レビューして」などの依頼時に使用。rsvelte（公式 Svelte コンパイラの Rust ポート）専用。
baseballyama/rsvelte2372026年10月12日 更新
無料GitHub で公開
ci-fix-and-verify
PR の CI 失敗を修正し、全 CI がパスするまでプッシュ→待機→修正を繰り返す。「/ci-fix-and-verify [PR番号]」「CI直して」「CIが落ちてる」「CI修正」などの依頼時に使用。
含まれるファイル（2）
- SKILL.md2.8 KB
- wait-ci.sh2.2 KB
SKILL.md（原文）
インストールする前に、エージェントに与えられる指示の中身を確認できます。
CI Fix and Verify
PR の CI 失敗を検出・修正し、全チェックがパスするまでサイクルを回す。引数は PR 番号（省略時は現在ブランチから検出）。
Phase 0: 初期化
PR_NUMBER="${1:-$(gh pr list --head "$(git branch --show-current)" --json number --jq '.[0].number')}"
REPO_INFO=$(gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"')
OWNER="${REPO_INFO%/*}"; REPO="${REPO_INFO#*/}"
Phase 1: CI 状態確認
gh pr checks "$PR_NUMBER" --repo "$OWNER/$REPO"
| 状態 | 次 |
|---|---|
| 全てパス | 完了報告して終了 |
| 失敗あり | Phase 2 |
| 実行中 | wait-ci.sh で待機してから再確認 |
Phase 2: 失敗分析と修正
gh run view <run_id> --repo "$OWNER/$REPO" --log-failed
| 失敗タイプ | ローカル再現 / 修正 |
|---|---|
| fmt | cargo fmt --all |
| clippy | cargo clippy --all-targets --all-features -- -D warnings |
| ビルド | cargo build --all-targets |
| テスト | 失敗テストを CI ログから特定し cargo test --release --test <suite> で個別実行（フル実行は最後） |
| fixtures ずれ | pnpm run generate-fixtures 後に再テスト |
| docs / compatibility report | pnpm run test-and-update で再生成 |
| Node 側 | pnpm install 後、該当 node scripts/... の出力を確認 |
CI と同じコマンドで再現する。ワークフローは .github/workflows/ を参照。
Phase 3: プッシュと待機
cargo fmt --all
cargo clippy --all-targets --all-features -- -D warnings # pre-commit hook と同じ
git add <修正ファイル>
git commit -m "fix(ci): <要約>" # 英語 Conventional Commits、atomic commit
git push origin HEAD
# Bash tool の timeout は 600000（10分）に設定。最大 20 分待機
bash .claude/skills/ci-fix-and-verify/wait-ci.sh "$OWNER" "$REPO" "$PR_NUMBER"
| wait-ci.sh 出力 | アクション |
|---|---|
ALL_PASSED | Phase 4 |
FAILED | Phase 2 に戻る |
TIMEOUT | gh pr checks を確認し、必要なら wait-ci.sh を再実行して待機延長 |
API_ERROR | エラーを表示して終了 |
Phase 4: 完了報告
CI が全てパスしました！
- 修正回数: X回
- 修正内容: [修正ごとの要約]
ルール
- 修正サイクルは最大 5 回。超えたらユーザーに状況を報告する
--no-verifyなどのフック回避フラグは使わない
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
Rust の性能改善を「計測 → 仮説 → 変更 → 再計測」のループで地道に回すためのスキル。プロファイラの選び方、Cargo の最適化設定、データ構造・アロケーション・ハッシュ・分岐などの定石をフェーズ順に適用する。1 回 1 変更 1 計測の規律を厳守する。rsvelte 固有の既知ボトルネック（`serde_json::Value` 駆逐、`bumpalo` 導入、`Atom<'a>`、codegen 直書き）と OXC 対応表、NAPI 検証手順も §7 に収録。「Rust の性能改善」「ボトルネック調査」「プロファイル取って最適化」などの依頼で使用。
baseballyama/rsvelte2372026年10月12日 更新
Audit and clean up the repository — remove dead files, fix naming inconsistencies, update .gitignore, and ensure the repo is well-organized for OSS contributors. Does NOT modify source code logic.
日本語の概要は準備中です。原文の説明を表示しています。
baseballyama/rsvelte2372026年10月12日 更新
GitHub PR のコードレビューコメントに対応する。未 resolve のみを抽出 → 対応方針をユーザー承認 → 1 件ずつ修正＋返信 → AI レビュー由来の指摘はナレッジに反映するワークフロー。「/review-response [PR番号]」「レビュー対応」「レビューに返信」などの依頼時に使用。
baseballyama/rsvelte2372026年10月12日 更新
Upgrade the Svelte submodule to the latest (or specified) version, regenerate fixtures, identify test failures, and fix all regressions until tests pass 100%.
日本語の概要は準備中です。原文の説明を表示しています。
baseballyama/rsvelte2372026年10月12日 更新
Svelte を使う外部リポジトリ（ツール / ライブラリ / アプリ）を git submodule として取り込み、Svelte コンパイラを rsvelte に差し替えても完全に同等に動作するかを検証する。既存のサブモジュールが指定された場合は最新化したうえで再検証し、回帰があれば rsvelte 側を自動修正する。「/verify-svelte-compat <url-or-name>」で実行。
baseballyama/rsvelte2372026年10月12日 更新