plugins/teamcraft-glgd/skills/capture-requirements/SKILL.md
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.
npx skillsauth add codingthefuturewithai/claude-code-primitives teamcraft-glgd:capture-requirementsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
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).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.
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.
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 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.
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.
Share the Drive URL (or location, if stored elsewhere). Summarize what was captured and any open questions that need follow-up.
tools
Capture feedback about Teamcraft itself and turn it into a well-structured GitHub issue on the plugin's repo. Vets whether the problem is really a Teamcraft skill defect (vs. misuse, the harness, or the user's own project) by root-causing against the actual skill source, then helps the developer decide whether to file and publishes via the GitHub CLI. Use when the user says 'improve teamcraft', 'a teamcraft skill did the wrong thing', 'file feedback on teamcraft', 'report a teamcraft bug', 'I have an idea to make teamcraft better', or when a Teamcraft skill clearly misbehaved and the user wants that captured upstream.
tools
Learn the Teamcraft plugin itself — how its workflow, skills, and artifacts fit together. A guided overview for a human getting started, or a system map for Claude orienting itself to how Teamcraft works before working in a Teamcraft repo. Teaching only; needs no project or environment access. Use when someone wants to understand Teamcraft (the tool, not their specific project), asks "how does Teamcraft work", "explain the workflow", "which skill do I use for X", or when Claude needs the big picture of how the skills hook together.
tools
--- name: teamcraft:work-board description: Launch (or re-launch) the user's live, multi-project work board. The dashboard is a single HTML file copied to a stable user-side location at ~/.claude/teamcraft-board.html and opened in the user's default browser. It has two views via a header toggle — a drag-and-drop Kanban Board and a live Status tab (analytics: work by status, throughput, cycle time, aging, blocked chains, recomputed on every poll). Each project is added via a header dropdown; the
development
Run pre-PR reviews (code health, security, acceptance criteria), address findings, and submit the PR for review. Ends when the PR is ready and CI has passed. Use when implementation is done and ready for review, or when the user says "I'm done coding", "validate this", "ready for review", "submit this for review", "run the pre-PR reviews", or "prepare this for review".