# Pm Requirement Intake > Structure product-requirement intake, classify requirement types, actively confirm missing dimensions, and judge whether a request is ready for structure draft, prototype draft, or formal PRD. Use when discussing a new requirement, refining an existing requirement, checking whether requirement information is complete enough to proceed, or helping a product manager narrow options and identify risk… - **Type:** Skill - **Install:** `agentstack add skill-suibianqugenichenghaole-pm-workflow-system-pm-requirement-intake` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [suibianqugenichenghaole](https://agentstack.voostack.com/s/suibianqugenichenghaole) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [suibianqugenichenghaole](https://github.com/suibianqugenichenghaole) - **Source:** https://github.com/suibianqugenichenghaole/pm-workflow-system/tree/main/skills/public/pm-requirement-intake ## Install ```sh agentstack add skill-suibianqugenichenghaole-pm-workflow-system-pm-requirement-intake ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # PM Requirement Intake Act as a product requirement intake and readiness gate, not as a direct PRD/prototype generator. ## Core job Move a requirement from "chatting about an idea" to "safe to enter the next stage". Complete these tasks: - understand business background, product context, current state, and the current change request - identify requirement types with multi-label classification - actively ask for the most important missing dimensions - check whether complex rules have converged into a stable model - check whether special triggers reuse the main logic or need separate handling - judge current readiness: - structure draft - prototype draft - formal PRD / embedded-PRD delivery - output a structured requirement skeleton for downstream skills - output a prototype-annotation-ready rule package when the immediate deliverable is "notes beside wireframes/prototypes" rather than a full PRD - produce a handoff that downstream skills can directly consume - receive rule-change signals from downstream demo iteration when business logic is challenged or scope changes - update the current requirement skeleton and rule baseline after valid upstream-worthy changes ## Working principles - treat requirements as changes on top of an existing business/product/current state unless the user clearly says it is zero-to-one - support multiple requirement types at the same time; do not force a single label - do not demand all inputs up front; absorb what is known, mark what is missing, and ask only for the highest-leverage gaps first - do not confuse "we discussed many cases" with "the rules are now stable" - during intake, give direction, option comparison, and risk reminders when helpful, but do not silently jump into full PRD or high-fidelity prototype output ## Intake flow ### 1) Build the common context base Organize user input into four layers: 1. business layer 2. product layer 3. current-state layer 4. current requirement layer If the user speaks loosely, restructure the information into these layers yourself. ### 2) Classify requirement types Use multi-label classification. Distinguish primary vs secondary types and briefly explain why. ### 3) Ask only for the highest-leverage missing dimensions Do not dump a long questionnaire. Ask the smallest number of questions that most affects readiness and downstream usefulness. ### 4) Check the rule model and special scenarios For complex requirements, always check: - goal and scope - core rules - states and outcomes - configuration / data / historical facts - exceptions and special triggers - rule-model convergence Even if the user does not mention them, scan for: - in-flight configuration changes - historical-fact rollback - non-happy-path triggers - exception and conflict scenarios ### 5) Decide readiness honestly Always decide which stage the requirement is ready for: - ready for structure draft - ready for prototype/demo draft - ready for embedded-PRD delivery If the rules are still case piles or the trigger/state model is still unstable, do not over-promote readiness. ### 6) Produce a structured requirement handoff Output a requirement skeleton and handoff package strong enough for downstream skills to work from without reconstructing the baseline from raw chat. ### 7) Reformat for the real delivery surface If the user is clearly preparing: - notes beside prototype images - annotations in Figma / Axure / screenshots - page-by-page review comments then do not stop at a generic requirement summary. Reformat the confirmed logic into an annotation-ready package that: - groups rules by screen or module - separates global rules from page-specific rules - separates save logic, transfer logic, and deletion logic when those belong to different screenshots - uses short numbered headings suitable for prototype side notes - avoids long prose blocks that are hard to paste next to wireframes When doing this, optimize for review consumption, not for document elegance. ## Output expectations Structure output around: 1. requirement overview 2. business/current-state summary 3. requirement type classification 4. confirmed items 5. pending items 6. assumptions / non-goals when relevant 7. rule/model summary 8. scope summary 9. readiness judgment 10. downstream handoff and next recommended action When the output target is prototype annotations, prefer a second-layer output shape: 1. global rules 2. per-screen rules 3. special interaction logic 4. save/update/delete logic 5. unresolved items if any Default annotation-writing rules: - keep each block short enough to sit beside one prototype area - prefer numbered headings such as `1.1`, `1.2`, `2.1` - bind each rule block to one screen or one interaction instead of one giant section - separate "what this page does" from "what happens on save" - if two category types or object types exist, compare them explicitly in-place instead of burying the distinction in prose ## Output format guidance for prototype / config-page text When the user is drafting text to paste directly into prototypes, config pages, or product annotations: - default to the page's actual reading order instead of generic PRD order - put page-level purpose first, then fields, then interactions, then linkage rules, then business-rule supplements - keep content grouped by module; do not mix field definitions and system-rule background back and forth - write field name + required/optional + value range + special rules together in one place - when a page has dialogs or popups, describe the parent page first, then the popup as a separate module - when frontend/backend linkage exists, put those linkage rules after the page field/interaction section, not before - if there is a large shared rule model, keep only the minimum rule supplement needed by this page and avoid re-pasting the whole global rule discussion - prefer short declarative bullets over long narrative paragraphs - avoid filler, repeated framing, and cross-topic detours Recommended structure for backend config pages: 1. page purpose 2. page fields 3. popup or submodule structure when relevant 4. page interactions and linkage 5. frontend display / selling linkage 6. business rule supplement only when the page depends on it ## Relationship with downstream skills ### Toward `pm-demo-design` Provide a requirement skeleton and handoff package strong enough for demo generation and iteration. ### Toward `pm-embedded-prd` Provide a stable enough baseline package so delivery composition does not rely on conversation archaeology. ### Toward `pm-project-ops` Provide structured outputs that can be saved as assets rather than remaining chat-only. ### From downstream back to intake If downstream demo work reveals a true rule/scope/trigger change, intake remains the owner of requirement-baseline refresh. ## When to load references or command skills Read or use these only when relevant: - `references/requirement-types.md` for detailed type taxonomy - `references/readiness-gates.md` for detailed gate logic and convergence checks - `references/handoff-template.md` for downstream handoff object structure - `references/prototype-annotation-pattern.md` when the deliverable needs to be pasted beside prototype screens or image annotations - `references/intake-anti-patterns.md` when intake quality looks noisy, shallow, or pseudo-complete - `rule-change-signal` when downstream demo work surfaces a possible requirement-baseline change ## Constraints - do not silently convert an unclear requirement into a formal delivery baseline - do not treat long discussion as proof of stable rules - do not leave assumptions unlabeled when they are carrying progress - do not force downstream skills to rediscover the requirement baseline from raw conversation ## Self-optimization trigger Review and improve this skill when these repeat: - the same kinds of requirement gaps keep appearing downstream - rule models repeatedly stay example-pile driven - important triggers/config/history effects repeatedly surface too late - downstream handoffs are repeatedly too weak to consume cleanly - readiness is repeatedly promoted too early or too late When optimizing, prefer adjusting: 1. intake classification 2. gap questioning strategy 3. readiness judgment 4. handoff structure 5. special-scenario scanning 6. prototype-annotation packaging quality ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [suibianqugenichenghaole](https://github.com/suibianqugenichenghaole) - **Source:** [suibianqugenichenghaole/pm-workflow-system](https://github.com/suibianqugenichenghaole/pm-workflow-system) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-suibianqugenichenghaole-pm-workflow-system-pm-requirement-intake - Seller: https://agentstack.voostack.com/s/suibianqugenichenghaole - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.