Mockgen Tailwind

Mockgen HTML

Generate a Node.js + HTMX + Alpine.js mockup server from PRD.md for UI/UX designer review. Header, footer, and sidebar are served as partials. Content pages are HTMX fragments swapped into a shell layout. All image/PDF links open in new tabs.

Stack

| Layer | Technology | |-------|------------| | Server | Node.js + Express.js | | Partial loading / navigation | HTMX 2.x | | Interactive UI (dropdowns, dark mode) | Alpine.js 3.x | | Styling | Tailwind CSS (CDN) | | Icons | Inline Heroicons SVG |

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-tailwind hub_middleware v1.0.3 (all modules, up to v1.0.3)
• /mockgen-tailwind hub_middleware v1.0.3 module:Location Information (one module, specific version)
• /mockgen-tailwind "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 screens

for that specific module. All other modules are skipped. Common screens (home, profile, account, notifications), partials (shell, header, footer, sidebars), and server files are NOT regenerated when a module filter is active — only the module's own content fragments 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 screens.

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 content fragment generation (Step 6e).

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

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

| Aspect | Full Generation | Module-Filtered | |--------|----------------|-----------------| | Common screens (home, profile, account, notifications) | Generate for every role | SKIP — already exist | | Partials (shell, header, footer) | Generate | SKIP — already exist | | Sidebar per role | Generate | SKIP — already exist | | server.js + package.json | Generate | SKIP — already exist | | Module content files (target module) | Generate | Generate / overwrite | | Module content files (other modules) | Generate | SKIP — leave untouched | | MOCKUP.html | Generate full file | Update only the target module's cards | | footer.html 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 screens
• Update the total screen count per role (add net new screens)
• 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 content 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 screens | | 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 sub-group | | 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 CDN ` config block in shell.html` (custom colors, fonts), all generated partials (consistent color classes), and component rendering

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 screens.

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 sensible defaults: a neutral color palette, Inter/system font stack, and standard Tailwind utility classes for spacing and layout.

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 screens for the corresponding module include a status column with colored badges for each state
• Use design system color tokens for badge colors (e.g., success color for active/completed states, warning for pending, danger for failed/rejected)

Step 3: Plan Screen Files

For each role, determine ALL screens to generate. Every clickable link, tab, or action in any generated screen MUST have a corresponding content fragment file. No link may point to # or be a dead end.

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

3a: Core Screens (content fragments)

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

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

For each module screen, analyze the user stories and identify sub-screens needed:

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

3f: Report Layout Screens (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 (JasperReports JRDesign API for Java, Puppeteer for Laravel/React).

For each identified report, create a standalone HTML file in a reports/ subfolder:

| Report Source | File Generated | |--------------|----------------| | NFR de

…

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.