codingthefuturewithai/teamcraft-glgd: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.
• If a Drive file operation fails with a path error, read the error message to identify a valid accessible host path and retry with it.

Resolve Drive Account

Call mcp__google-drive__list_accounts before any other Drive operation:

• No accounts — Drive is not configured. Tell the user and skip Drive operations — the discovery summary can be shared as session output instead.
• One account — Use it. Pass account_email explicitly on every Drive tool call this session.
• Multiple accounts — Present the list, ask which account to use for this session.

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.

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.

Ask the user where in Google Drive to store it — which folder. Never save to the Drive root. Do not search Drive for a location; ask directly. Record the URL.

Done

Share the Drive URL. 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.