100 Domain Knowledge

What this skill is for

100-domain-knowledge produces a research-backed domain reference before any planning or architecture work begins. It captures the market the product operates in, the users it must serve, the workflows those users actually follow, the language the domain uses, and the constraints that shape what a good solution looks like.

This is not a product spec and not a business plan. It is the external context document that helps every downstream SpecFlow workflow use the right terminology, prioritize the right problems, and avoid designing against a false understanding of the domain.

Output path: .specflow/context/domain-knowledge.md

When to use it

• When the domain is unfamiliar, regulated, or terminology-heavy
• At the start of a new project before writing the product overview
• On an existing project where domain assumptions have never been made explicit
• When 101-project-overview would benefit from grounded market and user research

When NOT to use it

• When the team already has deep domain expertise and documented user research
• For a quick internal tool where domain complexity is not a real concern
• When you just need to start coding and domain context is already clear

Optional but high-leverage

Skipping 100 is fine when the domain is already well understood. But on unfamiliar or regulated domains, the research it produces often prevents costly architecture and scope decisions made against a wrong model of the world.

What it produces

• .specflow/context/domain-knowledge.md covering:
  • Market context and product category
  • Target user roles and their actual workflows
  • Competitor and substitute patterns
  • Regulatory or operational constraints
  • Differentiation opportunities
  • Domain terminology and key concepts with citations

Required inputs

1. Product concept — what is being built
2. Target domain or industry — what market or vertical
3. Target users — primary users or buyer roles
4. Known constraints — regulatory, geographic, compliance, or budget limits

Common prompts

Live internet research

This skill uses deep-research to fetch live content from the internet. It makes real web requests to research your domain, competitors, users, and market context — so the output is grounded in current sources rather than model memory alone.

Voice to text works great here

One of the fastest ways to seed this document is to use voice-to-text and just talk through what you are building. Describe the product idea, list features you are thinking about, name what you think makes it unique, and explain who you are building it for. You do not need to be organized — a brain dump is fine. The more raw context you can provide, the better the research will be focused. Spending time iterating on 100-domain-knowledge sets a strong foundation that makes every downstream workflow — architecture, data model, feature design, implementation — significantly easier to execute well.

Starting from scratch with a rough idea

Prompt

Run 100. I'm building [brief description]. The target users are [who], and the main problem I'm solving is [problem]. I don't have a lot of detail yet — help me research the domain and get a solid foundation.

Starting with a brain dump (recommended)

Prompt

Run 100-domain-knowledge. Here's everything I know about what I'm building — use this as your starting point and fill in the gaps with research:

[Paste or dictate your brain dump here. Include: what the product does, who it's for, what features you're thinking about, what makes it different, who the competitors are, any constraints or regulations you're aware of, and anything else that feels relevant. More is better.]

Researching a specific domain or industry vertical

Prompt

Run 100 for a product in the [industry/domain] space. The target users are [user roles]. I need to understand the workflows, terminology, regulatory environment, and what differentiates strong solutions in this space from generic ones.

Refreshing an existing document

Prompt

Run 100-domain-knowledge to refresh our existing domain research. We've been building for a few months and the market context may have shifted. Focus on updating competitor patterns, user expectations, and any new regulatory or operational constraints that have emerged.

Focused differentiation research

Prompt

Run 100. I know the domain reasonably well but I need sharper differentiation analysis. The main competitors we're watching are [list competitors]. Help me understand where we can actually win and what we must match even if we don't lead on it.

Lightweight draft without deep research

Prompt

Run 100-domain-knowledge but skip the deep-research step — I just need a draft structured from the context I'm providing now. I'll validate it against live research separately.

Context: [your domain description, user roles, known constraints, and differentiation ideas]

What usually comes next

101-project-overview — define what the product is and who it serves, using the domain research as grounding.

Practical guidance

• 100 normally delegates live web research to deep-research. The output is only as good as the research performed.
• Direct the research to answer the questions that will actually change design decisions — not generic background reading.
• If the project has an existing product overview, read it first so the research aligns with current framing rather than contradicting it.
• Treat the output as a living reference: update it when the domain understanding changes, not just at project start.

Common mistakes

• Treating the output as a marketing document instead of a decision-useful reference
• Researching generic industry background instead of specific user workflows and constraints
• Skipping this step and then discovering domain mismatches during feature design