RTFM-First
ユーザーが提供したマニュアルを、このタスクにおける唯一の信頼できる情報源として扱います。記憶やオンラインの情報に頼ってコードを書かないでください。
鉄則
- マニュアルが存在する場合は、コードを書く前に必ずマニュアルを読んでください。API名、パラメータ、デフォルト値、単位、動作は全てマニュアルに従います。
- コーディングを開始する前に、マニュアルのバージョンと現在の環境バージョンを照合し（「環境のスキャンとバージョン照合」を参照）、その結果をユーザーに報告してください。
- マニュアルから重要な事実を引用する場合は、出典を明記してください：
.rtfm/<名前>.txt:行番号またはPAGE n。 - マニュアルとコードまたは環境が矛盾する場合、すぐにコードをオンラインの慣習に合わせて「修正」しないでください。一旦作業を止めて差異を説明し、ユーザーに判断を仰いでください。
- マニュアルがない場合は、まずマニュアルのパスを要求または確認し、記憶だけで実装を始めないでください。
- 何かを「修正」する前には、必ずマニュアルのどの条項に違反しているかを指摘できなければなりません。出典を示せない場合は、変更を許可しません。
ワークフロー
1. マニュアルの特定と抽出
- ユーザーがパスを指定しなかった場合、プロジェクト内の候補ファイルを検索します（
*.pdf、*.md、docs/**、READMEで言及されている仕様書など）。複数の候補がある場合は一覧表示し、ユーザーに確認を求めてください。 - スクリプトは、このSKILL.mdが置かれているディレクトリの
scripts/にあります。 - プロジェクトルートの
.rtfm/ディレクトリに統一して抽出します（gitリポジトリの場合は、必ず.gitignoreに.rtfm/を含めてください）：- PDF：このスキルの
scripts/extract_manual.py <manual.pdf> .rtfm/<名前>.txtを実行します。 - MD/TXT：同じスクリプトを実行し、テキストとしてコピーします。
- PDF：このスキルの
- 複数のマニュアルがある場合（例：APIリファレンス＋プロトコル仕様＋SDKドキュメント）、全て抽出し、それぞれにインデックスを作成します。引用時にはどのマニュアルかを明記してください。
- PDFがスキャン画像である場合（抽出テキストが極端に短い場合）、OCRが必要であることを報告し、内容を推測しないでください。
- スクリプトが「PDFテキスト抽出器がない」とエラーを出した場合は、指示に従って
poppler-utilsまたはpypdfをインストールしてから再試行してください（システム全体へのインストールが必要な場合は、事前にユーザーの同意を得てください）。PDFをスキップして記憶だけに頼ってコードを書くことは禁止します。 - まずタイトルページ/序文/改訂履歴を読み、以下の情報を記録します：製品名、マニュアルバージョン、対象バージョン、日付、改訂内容。
2. インデックスの作成
- このスキルの
scripts/index_manual.py .rtfm/<名前>.txt .rtfm/index.mdを実行します。 - トピックを検索する際は、必ず
rg -nでインデックスと本文を検索してください。「そんな記憶はない」という理由で、マニュアルに書かれていないと判断しないでください。
3. 環境のスキャンとバージョン照合
- 環境の証拠を収集します：マニフェスト/ロックファイル（package.json、pyproject.toml、Cargo.lock、go.mod、requirements*.txt など）、
--version/-V、pkg-config --modversion、ランタイムバージョン、SDK/ツールチェーン/ハードウェア識別子。 - マニュアルの表紙、改訂履歴、フッター、メタデータからマニュアルのバージョンを特定します。
references/version-matching.mdに従って、MATCH / COMPATIBLE / MISMATCH / UNKNOWN を判定します。- 結果を
.rtfm/version-report.mdに書き込み、ユーザーに報告します。 - MISMATCH または UNKNOWN の場合は、そこで作業を止めてください：ユーザーに一致するバージョンのマニュアルを提供してもらうか、続行の明確な承認を得てください。承認された場合は、そのリスクをメモに記録してください。
4. マニュアルに従ってコードを書く
- 各コンポーネント/APIに取りかかる前に、関連するセクションを全て読んでください。主要なシグネチャ、定数、デフォルト値、境界条件を
.rtfm/notes.mdに抜粋し、出典を添付してください。 .rtfm/notes.mdの推奨構造：マニュアル名とバージョン、バージョン照合結果（MATCH/COMPATIBLE/MISMATCH/UNKNOWN）、トピック別の抜粋（各行にmanual.txt:L行またはPAGE nを付ける）、変更履歴。- 識別子、文字列、数値はマニュアルからコピーしてください。自分で書き写して誤記を混入させないでください。
- マニュアルでカバーされていない点は、TODO + 出典（例：「マニュアルの○○節で説明なし」）を明記し、黙ってオンライン情報で補完しないでください。どうしても補完が必要な場合は、事前にユーザーの同意を得てください。
- マニュアルに書かれていることは絶対です：たとえオンラインの「ベストプラクティス」と異なっていても、ユーザーから要求があった場合、またはビルド/テストの証拠がマニュアルの内容と現在の環境が一致しないことを示す場合を除き、オンラインバージョンに「修正」しようと繰り返さないでください。
5. 検証と完了
- 完了後、マニュアルの各セクションと照らし合わせてセルフチェックを行ってください：使用した全てのAPI/設定/動作について、notes内に出典があることを確認します。
- ビルド/テストを実行します。失敗した場合は、まずマニュアルの該当セクションを参照して根拠を調べ、次に環境を確認します。推測は禁止です。
- 納品時には、以下の情報を簡潔にリストアップします：マニュアルバージョン、環境バージョン、照合結果、主要な出典、およびユーザーの確認が必要な差異。
修正ループの防止
このスキルが存在する直接的な理由：AIがマニュアルを読まず、オンラインの記憶に基づいてコードを「修正」し、また間違え、さらに修正するという繰り返しを防ぐためです。以下のルールは必ず守ってください：
- 修正前に証明すること：コード/設定を変更する前に、必ず「現在の実装がマニュアルのどの行に違反しているか」を指摘し、出典を引用してください。出典を示せない場合は変更を許可しません。
- 一度に一つの理由だけを修正すること：「見た目が気に入らない」と「マニュアルと一致しない」を同じ修正に混ぜないでください。関係のないコードはそのままにしておきます。
- 同じ現象が2回修正されてもまだ発生する場合：パッチを当てるのをやめ、マニュアルに戻って関連セクションを全て読み直し、自分の理解が間違っている可能性を疑ってください。推測を続けてはいけません。
- マニュアルの動作とオンラインの慣習が衝突する場合：マニュアルを優先します。「動くがマニュアルに準拠していない」コードをオンラインバージョンに変更してはいけません。その逆も同様です。
- エラーが発生したらまずマニュアルを調べること：エラーコード、制約、境界条件のセクションを確認してください。マニュアルに対応する項目がない場合は、環境の証拠を調べます。直感で変更することは禁止です。
- 毎回の変更は、
.rtfm/notes.mdの変更履歴に一行追加します：対象、変更内容、根拠の出典。2回修正しても問題が解決しない場合は、変更履歴を確認して同じ修正を繰り返していないか確認してください。