Skill.md検索

テンプレート差分を自動検出: ローカルプロジェクトで加えたテンプレート関連ファイルの改善を自動で検出し、テンプレートリポジトリへの貢献候補として提示できます。 プロジェクト固有コンテンツの自動チェック: テンプレートに提出予定のファイルに、プロジェクト固有の値（プロジェクト名、APIキーなど）が混入していないか、置換ログベース + 正規表現マッチングで検証します。 貢献ファイルの選別: 検出された全変更について、ユーザーに貢献するかどうかを確認させ、無駄なPR提出を防ぎます。 テンプレートへの自動PR作成: 汚染チェックを通過したファイルを、テンプレートリポジトリに対して Pull Request として自動提出できます。 複数ファイル対応: .claude/commands/、.claude/skills/、.devcontainer/、scripts/、install.sh など、複数のテンプレート由来ファイルを一括処理できます。 複数プロジェクト運用しているチーム: テンプレート改善を集約し、全プロジェクトに共通の改善を還元したい スキル・コマンド開発者: 新規スキルやコマンドをテンプレートに追加提案し、他プロジェクトへの波及を促したい テンプレート保守者: プロジェクト側からの改善提案を、汚染チェックを通して安全に取り込みたい DevOps・インフラ導入者: DevContainer や スクリプト改善をテンプレートに還元し、オンボーディングを継続改善したい テンプレート由来ファイルの改善をテンプレートリポジトリにPRとして提出するスキルです。対象ファイル：.claude/commands/、.claude/skills/、.claude/CLAUDE.md、.devcontainer/、scripts/、install.sh。 Workflow：(Step 1) テンプレートリポジトリをクローン→ローカルとの差分検出、(Step 2) 検出された変更をユーザーに提示、(Step 3) ユーザーが貢献ファイルを選択、(Step 4★必須) 機械的な汚染チェック（.claude/template-substitutions.json ベースで、プロジェクト固有値の残存を検出し、プレースホルダー（{{...}}）への置換を指示）、(Step 5) 選別したファイルでテンプレートリポジトリに PR 作成。汚染チェックでは、置換ログに記録されたプロジェクト固有値がファイルに残っていないか grep で検証し、残存があれば「汎用的な表現に置き換え」を指示。

品質チェックスクリプト・多角的レビューを実施してからコミット＆プッシュ＆マージし、タスクを完全に完了できます。 QA回答の確認から始まり、品質チェック→多観点レビュー→PR作成→Issueクローズ→Worktree削除まで一括で処理できます。 Auto-Approval モード（--auto または auto フラグ）で、品質チェック通過時に自動承認されるため、確認作業を大幅に削減できます。 品質チェック失敗時には修正提案と再実行を自動で試行し、修正なしで進まないため本番環境への悪いコードの流入を防げます。 タスク実装が完了して、これからマージしたい開発者 Auto-Approval で自動審査・自動マージしたいチーム PR レビューを自動化して開発速度を上げたい人 品質基準を満たさないコードの本番投入を避けたい人 Phase 0: Quality Assurance（品質チェック）の 5ステップ。Step 0 では docs/qa/answers.jsonl から QA回答を確認、新回答があれば表示して実装修正の必要性判定。Step 1 で git status/git diff で変更内容確認。Step 2 でプロジェクト固有の scripts/quality-check.sh 実行（失敗時は修正提案・再実行）。Step 3 で /review コマンドで多角的レビュー実施（アーキテクチャ・リスク・テスト・Fallback・仕様充足等のサブエージェント並列実行）、絶対スキップ不可。Step 4 でレビュー結果提示。Step 5 で承認判定分岐：Auto-Approval モード判定（--auto または auto 引数、または /issue/auto から呼び出し）、品質チェックパスで自動 Phase 1 進行。/commit/push との比較表：merge は品質レビュー・PR作成・squash マージ・Issue クローズ・Worktree削除を実施、push は途中保存のみ。

docs/backlog.md のバックログ項目を自動分析し、「後回しにした理由」を分類して、解消可能なブロッカーを判定します。 自動解消可能なブロッカー（実装・テスト追加・設計完了で対応可能なもの）に対して、具体的なIssue（例：「test: Add real FAISS E2E tests」）を自動作成します。 ユーザー確認が必要なブロッカー（判断が必要な場合）も検出し、レポートするため、何も見落とさないようにできます。 ドライラン機能で、実際にIssue作成する前に分析結果を確認でき、安心して実行できます。 バックログに積み上がったタスクの阻害要因を整理し、開発を加速させたいプロジェクトマネージャーやリード ブロッカーが何かをリストアップするのに手作業をかけたくない開発チーム ブロッカー解消のための具体的なタスク化を自動化したいアジャイルチーム バックログ (docs/backlog.md) のブロッカーを分析し、自動解消可能なものについてIssueを作成します。ブロッカーがない項目のIssue化は別スキル /issue/backlog が担当します。使用方法は /issue/unblock（標準実行）、/issue/unblock --dry-run（分析のみ）、/issue/unblock --all（ユーザー確認必要な項目も報告）です。各バックログ項目から「後回しにした理由」を分析し、🤖自動解消可能（実装・テスト追加で解消）と👤ユーザー確認必要に分類します。自動解消可能な項目について具体的な不足を分析し、対応するIssueを作成するワークフローとなっています。

開発中の判断事項（CSV か JSON か、認証方式など）を structured な質問として docs/qa/questions.jsonl に記録できます。 質問投稿後、自動的に Slack/Discord に通知し、チームからの回答を約1分間待機します。 回答がない場合は仮決定（provisional decision）を自動採用して作業を継続し、判断遅延を防ぎます。 全ての質問と回答を JSON Lines 形式で履歴管理でき、後から /qa/check で確認・監査できます。 分散チーム・リモート開発で、チーム意思決定を記録・追跡したい人 プロジェクトマネージャーで、重要な判断ポイントの履歴を残したい人 開発がブロックされることなく、非同期で意思決定をキャッチアップしたい人 使用例：/qa/ask "CSV or JSON?"、/qa/ask --type provisional --decision JSON "Data format preference?"、/qa/ask --type deferred --stub "auth_placeholder()" "Authentication method?"。パラメータ：question（必須）、--type（provisional|deferred、デフォルト provisional）、--decision（provisional の仮決定）、--stub（deferred のスタブコード）、--options（選択肢カンマ区切り）。実装：scripts/qa/models.Question、qa.store.QAStore を使用。ワークフロー：(1)ブランチ名から Issue 番号抽出、(2)次の質問ID生成（Q001,Q002,…）、(3)Question オブジェクト作成、(4)docs/qa/questions.jsonl に追記。投稿後、wait_for_answer 関数で約60秒間 answers.jsonl をポーリング（5秒間隔）。回答受信時は「✅ 回答を受信」とログ出力。タイムアウト時、provisional の decision がある場合は notify_decision で Slack スレッドに仮決定を投稿して作業継続。answer が null なら「⏳ タイムアウト。後で /qa/check で確認してください」と案内。