AgentSkillsCN

business-to-requirements

将商业想法、问题与对话转化为结构化的技术需求。当用户希望 (1) 从模糊的想法或功能需求中创建 PRD，(2) 从商业问题中提炼技术需求，(3) 通过迭代式对话正式化需求，或 (4) 从商业需求中创建用户故事与验收标准时，使用此技能。可通过“帮我写需求”、“为……创建 PRD”、“规格应该包含什么”等请求，或在关于新功能/产品的讨论中触发。

SKILL.md
--- frontmatter
name: business-to-requirements
description: Transform business ideas, problems, and conversations into structured technical requirements. Use this skill when users want to (1) create a PRD from a vague idea or feature request, (2) derive technical requirements from a business problem, (3) formalize requirements through iterative conversation, or (4) create user stories and acceptance criteria from business needs. Triggers on requests like "help me write requirements", "create a PRD for...", "what should the spec include", or discussions about new features/products.

Business to Requirements

Transform vague business ideas into actionable technical specifications through structured elicitation and documentation.

Workflow Decision Tree

Determine the starting point:

  1. •

    Idea → PRD: User has a feature/product idea

    • •Elicit requirements through questions
    • •Output: Complete PRD document
  2. •

    Problem → Solution Requirements: User describes a business problem

    • •Understand the problem deeply first
    • •Derive solution requirements
    • •Output: Requirements with rationale
  3. •

    Conversation → Spec: User wants to discuss and refine

    • •Iterative Q&A to clarify
    • •Build spec incrementally
    • •Output: Formalized specification

Core Process

Step 1: Understand Context

Ask targeted questions to understand:

  • •Problem: What problem are we solving? Who has this problem?
  • •Users: Who are the primary/secondary users?
  • •Success: How will we measure success?
  • •Constraints: Timeline, budget, technical limitations?

See requirements_elicitation.md for comprehensive question templates.

Step 2: Clarify Ambiguity

Surface and resolve:

  • •Vague requirements → Specific, measurable criteria
  • •Implicit assumptions → Explicit decisions
  • •Conflicting needs → Prioritized trade-offs
  • •Edge cases → Defined behaviors

Step 3: Structure Requirements

Organize into:

  • •User Stories: As a [user], I want [goal], so that [benefit]
  • •Functional Requirements: What the system must do (P0/P1/P2)
  • •Non-Functional Requirements: Performance, security, scalability
  • •Acceptance Criteria: Given/When/Then or checklist format

See user_stories.md for format and examples.

Step 4: Document

Output in requested format:

  • •PRD: Full product requirements document
  • •User Stories: Story-focused format
  • •Technical Spec: Implementation-focused

See prd_guide.md for PRD structure and examples.

Quick Reference

User Story Format

code
As a [persona],
I want [goal],
So that [benefit].

Acceptance Criteria:
- Given [context], when [action], then [outcome]

Priority Levels

LevelMeaningGuideline
P0Must HaveLaunch blocked without this
P1Should HaveImportant, target v1.1
P2Nice to HaveBacklog for future

Requirement Quality Checklist

  • • Specific (not vague)
  • • Measurable (has success criteria)
  • • Achievable (technically feasible)
  • • Relevant (ties to business goal)
  • • Testable (has acceptance criteria)

Example Interaction

User: I want to add notifications to our app

Response approach:

  1. •Clarify: What triggers notifications? Push/email/in-app?
  2. •Users: Who receives them? Can users configure preferences?
  3. •Content: What information in each notification?
  4. •Timing: Real-time or batched? Quiet hours?
  5. •Edge cases: What if user has notifications disabled?

Then structure findings into user stories with acceptance criteria.

References