discover-domain

name	discover-domain
description	Interactive interview to understand the domain, the target user, and the problem space. First skill to run — fills initial domain-input files.

/discover-domain - Domain Discovery Interview

When to Use

• First skill to run when starting a new OS design
• When the designer says "I want to build an OS for [domain]"
• When domain-input/ files are all empty

Process

This is an interactive conversation, not a batch operation. Ask questions one section at a time. Wait for answers before proceeding. Do NOT dump all questions at once.

Section 1: The Domain and the User

Ask these questions conversationally. Probe for specifics.

1. What domain is this OS for? (e.g., freelance consulting, real estate investing, academic research, content creation, sales, recruiting, personal health management)
2. Who is the target user? Not "anyone who does X." A specific person. What's their role? What's their experience level? What tools do they already use?
3. What problem does this OS solve? What's painful, slow, or error-prone today? What would change if this OS worked perfectly?
4. What does success look like? Not in abstract terms. What's the measurable outcome? (e.g., "land 3 clients per month," "publish 2 papers per year," "close 4 deals per quarter")

After the designer answers, summarize back to them in 2-3 sentences. Confirm you have it right before moving on.

Section 2: The Daily Reality

5. Walk me through a typical day. Monday morning to Friday evening. What does the user actually DO? Not what a textbook says they should do — what they actually spend time on.
6. Where do they waste time? What's repetitive? What could be automated but isn't? What requires 30 minutes but should take 5?
7. What requires human judgment? What parts of the work can't be automated? Where does the user's expertise actually matter?
8. What's the cadence? Is this daily work (like job search), weekly (like content creation), event-driven (like sales closing), or seasonal?

After the designer answers, say back: "So the system needs to handle [daily tasks], automate [automatable parts], and support judgment on [judgment parts]. The cadence is [cadence]."

Section 3: The Pipeline

9. What's the pipeline? Things move through stages in every domain. What are the stages? (e.g., prospect → qualified → proposal → negotiation → close)
10. What moves things forward? What action advances something from stage to stage?
11. Where do things die? At which stage do most things fail? Why?
12. What are healthy numbers? If the pipeline is working well, what do the conversion rates look like between stages?

Section 4: Quick Domain Knowledge Scan

13. What are the 3-5 key frameworks or methodologies in this domain? Named frameworks, scoring systems, evaluation methods that practitioners actually use.
14. What's the specialized vocabulary? What terms would an outsider not understand? What terms does the community use that mean something specific?
15. What reference data matters? Is there an equivalent to "company profiles" or "interview frameworks" — pre-built knowledge that makes the system faster?
16. What data goes stale? What information has a shelf life? How quickly does it expire?

Section 5: Who Else Is in the Picture

17. Who evaluates the user's output? Not just the end client/customer. Everyone who looks at what the user produces and forms a judgment. (e.g., for a consultant: the client, the partner reviewing the deck, the procurement team, the end-users who interact with the deliverable)
18. What does each evaluator care about most? In priority order.
19. Where do evaluator priorities conflict? (e.g., client wants fast; partner wants thorough)

Output

After the interview, write structured summaries to domain-input/ files:

1. Update domain-input/domain-workflow.md with Sections 2-3 answers (partial — /map-workflow will complete it)
2. Update domain-input/audiences.md with Section 5 answers (partial — /define-audiences will complete it)
3. Update domain-input/domain-knowledge.md with Section 4 answers (partial)
4. Update domain-input/identity-model.md with Section 1 answers (partial — /design-identity will complete it)

At the end, tell the designer:

Domain discovery complete. Here's what I captured:
- Domain: [X]
- Target user: [X]
- Core problem: [X]
- Pipeline: [stages]
- Key audiences: [list]

Next steps:
1. Run /map-workflow to detail the daily workflow and pipeline metrics
2. Run /define-audiences to deep-dive on each evaluator
3. Or run /build-scoring if you already know your evaluation frameworks

Quality Checks

Good discovery:

• Every answer includes a concrete example, not just an abstraction
• The pipeline has specific stages with names, not "it goes through several phases"
• The designer confirmed the summary matches their mental model
• At least one surprise emerged — something the factory wouldn't have guessed

Bad discovery:

• Designer gave textbook answers and the factory didn't probe deeper
• Pipeline stages are vague ("early stage," "middle stage," "late stage")
• No conflict identified between evaluator priorities
• The summary could apply to any domain