ashermahonin 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
- 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.
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 for05-domain-research.md.