Mockgen Shadcn

Mockgen shadcn/ui

Generate a Vite + React 19 + TypeScript + shadcn/ui mockup application from PRD.md for UI/UX designer review. Layout uses React components (header, sidebar, footer) composed in a shared layout route. Pages are React Router routes rendered inside the layout. All navigation is client-side via React Router ` and useNavigate`.

Stack

| Layer | Technology | |-------|------------| | Build tool | Vite 6 | | UI framework | React 19 + TypeScript 5 | | Component library | shadcn/ui (Radix UI + Tailwind CSS) | | Routing / navigation | React Router v7 | | Styling | Tailwind CSS v3 (PostCSS) | | Icons | Lucide React | | Dark mode | next-themes |

Input

This skill uses standardized input resolution. Provide:

| Argument | Required | Example | Description | |----------|----------|---------|-------------| | ` | Yes | hub_middleware | Application name to locate the context folder | | | Yes | v1.0.3 | Version to scope processing (filter user stories | No | module:Location Information | Limit generation to a single module |

Application Folder Resolution

The application name is matched against root-level application folders:

1. Strip any leading _ prefix from folder names (e.g., 1_hub_middleware → hub_middleware)
2. Match case-insensitively against the provided application name
3. Accept snake_case, kebab-case, or title-case input (all match the same folder)
4. If no match found, list available applications and stop

Auto-Resolved Paths

| File | Resolved Path | |------|---------------| | PRD.md | /context/PRD.md | | Module Models | /context/model/ | | Output (mockup) | /context/mockup/ |

Example Invocations

• /mockgen-shadcn hub_middleware v1.0.3 (all modules, up to v1.0.3)
• /mockgen-shadcn hub_middleware v1.0.3 module:Location Information (one module, specific version)
• /mockgen-shadcn "Hub Middleware" v1.0.3 module:Employer (title-case app name)

Version and Module Filtering

• Only include user stories, NFRs, constraints,

and references from sections whose version tag is less than or equal to the target version

• If a module is provided (e.g., module:Location Information), only generate/update pages

for that specific module. All other modules are skipped. Common pages (home, profile, account, notifications), layout components (header, footer, sidebars), and config files are NOT regenerated when a module filter is active — only the module's own page components are written (and MOCKUP.html is updated for only that module's cards).

• If no module is provided, process all modules (default behavior)

Argument parsing: The module: prefix is the canonical form. Also accept:

• module:"Location Information" (quoted, with space)
• module:location_information (snake_case — convert to title-case for matching)
• Natural language: for Location Information module, only Location Information

Version Gate

Before starting any work, resolve the application folder first (see Input Resolution below), then check CHANGELOG.md in the application folder (/CHANGELOG.md):

1. If /CHANGELOG.md does not exist, skip this check (first-ever execution for this application).
2. If /CHANGELOG.md exists, scan all ## vX.Y.Z headings and determine the highest version using semantic versioning comparison.
3. Compare the requested version against the highest version:

• If requested version >= highest version: proceed normally.
• If requested version **/CHANGELOG.md. Execution rejected."` Do NOT proceed with any work.

Workflow

Step 1: Parse PRD.md

Read the auto-resolved PRD.md file and extract:

1. Application name: Derive from the parent folder name containing PRD.md.

Strip leading number and underscore prefix, then title-case. Example: 1_hub_middleware -> "Hub Middleware"

1. Application initials: First letter of each word, uppercase.

Example: 1_hub_middleware -> "HM"

1. Modules: Each ## Module Name section under a # Module Category heading.

Record the module name and its description (the line after the heading).

