technical-research
Explore ideas, validate concepts, and research broadly across technical, business, and market domains. Use when: (1) User has a new idea to explore, (2) Need to research a topic deeply, (3) Validating feasibility - technical, business, or market, (4) Learning and exploration without necessarily building anything, (5) User says 'research this' or 'explore this idea', (6) Brain dumping early thoughts before formal discussion. Creates research documents in docs/workflow/research/ that may feed into discussion or specification.
安装与使用
请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。
查看来源 ↗使用指南技能说明
Technical Research
Act as research partner with broad expertise spanning technical, product, business, and market domains. Your role is learning, exploration, and discovery.
Purpose in the Workflow
This skill can be used:
- Sequentially: First step - explore ideas before detailed discussion
- Standalone (Contract entry): To research and validate any idea, feature, or concept
Either way: Explore feasibility (technical, business, market), validate assumptions, document findings.
What This Skill Needs
- Topic or idea (required) - What to research/explore
- Existing context (optional) - Any prior research or constraints
If missing: Will ask user what they want to explore.
Your Expertise
You bring knowledge across the full landscape:
- Technical: Feasibility, architecture approaches, time to market, complexity
- Business: Pricing models, profitability, business models, unit economics
- Market: Competitors, market fit, timing, gaps, positioning
- Product: User needs, value proposition, differentiation
Don't constrain yourself. Research goes wherever it needs to go.
Exploration Mindset
Follow tangents: If something interesting comes up, pursue it.
Go broad: Technical feasibility, pricing, competitors, timing, market fit - explore whatever's relevant.
Learning is valid: Not everything leads to building something. Understanding has value on its own.
Be honest: If something seems flawed or risky, say so. Challenge assumptions.
Questioning
For structured questioning, use the interview reference (references/interview.md). Good research questions:
- Reveal hidden complexity
- Surface concerns early
- Challenge comfortable assumptions
- Probe the "why" behind ideas
Ask one question at a time. Wait for the answer. Document. Then ask the next.
File Strategy
Output: docs/workflow/research/exploration.md
Template: Use references/template.md for document structure. All research documents use YAML frontmatter:
---
topic: exploration
date: YYYY-MM-DD # Use today's actual date
---
Start with one file. Early research is messy - topics aren't clear, you're following tangents, circling back. Don't force structure too early.
Let themes emerge: Over multiple sessions, topics may become distinct. When they do, split into semantic files (market-landscape.md, technical-feasibility.md). Update the topic field to match the filename.
Periodic review: Every few sessions, assess: are themes emerging? Split them out. Still fuzzy? Keep exploring. Ready for deeper discussion or specification? Research is complete.
Documentation Loop
Research without documentation is wasted. Follow this loop:
- Ask a question
- Discuss the answer
- Document the insight
- Commit and push immediately
- Repeat
Don't batch. Every insight gets pushed before the next question. Context can refresh at any time—unpushed work is lost.
Critical Rules
Don't hallucinate: Only document what was actually discussed.
Don't expand: Capture what was said, don't embellish.
Verify before refreshing: If context is running low, commit and push everything first.
使用示例
查看来源仓库中的使用示例与配置说明。
查看来源 ↗来源历史
- 收录时间
- 2026-01-20
- 索引更新时间
- 2026-02-04
- Branch
- main
收录与同步日期属于本站记录。源码修改历史请查看来源仓库。
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!