research-domain

Research Domain

Purpose

Give the project a grounded map of the world it is entering. Keep the work curious, skeptical, and useful: enough context to make better decisions, not a literature review for its own sake.

Inputs

• Name the target users and the work they are trying to get done.
• List domain terms that could be misunderstood.
• Identify external constraints: law, standards, workflows, integrations, procurement, trust, or operational habits.
• Separate confirmed facts from assumptions that need validation.

Decision process

1. Collect domain facts from provided docs, repo notes, user context, and current public sources when the topic is time-sensitive.
2. Summarize user workflows and pain points as practical situations.
3. Capture constraints that should influence requirements, architecture, or UX.
4. Write risks as testable concerns, not vague worries.
5. Pass only relevant findings forward; avoid dumping research into the main context.

Decision boundaries

• Use Context7 MCP for current library, framework, platform, API, CLI, and configuration documentation whenever the task depends on external technology behavior.

Decision record

• Domain summary
• User and operator map
• Terminology list
• Constraints and assumptions
• Risks and validation questions

Ready when

• Use specific language from the domain when it matters.
• Do not turn weak assumptions into confident requirements.
• Connect each major finding to a product or engineering implication.
• Keep citations or source notes when freshness matters.

Handoff

Hand off the findings that directly affect product scope, quality scenarios, architecture, or risk.

References

• references/domain-output.md: Use this structure for 05-domain-research.md.