1. User stories per module: Lines matching - [USxx#####] As a {Role} user, I want to...

Extract: tag, role, action summary.

1. Unique roles: Collect all distinct roles from user stories.

Example: "Hub Administrator", "Hub Operation Support"

1. Target version (from input argument): If a version was provided, record it for

filtering in the next sub-step.

1a: Version Filtering and Strikethrough Exclusion (MANDATORY)

PRD.md is a version-controlled document. Each section (User Story, Non Functional Requirement, Constraint, Reference) has a version tag in square brackets, e.g., [v1.0.1]. Items may also be marked with strikethrough (~~) to indicate they are deprecated/removed.

Strikethrough exclusion (always applied, regardless of version parameter):

• Any line wrapped in ~~strikethrough~~ markup MUST be excluded from processing
• This includes user stories, NFRs, constraints, and references
• Example: ~~[USHM00006] As a Hub Administrator user, I want to...~~ → SKIP
• Partially strikethrough lines (where only part is struck) should still be excluded

if the tag identifier is within the strikethrough

Version filtering (applied only when a target version is provided):

• Each section under a module has one or more version tags like [v1.0.0] or [v1.0.1]
• Items listed under a version tag belong to that version
• When a target version is specified (e.g., v1.0.1):
• Include items from sections whose version tag is target version
• Version comparison uses semantic versioning: compare major, then minor, then patch
• When no target version is specified, include all items from all versions (but still

exclude strikethrough items)

Version tracking per section: Record which version tag each item belongs to, as this will be used for traceability in the generated pages.

Example parsing of a section with multiple versions:

### User Story
[v1.0.0]
- ~~[USHM00006] As a Hub Administrator user, I want to manage...~~
- [USHM00009] As a Hub Administrator user, I want to map...
[v1.0.1]
- [USHM00012] As a Hub Administrator user, I want to manage the list...

With target version v1.0.0:

• USHM00006 → EXCLUDED (strikethrough)
• USHM00009 → INCLUDED (v1.0.0 v1.0.0)

With target version v1.0.1 (or no version specified):

• USHM00006 → EXCLUDED (strikethrough)
• USHM00009 → INCLUDED
• USHM00012 → INCLUDED

1c: Module Filtering (applied only when a module argument is provided)

When a module argument is present, apply module filtering after version filtering:

1. Match the specified module against the list of parsed modules (case-insensitive, ignoring

leading/trailing whitespace). Also accept snake_case input by converting it to title-case for comparison (e.g., location_information → match "Location Information").

1. Record the matched module name for use in Step 3 and beyond.
2. If no module matches, stop and report the available module names to the user before proceeding.
3. Module filter scope: the filter only affects page component generation (Step 6e).

All other steps complete normally (parsing, design system, planning) but output is restricted to the filtered module's pages.

Module-filtered generation mode differs from full generation in these ways:

| Aspect | Full Generation | Module-Filtered | |--------|----------------|-----------------| | Common pages (home, profile, account, notifications) | Generate for every role | SKIP — already exist | | Layout components (header, footer, sidebar) | Generate | SKIP — already exist | | Config files (package.json, vite.config.ts, etc.) | Generate | SKIP — already exist | | shadcn/ui component files | Generate | SKIP — already exist | | Route config (App.tsx) | Generate | Update — add routes for new module pages | | Module page components (target module) | Generate | Generate / overwrite | | Module page components (other modules) | Generate | SKIP — leave untouched | | MOCKUP.html | Generate full file | Update only the target module's cards | | Footer version string | Update | Update (version may have changed) |

MOCKUP.html partial update (module-filtered mode):

• Read the existing MOCKUP.html
• Locate the screen cards section for the target module (search by module name heading or

existing card tags)

• Replace only those cards with freshly generated ones reflecting the new pages
• Update the total screen count per role (add net new pages)
• Update the version badge if it changed
• Update the "N new screens added in vX.Y.Z" banner text
• Leave all other role sections and cards unchanged

Step 1b: Discover and Load Module Models

After parsing PRD.md, look for module models at the auto-resolved model path: /context/model/

For each module extracted in Step 1:

1. Convert the module name to kebab-case to derive the model folder name:

• Lowercase the module name and replace spaces with hyphens
• Examples: "Location Information" → location-information, "Industrial Classification" → industrial-classification, "Employer" → employer

1. Check for {model_dir}/{kebab-module}/model.md

1. If the file exists, parse it and extract the following sections:

• Section 2 – Collection Catalog: collection names and types (Root Collection, Audit Collection, etc.)
• Section 5 – Field Detail per Collection: for each collection — field name, type, required, nullable, constraints/notes
• Section 6 – Embedded Document Definitions: embedded type name and its sub-fields
• Section 7 – Enum Definitions: enum name and all allowed values with descriptions
• Section 9 – Index Recommendations: indexed fields (used to identify search/filter parameters)

1. Store this as the module model for the module, keyed by module name

Field classification (used during page generation in Step 6e):

| Category | Definition | Usage | |----------|-----------|-------| | System fields | _id, _audit, _version, deleted, deletedAt, deletedBy | Exclude from user-facing forms | | Audit-only fields | Fields whose Source is CONVENTION and type is Audit | Show in detail views only | | Required form fields | Required: Yes AND not a system field | Mandatory inputs in create/edit forms | | Optional form fields | Required: No AND not a system field | Optional inputs in create/edit forms | | Read-only after creation | Fields marked as unique identity keys (e.g., companyRegistrationNumber) | Show in edit forms as readonly | | Search/filter fields | Fields referenced in Index Recommendations | Render as filter controls in list pages | | Enum fields | Type matches an entry in Section 7 Enum Definitions | Render as ` dropdowns | | Embedded object fields | Type is a custom embedded document type (not a primitive) | Render as grouped sections | | Embedded array fields | Type ends in [] (e.g., PersonInCharge[]`) | Render as repeatable row with Add/Remove |

