• Conclusions come from mechanism comparison, not "I feel like it"
• Establish facts first, then make deductions
• Priority to authoritative sources, L1 > L2 > L3 > L4
• Intermediate results must be saved for easy traceback and reuse

1. Save in real-time: Write to the corresponding file immediately after completing each step, do not wait until the end
2. Incremental update: The same file can be updated multiple times, append or replace new content
3. Preserve process: Even if intermediate file content is later integrated into the final report, keep them
4. Easy recovery: If research is interrupted, progress can be restored from intermediate files

• Gain in-depth understanding of a concept/technology/phenomenon
• Compare similarities and differences between two or more things
• Collect information and basis for decision-making
• Write research reports or analysis documents

• "Deep Research", "In-Depth Study", "In-Depth Analysis"
• "Help me research", "Do a research", "Conduct a study"
• "Comparative Analysis", "Concept Comparison", "Technology Comparison"
• "Write a research report", "Produce a research report"

• Need visual diagrams → Use

  research-to-diagram

• Need writing output (articles/tutorials) → Use

  wsy-writer

• Need material organization → Use

  material-to-markdown

• Need pure research reports → Use this Skill

• AI-related: Large Model, LLM, GPT, Claude, Gemini, AI Agent, RAG, Vector Database, Prompt Engineering
• Cloud Native: Kubernetes New Versions, Serverless, Container Runtime
• Cutting-edge Technologies: Web3, Quantum Computing, AR/VR

1. Search with time constraints:
   • Use

     time_range: "month"

     or

     time_range: "week"

     to limit search results
   • Prioritize setting

     start_date: "YYYY-MM-DD"

     to within the last 3 months
2. Elevated priority for official sources:
   • Must first consult official documents, official blogs, official Changelogs
   • GitHub Release Notes, official X/Twitter announcements
   • Academic papers (preprint platforms like arXiv)
3. Mandatory version number labeling:
   • Any technical description must be labeled with the current version number
   • Example: "Claude 3.5 Sonnet (claude-3-5-sonnet-20241022) supports..."
   • Prohibit using vague expressions like "the latest version supports..."
4. Disposal of outdated information:
   • Technical blogs/tutorials older than 6 months → Only used as historical reference, cannot be used as factual basis
   • If version inconsistency is found → Must verify the current version before use
   • Obvious outdated descriptions (e.g., "will support in the future" but now supported) → Discard directly
5. Cross-verification:
   • High-sensitivity information must be confirmed from at least 2 independent sources
   • Priority: Official Documents > Official Blogs > Authoritative Technical Media > Personal Blogs
6. Direct verification of official download/release pages (BLOCKING):
   • Must directly access official download pages to verify platform support (do not rely on search engine cache)
   • Use

     mcp__tavily-mcp__tavily-extract

     or

     WebFetch

     to directly extract page content
   • Example:

     https://product.com/download

     or

     https://github.com/xxx/releases

   • Descriptions like "Coming soon" in search results may be outdated, must verify in real-time
   • Platform support is frequently changing information, cannot be inferred from old materials
7. Search for product-specific protocol/function names (BLOCKING):
   • In addition to searching for product names, must additionally search for the names of protocols/standards supported by the product
   • Common protocols/standards to search for:
     • 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 differentiated features, easily omitted in main documents but explained in dedicated pages

• Research Topic: [Topic]
• Sensitivity Level: 🔴Extremely High / 🟠High / 🟡Medium / 🟢Low
• Judgment Basis: [Why this level]
• Material 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 ____

**📁 Save Action**: Append the timeliness assessment to the end of `00_Problem_Decomposition.md`

---

• Sub-question A: "What is X and how does it work?" (Definition and mechanism)
• Sub-question B: "What are the relationships/differences between X and Y in various dimensions?" (Comparative analysis)
• Sub-question C: "In what scenarios is X applicable/not applicable?" (Boundary conditions)
• Sub-question D: "What are the development trends/best practices of X?" (Extended analysis)

1. Create the working directory

   ~/Downloads/research/<topic>/

2. Write to

   00_Problem_Decomposition.md

   , including:
   • Original question
   • Judged problem type and reasons
   • Research object boundary definition (population, region, time, level)
   • List of decomposed sub-questions
