teamcraft-glgd:capture-requirements

---
name: teamcraft-glgd:capture-requirements
description: Live requirements capture session with a client — interview, generate visual mockups and diagrams to confirm understanding, then produce or update a structured PRD. Use when a BA or product owner wants to run a requirements session, capture client needs visually, create a PRD from a client conversation, or update an existing PRD with new requirements. Works for any application type, first sessions and follow-ups.
argument-hint: "[Drive file ID/URL of existing PRD — optional]"
disable-model-invocation: true
user-invocable: true
allowed-tools:
  - mcp__google-drive__list_accounts
  - mcp__google-drive__search_files
  - mcp__google-drive__download_file
  - mcp__google-drive__create_file
  - mcp__google-drive__update_file
---

## Goal

Facilitate a live requirements session between a BA and their client. Confirm understanding through visualizations the client can see and react to — because reviewing a mockup together is far more effective than agreeing on words. Each visualization the client approves becomes concrete requirements in a structured PRD. The client decides what gets visualized and when — propose visuals, don't generate them unasked, because a visualization the client didn't request doesn't confirm anything.

Output is a structured PRD — new or updated — that downstream agents can act on without ambiguity.

## Hard Constraints

- 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.
- The PRD describes WHAT and WHY. Never HOW. Technology choices belong in a separate tech decisions session. Redirect if raised.
- HTML mockups must be fully self-contained. Never use anchor tags with `href` for navigation — Cowork's preview pane treats them as external navigation and leaves the session. Use JavaScript click handlers for all interactivity (scrolling, section toggling, tab switching).

## Understand the PRD Standard First

Before any client interaction, read `references/example-prd.md`. This is the complete standard for the PRD you will produce. Understand every section — you need to know what the final document requires so you can gather information for all of them during the session.

## Establish Intent

Understand what the user is here for before starting anything else. Are they starting a brand new project? Continuing a previous session? Do they already have material — requirements docs, sketches, spreadsheets, notes from stakeholder meetings? The material could be anywhere: in Google Drive, on their local machine, typed from memory, an uploaded image, or a combination of sources.

If they have existing material, ask how they want to provide it. If they point to Google Drive, resolve the Drive account at that point — call `mcp__google-drive__list_accounts`, and if multiple accounts exist, ask which one. If they provide material another way, work with what they give you.

If `$ARGUMENTS` contains a Drive URL or file ID, that's an existing PRD — load it and summarize its current state so the client has context.

## Capture Requirements Visually

As the client describes what they want, propose creating interactive visualizations to confirm understanding — UI mockups, workflow diagrams, navigation structures, data models, user journey maps, or whatever fits the concept being discussed. Explain briefly why: it's far easier to confirm requirements when you can see and interact with them together. If the `frontend-design` skill is available, use it for generating higher-fidelity mockups.

Visualizations should be interactive where appropriate: clickable navigation, working form elements, expandable sections, hover states, tab switching. Every confirmed visual maps to concrete requirements with acceptance criteria in the PRD. Iterate until the client confirms each visualization before moving on.

Surface gaps proactively — areas the client hasn't mentioned that a complete product would need. Ask, don't assume.

## Produce the PRD

Produce the PRD following the standard you read at the start. Attempt to include every section unless the user directs otherwise. Include a companion artifacts section that lists every approved visualization by name — someone reading the PRD should know what supporting materials exist and where to find them.

For follow-up sessions: integrate new requirements into the existing PRD. Summarize what changed — new sections, modified requirements, removed scope — before finalizing.

## Review and Store

Show the complete PRD for review. Do not store until the user confirms.

Google Drive is the default storage location. Ask where in Drive to store it. Upload the PRD and all approved visualizations to the same folder — the PRD references them by name, so they should live together. For follow-up sessions, update the existing file unless the user wants a new version. If the user wants to store it somewhere else, do that instead.

## Done

Share the Drive URL (or location, if stored elsewhere). Summarize what was captured and any open questions that need follow-up.