Menú
Web調査の方法論。一次ソース(RFC・公式仕様・公式ドキュメント・原論文・ソースコード)を最優先し、検索クエリの多角化・横断的検証(lateral reading)・独立ソースでの三角測量を経て、出典付きで報告する手順。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Rust ベストプラクティス(Plecto WASM フィルタ向け、Edition 2024)。plecto:filter WIT コントラクトを実装する WASM Component Model フィルタの規約とツールチェーン。
Grilling session that challenges your plan against moka-1's documented design decisions (tenets, ADRs) and domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when the user wants to stress-test a plan against the project's language and documented decisions, or says 「設計を詰めて」「用語を固めて」「ドキュメントと突き合わせて」.
クリーンアーキテクチャの依存ルールを moka-1 のミニマリズム制約下で適用する指針。レイヤ分割・interface 設計・依存方向の判断基準と、過剰抽象化を避けるガードレールを提供する。
moka-1 スタックの Docker Compose 操作と compose.yaml の書き方。ワンキック起動・開発ループ・ヘルスチェック・開発機(iGPU/Vulkan)固有設定・トラブルシュート。
Go ベストプラクティス(moka-core 向け、Go 1.26+)。常駐エージェントループ・LLM クライアント・フィード取得を含む moka-core の実装規約。
Python ベストプラクティス(eval/ 専用、Python 3.14 + uv + Pyrefly + Ruff)。モデル A/B・プロンプト評価スクリプトの規約と再現性の作法。
調査の品質は「何件読んだか」ではなく「どれだけ原典に近いソースで裏を取ったか」で決まる。
主張の根拠は必ず以下の階層の上位で確定させる。下位ソースは「発見の入口」であって「根拠」にしない:
| 優先度 | ソース | 例 |
|---|---|---|
| 1 | 標準・仕様の原文 | RFC (rfc-editor.org / datatracker.ietf.org)、W3C/WHATWG 仕様、ISO、ECMA |
| 2 | 公式ドキュメント・公式発表 | 言語/ライブラリの公式 docs、ベンダーの release notes、CVE/GHSA 原文 |
| 3 | ソースコードと changelog | GitHub の該当リポジトリ、コミット、Issue/PR での メンテナ発言 |
| 4 | 研究論文・一次データ | arXiv/学会原文、公式ベンチマーク、著者公式実装 |
| 5 | 解説記事・技術ブログ | 入口としては有用。根拠として引用しない |
運用ルール:
/en/latest/ より /en/v2.3/)。調べている対象のバージョンと一致させるv1 と v3 で数値や結論が変わることがある。引用時は参照したバージョンを明記する調査チェックリスト:
- [ ] 1. 問いを分解し、検索クエリを 2〜3 角度で発行
- [ ] 2. 結果から一次ソース候補を選び WebFetch で本文確認
- [ ] 3. 重要な主張は独立した 2 ソース以上で三角測量
- [ ] 4. 鮮度と適用条件(バージョン・日付)を確認
- [ ] 5. 出典付きで報告(確度の区別を明示)
1. クエリの多角化: 同じ問いを言い換えて 2〜3 本並行検索する(用語系: "RFC 9111" cache-control、実装系: <library> <symbol> changelog、問題系: <error message>)。1 本目の結果で語彙を学び、2 本目を精密化する。site 指定(site:datatracker.ietf.org)や allowed_domains で一次ソースに直接絞るのも有効。
2. 横断的検証(lateral reading): 知らないサイトに当たったら、そのサイトを読み込む前に「このソースは何者か」を別タブ(別検索)で確認する。サイトの自己紹介ではなく第三者の評価で判断する。
3. 三角測量: 実装判断を左右する主張(「X は deprecated」「Y の上限は N」)は、互いに引用し合っていない独立した 2 ソース以上で確認する。同一プレスリリースの転載 10 件は 1 ソースと数える。
4. 鮮度の確認: 現在の日付を意識する(環境コンテキストにある)。LLM・ライブラリ・API の情報は特に陳腐化が速い。記事の公開日と対象バージョンを必ず見る。日付のない記事の技術主張は確度を下げる。
5. 報告: 本文中の主要な主張に出典を紐付け、末尾に Sources として markdown リンク一覧を付ける。以下を区別して書く:
<claim> problems / <claim> criticism)