mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-18 23:03:06 +08:00
d66b5fa480
Add files present in zh-CN but missing from ja-JP: - commands: claw, context-budget, devfleet, docs, projects, prompt-optimize, rules-distill (7 files) - skills: regex-vs-llm-structured-text, remotion-video-creation, repo-scan, research-ops, returns-reverse-logistics, rules-distill, rust-patterns, rust-testing, skill-comply, skill-stocktake, social-graph-ranker, swift-actor-persistence, swift-concurrency-6-2, swift-protocol-di-testing, swiftui-patterns, team-builder, terminal-ops, token-budget-advisor, ui-demo, unified-notifications-ops, video-editing, videodb (+reference/*), visa-doc-translate, workspace-surface-audit, x-api (37 files) Result: ja-JP now has 517 files vs zh-CN 412 files. zh-CN parity: 0 missing files (complete parity achieved).
113 lines
4.6 KiB
Markdown
113 lines
4.6 KiB
Markdown
---
|
||
name: research-ops
|
||
description: 証拠優先のECC現状調査ワークフロー。ユーザーが現在の公開証拠と提供されたローカルコンテキストに基づいて最新の事実、比較、情報の充実、または推奨事項を求める場合に使用する。
|
||
origin: ECC
|
||
---
|
||
|
||
# リサーチオペレーション
|
||
|
||
ユーザーが現在の情報の調査、オプションの比較、人物や企業情報の充実、または繰り返しのクエリをモニタリング可能なワークフローに変換することを求める場合に使用する。
|
||
|
||
これはリポジトリのリサーチスタックの操作ラッパーである。`deep-research`、`exa-search`、`market-research` の代替品ではなく、それらをいつどのように組み合わせて使うかを指示するものである。
|
||
|
||
## スキルスタック
|
||
|
||
関連する場面では、これらのECCネイティブスキルをワークフローに組み込む：
|
||
|
||
* `exa-search`：現在のウェブ情報の素早い発見に使用
|
||
* `deep-research`：引用付きの複数ソース統合に使用
|
||
* `market-research`：最終結果が推奨または優先順位付け決定である場合に使用
|
||
* `lead-intelligence`：タスクが一般的な調査ではなく人物/企業を対象とする場合に使用
|
||
* `knowledge-ops`：結果を後続のコンテキスト用に永続的に保存する必要がある場合に使用
|
||
|
||
## 使用場面
|
||
|
||
* ユーザーが「調査」「調べる」「比較」「誰に連絡すべきか」「最新情報」に言及する場合
|
||
* 答えが現在の公開情報に依存する場合
|
||
* ユーザーが証拠を提供し、それを新しい推奨事項に組み込んでほしい場合
|
||
* タスクが繰り返し発生する可能性があり、一回限りのクエリではなくモニタリングに転換すべき場合
|
||
|
||
## 安全策
|
||
|
||
* 新鮮な検索が安価な場合、古い記憶に頼って現在の問いに答えない
|
||
* 以下を区別する：
|
||
* 出典付きの事実
|
||
* ユーザーが提供した証拠
|
||
* 推論
|
||
* 推奨事項
|
||
* 答えがローカルコードまたはドキュメントにすでに存在する場合、重い調査プロセスを起動しない
|
||
|
||
## ワークフロー
|
||
|
||
### 1. ユーザーがすでに提供した情報から始める
|
||
|
||
提供された素材を以下に正規化する：
|
||
|
||
* すでに証拠がある事実
|
||
* 検証が必要な内容
|
||
* 未解決の問い
|
||
|
||
ユーザーがすでに部分的なモデルを構築している場合、ゼロから再分析しない。
|
||
|
||
### 2. リクエストを分類する
|
||
|
||
検索前に正しいパスを選択する：
|
||
|
||
* 素早い事実的回答
|
||
* 比較または意思決定メモ
|
||
* リード/情報充実処理
|
||
* 繰り返しモニタリング候補
|
||
|
||
### 3. 最も軽量な有効な証拠パスを優先する
|
||
|
||
* `exa-search` を使って素早い発見を行う
|
||
* 統合または複数ソース情報が必要な場合、`deep-research` にアップグレードする
|
||
* 結果を推奨形式で提示する必要がある場合、`market-research` を使用する
|
||
* 実際のニーズがターゲット優先順位付けやウォームパス発見の場合、`lead-intelligence` に転送する
|
||
|
||
### 4. 証拠の境界を明示してレポートする
|
||
|
||
重要な主張については、それが以下のどれであるかを述べる：
|
||
|
||
* 出典付きの事実
|
||
* ユーザーが提供したコンテキスト
|
||
* 推論
|
||
* 推奨事項
|
||
|
||
時効性の高い回答には具体的な日付を含める。
|
||
|
||
### 5. タスクを手動のままにすべきか決定する
|
||
|
||
ユーザーが同じ調査の問いを繰り返す可能性がある場合、それを明示し、永遠に同じ手動検索を繰り返すのではなく、モニタリングまたはワークフローレイヤーの採用を提案する。
|
||
|
||
## 出力フォーマット
|
||
|
||
```text
|
||
問いのタイプ
|
||
- 事実的 / 比較的 / 補完的 / モニタリング的
|
||
|
||
証拠
|
||
- 出典付きの事実
|
||
- ユーザーが提供したコンテキスト
|
||
|
||
推論
|
||
- 証拠から導かれた結論
|
||
|
||
推奨事項
|
||
- 答えまたは次のアクション
|
||
- モニタリング項目にすべきか否か
|
||
```
|
||
|
||
## よくある落とし穴
|
||
|
||
* 出典付きの事実と推論を、ラベルなしで混在させない
|
||
* ユーザーが提供した証拠を無視しない
|
||
* ローカルリポジトリのコンテキストで答えられる問いに重い調査パスを使わない
|
||
* 日付のない時効性の高い答えを返さない
|
||
|
||
## 検証
|
||
|
||
* 重要な主張には証拠タイプのラベルを付ける
|
||
* 時効性の高い出力には日付を含める
|
||
* 最終的な推奨事項は実際に使用した調査モードと一致させる
|