|
|
|
@@ -11,6 +11,8 @@ description: |
|
|
|
|
|
- "research this", "investigate", "look into"
|
|
|
|
|
- "assess solution", "review solution draft"
|
|
|
|
|
- "comparative analysis", "concept comparison", "technical comparison"
|
|
|
|
|
category: build
|
|
|
|
|
tags: [research, analysis, solution-design, comparison, decision-support]
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Deep Research (8-Step Method)
|
|
|
|
@@ -37,14 +39,13 @@ Determine the operating mode based on invocation before any other logic runs.
|
|
|
|
|
|
|
|
|
|
**Standalone mode** (explicit input file provided, e.g. `/research @some_doc.md`):
|
|
|
|
|
- INPUT_FILE: the provided file (treated as problem description)
|
|
|
|
|
- Derive `<topic>` from the input filename (without extension)
|
|
|
|
|
- OUTPUT_DIR: `_standalone/<topic>/01_solution/`
|
|
|
|
|
- RESEARCH_DIR: `_standalone/<topic>/00_research/`
|
|
|
|
|
- OUTPUT_DIR: `_standalone/01_solution/`
|
|
|
|
|
- RESEARCH_DIR: `_standalone/00_research/`
|
|
|
|
|
- Guardrails relaxed: only INPUT_FILE must exist and be non-empty
|
|
|
|
|
- `restrictions.md` and `acceptance_criteria.md` are optional — warn if absent, proceed if user confirms
|
|
|
|
|
- Mode detection uses OUTPUT_DIR for `solution_draft*.md` scanning
|
|
|
|
|
- Draft numbering works the same, scoped to OUTPUT_DIR
|
|
|
|
|
- **Final step**: after all research is complete, move INPUT_FILE into `_standalone/<topic>/`
|
|
|
|
|
- **Final step**: after all research is complete, move INPUT_FILE into `_standalone/`
|
|
|
|
|
|
|
|
|
|
Announce the detected mode and resolved paths to the user before proceeding.
|
|
|
|
|
|
|
|
|
@@ -57,11 +58,11 @@ Before any research begins, verify the input context exists. **Do not proceed if
|
|
|
|
|
**Project mode:**
|
|
|
|
|
1. Check INPUT_DIR exists — **STOP if missing**, ask user to create it and provide problem files
|
|
|
|
|
2. Check `problem.md` in INPUT_DIR exists and is non-empty — **STOP if missing**
|
|
|
|
|
3. Check for `restrictions.md` and `acceptance_criteria.md` in INPUT_DIR:
|
|
|
|
|
- If missing: **warn user** and ask whether to proceed without them or provide them first
|
|
|
|
|
- If present: read and validate they are non-empty
|
|
|
|
|
4. Read **all** files in INPUT_DIR to ground the investigation in the project context
|
|
|
|
|
5. Create OUTPUT_DIR and RESEARCH_DIR if they don't exist
|
|
|
|
|
3. Check `restrictions.md` in INPUT_DIR exists and is non-empty — **STOP if missing**
|
|
|
|
|
4. Check `acceptance_criteria.md` in INPUT_DIR exists and is non-empty — **STOP if missing**
|
|
|
|
|
5. Check `input_data/` in INPUT_DIR exists and contains at least one file — **STOP if missing**
|
|
|
|
|
6. Read **all** files in INPUT_DIR to ground the investigation in the project context
|
|
|
|
|
7. Create OUTPUT_DIR and RESEARCH_DIR if they don't exist
|
|
|
|
|
|
|
|
|
|
**Standalone mode:**
|
|
|
|
|
1. Check INPUT_FILE exists and is non-empty — **STOP if missing**
|
|
|
|
@@ -94,10 +95,10 @@ Example: if `solution_draft01.md` through `solution_draft10.md` exist, the next
|
|
|
|
|
|
|
|
|
|
#### Directory Structure
|
|
|
|
|
|
|
|
|
|
At the start of research, **must** create a topic-named working directory under RESEARCH_DIR:
|
|
|
|
|
At the start of research, **must** create a working directory under RESEARCH_DIR:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
RESEARCH_DIR/<topic>/
|
|
|
|
|
RESEARCH_DIR/
|
|
|
|
|
├── 00_ac_assessment.md # Mode A Phase 1 output: AC & restrictions assessment
|
|
|
|
|
├── 00_question_decomposition.md # Step 0-1 output
|
|
|
|
|
├── 01_source_registry.md # Step 2 output: all consulted source links
|
|
|
|
@@ -166,7 +167,7 @@ A focused preliminary research pass **before** the main solution research. The g
|
|
|
|
|
|
|
|
|
|
**Uses Steps 0-3 of the 8-step engine** (question classification, decomposition, source tiering, fact extraction) scoped to AC and restrictions assessment.
|
|
|
|
|
|
|
|
|
|
**📁 Save action**: Write `RESEARCH_DIR/<topic>/00_ac_assessment.md` with format:
|
|
|
|
|
**📁 Save action**: Write `RESEARCH_DIR/00_ac_assessment.md` with format:
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
# Acceptance Criteria Assessment
|
|
|
|
@@ -340,83 +341,11 @@ First, classify the research question type and select the corresponding strategy
|
|
|
|
|
|
|
|
|
|
### Step 0.5: Novelty Sensitivity Assessment (BLOCKING)
|
|
|
|
|
|
|
|
|
|
**Before starting research, you must assess the novelty sensitivity of the question. This determines the source filtering strategy.**
|
|
|
|
|
Before starting research, assess the novelty sensitivity of the question (Critical/High/Medium/Low). This determines source time windows and filtering strategy.
|
|
|
|
|
|
|
|
|
|
#### Novelty Sensitivity Classification
|
|
|
|
|
**For full classification table, critical-domain rules, trigger words, and assessment template**: Read `references/novelty-sensitivity.md`
|
|
|
|
|
|
|
|
|
|
| Sensitivity Level | Typical Domains | Source Time Window | Description |
|
|
|
|
|
|-------------------|-----------------|-------------------|-------------|
|
|
|
|
|
| **🔴 Critical** | AI/LLMs, blockchain, cryptocurrency | 3-6 months | Technology iterates extremely fast; info from months ago may be completely outdated |
|
|
|
|
|
| **🟠 High** | Cloud services, frontend frameworks, API interfaces | 6-12 months | Frequent version updates; must confirm current version |
|
|
|
|
|
| **🟡 Medium** | Programming languages, databases, operating systems | 1-2 years | Relatively stable but still evolving |
|
|
|
|
|
| **🟢 Low** | Algorithm fundamentals, design patterns, theoretical concepts | No limit | Core principles change slowly |
|
|
|
|
|
|
|
|
|
|
#### 🔴 Critical Sensitivity Domain Special Rules
|
|
|
|
|
|
|
|
|
|
When the research topic involves the following domains, **special rules must be enforced**:
|
|
|
|
|
|
|
|
|
|
**Trigger word identification**:
|
|
|
|
|
- AI-related: LLM, GPT, Claude, Gemini, AI Agent, RAG, vector database, prompt engineering
|
|
|
|
|
- Cloud-native: Kubernetes new versions, Serverless, container runtimes
|
|
|
|
|
- Cutting-edge tech: Web3, quantum computing, AR/VR
|
|
|
|
|
|
|
|
|
|
**Mandatory rules**:
|
|
|
|
|
|
|
|
|
|
1. **Search with time constraints**:
|
|
|
|
|
- Use `time_range: "month"` or `time_range: "week"` to limit search results
|
|
|
|
|
- Prefer `start_date: "YYYY-MM-DD"` set to within the last 3 months
|
|
|
|
|
|
|
|
|
|
2. **Elevate official source priority**:
|
|
|
|
|
- **Must first consult** official documentation, official blogs, official Changelogs
|
|
|
|
|
- GitHub Release Notes, official X/Twitter announcements
|
|
|
|
|
- Academic papers (arXiv and other preprint platforms)
|
|
|
|
|
|
|
|
|
|
3. **Mandatory version number annotation**:
|
|
|
|
|
- Any technical description must annotate the **current version number**
|
|
|
|
|
- Example: "Claude 3.5 Sonnet (claude-3-5-sonnet-20241022) supports..."
|
|
|
|
|
- Prohibit vague statements like "the latest version supports..."
|
|
|
|
|
|
|
|
|
|
4. **Outdated information handling**:
|
|
|
|
|
- Technical blogs/tutorials older than 6 months → historical reference only, **cannot serve as factual evidence**
|
|
|
|
|
- Version inconsistency found → must **verify current version** before using
|
|
|
|
|
- Obviously outdated descriptions (e.g., "will support in the future" but now already supported) → **discard directly**
|
|
|
|
|
|
|
|
|
|
5. **Cross-validation**:
|
|
|
|
|
- Highly sensitive information must be confirmed from **at least 2 independent sources**
|
|
|
|
|
- Priority: Official docs > Official blogs > Authoritative tech media > Personal blogs
|
|
|
|
|
|
|
|
|
|
6. **Official download/release page direct verification (BLOCKING)**:
|
|
|
|
|
- **Must directly visit** official download pages to verify platform support (don't rely on search engine caches)
|
|
|
|
|
- Use `mcp__tavily-mcp__tavily-extract` or `WebFetch` to directly extract download page content
|
|
|
|
|
- Example: `https://product.com/download` or `https://github.com/xxx/releases`
|
|
|
|
|
- Search results about "coming soon" or "planned support" may be outdated; must verify in real time
|
|
|
|
|
- **Platform support is frequently changing information**; cannot infer from old sources
|
|
|
|
|
|
|
|
|
|
7. **Product-specific protocol/feature name search (BLOCKING)**:
|
|
|
|
|
- Beyond searching the product name, **must additionally search protocol/standard names the product supports**
|
|
|
|
|
- Common protocols/standards to search:
|
|
|
|
|
- AI tools: MCP, ACP (Agent Client Protocol), LSP, DAP
|
|
|
|
|
- Cloud services: OAuth, OIDC, SAML
|
|
|
|
|
- Data exchange: GraphQL, gRPC, REST
|
|
|
|
|
- Search format: `"<product_name> <protocol_name> support"` or `"<product_name> <protocol_name> integration"`
|
|
|
|
|
- These protocol integrations are often differentiating features, easily missed in main docs but documented in specialized pages
|
|
|
|
|
|
|
|
|
|
#### Timeliness Assessment Output Template
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
## Timeliness Sensitivity Assessment
|
|
|
|
|
|
|
|
|
|
- **Research Topic**: [topic]
|
|
|
|
|
- **Sensitivity Level**: 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low
|
|
|
|
|
- **Rationale**: [why this level]
|
|
|
|
|
- **Source Time Window**: [X months/years]
|
|
|
|
|
- **Priority official sources to consult**:
|
|
|
|
|
1. [Official source 1]
|
|
|
|
|
2. [Official source 2]
|
|
|
|
|
- **Key version information to verify**:
|
|
|
|
|
- [Product/technology 1]: Current version ____
|
|
|
|
|
- [Product/technology 2]: Current version ____
|
|
|
|
|
```
|
|
|
|
|
Key principle: Critical-sensitivity topics (AI/LLMs, blockchain) require sources within 6 months, mandatory version annotations, cross-validation from 2+ sources, and direct verification of official download pages.
|
|
|
|
|
|
|
|
|
|
**📁 Save action**: Append timeliness assessment to the end of `00_question_decomposition.md`
|
|
|
|
|
|
|
|
|
@@ -460,7 +389,7 @@ When decomposing questions, you must explicitly define the **boundaries of the r
|
|
|
|
|
|
|
|
|
|
**📁 Save action**:
|
|
|
|
|
1. Read all files from INPUT_DIR to ground the research in the project context
|
|
|
|
|
2. Create working directory `RESEARCH_DIR/<topic>/`
|
|
|
|
|
2. Create working directory `RESEARCH_DIR/`
|
|
|
|
|
3. Write `00_question_decomposition.md`, including:
|
|
|
|
|
- Original question
|
|
|
|
|
- Active mode (A Phase 2 or B) and rationale
|
|
|
|
@@ -472,136 +401,18 @@ When decomposing questions, you must explicitly define the **boundaries of the r
|
|
|
|
|
|
|
|
|
|
### Step 2: Source Tiering & Authority Anchoring
|
|
|
|
|
|
|
|
|
|
Tier sources by authority, **prioritize primary sources**:
|
|
|
|
|
Tier sources by authority, **prioritize primary sources** (L1 > L2 > L3 > L4). Conclusions must be traceable to L1/L2; L3/L4 serve as supplementary and validation.
|
|
|
|
|
|
|
|
|
|
| Tier | Source Type | Purpose | Credibility |
|
|
|
|
|
|------|------------|---------|-------------|
|
|
|
|
|
| **L1** | Official docs, papers, specs, RFCs | Definitions, mechanisms, verifiable facts | ✅ High |
|
|
|
|
|
| **L2** | Official blogs, tech talks, white papers | Design intent, architectural thinking | ✅ High |
|
|
|
|
|
| **L3** | Authoritative media, expert commentary, tutorials | Supplementary intuition, case studies | ⚠️ Medium |
|
|
|
|
|
| **L4** | Community discussions, personal blogs, forums | Discover blind spots, validate understanding | ❓ Low |
|
|
|
|
|
|
|
|
|
|
**L4 Community Source Specifics** (mandatory for product comparison research):
|
|
|
|
|
|
|
|
|
|
| Source Type | Access Method | Value |
|
|
|
|
|
|------------|---------------|-------|
|
|
|
|
|
| **GitHub Issues** | Visit `github.com/<org>/<repo>/issues` | Real user pain points, feature requests, bug reports |
|
|
|
|
|
| **GitHub Discussions** | Visit `github.com/<org>/<repo>/discussions` | Feature discussions, usage insights, community consensus |
|
|
|
|
|
| **Reddit** | Search `site:reddit.com "<product_name>"` | Authentic user reviews, comparison discussions |
|
|
|
|
|
| **Hacker News** | Search `site:news.ycombinator.com "<product_name>"` | In-depth technical community discussions |
|
|
|
|
|
| **Discord/Telegram** | Product's official community channels | Active user feedback (must annotate [limited source]) |
|
|
|
|
|
|
|
|
|
|
**Principles**:
|
|
|
|
|
- Conclusions must be traceable to L1/L2
|
|
|
|
|
- L3/L4 serve only as supplementary and validation
|
|
|
|
|
- **L4 community discussions are used to discover "what users truly care about"**
|
|
|
|
|
- Record all information sources
|
|
|
|
|
|
|
|
|
|
**⏰ Timeliness Filtering Rules (execute based on Step 0.5 sensitivity level)**:
|
|
|
|
|
|
|
|
|
|
| Sensitivity Level | Source Filtering Rule | Suggested Search Parameters |
|
|
|
|
|
|-------------------|----------------------|-----------------------------|
|
|
|
|
|
| 🔴 Critical | Only accept sources within 6 months as factual evidence | `time_range: "month"` or `start_date` set to last 3 months |
|
|
|
|
|
| 🟠 High | Prefer sources within 1 year; annotate if older than 1 year | `time_range: "year"` |
|
|
|
|
|
| 🟡 Medium | Sources within 2 years used normally; older ones need validity check | Default search |
|
|
|
|
|
| 🟢 Low | No time limit | Default search |
|
|
|
|
|
|
|
|
|
|
**High-Sensitivity Domain Search Strategy**:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
1. Round 1: Targeted official source search
|
|
|
|
|
- Use include_domains to restrict to official domains
|
|
|
|
|
- Example: include_domains: ["anthropic.com", "openai.com", "docs.xxx.com"]
|
|
|
|
|
|
|
|
|
|
2. Round 2: Official download/release page direct verification (BLOCKING)
|
|
|
|
|
- Directly visit official download pages; don't rely on search caches
|
|
|
|
|
- Use tavily-extract or WebFetch to extract page content
|
|
|
|
|
- Verify: platform support, current version number, release date
|
|
|
|
|
- This step is mandatory; search engines may cache outdated "Coming soon" info
|
|
|
|
|
|
|
|
|
|
3. Round 3: Product-specific protocol/feature search (BLOCKING)
|
|
|
|
|
- Search protocol names the product supports (MCP, ACP, LSP, etc.)
|
|
|
|
|
- Format: `"<product_name> <protocol_name>" site:official_domain`
|
|
|
|
|
- These integration features are often not displayed on the main page but documented in specialized pages
|
|
|
|
|
|
|
|
|
|
4. Round 4: Time-limited broad search
|
|
|
|
|
- time_range: "month" or start_date set to recent
|
|
|
|
|
- Exclude obviously outdated sources
|
|
|
|
|
|
|
|
|
|
5. Round 5: Version verification
|
|
|
|
|
- Cross-validate version numbers from search results
|
|
|
|
|
- If inconsistency found, immediately consult official Changelog
|
|
|
|
|
|
|
|
|
|
6. Round 6: Community voice mining (BLOCKING - mandatory for product comparison research)
|
|
|
|
|
- Visit the product's GitHub Issues page, review popular/pinned issues
|
|
|
|
|
- Search Issues for key feature terms (e.g., "MCP", "plugin", "integration")
|
|
|
|
|
- Review discussion trends from the last 3-6 months
|
|
|
|
|
- Identify the feature points and differentiating characteristics users care most about
|
|
|
|
|
- Value of this step: Official docs rarely emphasize "features we have that others don't", but community discussions do
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
**Community Voice Mining Detailed Steps**:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
GitHub Issues Mining Steps:
|
|
|
|
|
1. Visit github.com/<org>/<repo>/issues
|
|
|
|
|
2. Sort by "Most commented" to view popular discussions
|
|
|
|
|
3. Search keywords:
|
|
|
|
|
- Feature-related: feature request, enhancement, MCP, plugin, API
|
|
|
|
|
- Comparison-related: vs, compared to, alternative, migrate from
|
|
|
|
|
4. Review issue labels: enhancement, feature, discussion
|
|
|
|
|
5. Record frequently occurring feature demands and user pain points
|
|
|
|
|
|
|
|
|
|
Value Translation:
|
|
|
|
|
- Frequently discussed features → likely differentiating highlights
|
|
|
|
|
- User complaints/requests → likely product weaknesses
|
|
|
|
|
- Comparison discussions → directly obtain user-perspective difference analysis
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
**Source Timeliness Annotation Template** (append to source registry):
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
- **Publication Date**: [YYYY-MM-DD]
|
|
|
|
|
- **Timeliness Status**: ✅ Currently valid / ⚠️ Needs verification / ❌ Outdated
|
|
|
|
|
- **Version Info**: [If applicable, annotate the relevant version number]
|
|
|
|
|
```
|
|
|
|
|
**For full tier definitions, search strategies, community mining steps, and source registry templates**: Read `references/source-tiering.md`
|
|
|
|
|
|
|
|
|
|
**Tool Usage**:
|
|
|
|
|
- Prefer `mcp__plugin_context7_context7__query-docs` for technical documentation
|
|
|
|
|
- Use `WebSearch` or `mcp__tavily-mcp__tavily-search` for broad searches
|
|
|
|
|
- Use `mcp__tavily-mcp__tavily-extract` to extract specific page content
|
|
|
|
|
|
|
|
|
|
**⚠️ Target Audience Verification (BLOCKING - must check before inclusion)**:
|
|
|
|
|
|
|
|
|
|
Before including each source, verify that its **target audience matches the research boundary**:
|
|
|
|
|
|
|
|
|
|
| Source Type | Target audience to verify | Verification method |
|
|
|
|
|
|------------|---------------------------|---------------------|
|
|
|
|
|
| **Policy/Regulation** | Who is it for? (K-12/university/all) | Check document title, scope clauses |
|
|
|
|
|
| **Academic Research** | Who are the subjects? (vocational/undergraduate/graduate) | Check methodology/sample description sections |
|
|
|
|
|
| **Statistical Data** | Which population is measured? | Check data source description |
|
|
|
|
|
| **Case Reports** | What type of institution is involved? | Confirm institution type (university/high school/vocational) |
|
|
|
|
|
|
|
|
|
|
**Handling mismatched sources**:
|
|
|
|
|
- Target audience completely mismatched → **do not include**
|
|
|
|
|
- Partially overlapping (e.g., "students" includes university students) → include but **annotate applicable scope**
|
|
|
|
|
- Usable as analogous reference (e.g., K-12 policy as a trend reference) → include but **explicitly annotate "reference only"**
|
|
|
|
|
- Use `WebSearch` for broad searches; `WebFetch` to read specific pages
|
|
|
|
|
- Use the `context7` MCP server (`resolve-library-id` then `get-library-docs`) for up-to-date library/framework documentation
|
|
|
|
|
- Always cross-verify training data claims against live sources for facts that may have changed (versions, APIs, deprecations, security advisories)
|
|
|
|
|
- When citing web sources, include the URL and date accessed
|
|
|
|
|
|
|
|
|
|
**📁 Save action**:
|
|
|
|
|
For each source consulted, **immediately** append to `01_source_registry.md`:
|
|
|
|
|
```markdown
|
|
|
|
|
## Source #[number]
|
|
|
|
|
- **Title**: [source title]
|
|
|
|
|
- **Link**: [URL]
|
|
|
|
|
- **Tier**: L1/L2/L3/L4
|
|
|
|
|
- **Publication Date**: [YYYY-MM-DD]
|
|
|
|
|
- **Timeliness Status**: ✅ Currently valid / ⚠️ Needs verification / ❌ Outdated (reference only)
|
|
|
|
|
- **Version Info**: [If involving a specific version, must annotate]
|
|
|
|
|
- **Target Audience**: [Explicitly annotate the group/geography/level this source targets]
|
|
|
|
|
- **Research Boundary Match**: ✅ Full match / ⚠️ Partial overlap / 📎 Reference only
|
|
|
|
|
- **Summary**: [1-2 sentence key content]
|
|
|
|
|
- **Related Sub-question**: [which sub-question this corresponds to]
|
|
|
|
|
```
|
|
|
|
|
For each source consulted, **immediately** append to `01_source_registry.md` using the entry template from `references/source-tiering.md`.
|
|
|
|
|
|
|
|
|
|
### Step 3: Fact Extraction & Evidence Cards
|
|
|
|
|
|
|
|
|
@@ -647,37 +458,7 @@ For each extracted fact, **immediately** append to `02_fact_cards.md`:
|
|
|
|
|
|
|
|
|
|
### Step 4: Build Comparison/Analysis Framework
|
|
|
|
|
|
|
|
|
|
Based on the question type, select fixed analysis dimensions:
|
|
|
|
|
|
|
|
|
|
**General Dimensions** (select as needed):
|
|
|
|
|
1. Goal / What problem does it solve
|
|
|
|
|
2. Working mechanism / Process
|
|
|
|
|
3. Input / Output / Boundaries
|
|
|
|
|
4. Advantages / Disadvantages / Trade-offs
|
|
|
|
|
5. Applicable scenarios / Boundary conditions
|
|
|
|
|
6. Cost / Benefit / Risk
|
|
|
|
|
7. Historical evolution / Future trends
|
|
|
|
|
8. Security / Permissions / Controllability
|
|
|
|
|
|
|
|
|
|
**Concept Comparison Specific Dimensions**:
|
|
|
|
|
1. Definition & essence
|
|
|
|
|
2. Trigger / invocation method
|
|
|
|
|
3. Execution agent
|
|
|
|
|
4. Input/output & type constraints
|
|
|
|
|
5. Determinism & repeatability
|
|
|
|
|
6. Resource & context management
|
|
|
|
|
7. Composition & reuse patterns
|
|
|
|
|
8. Security boundaries & permission control
|
|
|
|
|
|
|
|
|
|
**Decision Support Specific Dimensions**:
|
|
|
|
|
1. Solution overview
|
|
|
|
|
2. Implementation cost
|
|
|
|
|
3. Maintenance cost
|
|
|
|
|
4. Risk assessment
|
|
|
|
|
5. Expected benefit
|
|
|
|
|
6. Applicable scenarios
|
|
|
|
|
7. Team capability requirements
|
|
|
|
|
8. Migration difficulty
|
|
|
|
|
Based on the question type, select fixed analysis dimensions. **For dimension lists** (General, Concept Comparison, Decision Support): Read `references/comparison-frameworks.md`
|
|
|
|
|
|
|
|
|
|
**📁 Save action**:
|
|
|
|
|
Write to `03_comparison_framework.md`:
|
|
|
|
@@ -834,7 +615,7 @@ Adjust content depth based on audience:
|
|
|
|
|
|
|
|
|
|
## Output Files
|
|
|
|
|
|
|
|
|
|
Default intermediate artifacts location: `RESEARCH_DIR/<topic>/`
|
|
|
|
|
Default intermediate artifacts location: `RESEARCH_DIR/`
|
|
|
|
|
|
|
|
|
|
**Required files** (automatically generated through the process):
|
|
|
|
|
|
|
|
|
@@ -892,185 +673,20 @@ Default intermediate artifacts location: `RESEARCH_DIR/<topic>/`
|
|
|
|
|
|
|
|
|
|
## Usage Examples
|
|
|
|
|
|
|
|
|
|
### Example 1: Initial Research (Mode A)
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
User: Research this problem and find the best solution
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Execution flow:
|
|
|
|
|
1. Context resolution: no explicit file → project mode (INPUT_DIR=`_docs/00_problem/`, OUTPUT_DIR=`_docs/01_solution/`)
|
|
|
|
|
2. Guardrails: verify INPUT_DIR exists with required files
|
|
|
|
|
3. Mode detection: no `solution_draft*.md` → Mode A
|
|
|
|
|
4. Phase 1: Assess acceptance criteria and restrictions, ask user about unclear parts
|
|
|
|
|
5. BLOCKING: present AC assessment, wait for user confirmation
|
|
|
|
|
6. Phase 2: Full 8-step research — competitors, components, state-of-the-art solutions
|
|
|
|
|
7. Output: `OUTPUT_DIR/solution_draft01.md`
|
|
|
|
|
8. (Optional) Phase 3: Tech stack consolidation → `tech_stack.md`
|
|
|
|
|
9. (Optional) Phase 4: Security deep dive → `security_analysis.md`
|
|
|
|
|
|
|
|
|
|
### Example 2: Solution Assessment (Mode B)
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
User: Assess the current solution draft
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Execution flow:
|
|
|
|
|
1. Context resolution: no explicit file → project mode
|
|
|
|
|
2. Guardrails: verify INPUT_DIR exists
|
|
|
|
|
3. Mode detection: `solution_draft03.md` found in OUTPUT_DIR → Mode B, read it as input
|
|
|
|
|
4. Full 8-step research — weak points, security, performance, solutions
|
|
|
|
|
5. Output: `OUTPUT_DIR/solution_draft04.md` with findings table + revised draft
|
|
|
|
|
|
|
|
|
|
### Example 3: Standalone Research
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
User: /research @my_problem.md
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Execution flow:
|
|
|
|
|
1. Context resolution: explicit file → standalone mode (INPUT_FILE=`my_problem.md`, OUTPUT_DIR=`_standalone/my_problem/01_solution/`)
|
|
|
|
|
2. Guardrails: verify INPUT_FILE exists and is non-empty, warn about missing restrictions/AC
|
|
|
|
|
3. Mode detection + full research flow as in Example 1, scoped to standalone paths
|
|
|
|
|
4. Output: `_standalone/my_problem/01_solution/solution_draft01.md`
|
|
|
|
|
5. Move `my_problem.md` into `_standalone/my_problem/`
|
|
|
|
|
|
|
|
|
|
### Example 4: Force Initial Research (Override)
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
User: Research from scratch, ignore existing drafts
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Execution flow:
|
|
|
|
|
1. Context resolution: no explicit file → project mode
|
|
|
|
|
2. Mode detection: drafts exist, but user explicitly requested initial research → Mode A
|
|
|
|
|
3. Phase 1 + Phase 2 as in Example 1
|
|
|
|
|
4. Output: `OUTPUT_DIR/solution_draft##.md` (incremented from highest existing)
|
|
|
|
|
For detailed execution flow examples (Mode A initial, Mode B assessment, standalone, force override): Read `references/usage-examples.md`
|
|
|
|
|
|
|
|
|
|
## Source Verifiability Requirements
|
|
|
|
|
|
|
|
|
|
**Core principle**: Every piece of external information cited in the report must be directly verifiable by the user.
|
|
|
|
|
|
|
|
|
|
**Mandatory rules**:
|
|
|
|
|
|
|
|
|
|
1. **URL Accessibility**:
|
|
|
|
|
- All cited links must be publicly accessible (no login/paywall required)
|
|
|
|
|
- If citing content that requires login, must annotate `[login required]`
|
|
|
|
|
- If citing academic papers, prefer publicly available versions (arXiv/DOI)
|
|
|
|
|
|
|
|
|
|
2. **Citation Precision**:
|
|
|
|
|
- For long documents, must specify exact section/page/timestamp
|
|
|
|
|
- Example: `[Source: OpenAI Blog, 2024-03-15, "GPT-4 Technical Report", §3.2 Safety]`
|
|
|
|
|
- Video/audio citations need timestamps
|
|
|
|
|
|
|
|
|
|
3. **Content Correspondence**:
|
|
|
|
|
- Cited facts must have corresponding statements in the original text
|
|
|
|
|
- Prohibit over-interpretation of original text presented as "citations"
|
|
|
|
|
- If there's interpretation/inference, must explicitly annotate "inferred based on [source]"
|
|
|
|
|
|
|
|
|
|
4. **Timeliness Annotation**:
|
|
|
|
|
- Annotate source publication/update date
|
|
|
|
|
- For technical docs, annotate version number
|
|
|
|
|
- Sources older than 2 years need validity assessment
|
|
|
|
|
|
|
|
|
|
5. **Handling Unverifiable Information**:
|
|
|
|
|
- If the information source cannot be publicly verified (e.g., private communication, paywalled report excerpts), must annotate `[limited source]` in confidence level
|
|
|
|
|
- Unverifiable information cannot be the sole support for core conclusions
|
|
|
|
|
Every cited piece of external information must be directly verifiable by the user. All links must be publicly accessible (annotate `[login required]` if not), citations must include exact section/page/timestamp, and unverifiable information must be annotated `[limited source]`. Full checklist in `references/quality-checklists.md`.
|
|
|
|
|
|
|
|
|
|
## Quality Checklist
|
|
|
|
|
|
|
|
|
|
Before completing the solution draft, check the following items:
|
|
|
|
|
|
|
|
|
|
### General Quality
|
|
|
|
|
|
|
|
|
|
- [ ] All core conclusions have L1/L2 tier factual support
|
|
|
|
|
- [ ] No use of vague words like "possibly", "probably" without annotating uncertainty
|
|
|
|
|
- [ ] Comparison dimensions are complete with no key differences missed
|
|
|
|
|
- [ ] At least one real use case validates conclusions
|
|
|
|
|
- [ ] References are complete with accessible links
|
|
|
|
|
- [ ] **Every citation can be directly verified by the user (source verifiability)**
|
|
|
|
|
- [ ] Structure hierarchy is clear; executives can quickly locate information
|
|
|
|
|
|
|
|
|
|
### Mode A Specific
|
|
|
|
|
|
|
|
|
|
- [ ] **Phase 1 completed**: AC assessment was presented to and confirmed by user
|
|
|
|
|
- [ ] **AC assessment consistent**: Solution draft respects the (possibly adjusted) acceptance criteria and restrictions
|
|
|
|
|
- [ ] **Competitor analysis included**: Existing solutions were researched
|
|
|
|
|
- [ ] **All components have comparison tables**: Each component lists alternatives with tools, advantages, limitations, security, cost
|
|
|
|
|
- [ ] **Tools/libraries verified**: Suggested tools actually exist and work as described
|
|
|
|
|
- [ ] **Testing strategy covers AC**: Tests map to acceptance criteria
|
|
|
|
|
- [ ] **Tech stack documented** (if Phase 3 ran): `tech_stack.md` has evaluation tables, risk assessment, and learning requirements
|
|
|
|
|
- [ ] **Security analysis documented** (if Phase 4 ran): `security_analysis.md` has threat model and per-component controls
|
|
|
|
|
|
|
|
|
|
### Mode B Specific
|
|
|
|
|
|
|
|
|
|
- [ ] **Findings table complete**: All identified weak points documented with solutions
|
|
|
|
|
- [ ] **Weak point categories covered**: Functional, security, and performance assessed
|
|
|
|
|
- [ ] **New draft is self-contained**: Written as if from scratch, no "updated" markers
|
|
|
|
|
- [ ] **Performance column included**: Mode B comparison tables include performance characteristics
|
|
|
|
|
- [ ] **Previous draft issues addressed**: Every finding in the table is resolved in the new draft
|
|
|
|
|
|
|
|
|
|
### ⏰ Timeliness Check (High-Sensitivity Domain BLOCKING)
|
|
|
|
|
|
|
|
|
|
When the research topic has 🔴 Critical or 🟠 High sensitivity level, **the following checks must be completed**:
|
|
|
|
|
|
|
|
|
|
- [ ] **Timeliness sensitivity assessment completed**: `00_question_decomposition.md` contains a timeliness assessment section
|
|
|
|
|
- [ ] **Source timeliness annotated**: Every source has publication date, timeliness status, version info
|
|
|
|
|
- [ ] **No outdated sources used as factual evidence**:
|
|
|
|
|
- 🔴 Critical: Core fact sources are all within 6 months
|
|
|
|
|
- 🟠 High: Core fact sources are all within 1 year
|
|
|
|
|
- [ ] **Version numbers explicitly annotated**:
|
|
|
|
|
- Technical product/API/SDK descriptions all annotate specific version numbers
|
|
|
|
|
- No vague time expressions like "latest version" or "currently"
|
|
|
|
|
- [ ] **Official sources prioritized**: Core conclusions have support from official documentation/blogs
|
|
|
|
|
- [ ] **Cross-validation completed**: Key technical information confirmed from at least 2 independent sources
|
|
|
|
|
- [ ] **Download page directly verified**: Platform support info comes from real-time extraction of official download pages, not search caches
|
|
|
|
|
- [ ] **Protocol/feature names searched**: Searched for product-supported protocol names (MCP, ACP, etc.)
|
|
|
|
|
- [ ] **GitHub Issues mined**: Reviewed product's GitHub Issues popular discussions
|
|
|
|
|
- [ ] **Community hotspots identified**: Identified and recorded feature points users care most about
|
|
|
|
|
|
|
|
|
|
**Typical community voice oversight error cases**:
|
|
|
|
|
|
|
|
|
|
> Wrong: Relying solely on official docs, MCP briefly mentioned as a regular feature in the report
|
|
|
|
|
> Correct: Discovered through GitHub Issues that MCP is the most hotly discussed feature in the community, expanded analysis of its value in the report
|
|
|
|
|
|
|
|
|
|
> Wrong: "Both Alma and Cherry Studio support MCP" (no difference analysis)
|
|
|
|
|
> Correct: Discovered through community discussion that "Alma's MCP implementation is highly consistent with Claude Code — this is its core competitive advantage"
|
|
|
|
|
|
|
|
|
|
**Typical platform support/protocol oversight error cases**:
|
|
|
|
|
|
|
|
|
|
> Wrong: "Alma only supports macOS" (based on search engine cached "Coming soon" info)
|
|
|
|
|
> Correct: Directly visited alma.now/download page to verify currently supported platforms
|
|
|
|
|
|
|
|
|
|
> Wrong: "Alma supports MCP" (only searched MCP, missed ACP)
|
|
|
|
|
> Correct: Searched both "Alma MCP" and "Alma ACP", discovered Alma also supports ACP protocol integration for CLI tools
|
|
|
|
|
|
|
|
|
|
**Typical timeliness error cases**:
|
|
|
|
|
|
|
|
|
|
> Wrong: "Claude supports function calling" (no version annotated, may refer to old version capabilities)
|
|
|
|
|
> Correct: "Claude 3.5 Sonnet (claude-3-5-sonnet-20241022) supports function calling via Tool Use API, with a maximum of 8192 tokens for tool definitions"
|
|
|
|
|
|
|
|
|
|
> Wrong: "According to a 2023 blog post, GPT-4's context length is 8K"
|
|
|
|
|
> Correct: "As of January 2024, GPT-4 Turbo supports 128K context (Source: OpenAI official documentation, updated 2024-01-25)"
|
|
|
|
|
|
|
|
|
|
### ⚠️ Target Audience Consistency Check (BLOCKING)
|
|
|
|
|
|
|
|
|
|
This is the most easily overlooked and most critical check item:
|
|
|
|
|
|
|
|
|
|
- [ ] **Research boundary clearly defined**: `00_question_decomposition.md` has clear population/geography/timeframe/level boundaries
|
|
|
|
|
- [ ] **Every source has target audience annotated**: `01_source_registry.md` has "Target Audience" and "Research Boundary Match" fields for each source
|
|
|
|
|
- [ ] **Mismatched sources properly handled**:
|
|
|
|
|
- Completely mismatched sources were not included
|
|
|
|
|
- Partially overlapping sources have annotated applicable scope
|
|
|
|
|
- Reference-only sources are explicitly annotated
|
|
|
|
|
- [ ] **No audience confusion in fact cards**: Every fact in `02_fact_cards.md` has a target audience consistent with the research boundary
|
|
|
|
|
- [ ] **No audience confusion in the report**: Policies/research/data cited in the solution draft have target audiences consistent with the research topic
|
|
|
|
|
|
|
|
|
|
**Typical error case**:
|
|
|
|
|
> Research topic: "University students not paying attention in class"
|
|
|
|
|
> Wrong citation: "In October 2025, the Ministry of Education banned phones in classrooms"
|
|
|
|
|
> Problem: That policy targets K-12 students, not university students
|
|
|
|
|
> Consequence: Readers mistakenly believe the Ministry of Education banned university students from carrying phones — severely misleading
|
|
|
|
|
Before completing the solution draft, run through the checklists in `references/quality-checklists.md`. This covers:
|
|
|
|
|
- General quality (L1/L2 support, verifiability, actionability)
|
|
|
|
|
- Mode A specific (AC assessment, competitor analysis, component tables, tech stack)
|
|
|
|
|
- Mode B specific (findings table, self-contained draft, performance column)
|
|
|
|
|
- Timeliness check for high-sensitivity domains (version annotations, cross-validation, community mining)
|
|
|
|
|
- Target audience consistency (boundary definition, source matching, fact card audience)
|
|
|
|
|
|
|
|
|
|
## Final Reply Guidelines
|
|
|
|
|
|
|
|
|
|
Oleksandr Bezdieniezhnykh