kai-kou
Userstar の多さでは埋もれてしまう「実際に使われている OSS」を、個人開発者が見つけられるようにする検索プラットフォーム
Categories
Indexed Skills (21)
claude-code-spec-sync
Claude Code 本体のバージョンアップ（changelog/releases）を定期キャッチアップし、本プロジェクトのルール・スキル定義・ハーネス（hooks）・設定を最新仕様に追随させるレーンのオーケストレーター。破壊的変更（これまでのやり方がエラーになる類）は検知したセッションが即対応（影響調査→修正→PR→マージ）、新機能・新設定は検証・検討フェーズ（Issue）を経てから反映する。「Claude Code の仕様変更に追随して」「Claude Code の最新情報をキャッチアップして」「spec-sync 実行して」「/claude-code-spec-sync」と依頼された時、または lane:claude-code-spec Issue を検知した定期スロット（R-1 ルーティンのプリフライト）で使用する。
project-sync
リポジトリ衛生管理スキル。Stale Issue（4時間超 in-progress）検出・Orphan PR（24時間超放置）解消・Abandoned ブランチ検出を自動実行する。「project-sync して」「リポジトリを整理して」「/project-sync」で起動する。プロジェクト定義の衛生スロットで自動実行される。受動的な衛生掃除が役割で、Issue 作成・進捗更新など能動的なタスク運用は project-manager を使う。
research-runner
Deep Research を完全自動実行するスキル。ネイティブ `/deep-research`（クラウド環境でも直接実行可能・Opus orchestrator）を主エンジン、`claude -p` サブプロセス経由の `/deep-research` を第2、DIY（Sonnet 5 + WebSearch/WebFetch のウェブリサーチ）を最終フォールバックとして、`content/research/{ID}_prompt.md` から `content/research/{ID}_deep_research.{md,json}` を自動生成し、品質ゲート・PR 作成・AIレビュー・自動マージまでを担う。外部 LLM API（Gemini 等）によるディープリサーチは行わない。「リサーチ自動化し���」「ディープリサーチして」「research-runner」と依頼された時に使用する。「ディープリサーチして」の既定エンジンは本スキルであり、ビルトインの deep-research や素の WebSearch へ直行しない。
apply-base
kai-kou/claude-code-repository-base（公開ベース）の汎用ルール・スキル定義・ハーネス一式を現在のリポジトリへ反映（適用・同期）する。「claude-code-base の内容を反映して」「claude-code-base を適用して」「ベースを反映して」「ベース設定を取り込んで」「claude-code-base で初期化して」「claude-code-base のアップデートを確認して適用して」「ベースのアップデート内容を確認して」等と依頼された時に使用する。前回適用時点からの更新内容（コミット一覧・手動手順が必要な更新）の確認も本スキルが担う。公開リポジトリのベースを git clone（クラウドでは gh の repo スコープ操作が 403 でブロックされるため git/MCP 経路）で取得して適用するため、ユーザーがコマンドを打つ必要はない。
checkpoint
Phase 境界でのチェックポイント作成スキル。長時間パイプラインのステップ完了時に git commit + 状態スナップショットを保存し、セッション切れ・失敗時の安全な復元ポイントを確保する。「チェックポイントを作って」「Phase 完了を記録して」「セーブポイントを作成して」と依頼された時に使用する。
code-review
自前実装のコードレビュースキル（組み込み /code-review の置き換え・FAIR Layer 1 の標準実行手段）。PR 差分または作業ツリー差分を観点別フレッシュ文脈レビュー（並列サブエージェント）→ 敵対的検証 → 指摘報告の 3 段で実行し、PR 文脈では指摘の有無にかかわらず必ず行単位インラインコメントでレビューを残す。「/code-review」「コードレビューして」「差分をレビューして」「PR
discussion-review
議論型レビュー（敵対的相互レビュー）をネイティブ Agent Teams（name 付き Agent tool + SendMessage + 共有ホワイトボード）で実行する。「専門チームを組成して」「チームで議論して」「議論型レビューして」「/discussion-review」と依頼された時、および pr-review-watcher の Layer 2 自動起動（discussion_review_trigger.py が対象と判定した時）に使用する。claude -p サブプロセスは起動しない（失敗時のみ tools/run_discussion_review.py へフォールバック）。役割分担型 fan-out（独立評価の集計）で足りる軽微タスクには使わない。
pr-review-watcher
PR 作成後のレビュー監視・指摘対応・自動マージを自律実行するスキル。「PR を監視して」「レビュー対応して」「PR をマージまで見届けて」「レビュー待ち PR を回収して」と依頼された時、PR 作成フローの直後、またはセッション復帰時に check_pending_pr_reviews.py がレビュー待ち PR を検出した時に必ず使用する。Layer 1 セルフレビュー（自前 code-review スキル。組み込み /code-review を同名 project スキルで置換済み・自律起動可）を必ず実行し、指摘対応 → 自動マージまでを自律実行する。外部 AI レビュアー（Copilot/Gemini）への依頼はしない。CI・人手コメントは subscribe_pr_activity で任意監視する。対応はサイレント（ユーザー報告せず PR スレッド・Issue 記録のみ・L-102）。
project-manager
GitHub プロジェクト（Milestones・Projects V2・Issues・Labels）を管理する。タスク作成・ステータス更新・マイルストーン反映・新規指示の Issue 化を行う。「タスクを作って」「Issue にして」「進捗を更新して」「マイルストーンに反映して」と依頼された時に使用する。能動的なタスク運用（作る/進める）が目的。放置された Issue/PR の受動的な衛生掃除が目的なら project-sync を使う。
retro-try-handler
type:retro-try ラベル（およびプロジェクト定義の更新系ラベル）の未対応 GitHub Issue を自動検出・分類・実装・PR 化するスキル。レトロスペクティブスキルが生成した Try アイテムを実際の改善コードとして反映する。「retro-try 対応して」「Try Issue を処理して」「/retro-try-handler」と依頼された時、または `sprint-cycle-router` の決定木 Step 5.5（2 時間おきの単一ルーティン・エージング 8 時間）から自動起動される時に使用する。
retrospective
各ワークフロー実行後に Agent Teams（3役割の並列サブエージェント）でレトロスペクティブを実施し、KPT（Keep/Problem/Try）を生成・Try アイテムを GitHub Issue 化する。各パイプライン（プロジェクト定義）の最終ステップから自動呼び出しされ、「レトロスペクティブして」「/retrospective」で手動実行も可能。KPT 生成・Try の Issue 化までが役割で、生成済み Try Issue の実装は retro-try-handler が担う。
self-improvement-loop
プロジェクト全体を定期的に横断レビューし、根本原因特定→改善Issue起票→棚卸し（集計・重複統合・Epic化・priority/sp 補完・低優先/滞留 Issue のリファインメント）→最優先即実装→マージまで自律実行するセルフ改善オーケストレーター。発見（定期の N 観点横断レビュー）・整理（棚卸し + リファインメント）・消化（改善Issueの高速処理）の3モードで動く。「セルフ改善して」「横断レビューして」「プロジェクト改善して」「改善Issueを棚卸しして」「改善バックログを整理して」「Epic化して」「リファインメントして」「後回しになっている Issue を精査して」「改善Issue消化して」「/self-improvement-loop」と依頼された時、またはプロジェクト定義の発見スロット / 日次消化スロット / リファインメントの週次ゲート（プロジェクト定義の定期ルーティン）で自動実行する。type:retro-try（振り返り由来の Try）は retro-try-handler、Issue/PR の状態・衛生は workflow-health-check / project-sync が担当する。
self-reviewer
PR作成前にセルフレビューを実行し、AIレビュアーが指摘しそうな問題を事前に検出・修正する。PR作成直前の最終チェックとして、「セルフレビューして」「PR前にチェックして」と依頼された時に使用する。PR 作成前の事前チェック（Step 0-3）と PR 作成前フレッシュ文脈レビュー（Step 3.5・自前 code-review スキルを --pre-pr で呼び出して CONFIRMED を修正してから PR を作る・#627）が主担当で、PR 作成後の Layer 1 観点別フレッシュ文脈レビューは同じ自前 code-review スキル（.claude/skills/code-review/・組み込みを置換・自律起動可）を Skill(code-review) で呼び出して実行する。
skill-audit
本リポジトリの Agent Skills（`.claude/skills/*/SKILL.md` + `.claude/commands/*.md`）を棚卸し監査する。トリガー衝突・死蔵・陳腐化（L-114 未追従含む）・肥大化・責務重複・欠落を観点別に検出し、description の発火精度を採点し、検出問題を Issue 化する。「Skill を棚卸しして」「スキル監査して」「/skill-audit」と依頼された時に使用する。個別スキルの中身の実装・修正は各スキル自身、ワークフロー健全性（PR/Issue 状態）の監査は workflow-health-check が担当するため、本スキルは Agent Skills 資産の構造監査に限定する。
skill-creator
新規スキルの作成・既存スキルの改善・スキル性能の測定を行うスキル。スキルをゼロから作成する・既存スキルを編集/最適化する・eval でスキルをテストする・分散分析でスキル性能をベンチマークする・トリガー精度向上のため description を最適化する、といった場合に使用する。「スキルを作って」「スキルを改善して」「スキルを評価して」「/skill-creator」等で起動する。
sprint-cycle-router
単一ルーティン（N 時間ごとの cron 起動）でスプリント開発を自走させる決定木ルーター。破壊的変更対応・自 PR 回収・進行中スプリント再開・SP→Issue 同期・新規スプリント着手（TDD・縦切り・専門チーム編成）・改善Issue消化・振り返り Issue 消化・衛生・週次リファインメント・spec-sync 検証の 10 ブランチから、1 firing につき該当する最初の 1 つだけを実行する。「スプリント自走ルーティン」「N 時間ごとの開発を進めて」「スプリントサイクルを回して」「/sprint-cycle-router」と依頼された時、またはルーティン設定（`docs/routines/sprint-cycle-routine.md`）から自動起動する時に使用する。各ブランチの実処理は既存パイプラインスキル（`claude-code-spec-sync` / `pr-review-watcher` / `self-improvement-loop` / `retro-try-handler` / `workflow-health-check` / `project-sync`）に委譲し、本スキル自身は「今どのブランチを実行すべきか」の判定と Step4（新規スプリント着手）の内部手順だけを持つ。改善Issueの発見・棚卸し自体は `self-improvement-loop`、リポジトリ衛生の監査自体は `workflow-health-check` の担当（本スキルはそれらの呼び出し元）。
waiting-user-handler
status:waiting-user の Issue を定期トリアージし、ユーザー確認最小化（A/B/C/D分類）で自動解決できるものは自律処理、真にユーザー判断が必要なものだけを事前リサーチ＋推奨案付きで AskUserQuestion でまとめて提示し、回答に基づいて処理するスキル。「waiting-user対応して」「waiting-userのIssueを確認して」「/waiting-user-handler」と依頼された時、またはプロジェクト定義の棚卸しスロットで自動実行する。Issue ラベルのトリアージが役割で、PR のレビュー監視・マージは pr-review-watcher を使う。ユーザーが実際に画面を操作する必要がある工程を 1 手順ずつ案内して一緒に進める段階は interactive-guide に委譲する（本スキルはトリアージ・提示までを担う）。
workflow-health-check
開発・運用ワークフローの健全性（PR 健全性・Issue 状態・パイプライン整合性・retro-try フィードバックループ・CLAUDE.md/常駐ルール肥大化）を自動監査し、問題を検出したら根本原因を特定して自動修正するスキル。「ワークフロー監査して」「ヘルスチェックして」「/workflow-health-check」と依頼された時に使用する。完全版は手動起動またはプロジェクトの定期ルーティンに組み込んだ週次ゲートから、軽量版（PR 健全性 + Issue 状態のみ）は日次の衛生スロット（project-sync 開始時）から実行される。監査ロジックの主体は本スキルで、project-sync は本スキルの軽量版を呼び出す側（主従関係）。
interactive-guide
Claude が代行できないユーザー操作（外部サービスの管理画面設定・アカウント作成・ローカル PC の GUI 操作・2FA/CAPTCHA 等）を、全体像サマリー提示 → 1 工程ずつ案内 → 完了確認、のループでユーザーと交互に進めるスキル。各工程の手順・URL は提示直前にリサーチして最新化し、UI 差異が疑われる工程ではキャプチャ画像を求めて確認する。「画面操作を一緒に進めて」「手順を案内して」「（外部サービスの）設定を手伝って」「〜のセットアップを手伝って」「画面の操作を教えて」と依頼された時、および他スキルが「この工程はユーザーが手を動かすしかない」と判定した時に使用する。Claude がファイル編集・CLI・API・MCP で代替できる作業には使わない（Claude Code 自体の settings.json 変更は update-config、コード実装の協働依頼は通常の自律実行）。status:waiting-user Issue のトリアージ・自動解決可否の判定は waiting-user-handler が担当し、本スキルはその判定後（または直接依頼）の実作業を担う。content/research/*_deep_research.* のような独立調査レポートは作らない（それは research-runner）。Issue 化は user-instruction-issue-rules.md の通常フローに従う（project-manager の代替ではない）。
doc-review
ドキュメントを7つの専門軸で並列レビューし、統合修正計画書を作成する。「ドキュメントレビュー」「文書レビュー」と言われた場合にも使用。
cjk-markdown-fix-poc
PoC 専用ファイル（scripts/run_body_loop.py の対象）。実スキルとして登録・起動しない。CJK Markdown の半角スペース修正ルールを本体に持ち、決定論的採点版の本体最適化ループの被最適化対象として使う。
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.