research-domain

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

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.

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.