القائمة
Web調査の方法論。一次ソース(RFC・公式仕様・公式ドキュメント・原論文・ソースコード)を最優先し、検索クエリの多角化・横断的検証(lateral reading)・独立ソースでの三角測量を経て、出典付きで報告する手順。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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・プロンプト評価スクリプトの規約と再現性の作法。
| name | web-research |
| description | Web調査の方法論。一次ソース(RFC・公式仕様・公式ドキュメント・原論文・ソースコード)を最優先し、検索クエリの多角化・横断的検証(lateral reading)・独立ソースでの三角測量を経て、出典付きで報告する手順。 |
調査の品質は「何件読んだか」ではなく「どれだけ原典に近いソースで裏を取ったか」で決まる。
主張の根拠は必ず以下の階層の上位で確定させる。下位ソースは「発見の入口」であって「根拠」にしない:
| 優先度 | ソース | 例 |
|---|---|---|
| 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)