3. Write to TodoWrite to track progress

github.com/<org>/<repo>/issues

github.com/<org>/<repo>/discussions

site:reddit.com "<Product Name>"

site:news.ycombinator.com "<Product Name>"

• Conclusions must be traceable to L1/L2
• L3/L4 are only for assistance and verification
• L4 community discussions are used to discover "what users really care about"
• Record all information sources

time_range: "month"

time_range: "year"

1. First Round: Targeted search of official sources
   - Use include_domains to limit official domain names
   - Example: include_domains: ["anthropic.com", "openai.com", "docs.xxx.com"]

2. Second Round: Direct verification of official download/release pages (BLOCKING)
   - Directly access official download pages, do not rely on search cache
   - Use tavily-extract or WebFetch to extract page content
   - Verify: Platform support, current version number, release date
   - This step must be done, search engines may cache outdated "Coming soon" information

3. Third Round: Search for product-specific protocols/functions (BLOCKING)
   - Search for protocol names supported by the product (MCP, ACP, LSP, etc.)
   - Format: `"<Product Name> <Protocol Name>" site:official domain`
   - These integration features are often not displayed on the homepage but explained in dedicated documents

4. Fourth Round: Time-limited extensive search
   - time_range: "month" or set start_date to recent period
   - Explicitly exclude outdated sources

5. Fifth Round: Version verification
   - Cross-verify version numbers in search results
   - Immediately check official Changelog if inconsistencies are found

6. Sixth Round: Community voice mining (BLOCKING - Mandatory for product comparison research)
   - Access the product's GitHub Issues page, view popular/pinned issues
   - Search for key function words in Issues (e.g., "MCP", "plugin", "integration")
   - View discussion trends in the last 3-6 months
   - Identify the function points and differentiated features that users care about most
   - Value of this step: Official documents often do not emphasize "features that others don't have but I do", but community discussions will

GitHub Issues Mining Steps:
1. Access 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. View issue labels: enhancement, feature, discussion
5. Record frequently mentioned feature demands and user pain points

Value Conversion:
- Frequently discussed features → May be differentiated highlights
- User complaints/requests → May be product shortcomings
- Comparison discussions → Directly obtain user-perspective difference analysis

- **Release Date**: [YYYY-MM-DD]
- **Timeliness Status**: ✅Currently Valid / ⚠️Needs Verification / ❌Outdated
- **Version Information**: [If applicable, mark the involved version number]

• Prioritize using

  mcp__plugin_context7_context7__query-docs

  to obtain technical documents
• Use

  WebSearch

  or

  mcp__tavily-mcp__tavily-search

  for extensive searches
• Use

  mcp__tavily-mcp__tavily-extract

  to extract specific page content

• Completely mismatched materials → Do not include
• Partially overlapping (e.g., "students" include college students) → Include but mark application scope
• Analogous reference (e.g., middle school policies as trend reference) → Include but explicitly mark "For Reference Only"

01_Source_Materials.md

undefined

• Title: [Material Title]
• Link: [URL]
• Level: L1/L2/L3/L4
• Release Date: [YYYY-MM-DD]
• Timeliness Status: ✅Currently Valid / ⚠️Needs Verification / ❌Outdated (Reference Only)
• Version Information: [If involving specific versions, must mark]
• Application Object: [Clearly mark the group/region/level targeted by this material]
• Match with Research Boundary: ✅Fully Matched / ⚠️Partially Overlapping / 📎For Reference Only
• Abstract: [1-2 key content sentences]
• Association with Sub-questions: [Corresponding sub-question]

undefined

• Statement: [Specific fact description]
• Source: [Link/document section]
• Confidence Level: High/Medium/Low

