From bee-pm-team
Gate 2: Feature relationship map - visualizes feature landscape, groupings, and interactions at business level before technical architecture.
npx claudepluginhub luanrodrigues/ia-frmwrk --plugin bee-pm-teamThis skill uses the workspace's default tool permissions.
**Feature relationships and boundaries must be mapped before architectural decisions.**
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Feature relationships and boundaries must be mapped before architectural decisions.
Jumping from PRD to TRD without mapping creates:
The Feature Map answers: How do features relate, group, and interact at a business level? The Feature Map never answers: How we'll technically implement those features (that's TRD).
| Phase | Activities |
|---|---|
| 1. Feature Analysis | Load approved PRD (Gate 1) and ux-criteria.md; extract all features; identify user journeys; map feature interactions and dependencies |
| 2. Feature Mapping | Categorize (Core/Supporting/Enhancement/Integration); group into domains; map user journeys; identify integration points; define boundaries; visualize relationships; prioritize by value |
| 3. Gate 2 Validation | All PRD features mapped; categories defined; domains logical; journeys complete; integration points identified; boundaries clear; priorities support phased delivery; no technical details |
| 4. UX Design | Dispatch product-designer to create detailed user flows (Mermaid) and wireframe specifications (YAML) |
Feature list (from PRD), categories (Core/Supporting/Enhancement/Integration), domain groupings (business areas), user journey maps, feature interactions, integration points, feature boundaries, priority levels, scope visualization
Technical architecture/components, technology choices/frameworks, database schemas/API specs, implementation approaches, infrastructure/deployment, code structure, protocols/data formats
| Excuse | Reality |
|---|---|
| "Feature relationships are obvious" | Obvious to you ≠ documented for team. Map them. |
| "We can figure out groupings during TRD" | TRD architecture follows feature structure. Define it first. |
| "This feels like extra work" | Skipping this causes rework when architecture mismatches features. |
| "The PRD already has this info" | PRD lists features; map shows relationships. Different views. |
| "I'll just mention the components" | Components are technical (TRD). This is business groupings only. |
| "User journeys are in the PRD" | PRD has stories; map shows cross-feature flows. Different levels. |
| "Integration points are technical" | Points WHERE features interact = business. HOW = technical (TRD). |
| "Priorities can be set later" | Priority affects architecture decisions. Set them before TRD. |
| "Boundaries will be clear in code" | Code structure follows feature boundaries. Define them first. |
| "This is just a simple feature" | Even simple features have interactions. Map them. |
If you catch yourself writing any of these in a Feature Map, STOP:
When you catch yourself: Remove the technical detail. Focus on WHAT features do and HOW they relate at a business level.
| Category | Requirements |
|---|---|
| Feature Completeness | All PRD features included; clear descriptions; categories assigned; none missing |
| Grouping Clarity | Domains logically cohesive; clear boundaries; cross-domain deps minimized; business function names |
| Journey Mapping | Primary journeys documented (start to finish); features touched shown; happy/error paths; handoffs identified |
| Integration Points | All interactions identified; data/event exchange points marked; directional deps clear; circular deps resolved |
| Priority & Phasing | MVP features identified; rationale documented; incremental value delivery; deps don't block MVP |
Gate Result: ✅ PASS → UX Design → TRD | ⚠️ CONDITIONAL (clarify boundaries) | ❌ FAIL (poor groupings/missing features)
After Feature Map passes Gate 2 validation, dispatch product-designer for UX design:
Task(
subagent_type="bee:product-designer",
model="opus",
prompt="Create detailed UX design based on PRD, ux-criteria.md, and feature-map.md at docs/pre-dev/{feature}/. Mode: ux-design. Create: user-flows.md with Mermaid diagrams for all user journeys (happy path, error paths, edge cases), wireframes/ directory with YAML specs for all screens, UI state documentation for all interactive elements."
)
UX Design Outputs:
docs/pre-dev/{feature}/user-flows.md - Detailed user flows with Mermaid diagramsdocs/pre-dev/{feature}/wireframes/ - Directory with YAML wireframe specs per screenUX Design Checklist:
| Check | Required |
|---|---|
| All user journeys from feature-map have flows | Yes |
| Happy path documented for each flow | Yes |
| Error paths documented for each flow | Yes |
| Edge cases identified and documented | Yes |
| Wireframe spec for each unique screen | Yes |
| All UI states defined (loading, error, empty, success) | Yes |
| Responsive behavior documented | Yes |
| Accessibility requirements in specs | Yes |
If UX Design fails:
Note: This phase is for Large Track only (2+ day features). Small Track skips to TRD directly.
Output to docs/pre-dev/{feature-name}/feature-map.md with these sections:
| Section | Content |
|---|---|
| Overview | PRD reference, status, last updated |
| Feature Inventory | Tables by category (Core/Supporting/Enhancement/Integration): Feature ID, Name, Description, User Value, Dependencies |
| Domain Groupings | Per domain: Purpose, Features list, Boundaries (Owns/Consumes/Provides), Integration Points (→/←) |
| User Journeys | Per journey: User Type, Goal, Path (steps with features, integrations, success/failure), Cross-Domain Interactions |
| Feature Interaction Map | ASCII/text diagram with relationships, Dependency Matrix table (Feature, Depends On, Blocks, Optional) |
| Backend Integration Points | (Fullstack only) API dependencies per feature, data flow direction, BFF requirements |
| Phasing Strategy | Per phase: Goal, Timeline, Features, User Value, Success Criteria, Triggers for next phase |
| Scope Boundaries | In Scope, Out of Scope (with rationale), Assumptions, Constraints |
| Risk Assessment | Feature Complexity Risks table, Integration Risks table |
| Gate 2 Validation | Date, validator, checklist, approval, next step |
⛔ MANDATORY: If topology.scope: fullstack, this section MUST be included.
Check research.md frontmatter:
topology:
scope: fullstack # ← This triggers backend integration documentation
Add to feature-map.md under ## Backend Integration Points:
## Backend Integration Points
### Overview
- **Topology:** Fullstack
- **API Pattern:** [direct | bff]
- **Backend Services:** List of backend services this feature depends on
### Per-Feature API Dependencies
| Feature | Backend Dependency | Data Direction | Notes |
|---------|-------------------|----------------|-------|
| F-001: User Dashboard | User Service | Read | Profile data |
| F-001: User Dashboard | Order Service | Read | Recent orders |
| F-002: Create Order | Order Service | Write | New order |
| F-002: Create Order | Inventory Service | Read | Stock check |
### Data Flow Summary
| Frontend Component | → | BFF/API | → | Backend Service |
|-------------------|---|---------|---|-----------------|
| DashboardPage | → | /api/dashboard | → | User + Order Services |
| OrderForm | → | /api/orders | → | Order + Inventory Services |
### BFF Requirements Matrix
| Feature | Needs BFF? | Reason |
|---------|-----------|--------|
| F-001 | Yes | Aggregates 2 services |
| F-002 | Yes | Needs inventory validation |
| F-003 | No | Single service, simple read |
Document risks related to backend dependencies:
### Integration Risks
| Feature | Backend Dependency | Risk | Mitigation |
|---------|-------------------|------|------------|
| F-001 | Order Service | Service unavailable | Graceful degradation |
| F-002 | Inventory Service | Stale stock data | Real-time check before submit |
| Excuse | Reality |
|---|---|
| "Backend integration is TRD concern" | TRD designs architecture. Feature Map identifies integration POINTS. Different scope. |
| "We'll figure out APIs during implementation" | Late API discovery causes frontend/backend misalignment. Document early. |
| "Feature Map is business only" | Integration points are business-level data flows. WHERE data comes from matters. |
| "API pattern is already in research.md" | Pattern is high-level. Feature Map documents per-feature specifics. |
| Violation | Wrong | Correct |
|---|---|---|
| Tech in Features | F-001: JWT-based auth with PostgreSQL sessions, Deps: Database, Redis cache | F-001: Users can create accounts and log in, User Value: Access personalized features, Deps: None (foundational), Blocks: F-002, F-003 |
| Tech in Domains | Domain: Auth Services with AuthService, TokenValidator, SessionManager components | Domain: User Identity - Purpose: Managing user accounts and sessions. Features: Registration, Login, Session Mgmt, Password Recovery. Owns: credentials, session state. Provides: identity verification |
| Tech in Integration | User Auth → Profile: REST API call to /api/profile with JWT | User Auth → Profile: Provides verified user identity |
| Factor | Points | Criteria |
|---|---|---|
| Feature Coverage | 0-25 | All mapped: 25, Most: 15, Some missing: 5 |
| Relationship Clarity | 0-25 | All documented: 25, Most clear: 15, Unclear: 5 |
| Domain Cohesion | 0-25 | Logically cohesive: 25, Mostly: 15, Poor boundaries: 5 |
| Journey Completeness | 0-25 | All paths: 25, Primary: 15, Incomplete: 5 |
Action: 80+ proceed to TRD | 50-79 address gaps | <50 rework groupings
Outputs:
docs/pre-dev/{feature-name}/feature-map.md - Feature relationship mapdocs/pre-dev/{feature-name}/user-flows.md - Detailed user flows (from product-designer, Large Track only)docs/pre-dev/{feature-name}/wireframes/ - Wireframe specifications (from product-designer, Large Track only)If you wrote a Feature Map with technical architecture details, remove them.
The Feature Map is business-level feature relationships only. Period. No components. No APIs. No databases.
Technical architecture goes in TRD. That's the next phase. Wait for it.
Map the features. Understand relationships. Then architect in TRD.
This skill is a business analysis skill and does NOT require WebFetch of language-specific standards.
Purpose: Feature Map defines business-level feature relationships and groupings. Technical standards are irrelevant at this stage—they apply during TRD (Gate 3) and implementation.
However, MUST load PRD (Gate 1) and ux-criteria.md to ensure feature map aligns with validated business requirements.
| Condition | Action | Severity |
|---|---|---|
| PRD (Gate 1) not validated | STOP and complete Gate 1 first | CRITICAL |
| Technical architecture creeps into map | STOP and remove—keep business level only | HIGH |
| Feature domains have unclear boundaries | STOP and clarify domain ownership | HIGH |
| User journeys cross all domains (no cohesion) | STOP and re-evaluate domain groupings | MEDIUM |
| Backend integration points undefined (fullstack) | STOP and document API dependencies | HIGH |
| Circular feature dependencies detected | STOP and resolve dependency cycle | HIGH |
These requirements are NON-NEGOTIABLE:
| Severity | Definition | Example |
|---|---|---|
| CRITICAL | Cannot proceed with mapping | PRD not validated, no features to map |
| HIGH | Map contains forbidden content | Technical components, API specs |
| MEDIUM | Map incomplete but usable | Some journeys not fully documented |
| LOW | Minor documentation gaps | Integration point descriptions brief |
| User Says | Your Response |
|---|---|
| "Include the component architecture" | "Cannot include components. Feature Map is business-level only. Components go in TRD." |
| "Feature relationships are obvious" | "Cannot assume obvious. Obvious to you ≠ documented for team. I'll map explicitly." |
| "Skip UX Design, we have wireframes" | "Cannot skip UX Design for Large Track. Wireframes need detailed flows and states. I'll dispatch product-designer." |
| "Mention the API dependencies" | "Cannot include API specifics. Document business-level integration points only. 'Feature A uses data from Feature B'." |
| "This feels like extra work" | "Cannot skip mapping. Skipping causes architecture-feature mismatch. 30 minutes now saves days of rework." |
| Rationalization | Why It's WRONG | Required Action |
|---|---|---|
| "Feature relationships are obvious" | Obvious to you ≠ documented for team | Map explicitly |
| "We can figure out groupings during TRD" | TRD architecture follows feature structure | Define groupings first |
| "This feels like extra work" | Skipping causes rework when architecture mismatches features | Complete the mapping |
| "PRD already has this info" | PRD lists features; map shows relationships | Different views, both needed |
| "I'll just mention the components" | Components are technical (TRD territory) | Keep business groupings only |
| "User journeys are in the PRD" | PRD has stories; map shows cross-feature flows | Different levels |
| "Integration points are technical" | WHERE features interact = business. HOW = technical | Document integration points |