Fallback: If no model.md exists for a module, infer fields from user story text (original behavior).

---

Step 2: Load Design System

Load the design system using a two-tier resolution strategy:

2a: PRD.md Design System Reference (Primary Source)

Check if PRD.md contains a # Design System section. If it does:

1. Extract the referenced file path (e.g., from [DESIGN_SYSTEM.md](reference/DESIGN_SYSTEM.md))
2. Resolve the path relative to PRD.md's location
3. If the referenced file exists, read it and extract:

• Color palettes (primary, secondary, accent, neutral — hex values)
• Typography (font families, font sizes, weight scale)
• Spacing scale (if overriding Tailwind defaults)
• Component patterns (button styles, card styles, form input styles, table styles, badge/chip styles, modal patterns)
• Layout grid rules

1. Apply extracted tokens to the Tailwind config (tailwind.config.js) custom colors/fonts,

shadcn/ui CSS variables in src/index.css, and all generated components

2b: Context Design Folder (Fallback)

If PRD.md does not have a # Design System section, or the referenced file does not exist, fall back to the application's /context/design/ folder. This folder contains pre-defined design tokens and Tailwind component guidelines maintained externally by the UI/UX team.

Read all files in {app_name}/context/design/ (where {app_name} is the resolved application folder name from Step 1). Apply the design tokens and guidelines found there to all generated mockup pages.

Expected files (any or all may be present):

• design-system.md — Colors, typography, spacing, and visual style definitions
• components.md — Reusable component patterns and Tailwind class conventions
• guidelines.md — Layout rules, accessibility standards, and stack-specific guidelines

2c: Default Fallback

If neither the PRD reference nor the {app_name}/context/design/ folder provides design tokens, use the default shadcn/ui "New York" style: zinc/neutral color palette, Inter/Geist font stack, and default shadcn/ui component styling with CSS variables.

2d: Process Flow Status States

If PRD.md contains a # High Level Process Flow section, scan it for entity status lifecycle descriptions (e.g., "Received → Validated → Enriched → Active"). For each status lifecycle found:

• Ensure list pages for the corresponding module include a status column with colored `` variants for each state
• Use design system color tokens for badge variants (e.g., default for active/completed, secondary for pending, destructive for failed/rejected)

Step 3: Plan Screen Files

For each role, determine ALL pages to generate. Every clickable link, tab, or action in any generated page MUST have a corresponding page component. No link may be a dead end.

Module filter applied here: If a module argument was provided (Step 1c), plan only the pages for that module across all roles. Skip common pages (home, profile, account, notifications) and skip all other modules entirely. The screen plan table should list only the filtered module's pages.

3a: Core Pages (React components)

1. home.tsx: Default home/dashboard page with welcome message and summary widgets
2. profile.tsx: User profile page (linked from header user dropdown)
3. account.tsx: Account settings page (linked from header user dropdown)
4. notifications.tsx: Notifications page (linked from header notification bell)
5. One page per module that has user stories for this role

3b: Sub-Pages (Detail / Edit / Create)

For each module page, analyze the user stories and identify sub-pages needed:

| User Story Pattern | Sub-Page Required | |-------------------|-------------------| | "view details of X" | {module}-detail.tsx - Detail view for a single record | | "add/create/register X" | {module}-create.tsx - Create/add form | | "edit/update/modify X" | {module}-edit.tsx - Edit form (pre-filled) | | "view history/audit of X" | {module}-history.tsx - History/audit log view | | "view associated X of Y" | {module}-{sub}-list.tsx - Associated records list |

3f: Report Layout Pages (conditional — if PRD.md contains report-related content)

Scan PRD.md for report-related content:

• NFRs mentioning "report", "Report interface", "generate report", "report generation"
• User stories describing generating/downloading PDF, Excel, or CSV reports
• A "Report" module or report-related NFRs defining specific report types

If report requirements are found, generate HTML report layout mockups for each identified report. These layouts serve as draft previews for human designers/stakeholders to verify the report structure before the AI coding agent implements the actual report generation code.

For each ide

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: rashidee
• Source: rashidee/co2-skills
• License: MIT
• Homepage: https://compound-context.com/

Install and usage instructions live in the source repository linked above.