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?
17. Does the system produce deliverables beyond text? PDFs, reports, spreadsheets, images? What format does each audience expect?
18. Does the system need to process things at scale? Batch operations, parallel processing, scanning multiple targets?
19. Does the system ingest external data? From what sources? How fresh does the data need to be?

Section 5: Historical Work and Backtesting

20. Does the target user have examples of past work they've done manually? Work that this OS will also produce — resumes, proposals, reports, designs, analyses, deliverables. Things they've actually delivered, not templates.
21. Can the input and output be separated? For each type of past work: did the user start with a clear brief/prompt/request (the input), and produce a distinct deliverable (the output)? Or are input and output interleaved in one document?
22. How many past examples might the user realistically have? Per type. 3-5? 10-20? 50+? Don't overestimate — be realistic about what people actually save.
23. What makes a historical example "good"? Is there a measurable outcome (it got an interview, the client accepted it, it was published)? Or is it expert judgment (the user considers it their best work)?
24. Would recent examples or best examples be more valuable for calibration? Has the user's style evolved over time (favor recent), or are their best results spread across time (favor importance/outcome ordering)?

After the designer answers, say back: "So the backtesting library should focus on [artifact types], with [N] cases minimum, ordered by [date/importance/outcome]. The user [can/cannot] easily separate input from output. [If cannot: We'll support manual separation in v2.0 and add automatic separation in v3.0.]"

If the designer says users don't have historical examples, note that backtesting is not applicable for this OS.

Section 6: Who Else Is in the Picture

25. 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)
26. What does each evaluator care about most? In priority order.
27. 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 6 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)
5. Update domain-input/data-contract.md with initial ownership hints if relevant (partial — /design-data-contract will complete it)
6. Update domain-input/artifact-pipeline.md if deliverables mentioned (partial — /design-artifact-pipeline will complete it)
7. Update domain-input/data-sources.md if external data mentioned (partial — /design-data-sources will complete it)
8. Update domain-input/backtesting-library.md with Section 5 answers if historical work exists (partial — /design-backtesting 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]

Backtesting: [applicable — N artifact types identified / not applicable]

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. Run /design-backtesting if historical work examples are available
4. 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