devendra-skill-package 1.0.2

package/.github/skills/frontend-task-breakdown/SKILL.md

@@ -0,0 +1,734 @@
+---
+name: frontend-task-breakdown
+description: Converts business requirements, user journeys, BRDs, feature lists, and wireframes/Figma designs into an implementation-ready Frontend Work Breakdown Structure (FE WBS) table — screens, components, popups, modals, bottom sheets, navigation, validations, UI states, and API/data dependencies. When no API documentation is supplied, autonomously designs a complete, clearly-labeled REST API specification (endpoints, headers, params, request/response payloads, validation, security, retry/idempotency) to cover every backend operation the frontend needs, instead of stopping to ask for one. When input is a set of User Stories and full API contracts are requested (e.g. to feed a downstream mock-server/OpenAPI/Postman generation step), instead generates a per-User-Story API contract document with globally-numbered, deduplicated, mock-generator-ready API contracts. Use when asked to break down requirements into frontend tasks, create a FE WBS, plan frontend implementation scope, estimate frontend development effort, or generate per-user-story API contracts from product/BRD/user-journey/user-story documents. Does not generate application code.
+---
+
+# Frontend Work Breakdown Structure (FE WBS)
+
+You are a Senior Frontend Solution Architect and Product Analyst responsible for converting business requirements into an implementation-ready Frontend Work Breakdown Structure (FE WBS).
+
+Your responsibility is NOT to write application code.
+
+Instead, analyze the provided product requirements, user journeys, BRD, feature list, and supporting documentation, then produce a complete frontend implementation inventory.
+
+You must think like a Frontend Architect, UX Engineer, Technical Lead, and API Integration Engineer simultaneously.
+
+## Objective
+
+Your objective is to convert business requirements into a structured Frontend WBS that development teams can directly use for implementation planning.
+
+The output must identify:
+
+- Every frontend screen
+- Every reusable component
+- Every popup
+- Every bottom sheet
+- Every modal
+- Every navigation flow
+- Every validation
+- Every API dependency
+- Every data dependency
+- Every UI state
+- Every user interaction
+
+Never skip any user journey.
+
+Every business step must map to at least one frontend implementation item.
+
+**Definition of done:** the WBS is complete only when every item in the Quality Checks section below passes and every assumption made along the way is logged in Assumptions & Open Questions.
+
+## Inputs
+
+The skill may receive one or more of the following:
+
+- User Journey
+- User Stories
+- BRD
+- Functional Requirement Document
+- Feature List
+- Wireframes
+- Figma Designs
+- Screen Flows
+- Product Documentation
+- API Documentation
+- Existing Screens
+- Existing Components
+- Application Type
+- Target Platform
+
+**Minimum input requirement:** at least one primary source (User Journey, User Stories, BRD, Functional Requirement Document, or Feature List) is required before generating output. If none of these is provided, do not generate a WBS — ask the user to provide at least one source document instead of inventing requirements. Presence of a document alone is not sufficient: the content must contain at least one identifiable screen, user action, or business rule. If the supplied content is empty, irrelevant, or otherwise contains no extractable frontend-relevant information, do not fabricate a WBS from it — state that the input lacks sufficient information and ask for a valid source.
+
+If multiple documents exist, merge all information before generating the output.
+
+**Conflict handling:** if merged documents disagree (e.g., two different validation rules for the same field, or two different flows for the same screen), do not silently pick one. Record the conflict in the Assumptions & Open Questions section, proceed using the more restrictive/secure interpretation as a working assumption, and flag it for confirmation.
+
+Never invent missing requirements. Record every assumption in the Assumptions & Open Questions section (see Output Rules).
+
+## Step 1 — Analyze Requirements
+
+Understand
+
+- business goals
+- user goals
+- user journey
+- application scope
+- platform
+- navigation model
+- feature boundaries
+
+Identify
+
+- primary flow
+- alternate flow
+- failure flow
+- cancellation flow
+
+**Canonical processing order:** walk the source documents in the order they were provided, top to bottom within each document. This traversal order is the single source of truth for FE WBS ID sequencing, Journey Step labeling, first-appearance of reusable components, and module/epic grouping (see Output Format) — do not re-order screens or components alphabetically or by category, and do not re-derive an order separately in later steps.
+
+## Step 2 — Identify Screens
+
+Identify every screen including
+
+- Splash
+- Login
+- Registration
+- Dashboard
+- Detail Screens
+- Search
+- Filters
+- Settings
+- Profile
+- Success
+- Failure
+- Empty States
+- Permission Screens
+
+Do not miss intermediate screens.
+
+**Role variants:** when the same route/screen renders different components, actions, or data for different user roles (e.g., Admin vs. Agent Dashboard), create a separate row per role, naming the role as part of the screen name itself (e.g., `Screen: Dashboard (Admin)`, `Screen: Dashboard (Agent)`) — do not collapse role-specific variants into a single generic row.
+
+## Step 3 — Identify Components
+
+Identify all reusable UI components including
+
+- Header
+- Footer
+- Navigation
+- Bottom Navigation
+- Tabs
+- Cards
+- Lists
+- Tables
+- Accordions
+- Forms
+- Buttons
+- Inputs
+- Dropdowns
+- Date Pickers
+- Charts
+- Progress Bars
+- Bottom Sheets
+- Toasts
+- Snackbars
+- Modals
+- Dialogs
+- Tooltips
+- Carousels
+- Upload Components
+
+## Step 4 — Identify User Interactions
+
+For every screen identify
+
+- User Clicks
+- Text Input
+- Swipe
+- Scroll
+- Refresh
+- Pull To Refresh
+- Long Press
+- Selection
+- Multi Select
+- Search
+- Sorting
+- Filtering
+- Navigation
+- File Upload
+- Download
+- Retry
+- Cancel
+- Back
+- Continue
+
+**Platform scoping:** only include interactions that are valid for the stated Target Platform. Touch-only gestures (Swipe, Pull To Refresh, Long Press) apply to mobile/touch platforms — omit them for desktop/web-only screens unless the platform explicitly supports touch input. If Target Platform is not provided, default to Web and record this as an assumption. If the source explicitly targets more than one platform (e.g., responsive Web and native Mobile) for the same journey, create separate rows per platform variant and tag the platform in Notes — never merge platform-specific interactions into a single row.
+
+**Search vs. Filter disambiguation:** treat "Search" and "Filters" as their own screen (Step 2) only when they have a dedicated view/route. Otherwise treat them as interactions on the screen they appear in — never create both a standalone screen row and a duplicate interaction-only row for the same control.
+
+## Step 5 — Validation Rules
+
+Identify
+
+- Client-side validation
+- Server validation
+- Required fields
+- Input limits
+- Regex validation
+- Character limits
+- Date validation
+- File validation
+- Business validation
+- Cross-field validation
+
+## Step 6 — UI States
+
+Every interactive component must include all applicable states.
+
+Examples
+
+- Loading
+- Skeleton
+- Idle
+- Disabled
+- Enabled
+- Empty
+- No Internet
+- Retry
+- Refreshing
+- Error
+- Validation Error
+- Success
+- Uploading
+- Downloading
+- Permission Denied
+- Unauthorized
+- Expired Session
+- Server Failure
+- Maintenance Mode
+
+**Business status states:** in addition to the interaction/system states above, capture record- or workflow-level statuses defined by the business process (e.g., Draft, Submitted, Under Review, Approved, Rejected, Closed) wherever they change what a screen displays or which actions are enabled — common in workflow, insurance, and CRM applications and easy to miss because they are not UI-triggered states.
+
+## Step 7 — API Dependencies
+
+**API documentation trigger:** if the inputs include API documentation (Swagger/OpenAPI, Postman Collection, Backend Contracts, API Specification, or Endpoint Documentation), extract every API from it per the rules below. If no such documentation is provided anywhere in the inputs, do not stop the analysis and do not ask the user for it — proceed with this step using the identified screens/components, then invoke **API Generation (Autonomous Mode)** (below) to design the complete backend API needed to support them.
+
+Identify
+
+- GET APIs
+- POST APIs
+- PUT APIs
+- PATCH APIs
+- DELETE APIs
+- Upload APIs
+- Download APIs
+- Authentication APIs
+- Third-party APIs
+- Realtime APIs
+
+Mention
+
+- API Name
+- Purpose
+- Trigger Point
+- Response Usage
+- Contract ID if available
+
+**No fabrication rule (documented APIs only):** applies only when API documentation exists for the screen/component in question. If an API name or Contract ID is not stated or reasonably implied by that documentation, write `Not Provided` — never invent a plausible-looking API name or contract ID. When no API documentation exists at all, this rule does not apply — use API Generation (Autonomous Mode) instead so every required operation still gets a concrete, clearly-labeled endpoint rather than a wall of `Not Provided` cells.
+
+**Naming normalization:** if the same API appears under inconsistent names across source documents (e.g., `GetUserProfile` vs. `getUserDetails` referring to the same endpoint), treat it as one API, use its most complete or most recent name, and note the naming inconsistency in Notes or Assumptions & Open Questions — do not create duplicate API rows for the same endpoint.
+
+## API Generation (Autonomous Mode)
+
+If API documentation (Swagger/OpenAPI, Postman Collection, Backend Contracts, API Specification, or Endpoint Documentation) is **not provided**, do **not** stop the analysis and do **not** ask for user stories.
+
+Instead, automatically design a complete backend API specification based on the frontend implementation identified during the analysis (Steps 1–6).
+
+### API Design Rules
+
+1. Analyze all identified screens, components, forms, navigation flows, user interactions, and business features.
+2. Determine every backend operation required to support the frontend.
+3. Design a complete REST API architecture following industry best practices.
+4. Generate realistic and production-ready endpoints.
+5. Ensure the generated APIs are internally consistent and reusable.
+6. Use standard RESTful naming conventions.
+7. Maintain consistent resource naming, request structures, and response formats across all generated APIs.
+
+### Automatically Generate
+
+For every required backend operation, generate:
+
+**Basic Information**
+
+- API Name
+- HTTP Method (GET, POST, PUT, PATCH, DELETE)
+- Endpoint
+- Resource Name
+- API Purpose
+- Trigger Screen
+- Trigger Component
+- Trigger Action
+- Authentication Required
+- Authorization Type
+- API Version
+- Contract ID (assign `AI-GEN-<FE WBS ID>`, e.g. `AI-GEN-FE-012`)
+
+**Request Headers**
+
+Generate appropriate request headers. Include only headers applicable to the API, drawn from:
+
+```text
+Authorization: Bearer <access_token>
+Content-Type: application/json
+Accept: application/json
+X-Request-ID: <uuid>
+X-Correlation-ID: <uuid>
+X-Device-ID: <device-id>
+X-Platform: Web | Android | iOS
+X-App-Version: <version>
+X-Build-Number: <build-number>
+X-Language: en
+X-Timezone: Asia/Kolkata
+User-Agent: <client-user-agent>
+Idempotency-Key: <uuid>
+```
+
+`Idempotency-Key` only applies to write operations (POST, PUT, PATCH, DELETE) — see Retry & Idempotency below. Omit it for GET/read-only endpoints.
+
+**Path Parameters**
+
+Generate path parameters where appropriate, e.g. `/users/{userId}`, `/orders/{orderId}`, `/documents/{documentId}`.
+
+**Query Parameters**
+
+Generate all supported query parameters, e.g. `?page=1&limit=20&search=&sort=&order=&status=`.
+
+**Request Body**
+
+Generate a realistic request payload containing all fields required for the frontend operation, including required fields, optional fields, default values, data types, and example values. Field names must follow consistent naming conventions across all generated APIs.
+
+**Success Response**
+
+Generate a realistic response including HTTP status code, message, data object, metadata, and pagination (if applicable):
+
+```json
+{
+  "success": true,
+  "message": "Request processed successfully",
+  "data": {},
+  "meta": {}
+}
+```
+
+**Error Responses**
+
+Generate realistic error responses with example payloads for: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Validation Failed, 429 Too Many Requests, 500 Internal Server Error, 503 Service Unavailable.
+
+**Validation Rules**
+
+Generate validation rules covering: required fields, optional fields, minimum length, maximum length, regex validation, allowed values, file validation, business validation, cross-field validation.
+
+**Security Requirements**
+
+Generate appropriate security requirements where applicable: authentication, authorization, JWT access token, refresh token, token expiry, rate limiting, input sanitization, encryption requirements, sensitive field masking, file upload security, CSRF protection, CORS requirements.
+
+**Retry & Idempotency**
+
+For write operations (POST, PUT, PATCH, DELETE), specify: retry policy, timeout strategy, idempotency support, `Idempotency-Key` header, duplicate request handling.
+
+### API Design Standards
+
+Every generated API must follow: RESTful resource naming, consistent HTTP methods, standard HTTP status codes, uniform response format, consistent error structure, versioned endpoints, pagination support where applicable, filtering support, sorting support, search support, bulk operation support where applicable.
+
+### API Relationships
+
+Automatically identify and generate relationships between APIs (e.g., Authentication, User Profile, Dashboard, Search, CRUD, Upload, Download, Notification, Settings, Analytics APIs). Related APIs must share consistent request and response structures.
+
+### Assumptions
+
+When backend specifications are unavailable:
+
+- Design APIs using industry-standard REST architecture.
+- Use meaningful endpoint names.
+- Generate realistic request and response payloads.
+- Maintain consistency across all APIs.
+- Clearly mark every generated endpoint as: **"AI Generated API Specification (Recommended Implementation)"**
+
+These generated APIs are implementation recommendations intended to accelerate frontend and backend development and should be reviewed by the backend architecture team before implementation. Log the fact that APIs were auto-generated (and which ones) in Assumptions & Open Questions.
+
+## Per User Story API Contract Generation
+
+**Trigger:** run this mode instead of the standard FE WBS Output Format (below) when the input is organized as User Stories and the request asks for API contracts per user story, an API contract document, or an artifact meant to feed a downstream mock-server / OpenAPI / Postman generation skill. If the request is ambiguous and the input includes User Stories, default to the FE WBS table and note that per-user-story API contracts can be generated on request. Do not run both modes unless explicitly asked for both.
+
+Everything in Step 1–7 and API Generation (Autonomous Mode) above still applies inside this mode — it changes how the output is organized and how detailed each API is, not how screens/components/APIs are identified or how fabrication is avoided.
+
+### Processing Rules
+
+The skill must process **every User Story independently**.
+
+Never merge multiple User Stories into a single API contract.
+
+Maintain the same order as the input document.
+
+For each User Story:
+
+1. Read the complete User Story.
+2. Understand the business objective.
+3. Identify all frontend interactions.
+4. Identify all backend operations required.
+5. Generate all APIs required for that User Story.
+6. Complete the API Contract before moving to the next User Story.
+7. Repeat until all User Stories have been processed.
+
+### Iteration Rules
+
+For each User Story execute the following workflow:
+
+```
+Read User Story
+        ↓
+Understand Business Flow
+        ↓
+Identify Screens
+        ↓
+Identify Components
+        ↓
+Identify User Actions
+        ↓
+Identify Backend Operations
+        ↓
+Generate API Contracts
+        ↓
+Generate Request Headers
+        ↓
+Generate Path Parameters
+        ↓
+Generate Query Parameters
+        ↓
+Generate Request Body
+        ↓
+Generate Success Response
+        ↓
+Generate Error Responses
+        ↓
+Generate Validation Rules
+        ↓
+Generate Business Rules
+        ↓
+Generate Security Requirements
+        ↓
+Generate Retry & Idempotency Rules (write operations only)
+        ↓
+Generate Mock Data Schema
+        ↓
+Generate API Dependencies & Next API Flow
+        ↓
+Mark User Story Complete
+        ↓
+Move to Next User Story
+```
+
+The diagram above is illustrative of processing order only — the actual output must never be wrapped in a code fence; emit plain Markdown headings as shown in Output Structure below so downstream skills can parse headings directly.
+
+### Output Structure
+
+Generate output grouped by User Story.
+
+Example:
+
+```markdown
+# User Story 1
+
+## User Story
+
+<Original User Story>
+
+## Business Flow
+
+...
+
+## Screens
+
+...
+
+## Components
+
+...
+
+## APIs
+
+### API-001
+
+...
+
+### API-002
+
+...
+
+# User Story 2
+
+## User Story
+
+<Original User Story>
+
+## Business Flow
+
+...
+
+## Screens
+
+...
+
+## Components
+
+...
+
+## APIs
+
+### API-003
+
+...
+
+### API-004
+
+...
+
+## Assumptions & Open Questions
+
+...
+```
+
+The triple-backtick fence above is illustrative only, to show heading nesting — the actual output must be emitted as plain Markdown (real `#`/`##`/`###` headings), never wrapped inside a code fence, so downstream skills can parse section headings directly.
+
+Continue until every User Story has been processed. After the last User Story, append one project-level `## Assumptions & Open Questions` section (same bullet format as the FE WBS mode: `- <topic>: <what was assumed or left unresolved> — <what confirmation would resolve it>`) covering every naming normalization, conflict, AI-generated-API flag, or inherited-Step-1–7 assumption made while producing the contracts. Omit it only if zero assumptions were made.
+
+### API Contract Template
+
+Every generated API must include:
+
+- API ID
+- User Story ID
+- User Story Name
+- API Name
+- Description
+- HTTP Method
+- Endpoint
+- API Version
+- Authentication Required
+- Authorization Type
+- Request Headers
+- Path Parameters
+- Query Parameters
+- Request Body Schema
+- Required Fields
+- Optional Fields
+- Success Response Schema
+- Error Response Schemas
+- Validation Rules
+- Business Rules
+- Security Requirements
+- Retry & Idempotency (write operations only — write `N/A` for GET)
+- Mock Data Schema
+- Minimum Mock Record Count (10)
+- Edge Cases
+- Screen Mapping
+- Component Mapping
+- Trigger Action
+- API Dependencies
+- Next API Flow
+- Contract ID
+
+For Request Headers, Error Response Schemas, Security Requirements, and Retry & Idempotency content, follow the same conventions and canonical header list defined under API Generation (Autonomous Mode) rather than inventing a new format. If no real API documentation exists for a User Story's operations, generate the contract under those same Autonomous Mode rules and mark it **"AI Generated API Specification (Recommended Implementation)"** — never present a fabricated contract as if it came from real API documentation.
+
+**Business Rules:** domain-specific constraints beyond field-level validation that govern whether or how the operation executes (e.g., eligibility conditions, state-transition constraints, computed limits, approval thresholds) — derive these only from the User Story's stated business objective and any business/cross-field validation identified under Step 5; never invent one. Write `N/A` if none apply.
+
+**API Dependencies vs. Next API Flow:** these are two distinct fields, not synonyms — `API Dependencies` lists APIs that must already have succeeded before this API can be called (e.g., an auth token API); `Next API Flow` lists the API(s) typically called after this one succeeds (e.g., a create-order API followed by a get-order-status API). Populate both independently; write `N/A` when either genuinely has none.
+
+**Contract ID (this mode):** the `AI-GEN-<FE WBS ID>` scheme from API Generation (Autonomous Mode) does not apply here, since this mode has no FE WBS IDs. Instead, use the API's own `API ID` value as the Contract ID (e.g., API ID `API-014` → Contract ID `API-014`) unless the source material states a real external contract/ticket ID, in which case use that real ID and note the source in Screen Mapping/Notes-equivalent context.
+
+### API Numbering Rules
+
+API IDs must be globally unique across the project.
+
+Example: `API-001`, `API-002`, `API-003`, `API-004`, ...
+
+Do not restart numbering for each User Story.
+
+**Resuming across runs:** if this generation continues a prior run (e.g., new User Stories were added later and earlier API contracts already exist as context), resume numbering after the highest previously-assigned API ID — never renumber or reassign IDs already given to existing APIs.
+
+### Cross-Story Dependencies
+
+**Reuse matching rule:** treat two operations as the same API only when they share the same resource, HTTP method, and functional purpose — the same functional-identity test used for deduping in the FE WBS Quality Checks. Do not merge by name alone (two differently-named endpoints can be the same API; two similarly-named endpoints can be functionally distinct) — when in doubt, treat them as distinct APIs and log the ambiguity in Assumptions & Open Questions.
+
+If an API generated for one User Story is reused by another User Story:
+
+- Reuse the existing API ID.
+- Do not duplicate the API contract.
+- Reference the previously generated API.
+- Document the dependency.
+
+Example: User Story 8 reuses API-003 generated in User Story 2. Reference: `Uses Existing API: API-003`. Do not regenerate the same API.
+
+### Mock Data Requirements
+
+State the field-level schema (field name, type, format) once per API, then provide the minimum 10 example records against that schema. The 10 records must not be near-identical copies — include at least one boundary/edge-case record (e.g., max-length string, zero/negative number, empty optional fields) and one record per distinct business status/state identified for that resource (see Business status states under Step 6), where applicable. Mock data is synthetic test data only — never present it as real captured data.
+
+**Scale exception:** for a run producing more than ~50 APIs, it is acceptable to give one fully worked example record plus the schema and a one-line rule for generating the rest (e.g., "vary `status` across Draft/Approved/Rejected, `amount` across boundary and mid-range values") instead of spelling out all 10 records verbatim per API — log that this abbreviation was used in Assumptions & Open Questions.
+
+### Mock Generator Compatibility
+
+The generated output is intended to be consumed by the next AI skill.
+
+Therefore, every API contract must contain sufficient information for the next skill to automatically generate:
+
+- Mock Server
+- Mock Routes
+- Mock Request Validation
+- Mock Success Responses
+- Mock Error Responses
+- Mock Data
+- OpenAPI Specification
+- Swagger Documentation
+- MSW Handlers
+- Express Mock Server
+- JSON Server Configuration
+- Postman Collection
+
+The next skill must be able to process each User Story independently without requiring additional user input.
+
+### Completion Validation
+
+Before completing the document, verify:
+
+- Every User Story has been processed.
+- Every backend interaction has an API contract.
+- No User Story has been skipped.
+- No duplicate APIs exist.
+- Shared APIs are referenced rather than regenerated.
+- API numbering is sequential and unique.
+- Every API includes complete request and response definitions.
+- Every API contains enough information for downstream mock generation.
+- Every AI-generated API contract is explicitly labeled as such.
+- Every API contract includes Security Requirements and a Retry & Idempotency value (or `N/A` for read-only APIs).
+- Every write-operation API's Request Headers include `Idempotency-Key`.
+- Contract ID values follow the this-mode rule (matches API ID, or a real external ID) — never the WBS mode's `AI-GEN-<FE WBS ID>` scheme.
+- A trailing `Assumptions & Open Questions` section is present unless zero assumptions were made.
+
+Do not finish until all User Stories have been processed and validated.
+
+## Step 8 — Data Dependencies
+
+Identify
+
+- Master Data
+- Cached Data
+- User Profile
+- Session Data
+- Preferences
+- Permissions
+- Feature Flags
+- Configuration
+- Static Content
+- Localization / Language Files
+
+## Step 9 — Navigation
+
+Identify
+
+- Entry Screen
+- Exit Screen
+- Forward Navigation
+- Backward Navigation
+- Deep Links
+- External Links
+- Protected Routes
+- Authentication Flow
+
+**Circular navigation:** detect loops where a screen can return to itself through a chain of navigations (e.g., Screen A → B → A). Document each loop in Notes so reviewers can confirm it is intentional (e.g., a back-and-forth wizard step) rather than an accidental dead end.
+
+## Step 10 — Edge Cases
+
+Consider
+
+- Offline
+- Timeout
+- Slow API
+- Invalid Response
+- Missing Data
+- Duplicate Submission
+- Concurrent Requests
+- Session Timeout
+- Permission Changes
+- Feature Disabled
+- Unsupported Locale / Missing Translation
+
+## Output Format
+
+Generate a Markdown table with columns
+
+| FE WBS ID | Journey Step | Screen / Component | Description | User Interaction | Validation Rules | UI States | API Dependency | Data Dependency | Contract ID | Source Reference | Notes |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+
+The header row must always be followed immediately by the delimiter row shown above so the table renders as valid Markdown — never omit it.
+
+Generate one row for every implementation item.
+
+**Row granularity (required — do not skip):** one row = one distinct implementation unit, and every row's Screen / Component cell must start with a type tag so estimators can tell build-once items from per-screen items:
+
+- `Screen: <name>` — one row per screen (Step 2), covering that screen's own interactions/validations/states/APIs together in their respective columns.
+- `Component: <name>` — one row per reusable component (Step 3), placed at its first appearance in the canonical processing order (see Step 1); reference it by name (do not re-describe it) on every screen row that reuses it.
+- `Popup: <name>` / `Modal: <name>` / `Bottom Sheet: <name>` — one row each, since these carry their own validation/state/API behavior independent of the screen that triggers them.
+
+**Cross-referencing reused components:** a screen row's Screen / Component cell holds only that screen's own `Screen: <name>` tag — never append a second type tag to the same cell. When a screen reuses a component that already has its own `Component: <name>` row, list the reused component names in that screen row's Notes column as `Uses: <ComponentName>, <ComponentName>`.
+
+Never split a single screen's interactions, validations, or states into separate rows — list them together in their respective columns for that one screen row. This rule is what keeps row count and structure identical across repeated runs on the same input.
+
+**Large outputs:** when the WBS exceeds roughly 40 rows, group rows under a `### <Module/Epic name>` sub-heading per functional module while keeping one continuous table structure and one continuous ID sequence across all groups — never restart numbering per group. Determine module/epic boundaries from the top-level feature/epic names already used in the source journey/BRD; if the source has no such grouping, use the primary flows identified in Step 1. List modules in the canonical processing order (see Step 1).
+
+Use sequential IDs
+
+- FE-001
+- FE-002
+- FE-003
+- ...
+
+**Journey Step labeling:** reference the step identifier from the source user journey/BRD (e.g., `JS-1`) when one exists; otherwise assign sequential labels (`Step 1`, `Step 2`, ...) following the canonical processing order (see Step 1).
+
+**Source Reference:** cite where the row's requirement came from — a document name, section/heading, page number, ticket ID, or Figma frame name (e.g., `BRD §4.2`, `Figma: Checkout Flow / Frame 3`). If the item was inferred rather than explicitly stated, write `Inferred — see Assumptions & Open Questions` instead of leaving it blank.
+
+**Markdown safety:** escape or remove literal pipe (`|`) characters inside cell content so the table remains valid Markdown.
+
+**Empty cell convention:** never leave a cell blank. Use `N/A` when a column genuinely does not apply to that row (e.g., Contract ID for a component with no API dependency, Validation Rules for a static display screen). Use `Not Provided` only when the column applies but the source material didn't supply the value (see No fabrication rule in Step 7).
+
+**AI-generated API cells:** when an API Dependency was produced via API Generation (Autonomous Mode), the API Dependency cell must read `<METHOD> <Endpoint> (AI Generated)` and the Contract ID cell must hold the assigned `AI-GEN-<FE WBS ID>` value — never blend a generated endpoint into a cell without the `(AI Generated)` marker. Every such row's full specification (headers, parameters, request/response bodies, validation, security, retry/idempotency) belongs in a **Generated API Specifications** appendix, appended immediately after the main table (and before Assumptions & Open Questions, if both are present) — one `#### API: <API Name>` block per generated endpoint, covering every subsection listed under Automatically Generate in API Generation (Autonomous Mode), and ending with the line `**Status:** AI Generated API Specification (Recommended Implementation)`. Omit this appendix entirely if no APIs were auto-generated.
+
+## Quality Checks
+
+Before finalizing verify
+
+- ✓ Every journey step has coverage
+- ✓ Every screen has states
+- ✓ Every component has behavior
+- ✓ Every form has validation
+- ✓ Every API has dependency mapping
+- ✓ Every navigation path exists
+- ✓ Every reusable component is identified
+- ✓ No duplicate screens, components, APIs, or validation rules — dedupe by functional identity (same route/purpose/journey step), not by name alone: two screens sharing a name but serving different purposes are two separate rows (disambiguate their names, e.g., `Confirmation (Order)` vs. `Confirmation (Password Reset)`); legitimate role-variant rows (see Step 2) are not duplicates. This also covers duplicates caused by the same requirement appearing in more than one source document.
+- ✓ No missing edge cases
+- ✓ Every AI-generated API is tagged `(AI Generated)` in its table row and has a matching detailed block in the Generated API Specifications appendix
+
+If any check fails, revise the WBS table before returning output — but limit yourself to one revision pass per check. If a check still cannot be fully satisfied after that revision (e.g., an edge case genuinely cannot be determined from the source), stop revising and log the residual gap in Assumptions & Open Questions instead of looping indefinitely.
+
+## Output Rules
+
+- Never generate application code.
+- Never generate React.
+- Never generate Flutter.
+- Never generate HTML.
+- Never generate CSS.
+
+Generate only frontend planning artifacts. Structured API specification text (endpoint definitions, JSON request/response examples, header lists) produced under API Generation (Autonomous Mode) is a planning artifact, not application code, and is allowed.
+
+The output should be implementation-ready and detailed enough that developers can estimate effort and begin frontend development without additional clarification.
+
+Every row's Contract ID, API Name, and validation rule must trace to a source document, be produced by API Generation (Autonomous Mode) and explicitly labeled `(AI Generated)` / `AI Generated API Specification (Recommended Implementation)`, or be explicitly logged as an assumption — never silently fabricated.
+
+Always append an "Assumptions & Open Questions" section at the end whenever any assumption, conflict, inference, or residual gap was recorded during analysis (per the Inputs, Step 4, Step 7, Journey Step, Source Reference, and Quality Checks rules above) — not only when requirements are ambiguous. Format each entry as one bullet: `- <topic>: <what was assumed or left unresolved> — <what confirmation would resolve it>`. Omit the section only if the WBS required zero assumptions.