reviewing-user-research-prior-art-survey について
ユーザー調査の先行研究資料を、権威ある条件一覧に照らして確認するスキルです。調査そのものではなく、検索と発見が記録に正確に反映されているかを重視し、検証と根拠に基づく判定の手順を定めています。
主な機能
- 01番号付き条件に沿った調査資料の確認
- 02決定論的な検証ゲートの実行
- 03引用した根拠に基づく指摘
- 04承認または修正の単一判定
活用シーン
- 01受け入れ前の調査用語マップ確認
- 02ソースマップと併せた検索結果のレビュー
- 03証拠レジスターと付属レポートの評価
- 04調査記録内の根拠のない主張の特定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ bm629/ agent-skills --skill reviewing-user-research-prior-art-surveyインストール後、Claude Code で/reviewing-user-research-prior-art-surveyを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/conditions.mdsources.mdreferences/fixtures/C30-transferability-restates-method.mdC32-findings-not-distinct.mdC33-population-is-the-project.mdextract.clean.mdregister.clean.yaml詳細
reviewing-user-research-prior-art-survey — SKILL.md
概要
生成された成果物を、references/conditions.md に記載された40項目の基準に照らして評価します。このファイルが正式な基準です。この本文では、その適用方法を説明しますが、条件を規範的に言い換えることはありません。
この構成にしているのは、生成側とレビュー側で基準を重複させると、内容に食い違いが生じるためです。一方の文書では kept が結果を数えるとし、もう一方では行を数えるとしても、どちらも単独では正しく見えます。そして、成果物を書いていない側が採点したときに初めて、食い違いが明らかになります。
有効にするタイミング
- 調査用語マップ、ある観点の検索結果、抽出コンテナー、またはエビデンス登録簿とそのレポートが受け入れられる前に評価するとき。
次の場合は有効にしないでください: これらの成果物のいずれかを作成するとき(生成側の対となるものです)。また、基礎となる調査が科学的に優れているかどうかを評価するとき。基準となるのは、調査内容ではなく、成果物が何を検索し、何を見つけたかを正直に示しているかどうかです。
渡されるもの
成果物と、検索結果の場合は、その作成元となった用語マップです。検索結果にマップが添付されていない場合は、レビューを中止してその旨を伝えてください。 マップなしでは該当する条件セットを導き出せず、そのため網羅性を確認できません。それでもレビューを続けると、最も重要な条件を気づかれないまま無視することになります。
ワークフロー
- 決定論的なゲートがまだ実行されていない場合は実行します。
validate_user_research_prior_art.py keyword-map <file>または... search <file> --keyword-map <map>を実行します。失敗があれば、レビュー前に生成側が修正します。(gated) と記された条件は、この実行によって満たされるため、指摘として再掲しません。バリデーターの結果を重複して報告すると、ノイズに埋もれて判断部分が見えなくなります。 - 判断が必要な条件を順番に確認します。 成果物を各条件に照らして読み、問題を探して流し読みしないでください。
- すべての指摘に根拠を示します。 該当する成果物の文言を引用し、条件番号を明記します。成果物、スキーマ、登録簿、またはマップから根拠を示せないものは、指摘ではなく観察事項です。
- 判定を1行で示し、その後に指摘を記載します。
この成果物のレビューでよくある誤り
- 記録ではなく調査を評価する。 研究の設計が適切かどうかは、この基準の対象ではありません。何を検索し、何が見つかり、何が取得できなかったかを成果物が正直に示しているかどうかが対象です。
- 文献についての自分の知識を根拠として使う。 重要な論文が抜けているように見える場合、指摘すべきなのは、それを網羅範囲に含めていないことです。論文の題名を知っていると主張することではありません。生成側はマップに基づいて検索しているため、指摘はそのマップを根拠とする必要があります。
- 情報が少ないことを失敗とみなす。 製品スコープを直接扱う調査は、ほとんどない場合が大半です。そう決めつける反射的な傾向が強いため、C27 は番号付き条件として設けられています。
- 情報源を再度調べ、自分がアクセスできたことを証拠にする。 ここで使われる情報源の1つは、世界中で共有されるプールを運用しており、スロットリングの状況は刻々と変化します。今アクセスできたとしても、生成側がアクセスできたかどうかはわかりません。
- 指摘を1つずつ報告する。 各ラウンドで修正サイクルが必要になり、あと一歩で正しかった作業も、ループの上限に達します。1回のレビューですべての指摘を出してください。
この種の成果物に固有の2つの条件
これらをここで説明するのは、同じ種類のほかの成果物と異なる点だからです。条件を規範的に言い換えるためではありません。適用される正式な文言は conditions.md にあります。
採用には2つの要件があります(C18、C19)。全文を取得できるだけでは、調査報告のない実務家の主張まで採用されてしまいます。方法が記されているだけでは、要旨から作られた記録も採用されます。その記録は、方法セクションに基づく記録と見分けがつきません。一方だけを確認するレビュー担当者は、成果物の半分を見落とします。
確実性と転用可能性は、第1波で判断する項目ではありません(C26)。どちらも全文を読んで初めて判断でき、採用の可否はその前に決まります。エビデンスを採点する第1波の成果物は、誰にも検証できない、精密に見える値を作り出してしまっています。
出力
判定行は VERDICT: approve または VERDICT: revise のいずれか1行のみとし、その後に、該当する条件番号と、それに違反する成果物のテキストを引用した指摘を記載します。呼び出し元のブリーフに同等の形式が指定されている場合を除き、判定行の後には何も記載しません。その場合は、指定された形式が判定行に置き換わります。両方の形式を出力すると違反になります。固定されているのは形式ではなく、個数です。
関連項目
user-research-prior-art-survey— 作成側にあたります。そのバリデーターが(ゲート付きの)条件を確認します。references/source-registry.yamlは根拠資料の一部です。references/conditions.md— 権威ある基準です。