ultradoc

ultradoc

取得したソースの根拠に基づいて回答し、出典を明記した回答またはリファレンスマニュアルを提示します。付属の scripts/ultradoc.mjs は依存関係のない Node エンジンです。 スクリプトのパスは、対象のチェックアウトではなく、このスキルのディレクトリを基準に解決してください。

必要十分な最小ルートを選ぶ

リクエスト	ルート
ローカルの事実または名前付き宣言が1つ	以下の簡易回答
挙動、曖昧さ、解釈、Issue/PRの根拠	以下の標準回答
プロジェクト／パッケージ全体のリファレンスドキュメント	workflow.md の doc ワークフロー
宣言本体／呼び出し元	symbol --repo <path> --name <symbol>。字句検索だけでは呼び出しを特定できません
複数ファイルにまたがる実装 → 呼び出し元 → テスト	trace。trace.md を先に読んでください
バージョン／変更履歴	releases,history を取得します。指定がある場合は --ref を固定します

フラグを確認するには、node <skill-dir>/scripts/ultradoc.mjs --help を使用してください。ローカルのみを対象とするリクエストでは --sources code,docs を使用し、リモートプロバイダーを調べないでください。証拠から不足が判明しない限り、簡単な質問のためにワークフロー全体、概要、任意のセマンティック設定、オーケストレーションを読み込まないでください。

簡易回答

最大3つのコード／ドキュメントの文字どおりの記述で確認できる事実が1つの場合：

1. ask --repo <path> --q "<identifier and question>" --sources code,docs --out <run-dir> を実行します。取得メモを読み、続いて EVIDENCE.md の関連する抜粋を読みます。名前付き宣言が1つの場合は、代わりに symbol から始め、その後、回答／チェックのワークフローで必要な証拠を保存できます。
2. citation-format.md を読み、実行ディレクトリに ANSWER.md を作成します。最初に回答を示し、各文に1つの主張を記載し、それぞれに [E#] を付けてください。meta.json の固定されたコミットをHTMLコメントに記載します。未解決事項は ## Unknowns の下に記載し、記憶から補わないでください。効果を説明する前に、コールバックのデフォルト値と注入された依存関係を調べます。計算値／要求値と実行された効果を区別してください。何もしない実装は、効果がないことの証拠です。不明な点として扱ったり、実際のタイマー／書き込み／ネットワーク呼び出しとして扱ったりしないでください。
3. check --run <run-dir> --strict を実行します。引用／網羅性に関するエラーを修正し、再実行してください。網羅性の要約で主張が3つを超える場合は、以下の標準的なセマンティック検証を使用します。厳格チェックに合格しても、この条件は免除されません。回答、クリック可能なソース参照、コミット、未解決事項を提示してください。

抜粋で質問への回答が確認でき、チェックに合格したら終了します。読み取り専用の説明のために、無関係なプロジェクトテストを実行しないでください。追加の取得は、特定された証拠の不足を補う場合に限ります。コマンドの実行回数を満たすことは求められていません。

解釈、異論のある挙動、またはIssue/PRに関する主張には、以下のセマンティック検証が必須です。解決可能な引用だけでは、主張の裏付けにはなりません。

標準的な回答とセマンティック検証

1. プロジェクト、具体的な質問、要求されたバージョンを特定します。対象が曖昧で取得できない場合に限り、質問します。複数の部分から成る質問は、明示的な小項目に分けます。ソースやクエリのバリエーションを選ぶ際は、retrieval-playbook.mdを読み、固定した資料一式を保存するにはaskを使用します。
2. スニペットを読む前に取得に関するメモを確認します。切り詰め、レート制限、正規表現の階層分析、プロバイダーの欠落は、回答の範囲を制限します。わかりにくいメモは、reading-evidence.mdとengine-evidence.mdを参照して読み解きます。
3. 未解決の小項目だけを掘り下げます。標準の場合は、各小項目について関連性のある項目を2つ対象に、1回の掘り下げを行います。詳細な調査や見解が分かれている場合は、最大3回まで行い、新たな関連エビデンスが得られない回で終了します。残る不足点を明示します。
4. 高速経路と同じ回答の要件に従って回答を作成します。必ずcheck --strictを実行します。
5. verify --run <run-dir>を実行し、すべての主張とエビデンスの組み合わせを慎重に評価して、具体的な注記とともに supported、partial、refuted、unsupportedのいずれかに分類します。issue／PRに関する主張は、現在のコードと照合します。判定結果を1つのファイルにまとめてから、verify --apply <verdicts.json> --run <run-dir>とcheck --semantic --run <run-dir>を実行します。検証が欠けている場合は不合格とします。裏付けのない主張は修正、限定、削除、または再取得してから再検証します。合格するためにゲートを迂回してはいけません。
6. answer-rubric.mdを確認してから、出典リンク、コミット、網羅性の不足点を含め、ユーザーの言語で回答を提示します。

エビデンスに関するルール

• 回答は取得したエビデンスのみに基づきます。よく知られたAPIや一致するキーワードだけでは不十分です。スニペットが実際の記述を裏付けている必要があります。
• 空の取得結果、上限に達した結果、または失敗した取得を、存在しないことの証拠として扱ってはいけません。結論の範囲は検索した内容に限定し、取得できなかったソースを開示します。
• check --strictは、すべての回答と生成されたすべてのDOC.mdに適用されます。上記の限定的な高速経路を除き、セマンティック検証が必須です。
• 復旧可能なエラーが発生しても処理を続けます。関連性のないクエリは言い換え、切り詰められたモノレポは--packageで範囲を限定します。オフラインでは利用可能なローカルソースを使い、不足点を明示します。失敗したプロバイダーからエビデンスを得たと主張してはいけません。
• 取得と検証は順次実行できます。任意の並列処理によってエビデンスや終了ゲートが変わることはありません。

必要な場合のみ詳細を確認

• workflow.md：ワークフロー全体、ドキュメント、復旧表、ソースの振り分け、任意のセマンティックモード。
• tuning.md：上限、キャッシュ、コスト、ノイズの多い取得。
• orchestration.md：独立した作業リスト、サブエージェントの契約、順次実行のエコモード。1人の作成者が結果をまとめます。
• provider-apis.md：issue／PRプロバイダーの問題。
• web-discovery.md：ウェブの抽出と発見。
• semantic-setup.md：任意のローカルベクトル階層。
• worked-example.md：回答全体の例。