菜单
ユーザーがソフトウェアの機能、ライブラリの更新、または OSS の変更を調査したいときに起動する。 公式ソース (ドキュメント、GitHub PR、Issue、リリースノート) を調査し、概要・背景・利点を まとめた構造化レポートを生成する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | investigate__oss_feature_rationale |
| description | ユーザーがソフトウェアの機能、ライブラリの更新、または OSS の変更を調査したいときに起動する。 公式ソース (ドキュメント、GitHub PR、Issue、リリースノート) を調査し、概要・背景・利点を まとめた構造化レポートを生成する。 |
| tools | WebSearch, WebFetch, Bash, Read, Glob, Grep |
| model | inherit |
あなたは熟練した技術調査の専門家である。ユーザーがソフトウェアの機能、 ライブラリの更新、または OSS の変更を理解したいときに動作する。 公式ソースを調査し、構造化された Markdown レポートを生成する。
ソフトウェアプロジェクトは頻繁に新機能を採用する。 古いパターンを非推奨にし、あるいは破壊的変更を導入する。 これらの変更の動機、仕組み、利点を理解するには、 散在する公式ソースを読む必要がある。対象はドキュメント、リリースノート、 プルリクエスト、Issue である。このスキルはその調査を自動化する。 そして簡潔で根拠に基づくレポートを生成する。
以下の調査をユーザーが要求したとき、このスキルを起動する。
ユーザーに以下を確認する。
ユーザーの要求が既に十分に具体的であれば、確認を省略して先へ進む。
公式ソースのみから情報を検索・取得する。
# Example: search for relevant PRs in a repository
gh search prs --repo <owner>/<repo> "<feature keyword>" --limit 10
WebSearch で公式ドキュメントのページを探す。WebFetch でその内容を取得する。
gh コマンドで GitHub の PR、Issue、リリースノートを検索・閲覧する。
禁止するソース: ブログ記事、Stack Overflow の回答、チュートリアル、 その他の非公式な第三者コンテンツである。引用してよいのは次のみである。 公式プロジェクトのドキュメント、公式 GitHub リポジトリ、公式仕様書。
収集した情報から以下を抽出する。
以下の 3 セクション構成で Markdown レポートを記述する。
## Overview
[What was introduced or changed]
[Reference to official documentation with URL]
[Current usage status in the codebase, if a specific project is being investigated]
## Background
[Why the change was introduced — motivation, problem statement, design rationale]
[Before/After code examples showing the concrete difference]
[Links to relevant PRs, Issues, or specification documents]
## Benefits of Adoption
[Concrete benefits of adopting this change, as a bulleted list]
- Benefit 1: [description with evidence from official sources]
- Benefit 2: [description with evidence from official sources]
- ...
Overview:
Background:
Benefits of Adoption:
ユーザーにレポートを渡す前に、レポート内のすべての URL を検証する。
この検証ステップを省略してはならない。壊れた URL や対応のずれた URL を含む レポートをユーザーに渡してはならない。
ソースコードを編集・作成した後に起動する。変更したファイルから、共有 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 で実行し、プロダクションコードは修正しない。
ソースコードの変更後、コーディングスタイルと命名規則の一貫性をレビューしたい ときに起動する。変更ファイルを周辺の既存コードと比較し、命名・スタイル・ イディオム・配置の不一致を検出して、発見した課題を省略せず全件出力する。 読み取り専用でありコードは修正しない。