| name | research-domain |
| description | Research domain context, users, jobs-to-be-done, constraints, terminology, workflows, risks, and decision pressure before requirements or architecture. Use when creating a new product, entering an unfamiliar domain, validating product assumptions, preparing `05-domain-research.md`, or deciding what the system must respect before design or implementation begins. |
Research Domain
Role
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.
Start By
- 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.
Procedure
- Collect domain facts from provided docs, repo notes, user context, and current public sources when the topic is time-sensitive.
- Summarize user workflows and pain points as practical situations.
- Capture constraints that should influence requirements, architecture, or UX.
- Write risks as testable concerns, not vague worries.
- Pass only relevant findings forward; avoid dumping research into the main context.
Principal-Level Defaults
- Follow
../../routing/principal-operating-model.md before moving from analysis to implementation.
- Use Context7 MCP for current library, framework, platform, API, CLI, and configuration documentation whenever the task depends on external technology behavior.
- Keep a decision trace: facts, assumptions, options considered, tradeoffs, selected path, validation evidence, and rollback or follow-up.
- Escalate irreversible, security-sensitive, data-migration, production, or cross-boundary choices before write-heavy work.
Output Artifacts
- Domain summary
- User and operator map
- Terminology list
- Constraints and assumptions
- Risks and validation questions
Quality Bar
- 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.
