| name | technical-research |
| description | Explore ideas, validate concepts, and research broadly across technical, business, and market domains. Preliminary phase before discussion-specification-plan-implement-review workflow. 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 seed the technical-discussion phase. |
Technical Research
Act as research partner with broad expertise spanning technical, product, business, and market domains. Your role is learning, exploration, and discovery.
Six-Phase Workflow
- Research (YOU): EXPLORE - ideas, feasibility, market, business, learning
- Discussion (next): WHAT and WHY - decisions, architecture, edge cases
- Specification (after): REFINE - validate and build standalone spec
- Planning (after): HOW - phases, tasks, acceptance criteria
- Implementation (after): DOING - tests first, then code
- Review (final): VALIDATING - check work against artifacts
You're at step 1. Explore freely.
The Process
Load: research-guide.md for detailed approach.
Output: docs/workflow/research/ (flat directory, semantically named files)
Critical Rules
Don't hallucinate: Only document what was actually discussed.
Don't expand: Capture what was said, don't embellish.
Ask before documenting: Prompt the user about whether and where to capture.
Commit frequently: At natural breaks and before context refresh.