# Mockgen Shadcn

> >

- **Type:** Skill
- **Install:** `agentstack add skill-rashidee-co2-skills-mockgen-shadcn`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [rashidee](https://agentstack.voostack.com/s/rashidee)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [rashidee](https://github.com/rashidee)
- **Source:** https://github.com/rashidee/co2-skills/tree/main/skills/mockgen-shadcn
- **Website:** https://compound-context.com/

## Install

```sh
agentstack add skill-rashidee-co2-skills-mockgen-shadcn
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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"

2. **Application initials**: First letter of each word, uppercase.
   Example: `1_hub_middleware` -> "HM"

3. **Modules**: Each `## Module Name` section under a `# Module Category` heading.
   Record the module name and its description (the line after the heading).

4. **User stories per module**: Lines matching `- [USxx#####] As a {Role} user, I want to...`
   Extract: tag, role, action summary.

5. **Unique roles**: Collect all distinct roles from user stories.
   Example: "Hub Administrator", "Hub Operation Support"

6. **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:
```markdown
### 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").
2. **Record the matched module name** for use in Step 3 and beyond.
3. If no module matches, stop and report the available module names to the user before proceeding.
4. **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`

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

3. 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)

4. 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
4. 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](https://github.com/rashidee)
- **Source:** [rashidee/co2-skills](https://github.com/rashidee/co2-skills)
- **License:** MIT
- **Homepage:** https://compound-context.com/

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-rashidee-co2-skills-mockgen-shadcn
- Seller: https://agentstack.voostack.com/s/rashidee
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.