菜单
新規調査を実行するスキル。テーマを受け取り、既存トピックとの関連を判断した上で、 既存トピックへの追記または新規トピック作成を行い、survey-any リポジトリに記録する。 ghq でリポジトリパスを自動解決するため、どのプロジェクトで作業中でも呼び出せる。 Use when: ユーザーが「〜について調べて」「〜を調査して」「〜をサーベイして」と依頼したとき、 または research / survey / investigate といった調査系のリクエストがあったとき。 既存調査の参照は /ask、論文サーベイは /survey-paper、断片メモの捕獲は /survey-capture を使う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
調査トピックの一覧表示・フィルタリングを行うスキル。 Use when: 「トピック一覧」「何を調べた?」「リスト見せて」「〜タグのトピック」 「完了したトピック」「in-progressのトピック」など、トピックの一覧や検索を求めたとき。
トピック間の関連付け整理とメタデータ整備を行うスキル。 frontmatter の related フィールド更新と INDEX.md 再生成を行う。 Use when: 「整理して」「関連付けて」「organize」「メタデータ更新」「INDEX更新」と依頼されたとき。
survey-any の Astro viewer (viewer/) をローカルでビルドし、Cloudflare Pages 互換のサーバ (wrangler pages dev + D1 + Functions) を起動してブラウザ確認するスキル。 Use when: 「preview」「プレビュー」「viewer 見たい」「ローカルで表示」「ローカルサーバ起動」 「ローカルで確認」「ブラウザで見たい」「8788」「local preview」と依頼されたとき。 本番反映 (Cloudflare Pages へ deploy) は別。preview はローカル確認のみ。
学術論文の再帰的サーベイスキル。survey-any リポジトリに記録する。 6項目サーベイフォーマットで各論文をまとめ、引用・被引用を芋づる式に探索して飽和するまで続ける。 subagent で並列処理しコンテキストを節約する。ghq でリポジトリパスを自動解決。 Use when: 「論文サーベイ」「paper survey」「学術調査」「文献調査」「論文を網羅的に」と依頼されたとき。 /survey との違い: /survey は記事・スライド含む一般調査。本スキルは学術論文に特化し、 6項目サーベイ + 再帰的引用探索 + 飽和判定を行う。
survey-any リポジトリに蓄積された既存調査を検索・参照して質問に回答するスキル。 ghq でリポジトリパスを自動解決し、mise タスク経由でトピックを横断検索、 該当する topics/references をソース付きで回答する。 Bates の berrypicking モデルに沿って、単発検索ではなく複数戦略で動線を提示する。 Use when: ユーザーが既存リサーチの内容について質問したとき、または既存知識を引きたいとき。 「〜について教えて」「〜の内容は?」「〜ってどうだった?」「前に調べた〜」 「〜のトピックある?」「〜のナレッジ検索」「survey-any確認」「調査結果参照」 「〜について何か知ってる?」「リサーチノート検索」など。 新規調査（/survey）や整理（/inbox-organize）とは別。
調査済み内容を土台に学習コース (courses/) を作成するスキル。 テーマを受け取り、既存 topics/references を検索し、AskUserQuestion で学習者の理解度を 診断してから、必要に応じて /survey または /survey-paper で追加情報を収集し、 理解度と学習目標に合わせた順序付きレッスン群を生成する。 ghq で survey-any リポジトリのパスを自動解決するため、どのプロジェクトで作業中でも呼び出せる。 Use when: ユーザーが「〜の学習コース作って」「〜を習得したい」「〜のチュートリアルほしい」 「〜を体系的に学べるコース」「learning course」「カリキュラム作成」と依頼したとき。 既存調査の参照は /ask、新規調査は /survey、論文サーベイは /survey-paper を使う。
基于 SOC 职业分类
| name | survey |
| description | 新規調査を実行するスキル。テーマを受け取り、既存トピックとの関連を判断した上で、 既存トピックへの追記または新規トピック作成を行い、survey-any リポジトリに記録する。 ghq でリポジトリパスを自動解決するため、どのプロジェクトで作業中でも呼び出せる。 Use when: ユーザーが「〜について調べて」「〜を調査して」「〜をサーベイして」と依頼したとき、 または research / survey / investigate といった調査系のリクエストがあったとき。 既存調査の参照は /ask、論文サーベイは /survey-paper、断片メモの捕獲は /survey-capture を使う。 |
| license | MIT |
新規の一般調査を実行し、survey-any に成果物を記録する。
前提: ghq, mise, jq がインストール済みであること。
SURVEY_REPO=$(ghq list --full-path | grep 'survey-any$' | head -1)
以降のコマンドは mise -C "$SURVEY_REPO" または cd "$SURVEY_REPO" 後に実行する。
トピック数が140件超のため fm の全件 dump からいきなり始めない。まず絞り込みで当たりを付ける:
mise -C "$SURVEY_REPO" run search-fulltext "<調査テーマのキーワード>" --top 10 --kind topic
mise -C "$SURVEY_REPO" run fm-tags # テーマに近い統制タグを確認
ヒットが出た範囲でのみ fm を絞り込んで詳細確認する:
mise -C "$SURVEY_REPO" run fm | jq --arg t "<タグ>" '.[] | select(.tags | index($t))'
出力を確認し、依頼テーマと関連するトピックがあるか判断する。 判断材料: tags の重複、タイトルの類似性、テーマの包含関係。
必要に応じて mise -C "$SURVEY_REPO" run fm-related <topic> で特定トピックとの関連度を確認する。
全件 dump (mise run fm 単体) は上記で手がかりが得られなかった場合の最終手段に留める。
| 状況 | 対応 |
|---|---|
| 既存トピックの深掘り・補足 | 既存 README.md に追記 |
| 既存トピックのサブテーマで独立性あり | 既存ディレクトリ内にサブファイル追加 (topics/{parent}/subtopic.md) |
| 関連するが別の問い | 新規トピック作成 + related で相互リンク |
| 既存と無関係 | 新規トピック作成 |
迷う場合は AskUserQuestion でユーザーに確認する。
Step 3 の判断結果に応じて以下を実行する。各分岐で必要な操作はすべてこの表に網羅されている。自前で frontmatter スキーマを設計しないこと。
| Step 3 の選択 | 手順 |
|---|---|
| 既存トピックの深掘り・補足 | topics/<existing>/README.md を直接編集。frontmatter の updated: を当日 (UTC) に更新。本文末尾または該当セクションに追記。新規 reference を追加した場合は sources: も更新 |
| 既存トピックのサブテーマで独立性あり | topics/<existing>/<subtopic-slug>.md を新規作成 (mise タスクなし、エディタで直接作成)。frontmatter は最低限 title, parent: <existing-topic>, status, tags, created, updated を入れる。親 README に「サブトピック」セクションを設けて相対リンクを追加し、親の updated: も更新 |
| 関連するが別の問い | mise -C "$SURVEY_REPO" run new <kind> <topic-name> で新規作成。新旧両方の README の related: で相互リンク (双方向) |
| 既存と無関係 | mise -C "$SURVEY_REPO" run new <kind> <topic-name> で新規作成 |
<kind> の選択基準 (mise run new <kind> <name> の <kind> 部分):
| kind | 用途 | 目安 (半開区間で重複なく定義) |
|---|---|---|
| memo | 走り書き〜短文。短く完結する技術調査 | セクション数 < 4 かつ reference < 3 |
| report | 構造的なレポート。複数ソース統合 | セクション数 ≥ 4 または reference ≥ 3 |
| notebook | データ可視化・コード実行記録 | 数値計算・グラフ・統計処理がある場合のみ (.ipynb) |
実在する mise タスクは mise run new <kind> <name> の 1 つのみ。new-report new-notebook new-reference などの flat タスクは存在しない。<kind> の指定は必須 (省略不可)。
WebSearch / WebFetch で情報収集する。調査手法は場当たりにせず、以下の方法論に沿う（根拠は topics/systematic-inquiry-pkb-application）。survey-paper の体系性（引用グラフ探索・飽和判定）に対応する backbone を一般 web 調査にも効かせる。
検索戦略（単一の曖昧クエリを投げない）:
停止判定（回数でなく飽和で止める）:
裏取り（triangulation）:
統合（要約の寄せ集めにしない）:
読解のトリアージ:
外部 IO 失敗時の失敗ラダー (上から順に試行し、ヒットしたら以降はスキップ):
https://r.jina.ai/<URL> で再取得 — SPA や JS rendering 必須サイト、軽度の bot 検出を回避できる場合がある (Jina Reader が headless ブラウザでレンダリング後 Markdown 化)https://web.archive.org/web/2*/<URL> — 元サイト消滅・地域制限・本格的な bot wall に対する最後の手段(未確認) と注記し、reference には登録しない各段の使い分け診断 (本格的にラダーを駆け降りる前に判断するためのヒント):
| 失敗種別 | 推奨ステップ |
|---|---|
| 429 (rate limit) | 1 → 2 (Jina の cache hit に賭ける) |
| 403 (Cloudflare bot wall) | 2 → 3 (Jina で UA 偽装 → Archive) |
| 動的 SPA (空 HTML) | 2 (Jina Reader が JS 実行) |
| 404 / リンク切れ | 3 (Archive のスナップショット) |
| auth wall | 4 (代替不能) |
探索回数は固定でなく 5-0 の飽和判定で決める。WebSearch 3 回 + WebFetch 5 回程度は暴走防止の上限の目安であって到達目標ではない。飽和が先に来たら早く止め、新概念が出続けるなら（重要テーマなら）上限まで粘る (ラダーの段は WebFetch 回数にカウント)。
r.jina.ai 経由で取得した内容を references に記録する場合、frontmatter の retrieved の隣 (またはノート行) に via: r.jina.ai を明記する (Jina 側のキャッシュ起源・rendering 副作用を識別するため)。
調査で発見した図表（アーキテクチャ図・結果グラフ・比較表の画像・スクリーンショット等）は、テキスト説明で済ませず画像として同梱する。二重符号化（R8）で理解と保持が上がり、後で読み返す自分・エージェント・他者に効く。自作の ASCII/mermaid 図とは別枠で、一次資料の図をそのまま引用する。
手順:
curl -sL <img-url> -o <path>）。図の URL は WebFetch/Jina で得た HTML の <img src> や、記事・スライドの画像リンクから拾うtopics/<topic>/assets/<file> または references/assets/<ref-name>/<file>（scratchpad や外部 URL 直貼りは消える・切れる・最適化されないので不可。viewer は同梱画像を webp 自動最適化する）。直後にキャプションで出典を必ず明記（*図: <何の図か>（出典: [<タイトル>](<URL>) Fig.N）*）droid-scene-diversity-vs-success.png 等）WebSearch で「<テーマ> figure / architecture / benchmark results」を検索すると図に辿り着きやすい。
| 内容 | 書き出し先 |
|---|---|
| 外部資料（記事・スライド・論文）の客観的な内容記録 | references/{name}.md |
| 自分の考察・複数情報の統合・所感 | topics/{topic}/README.md |
外部資料が見つかった場合:
mise -C "$SURVEY_REPO" run new reference <name> で references/ にファイルを作成strength: を必須で付ける（R3。エビデンス強度の統制語彙。強い順:
meta-analysis / replicated / peer-reviewed / preprint / single-author-preprint / official-docs / blog / anecdote）。
判定に迷う場合は著者数・査読有無・一次情報かで判断するsources: フィールドに reference 名を追加topics/README.md への記述:
title, status, tags を記入related に記入maturity: を付ける（R5。SOLO 分類。collected(事実を集めた) → connected(並べて比較した) →
integrated(矛盾を解消し統合した) → generalized(他領域へ一般化した)。status とは直交する軸で、
「調べただけ」か「統合まで到達したか」を区別する）recall: に核心を問う自問を 2-3 問置く（R4。検索練習効果。答えは本文中にある状態にする。
例:「FAKTUAL と Geometric Entropy の結論はなぜ両立するか?」）related（無型）に加えて relations: で型付きリンクにする（R2）。
「なぜ関連か」を一言で言えない相手には付けない
relations:
- to: <topic-slug>
type: contrasts # extends | contrasts | refutes | applies | analogous | prereq
note: 結論が対立して見えるが文脈が異なる
sources: で参照し、本文での重複記載を避けるstrength: を一言添える（単一ソースなら「単一ソース」と明示し弱める。例:「〜（単著プレプリント、示唆レベル）」）本文冒頭は以下の 3 層構造に固定する。読者は最初に全体像を掴んでから詳細に降りる方が定着する:
mise -C "$SURVEY_REPO" run index
mise -C "$SURVEY_REPO" run doctor タスクが存在する場合は続けて実行し、ERROR が出たら（sources 参照切れ・
related の片方向・strength/maturity 欠落など）その場で修正してから次に進む（存在しない場合はスキップ可）。
berrypicking trace を 1 行記録する (新規調査の発端を残すため):
mise -C "$SURVEY_REPO" run trace \\
--query "<ユーザーが投げた調査テーマ>" \\
--hits "<検索で参照した既存トピック群 (comma)>" \\
--picked "<新規作成 or 追記したトピック>" \\
--strategy subject
引数の意味と空値の扱い:
--hits: Step 2 の mise run fm 出力の中で、テーマと意味的に近接していると判断した既存トピックを comma 区切りで列挙する。完全新規テーマで該当ゼロなら --hits "" (空文字) で OK--picked: 今回新規作成または追記した topic 名 1 つ (サブファイル追加の場合は親 topic 名)--strategy: Bates の 6 berrypicking 戦略のいずれか。ユーザー依頼が「テーマ X について調べて」なら通常 subject、「この論文の引用を辿って」なら footnote、「この著者の他の仕事」なら author 等memory/seeking-trace.jsonl への 1 行追記。.gitignore 対象 (個人ローカル)。
将来の retrieval reward / 自動 related 候補生成のシードになる。
ユーザーに以下を伝える:
$SURVEY_REPO/topics/...）git commit は行わない（ユーザーが必要に応じて実施）。