End-to-end workflow for implementing a new feature in the mock-app, ensuring data model alignment, sample data, UI/UX consistency, component reuse, and automated verification with Playwright MCP.
Installation
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
End-to-end workflow for implementing a new feature in the mock-app, ensuring data model alignment, sample data, UI/UX consistency, component reuse, and automated verification with Playwright MCP.
Implement Feature Skill (Mock App Only)
Purpose
Guide the complete implementation of a new feature in the mock-app. This skill is only for UI-driven, mock features—no server-side or backend code should be created. Ensure:
Data model and sample data are correct and centralized
UI/UX patterns are consistent and reusable
Components are discoverable and tested
The feature is visually and functionally verified using Playwright MCP (including Storybook stories)
E2E tests are generated for all new flows
When to Use
Load this skill for ANY of the following — there are no exceptions for "simple" or "small" changes:
Adding a new page or route
Adding or editing navigation (nav bar, sidebar, breadcrumbs, links)
Adding any new UI element that appears more than once (buttons, badges, inputs, cards, etc.)
Editing an existing page's content or layout
Building a new UI-driven feature or workflow
Adding or updating domain logic, UI, or sample data (mock only)
Why no exceptions? Small UI changes are exactly where components get inlined instead of extracted, stories get skipped, and the registry goes stale. The cost of loading this skill is low; the cost of skipping it compounds.
Do not use this skill to build server-side, backend, or production API code. All features must be mock, UI-driven, and client-side only.
Workflow
Clarify Feature Requirements
Reference the feature spec or user story.
If unclear, use the document-feature skill to create or refine requirements.
Data Model Alignment
Use update-data-model to add or modify Zod schemas in /model.
Ensure all types are defined in /model and imported via @model.
If sample/mock data is needed, use generate-sample-data to create or update sample generators in /model/*.sample.ts.
Check Component Registry and Extract Components FIRST
Read the Component Registry: .github/skills/component-registry/REGISTRY.md
Check what components you need:
Button, Card, Badge, Table, Form inputs, etc.
Look under "✅ Extracted Components" for existing components
Look under "⚠️ Patterns Needing Extraction" for unextracted patterns
Extract patterns marked ⚠️ NEEDS EXTRACTION BEFORE implementing:
If registry shows a pattern used 2+ times, extract it first
Create component in /mock-app/src/components/ui/
Create Storybook story
Refactor existing usages to use new component
Update registry: Change status from ⚠️ to ✅
Rule: If you use the same element 2+ times in YOUR feature, extract it.
Do this BEFORE building new pages.
Select UI/UX Pattern
Use the UX Pattern Selector skill (if available) to choose the right UI pattern.
Verify all needed reusable components from step 3 now exist (extracted or already available).
Implement UI & Logic
Build new pages in /mock-app/src/pagesusing only the extracted reusable components.
NO inline buttons, forms, cards, or repeated patterns - use components from step 3.
Compose new components when needed, always with Storybook stories.
Mock Data & API
Update /mock-app/src/mocks/handlers.ts to provide mock API responses using sample data from /model.
Ensure mock data matches the Zod schemas.
Provide sufficient data (15-20+ items) to trigger scrollbars in lists/tables during testing.
Automated Verification (Playwright MCP)
Use Playwright MCP to:
Verify the feature in the running mock-app (visual and functional checks)
Verify Storybook stories for new/updated components
Use responsive-design skill to verify responsiveness across breakpoints and test scrollbar behavior
Generate E2E tests with Playwright for all new flows. These tests should verify that the mock app is able to express or demo the feature—not that a real backend or production implementation exists.
Testing & Storybook
Run and verify the feature in the mock-app.
Use Storybook to validate reusable components.
Update or add tests as needed.
Update Component Registry
Update the Component Registry (.github/skills/component-registry/REGISTRY.md):
Add any new components you created to "✅ Extracted Components"
Document patterns you noticed used 2+ times but didn't extract in "⚠️ Patterns Needing Extraction"
Update usage counts for components you used
Add entry to Maintenance Log
Update relevant skills if new patterns/conventions are introduced.
References
document-feature: For writing or refining feature specs.
responsive-design: For ensuring features work across all device sizes and testing scrollbar behavior.
update-data-model: For Zod schemas and types in /model.
generate-sample-data: For mock/sample data in /model/*.sample.ts.
component-registry: For tracking and managing reusable components and patterns.
create-skill: For documenting new workflows or skills.
Component Registry: .github/skills/component-registry/REGISTRY.md - Check this FIRST!
Reusable Components: Place in /mock-app/src/components/ui, with a Storybook story.
Playwright MCP: For automated UI verification and E2E test generation.