• Statement: [Specific fact description]
• Source: [Material #Serial Number] [Link]
• Application Object: [The group this fact applies to, inherited from materials or further refined]
• Confidence Level: ✅/⚠️/❓
• Associated Dimension: [Corresponding comparison dimension]

**⚠️ Application Object in Fact Statements**:
- If the fact comes from partially overlapping or reference-only materials, **must clearly mark the application scope** when stating
- Wrong Example: "Ministry of Education prohibits bringing mobile phones into classrooms" (does not specify who it targets)
- Correct Example: "Ministry of Education prohibits middle school students from bringing mobile phones into classrooms (not applicable to college students)"

1. Objectives/Problems solved
2. Working mechanism/process
3. Input/output/boundaries
4. Advantages/disadvantages/trade-offs
5. Application scenarios/boundary conditions
6. Cost/benefit/risk
7. Historical evolution/future trends
8. Security/permission/controllability

1. Definition and essence
2. Trigger/call method
3. Execution subject
4. Input/output and type constraints
5. Determinism and repeatability
6. Resource and context management
7. Combination and reuse methods
8. Security boundaries and permission control

1. Program overview
2. Implementation cost
3. Maintenance cost
4. Risk assessment
5. Benefit expectations
6. Application scenarios
7. Team capability requirements
8. Migration difficulty

03_Comparison_Framework.md

undefined

1. [Dimension 1]
2. [Dimension 2] ...

• Is the definition of the reference object stable/recognized?
• Does it need verification, or can it use domain common sense?
• Do readers understand the reference object the same way I do?
• Are there ambiguities that need clarification first?

1. Fact Confirmation: According to [Source], the mechanism of X is...
2. Compare with Reference Object: While the mechanism of Y is...
3. Conclusion: Therefore, the difference between X and Y in this dimension is...

**Key Discipline**:
- Conclusions come from mechanism comparison, not "I feel like it"
- Each conclusion can be traced back to specific facts
- Mark uncertain conclusions

**📁 Save Action**:
Write to `04_Derivation_Process.md`:
```markdown

• According to my conclusion, how should this scenario be handled?
• Is this actually the case?
• Are there any counterexamples that need explanation?

• Is the draft conclusion consistent with the fact cards in Step 3?
• Are there any important dimensions missing?
• Is there any over-inference?
• Is the conclusion operable/verifiable?

05_Verification_Records.md

undefined

• Draft conclusion is consistent with fact cards
• No missing important dimensions
• No over-inference
• Found issues: [If any]

1. One-sentence summary: Can be directly repeated in meetings
2. Structured chapters: Use subheadings to split the deduction chain
3. Traceable evidence: Attach source links to key facts

FINAL_Research_Report.md

• Extract background from

  00_Problem_Decomposition.md

• Cite key facts from

  02_Fact_Cards.md

• Organize conclusions from

  04_Derivation_Process.md

• Generate references from

  01_Source_Materials.md

• Supplement use cases from

  05_Verification_Records.md

~/Downloads/research/<topic>/

00_Problem_Decomposition.md

01_Source_Materials.md

02_Fact_Cards.md

03_Comparison_Framework.md

04_Derivation_Process.md

05_Verification_Records.md

FINAL_Research_Report.md

• raw/*.md

  - Archive of original materials (save when content is long)

User: Help me conduct in-depth research on the differences between REST API and GraphQL

1. Judge type: Concept Comparison Type
2. Decompose problems: Definition, mechanism, application scenarios, advantages and disadvantages
3. Consult official specifications (REST papers, GraphQL official documents)
4. Extract fact cards
5. Analyze with 8-dimension comparison framework
6. Verify with actual project scenarios
7. Output structured report

User: Should we choose PostgreSQL or MongoDB? Help me research it

1. Judge type: Decision Support Type
2. Supplement questions: User's business scenarios, data characteristics, team experience
3. Consult official documents and performance benchmarks
4. Analyze with decision dimension framework
5. Provide scenario-based recommendations
6. Mark risks and preconditions

User: What are the development trends of AI Agent? Conduct an in-depth analysis

1. Judge type: Trend Analysis Type
2. Sort out historical evolution context
3. Collect first-hand materials (papers, official announcements)
4. Identify driving factors
5. Analyze current landscape
6. Prudent trend prediction (mark uncertainties)

1. URL Accessibility:
   • All cited links must be publicly accessible (no login/paywall required)
   • If citing content that requires login, must mark

     [Login Required]

   • For academic papers, prioritize providing public versions such as arXiv/DOI
2. Precise Citation Positioning:
   • For long documents, must specify the specific section/page number/timestamp
   • Example:

     [Source: OpenAI Blog, 2024-03-15, "GPT-4 Technical Report", §3.2 Safety]

   • For video/audio citations, mark the timestamp
3. Content Correspondence:
   • The cited fact must have a corresponding statement in the original text
   • Prohibit using over-inferred content as "citation"
   • If there is interpretation/inference, must explicitly mark "Inferred based on [Source]"
4. Timeliness Labeling:
   • Mark the release/update date of materials
   • For technical documents, mark the version number
   • Evaluate validity if materials are older than 2 years
5. Handling of Unverifiable Information:
   • If the information source cannot be publicly verified (e.g., private communication, paid report abstracts), must mark

     [Source Restricted]

     in the confidence level
   • Unverifiable information cannot be the only support for core conclusions

• All core conclusions are supported by L1/L2-level facts
• No vague words like "may" or "probably" without marking uncertainty
• Comparison dimensions are complete, no key differences are missing
• At least one actual use case verifies the conclusion
• References are complete, links are accessible
• Every citation can be directly verified by users (Source Verifiability)
• One-sentence summary is clear and reproducible
• Structure is clear, bosses can quickly locate content

• Timeliness sensitivity assessment completed:

  00_Problem_Decomposition.md

  includes the timeliness assessment section
• Material timeliness labeled: Each material has release date, timeliness status, and version information
• No outdated materials as factual basis:
  • 🔴Extremely High: Core fact sources are all within 6 months
  • 🟠High: Core fact sources are all within 1 year
• Version numbers clearly marked:
  • Descriptions related to technical products/APIs/SDKs all mark specific version numbers
  • No vague time expressions like "latest version" or "currently"
• Official sources prioritized: Core conclusions are supported by official documents/blogs
• Cross-verification completed: Key technical information confirmed from at least 2 independent sources
• Download pages directly verified: Platform support information comes from real-time extraction of official download pages, not search cache
• Protocol/function names searched: Have searched for protocol names supported by the product (MCP, ACP, etc.)
• GitHub Issues mined: Have viewed popular discussions in the product's GitHub Issues
• Community hotspots identified: Have identified and recorded the function points that users care about most

❌ Wrong: Only rely on official documents, mention MCP as an ordinary feature in the report ✅ Correct: Discover that MCP is the most discussed feature in the community through GitHub Issues, and focus on analyzing its value in the report

❌ Wrong: "Both Alma and Cherry Studio support MCP" (no analysis of differences) ✅ Correct: Discover through community discussions that "Alma's MCP implementation is highly consistent with Claude Code, which is its core competitiveness"

❌ Wrong: "Alma only supports macOS" (based on search engine cached "Coming soon" information) ✅ Correct: Directly access alma.now/download page to verify the currently supported platforms

❌ Wrong: "Alma supports MCP" (only searched MCP, missed ACP) ✅ Correct: Search both "Alma MCP" and "Alma ACP", and discover that Alma also supports ACP protocol integration CLI tools

❌ Wrong: "Claude supports function calling" (no version marked, may refer to old version capabilities) ✅ Correct: "Claude 3.5 Sonnet (claude-3-5-sonnet-20241022) supports function calling through the Tool Use API, with a maximum of 8192 tokens for tool definitions"

❌ Wrong: "According to a 2023 blog, the context length of GPT-4 is 8K" ✅ Correct: "As of January 2024, GPT-4 Turbo supports 128K context (Source: OpenAI Official Document, updated on 2024-01-25)"

• Research boundaries clearly defined:

  00_Problem_Decomposition.md

  has clear population/region/time/level definitions
• Each material marked with application object:

  01_Source_Materials.md

  has "Application Object" and "Match with Research Boundary" fields for each material
• Mismatched materials handled correctly:
  • Completely mismatched materials not included
  • Partially overlapping materials marked with application scope
  • Reference-only materials explicitly marked
• No object confusion in fact cards: Application objects of each fact in

  02_Fact_Cards.md

  are consistent with research boundaries
• No object confusion in report: Policies/research/data cited in the final report have application objects consistent with the research topic

Research Topic: "College students' inattentiveness in class" Wrong Citation: "In October 2025, the Ministry of Education issued a document prohibiting mobile phones in classrooms" Problem: This policy targets middle school students, not college students Consequence: Readers mistakenly think the Ministry of Education prohibits college students from bringing mobile phones, causing serious misunderstanding

tar -czvf ~/outcome.tar.gz -C <parent_dir> <workspace_name>

• If

  ~/outcome.tar.gz

  already exists, overwrite it directly
• Inform the user that packaging is completed and the file location

• One-sentence core conclusion
• Key findings summary (3-5 points)
• Package file location (

  ~/outcome.tar.gz

  )
• If there are major uncertainties, mark points that need further verification

• List of process files (e.g.,

  00_Problem_Decomposition.md

  ,

  01_Source_Materials.md

  , etc.)
• Detailed research step descriptions
• Working directory structure display

• v1.6 (2026-01-12): Added community voice mining mechanism
  • Added the "Specification of L4 Community Sources" table, clarifying sources like GitHub Issues/Discussions/Reddit/HN
  • Expanded search strategy from 5 rounds to 6 rounds, added "Community Voice Mining" round
  • Added "Specific Operations for Community Voice Mining" guide
  • Added to quality checklist: GitHub Issues mined, community hotspots identified
  • Added typical community voice omission error cases
  • Source: Lesson from underestimating the importance of MCP function in Alma vs Cherry Studio research—official documents won't emphasize "features others don't have but I do", but community discussions will
• v1.5 (2026-01-12): Enhanced accuracy of high-sensitivity field research
  • Added Rule 6 "Direct Verification of Official Download/Release Pages" - Must access download pages in real-time, do not rely on search cache
  • Added Rule 7 "Search for Product-Specific Protocol/Function Names" - Must search for protocol names like MCP and ACP
  • Expanded search strategy from 3 rounds to 5 rounds, added download page verification and protocol search rounds
  • Added "Final Response Specification" chapter - Prohibit listing process files in replies
  • Added to quality checklist: Download page verification, protocol search check items
  • Added typical error cases: Platform support omission (Alma Windows), protocol omission (Alma ACP)
  • Source: Lesson from missing Windows support and ACP function in Alma vs Cherry Studio research
• v1.4 (2026-01-12): Added timeliness sensitivity judgment mechanism
  • Added Step 0.5 "Timeliness Sensitivity Judgment", dividing questions into 4 sensitivity levels (Extremely High/High/Medium/Low)
  • Mandatory implementation for 🔴Extremely High sensitivity fields (AI/Large Models, etc.): 6-month time window, priority to official sources, mandatory version number labeling
  • Added "Timeliness Screening Rules" and "Search Strategy for High-Sensitivity Fields" in Step 2
  • Added to source material template: Release date, timeliness status, version information fields
  • Added "Timeliness Check" chapter to quality checklist
  • Source: User feedback that technology-related research easily cites outdated information leading to misunderstanding
• v1.3 (2026-01-11): Added Source Verifiability Requirements
  • Added "Source Verifiability Requirements" chapter, including 5 mandatory rules
  • URL accessibility, precise citation positioning, content correspondence, timeliness labeling, handling of unverifiable information
  • Added to quality checklist: "Every citation can be directly verified by users" item
  • Source: User requirement to ensure external citations are directly verifiable
• v1.2 (2026-01-11): Added application object verification mechanism
  • Added "Research Object Definition" in Step 1, requiring clear population/region/time/level boundaries
  • Added "Application Object Verification" in Step 2, must verify application object match before including materials
  • Added "Application Object" field to fact card template in Step 3
  • Added "Application Object Consistency Check" chapter to quality checklist
  • Source: Lesson from mistakenly citing middle school policies in classroom attention rate research
• v1.1 (2026-01-11): Enhanced intermediate product management
  • Added "Working Directory and Intermediate Product Management" chapter
  • Clear save actions for each step (marked with 📁)
  • Changed intermediate files from "optional" to "mandatory"
  • Standardized file naming and directory structure
• v1.0 (2025-01-11): Initial version
  • Refined from the case study of Claude Skills vs Functions research
  • Complete 8-step process
  • 5 problem type frameworks
  • Multi-dimensional comparison template