zhenxuanshi-ship-it/skills/biz-discovery

Biz Discovery

Turn messy business input into a structured, decision-usable project brief.

This skill is the front-end of the business-doc workflow.

Use it before formal drafting when the user has:

• vague goals,
• mixed stakeholder input,
• scattered notes,
• unclear scope,
• incomplete assumptions.

Core rule

Do not over-formalize too early.

The goal is not to write the final document. The goal is to produce a clean intermediate artifact that makes writing easier and less fake.

Primary outputs

Choose the right combination based on the situation:

• project-brief.md
• scope-definition.md
• stakeholder-map.md
• requirements-seed.md
• risk-list.md
• open-questions.md
• recommended-next-doc.md

Main modes

1. brief

Use when the user wants a clean summary of a project idea.

Output:

• project background
• objective
• target audience/stakeholders
• scope
• constraints
• suggested next step

2. notes-to-brief

Use when the user provides meeting notes, raw bullets, or chat logs.

Output:

• structured brief
• extracted decisions
• unresolved questions
• action items

3. scope-clarification

Use when the problem is mainly boundary confusion.

Output:

• in-scope
• out-of-scope
• assumptions
• dependencies
• unresolved boundary items

4. requirements-seed

Use before PRD writing.

Output:

• goals
• user roles
• scenarios
• rough functional requirements
• rough non-functional requirements
• open product questions

5. proposal-intake

Use before project proposal / feasibility report writing.

Output:

• business context
• why now
• expected outcomes
• constraints
• initial options / direction
• risk prompts

Workflow

Step 1: classify the input material

Typical input types:

• meeting notes
• leadership message / high-level instruction
• rough idea description
• fragmented requirements
• chat screenshots copied as text
• old document excerpts

Use references/input-patterns.md if needed.

Step 2: find the real center of gravity

Identify:

• what problem is being solved
• for whom
• why now
• what success might look like
• what constraints are already present

Do not assume the loudest detail is the most important one.

Step 3: separate facts from assumptions from wishes

Always distinguish these three categories:

1. Known facts
2. Working assumptions
3. Open questions / unknowns

This separation is critical.

Step 4: define scope and stakeholders

At minimum, try to extract:

• target users / stakeholders
• owner / sponsor if known
• main business scope
• non-scope if inferable
• external dependencies

Step 5: recommend the next document type

Map the result into the next best document:

• feasibility-report
• project-proposal
• prd
• architecture-design
• implementation-plan

Use references/next-doc-mapping.md.

Output structure

Default output sections:

1. Project brief

Include:

• background
• objective
• target stakeholders
• expected outcomes

2. Scope snapshot

Include:

• in scope
• likely out of scope
• dependencies
• constraints

3. Assumptions and unknowns

Split clearly:

• known facts
• assumptions
• open questions

4. Risks / ambiguity points

List the biggest uncertainty sources.

5. Recommended next step

State:

• which document should be written next
• what information is still missing

When to ask questions

Ask concise questions only when they materially change the direction.

Good clarifying questions:

• “This is closer to a project proposal or a PRD. Which one do you want first?”
• “Is the primary goal approval, implementation, or requirement clarification?”
• “Who is the main audience: leadership, product team, or engineering team?”

Bad clarifying questions:

• long interviews up front
• asking for every detail before producing anything useful

Good discovery behavior

Good:

• compress messy input into structure
• expose ambiguity instead of hiding it
• preserve useful raw intent
• identify missing decision points

Bad:

• immediately writing polished formal prose
• inventing business context
• forcing certainty where none exists

References

Read when relevant:

• references/input-patterns.md — map messy input to discovery mode
• references/brief-structure.md — standard project brief structure
• references/next-doc-mapping.md — decide the next document type
• references/question-strategy.md — ask fewer, better clarification questions