codingthefuturewithai/teamcraft-jcg:discover-problem

Goal

Facilitate structured problem discovery with a client or stakeholder — the session that happens before requirements can be written. The PM is in a live conversation. The goal is not to document what the client already knows; it is to help the client discover what the real problem is, surface hidden assumptions, and narrow to a problem statement clear enough to become a PRD.

A well-run discovery session ends with: a sharp problem statement, identified root causes, competing hypotheses ranked by evidence, known gaps that need research before committing to a solution, and a clear recommendation on whether to proceed directly to requirements or validate further first.

Hard Constraints

• This skill facilitates a live session. Move at conversation pace — do not overwhelm the PM with questions to relay. Surface one thing at a time.
• Never start writing requirements during this session. If the PM or client jumps to solutions, acknowledge the idea, park it, and redirect to the problem.

Facilitate the Session

Start by asking the PM what situation they are walking into — who is in the room, what the client has said so far, and whether there are any existing documents to load as context. If they point to a Confluence page, load it with mcp__sooperset-mcp-atlassian__confluence_get_page.

Guide the discovery through the problem space. The depth and order follow the conversation, not a fixed script. What matters is reaching a clear problem statement:

Understand the pain — what is happening that should not be, or not happening that should be? Who experiences it and how often? What does it cost — in time, money, errors, missed opportunities?

Find the root — what causes the problem? Challenge surface symptoms. Ask why until the real driver emerges. If multiple causes exist, name them separately.

Surface competing hypotheses — what are the different ways this problem could be solved? Do not evaluate yet — list them. Include the client's initial ideas.

Assess what is known vs. assumed — for each hypothesis, what evidence supports it? What is being assumed? What would need to be true for this to be the right solution?

Identify gaps — what do we not know that we need to know before committing to a direction? Is more research needed, or is there enough to write requirements now?

Use Visuals When They Help

When a visual would make the problem clearer — a process flow, a data model, a user journey, a rough UI concept — generate it inline. Mermaid diagrams for flows and relationships. HTML artifacts for interactive UI concepts. Visuals are part of the session, not a separate step. Use them whenever a picture clarifies faster than words.

The frontend-design plugin, if installed, will automatically improve the quality of any HTML mockup generated during this session.

Discovery Summary

When the session reaches a natural stopping point, produce a discovery summary. See references/example-discovery-summary.md for the expected structure and depth.

Show the complete summary for review before storing. Confirm content with the PM.

Store in Confluence

Ask which Confluence space to store the discovery summary in. Use mcp__sooperset-mcp-atlassian__confluence_search to surface available spaces if the user doesn't know the space key. Once the space is confirmed, use mcp__sooperset-mcp-atlassian__confluence_get_page_children to browse its structure and recommend a parent page location based on what already exists. Confirm the location before creating with mcp__sooperset-mcp-atlassian__confluence_create_page.

Done

Share the Confluence page URL and page ID. If the problem is well-enough understood to write requirements, the natural next step is capture-requirements — point at this discovery summary as the primary input. If more research is needed first, say so explicitly and name what questions need answers before a PRD session makes sense.