research

name	research
description	Investigate domain fit, prior art, and technical options before committing to a PRD. Use when evaluating a new feature, library, architecture pattern, or integration approach.

Research

Investigate the proposed feature or technical direction across three dimensions before committing to a specification. Present findings for human decision — do not auto-proceed to PRD generation.

Process

1. Gather context

Read the current conversation context. If a feature brief, issue, or design question has been discussed, use that as the research target. Reference the project's domain glossary (CONTEXT.md) for consistent terminology.

2. Investigate three concerns

For each concern, research thoroughly, then summarize findings with a clear recommendation.

Domain Validation

Is this the right feature to build? Does it solve the user's actual problem?

• Search for articles, blog posts, and case studies about this problem space
• Look for competing products or existing solutions that address the same need
• Check for user research, surveys, or documented pain points that validate the assumption
• Challenge the premise — are there signs this feature won't deliver the expected value?

Output: Summary of evidence for/against building this feature. Recommendation: proceed, pivot, or investigate further.

Prior Art

How have others implemented this? What pitfalls should we avoid?

• Find reference implementations in open-source projects
• Look for research papers, technical blog posts, or conference talks about this approach
• Identify documented pitfalls, failure modes, and lessons learned
• Check for established patterns (event-driven, pub/sub, CQRS, etc.) that fit the problem shape

Output: Summary of approaches found, with links where available. Recommendation: which approach best fits our constraints.

Technical Options

Which specific tools, libraries, or patterns fit our stack?

• Evaluate candidate libraries or frameworks. Compare across:
  • API surface complexity (prefer small interfaces — deep module principle)
  • Performance overhead and bundle size impact
  • Ease of automated testing (can we test through public interfaces?)
  • Maintenance health (recent commits, issue responsiveness, breaking change history)
  • Lock-in risk and migration path
• Check compatibility with our existing stack (TypeScript, pnpm workspaces, vitest)
• Identify architectural patterns that support building deep modules with simple surface area
• Flag security risks or constraints that the choice introduces

Output: Comparison table or structured summary. Recommendation: which option to adopt and why.

3. Present findings

Compile all three sections into a structured research summary. For each section, clearly state:

• What was found
• What the recommendation is
• Confidence level (high / medium / low)
• What remains uncertain

Wait for human approval before proceeding. The approved direction feeds into Phase 3 (PRD Generation).