Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

fix-ci-setup

Sterne6

Forks1

Aktualisiert4. Mai 2026 um 22:48

GitHub Actions の CI/CD 環境構築・セットアップ周りの問題（JDK バージョン、キャッシュ設定、シークレット、ワークフロー定義）を診断・修正する。Use when "CI のセットアップ問題", "GitHub Actions の設定", "JDK バージョン問題", "ワークフロー定義の修正".

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

TBSten

TBSten/compose-preview-lab

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	fix-ci-setup
description	GitHub Actions の CI/CD 環境構築・セットアップ周りの問題（JDK バージョン、キャッシュ設定、シークレット、ワークフロー定義）を診断・修正する。Use when "CI のセットアップ問題", "GitHub Actions の設定", "JDK バージョン問題", "ワークフロー定義の修正".

fix-ci-setup

CI/CD 環境構築とセットアップ診断スキル

目的

GitHub Actions CI/CD パイプラインの設定を確認し、環境構築上の問題を診断・修正する。

実行手順

Step 1: CI 設定ファイルの確認

必ず最初に実行:

.github/workflows/ ディレクトリの存在確認
- ツール: Glob で .github/workflows/*.yml を検索
各ワークフローファイルを読み込んで内容を把握
- ツール: Read で各ワークフローファイルを読み込む
- 特に pull-request.yml の内容を詳細に確認

確認すべき内容:

どのジョブが存在するか
各ジョブで実行されるコマンド
マトリックス戦略の設定
環境変数やシークレットの設定

Step 2: ワークフロー構造の理解

pull-request.yml の主要ジョブ:

lint: ./gradlew ktlintCheck
- Kotlin コードのリントチェック
validate-binary-compatibility: ./gradlew apiCheck
- バイナリ互換性の検証
test: マトリックス戦略で複数のプラットフォームでテスト
- Jvm, JS, Wasm JS, Android Debug/Release, iOS
publish: Maven Local への公開

Step 3: 環境情報の確認

ローカル環境の情報を確認:

java -version
./gradlew --version

Windows vs macOS vs Linux での差異を考慮する。

トラブルシューティング

CI 設定ファイルが見つからない場合

Glob でプロジェクトルートを確認
.github/workflows/*.yml を検索
存在しない場合は、プロジェクトがまだ CI を使用していない可能性を報告

環境変数/シークレットの不足

GitHub Secrets が適切に設定されているか確認
ワークフローファイルで参照されている変数を確認
不足している場合は、ユーザーに通知して設定を依頼

Mehr aus diesem Repository

gleiches Repository

exploratory-nightly-verification

TBSten/compose-preview-lab

Nightly Checking ワークフロー上で 60 分 budget の単発探索的検証を行う運用規約。 PR 差分ではなく main の最新を対象に、ライブラリ本体・integrationTest・docs 全体を多角的に揺さぶり、発見都度 `.local/nightly-exploration/issues/` へ Markdown 起票する。 Kotlin / Compose / Gradle / AGP の最新 release 情報も探索範囲に含める。 Use when requested: "nightly 探索", "夜間探索的検証", "exploratory-nightly".

2026-05-116

exploratory-pr-verification

TBSten/compose-preview-lab

PR の探索的検証で 5 並列 subagent を category 別に kick する際の運用規約。 PDCA / MCP / 設定ファイル拡張 / CI ログ / apiDump / ticket 起票 / PR コメント / gradle 隔離 / working tree / 時間管理 / 他 KCP 比較 / 各 cat 役割 / ループ終了処理 / メンテナ反応 latency trace / close 後 handshake を含む。各探索 iter で subagent を kick する前に必読。

2026-05-096

pr-fix-loop

TBSten/compose-preview-lab

複数の GitHub Pull Request を並行管理する際、各 PR の CI ステータスと未対応 review コメントを 1 回のループで一括チェックし、失敗 check の種類 (lint / binary compat / build / test / transient infra) を自動判定して対応する fix-ci-* skill (lint=fix-ci-lint, binary=fix-ci-binary, build=fix-ci-build, test=fix-ci-test, comments=fix-ci-pr-comments) に委譲、 review コメントは取得 → 修正 → commit → push → resolve まで実行する。 stack 関係 (PR Y の base が PR X のブランチ) があれば自動で rebase 連鎖。 `/loop` skill と組み合わせれば 10 分間隔などで自動化できる (5 回連続「変化なし」で終了)。ユーザーが「複数 PR を見ながら修正」「PR ループ」「PR fix loop」「stacked PR を順番に green に」「PR を寝かせている間に CI 修正したい」「複数 PR の CI と review comment を自動で対応」などと言ったら必ずこの skill を使う。単一 PR でも、 CI fix と review comment 対応をワンセットで自動化したい文脈なら trigger してよい。

2026-05-096

pr-creator

TBSten/compose-preview-lab

ユーザーがプルリクエストの作成、PRの準備、またはコードレビュー用の変更案の作成を要求した際に使用するエージェントです。これには、ユーザーが明示的にプルリクエストの作成/オープン/ドラフトを依頼する場合が含まれます。例: - <example> Context: ユーザーが新機能の実装を完了し、プルリクエストを作成したい。 user: "新しいsealed classのコピー関数機能の実装が完了しました。PRを作成してもらえますか？" assistant: "Taskツールを使用してpr-creatorエージェントを起動し、変更のプルリクエストを準備・作成します。" <commentary>ユーザーがPR作成を要求しているため、pr-creatorエージェントを使用してプルリクエストの準備と作成プロセスを処理します。</commentary> </example> - <example> Context: ユーザーが変更をコミットし、レビューの準備ができていることを述べる。 user: "バグ修正をコミットしました。レビューしてもらいましょう。" assistant: "Taskツールを使用してpr-creatorエージェントを起動し、バグ修正のプルリクエストを作成します。" <commentary>ユーザーはコードレビューの準備ができていることを示しており、これにはPR作成が必要です。pr-creatorエージェントを使用してこれを処理します。</commentary> </example> - <example> Context: ユーザーが日本語でPR作成を直接要求。 user: "Pull Requestを作成する。" assistant: "Taskツールを使用してpr-creatorエージェントを起動し、プルリクエストを作成します。" <commentary>PR作成の直接的な要求。pr-creatorエージェントを使用してプルリクエストのワークフローを処理します。</commentary> </example>

2026-05-086

commit

TBSten/compose-preview-lab

working tree にある差分を適切な粒度でコミット

2026-05-046

fix-ci-binary

TBSten/compose-preview-lab

バイナリ互換性チェック（./gradlew apiCheck）が失敗した時の診断と修正を行う。public API の差分を確認し、必要に応じて apiDump で API ダンプを更新する。Use when "apiCheck が失敗", "binary compatibility エラー", "API ダンプを更新", "公開 API の互換性チェック".

2026-05-046

name	fix-ci-setup
description	GitHub Actions の CI/CD 環境構築・セットアップ周りの問題（JDK バージョン、キャッシュ設定、シークレット、ワークフロー定義）を診断・修正する。Use when "CI のセットアップ問題", "GitHub Actions の設定", "JDK バージョン問題", "ワークフロー定義の修正".

fix-ci-setup

CI/CD 環境構築とセットアップ診断スキル

目的

GitHub Actions CI/CD パイプラインの設定を確認し、環境構築上の問題を診断・修正する。

実行手順

Step 1: CI 設定ファイルの確認

必ず最初に実行:

.github/workflows/ ディレクトリの存在確認
- ツール: Glob で .github/workflows/*.yml を検索
各ワークフローファイルを読み込んで内容を把握
- ツール: Read で各ワークフローファイルを読み込む
- 特に pull-request.yml の内容を詳細に確認

確認すべき内容:

どのジョブが存在するか
各ジョブで実行されるコマンド
マトリックス戦略の設定
環境変数やシークレットの設定

Step 2: ワークフロー構造の理解

pull-request.yml の主要ジョブ:

lint: ./gradlew ktlintCheck
- Kotlin コードのリントチェック
validate-binary-compatibility: ./gradlew apiCheck
- バイナリ互換性の検証
test: マトリックス戦略で複数のプラットフォームでテスト
- Jvm, JS, Wasm JS, Android Debug/Release, iOS
publish: Maven Local への公開

Step 3: 環境情報の確認

ローカル環境の情報を確認:

java -version
./gradlew --version

Windows vs macOS vs Linux での差異を考慮する。

トラブルシューティング

CI 設定ファイルが見つからない場合

Glob でプロジェクトルートを確認
.github/workflows/*.yml を検索
存在しない場合は、プロジェクトがまだ CI を使用していない可能性を報告

環境変数/シークレットの不足

GitHub Secrets が適切に設定されているか確認
ワークフローファイルで参照されている変数を確認
不足している場合は、ユーザーに通知して設定を依頼