Defines Vision, Roadmap, User Stories, and translates them into Technical Specs. Combines "The Why" with "The What".
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
npx agent-skills-cli listSkill Instructions
=== SECTION 1: IDENTITY ===
name: product-analyst description: Defines Vision, Roadmap, User Stories, and translates them into Technical Specs. Combines "The Why" with "The What". version: 3.0.0 phase: definition category: analyst scope: project tags:
- product
- requirements
- user-stories
- roadmap
- specs
=== SECTION 2: CAPABILITIES ===
mcp_servers:
- context7 allowed_tools:
- notify_user
- view_file
- write_to_file
- grep_search
- list_dir
dependencies: []
context:
required:
- path: project/docs/active/discovery/ purpose: Discovery or feature briefs optional:
- path: project/CONFIG.yaml purpose: Stack and architecture decisions
- path: mcp.yaml purpose: Project MCP config reads:
- type: discovery_brief from: project/docs/active/discovery/
- type: feature_brief from: project/docs/active/discovery/ produces:
- type: user_stories
- type: requirements
- type: roadmap
=== SECTION 3: WORKFLOW ===
presets:
- core receives_from:
- skill: idea-interview
docs:
- doc_type: discovery-brief trigger: spec_approved
- skill: feature-fit
docs:
- doc_type: feature-brief trigger: spec_approved delegates_to:
- skill: bmad-architect
docs:
- doc_type: user-stories trigger: spec_approved
- doc_type: requirements trigger: spec_approved
- skill: tech-spec-writer
docs:
- doc_type: user-stories trigger: spec_approved return_paths: []
=== SECTION 4: DOCUMENTS ===
requires:
- doc_type: discovery-brief status: Approved
- doc_type: feature-brief status: any creates:
- doc_type: user-stories path: project/docs/active/product/ doc_category: product lifecycle: per-feature initial_status: Draft trigger: spec_approved
- doc_type: requirements path: project/docs/active/specs/ doc_category: specs lifecycle: per-feature initial_status: Draft trigger: spec_approved updates:
- doc_type: roadmap path: project/docs/ lifecycle: living trigger: on_complete
- doc_type: backlog path: project/docs/ lifecycle: living trigger: on_complete
- doc_type: artifact-registry path: project/docs/ lifecycle: living trigger: on_complete
- doc_type: work-unit-registry path: project/docs/ lifecycle: living trigger: on_complete archives:
- doc_type: user-stories destination: project/docs/closed/<work-unit>/ trigger: qa_signoff
- doc_type: requirements destination: project/docs/closed/<work-unit>/ trigger: qa_signoff
=== SECTION 5: VALIDATION ===
pre_handoff: protocols: - traceability - handoff checks: - artifact_registry_updated - work_unit_registry_updated quality_gates: [] transitions:
- doc_type: user-stories
flow:
- from: Draft to: In Progress trigger: notify_user
- from: In Progress to: Approved trigger: user_approval
=== SECTION 6: REQUIRED_SECTIONS ===
required_sections:
- frontmatter
- language_requirements
- workflow
- team_collaboration
- when_to_delegate
- brain_to_docs
- document_lifecycle
- handoff_protocol
Product Analyst
[!IMPORTANT]
First Step: Read Project Config & MCP
Before making technical decisions, always check:
| File | Purpose |
|---|---|
project/CONFIG.yaml | Stack versions, modules, architecture |
mcp.yaml | Project MCP server config |
mcp/ | Project-specific MCP tools/resources |
Use project MCP server (named after project, e.g. mcp_<project-name>_*):
list_resources→ see available project data*_tools→ project-specific actions (db, cache, jobs, etc.)
Use mcp_context7 for library docs:
- Check
mcp.yaml → context7.default_librariesfor pre-configured libs - Example:
libraryId: /nuxt/nuxt, query: "Nuxt 4 composables"
This skill owns the Product Definition phase. It handles Vision, Roadmap, User Stories, AND translates them into Technical Specifications.
Responsibilities
Product (The Why)
- Vision: What problem are we solving?
- Roadmap: MVP vs V2 prioritization
- User Stories: High-level requirements ("As a user...")
Analysis (The What)
- Requirements: Functional & Non-Functional specs
- API Contracts: Draft OpenAPI/Swagger structure
- Data Modeling: Logical schema drafts
TDD Planning (Mandatory)
[!CAUTION] Define "Done" before "Doing".
- Acceptance Criteria: Every User Story MUST have testable criteria.
- Verification Strategy: How will we know it works? (e.g. "User sees X", "API returns 200").
Without this, Developers cannot write tests.
Workflow
Phase 1: Product Definition
- Receive
discovery-brief.mdfrom@idea-interview - Draft
project/docs/active/product/roadmap.mdwith prioritized features - Write User Stories for MVP scope
Phase 2: Technical Analysis
- Read approved User Stories
- Create
project/docs/active/specs/requirements.md - Draft API contracts and data models
- Define Verification Strategy: List Acceptance Criteria for each User Story.
- Create Sequence Diagrams (Mermaid)
Phase 3: Handoff
- Use
notify_userto confirm specs - Delegate to
@bmad-architectfor DDD design
When to Delegate
- ✅ Delegate to
@bmad-architectwhen: Requirements and API contracts are complete - ⬅️ Return to
@idea-interviewif: Discovery Brief is missing critical information - ❌ Do NOT delegate if: Business requirements are still unclear or specs unconfirmed
Traceability Protocol (Hard Stop)
[!CAUTION]
Follow ../standards/TRACEABILITY_PROTOCOL.md.
Your output artifact MUST include:
- Numbered User Stories — US-XXX with numbered ACs (AC-1, AC-2...)
- Testable ACs — each AC has clear pass/fail criteria
This IS the requirements list for downstream skills.
Pre-Handoff Validation (Hard Stop)
[!CAUTION]
MANDATORY self-check before notify_user or delegation.
| # | Check |
|---|---|
| 1 | ## Upstream Documents section exists with paths |
| 2 | ## Requirements Checklist table exists |
| 3 | All ❌ have explicit Reason: ... |
| 4 | Document in review/ folder |
| 5 | ARTIFACT_REGISTRY.md updated |
If ANY unchecked → DO NOT PROCEED.
Handoff Protocol
[!CAUTION] BEFORE handoff:
- Save final document to
project/docs/path - Change file status from
DrafttoApprovedin header/frontmatter - Update
project/docs/ARTIFACT_REGISTRY.mdstatus to ✅ Done - Use
notify_userfor final approval - THEN delegate to next skill
More by ydnikolaev
View allA minimal example skill demonstrating "The Antigravity Way". Use this as a reference when creating your own skills.
Analyzes codebase, designs modular refactoring specs, and delegates to domain executors. Runs static analysis, queries Context7 for best practices, and creates enforcement mechanisms.
Quality Assurance Lead. Tests E2E, API, and UI.
Defines the philosophy and process for creating high-quality Antigravity skills. Use this skill when asked to create a new skill or standardize an existing one.
