npm - @oisincoveney/pipeline - Versions diffs - 1.26.0 → 1.26.1 - Mend

@oisincoveney/pipeline 1.26.0 → 1.26.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (60) hide show

package/.agents/skills/add-dark-mode/SKILL.md +79 -0
package/.agents/skills/brand-kit/SKILL.md +61 -0
package/.agents/skills/brand-kit/brand-kit-prompt.md +158 -0
package/.agents/skills/canonicalize-tailwind/SKILL.md +86 -0
package/.agents/skills/componentize/SKILL.md +60 -0
package/.agents/skills/dark-mode-image/SKILL.md +64 -0
package/.agents/skills/design/SKILL.md +58 -0
package/.agents/skills/design/design-guidelines.md +74 -0
package/.agents/skills/design/guidelines/assets-api.md +196 -0
package/.agents/skills/design/guidelines/avatars.md +8 -0
package/.agents/skills/design/guidelines/badges.md +5 -0
package/.agents/skills/design/guidelines/border-radius.md +6 -0
package/.agents/skills/design/guidelines/buttons.md +27 -0
package/.agents/skills/design/guidelines/colors.md +6 -0
package/.agents/skills/design/guidelines/copywriting.md +9 -0
package/.agents/skills/design/guidelines/custom-fonts.md +7 -0
package/.agents/skills/design/guidelines/dark-mode.md +29 -0
package/.agents/skills/design/guidelines/dashboards.md +12 -0
package/.agents/skills/design/guidelines/description-lists.md +5 -0
package/.agents/skills/design/guidelines/feature-lists.md +5 -0
package/.agents/skills/design/guidelines/flexbox-layout.md +6 -0
package/.agents/skills/design/guidelines/font-recommendations.md +175 -0
package/.agents/skills/design/guidelines/footers.md +13 -0
package/.agents/skills/design/guidelines/form-controls.md +139 -0
package/.agents/skills/design/guidelines/general.md +47 -0
package/.agents/skills/design/guidelines/headers.md +8 -0
package/.agents/skills/design/guidelines/heading-groups.md +19 -0
package/.agents/skills/design/guidelines/icons.md +18 -0
package/.agents/skills/design/guidelines/images.md +12 -0
package/.agents/skills/design/guidelines/interactivity.md +6 -0
package/.agents/skills/design/guidelines/landing-pages.md +11 -0
package/.agents/skills/design/guidelines/login-pages.md +5 -0
package/.agents/skills/design/guidelines/logo-clouds.md +6 -0
package/.agents/skills/design/guidelines/navigation.md +10 -0
package/.agents/skills/design/guidelines/pagination.md +5 -0
package/.agents/skills/design/guidelines/placeholder-content.md +23 -0
package/.agents/skills/design/guidelines/pricing-cards.md +42 -0
package/.agents/skills/design/guidelines/prose-content.md +11 -0
package/.agents/skills/design/guidelines/responsive-design.md +15 -0
package/.agents/skills/design/guidelines/section-layout.md +23 -0
package/.agents/skills/design/guidelines/shadows.md +6 -0
package/.agents/skills/design/guidelines/surfaces.md +13 -0
package/.agents/skills/design/guidelines/svg.md +7 -0
package/.agents/skills/design/guidelines/tables.md +27 -0
package/.agents/skills/design/guidelines/team-sections.md +13 -0
package/.agents/skills/design/guidelines/testimonials.md +11 -0
package/.agents/skills/design/guidelines/typography.md +18 -0
package/.agents/skills/ideas/SKILL.md +161 -0
package/.agents/skills/make-responsive/SKILL.md +91 -0
package/.agents/skills/markup-from-image/SKILL.md +88 -0
package/README.md +4 -5
package/dist/config.d.ts +10 -10
package/dist/hooks.d.ts +1 -1
package/dist/moka-submit.d.ts +1 -1
package/dist/pipeline-init.js +12 -17
package/dist/runner-command-contract.d.ts +2 -2
package/docs/operator-guide.md +4 -5
package/package.json +1 -1
package/defaults/install-manifest.json +0 -8
package/dist/mcp/bootstrap.js +0 -27

package/.agents/skills/add-dark-mode/SKILL.md ADDED Viewed

@@ -0,0 +1,79 @@
+---
+name: add-dark-mode
+description: Add dark mode with colors, shadows, and surfaces handled the way a designer would.
+---
+# Add Dark Mode
+Use this when the user wants to add dark mode support to an existing UI.
+## Activation
+### Use For
+- adding dark mode to a page, section, component, or site
+- improving an existing dark mode treatment
+- converting a light-mode-only UI to support dark mode
+### Do Not Use For
+- brand-new design or layout work
+- standalone image dark-mode conversion
+- responsive behavior, component organization, or general visual polish without dark mode
+## Load First
+- No companion files are required.
+- Dark-mode design guidance is inline below.
+## Progress Updates
+Keep the user informed so longer runs do not look stuck.
+- One-line status update before each major phase.
+- Concrete and lightweight: what you are doing now, not verbose logs.
+## Workflow
+1. Inspect the existing UI and project Tailwind conventions.
+2. Convert markup to include appropriate dark-mode classes.
+3. Audit rasterized images for dark-mode variants.
+4. For each rasterized image that needs a dark-mode variant, hand off to `dark-mode-image`, which MUST load and use the `imagegen` skill before creating or editing image assets.
+5. Save generated dark-mode images alongside the originals and wire them into the dark-mode UI.
+## Dark Mode Rules
+### Design Rules
+- Dark mode is about maintaining the same contrast ratios as light mode, not simply inverting colors
+- Dark mode doesn't need to preserve every detail of the light mode design — it just needs to look good
+- Default dark mode to follow the operating system's `prefers-color-scheme` setting (Tailwind's built-in `dark:` behavior); only add a manual toggle when the user explicitly asks for one
+- Remove all shadows in dark mode — use `dark:shadow-none`
+- On dark-mode-only sites, add the `scheme-only-dark` class to `<html>` or the top-level element — ensures native elements like scrollbars, form controls, and `color-scheme` render in dark mode
+### Component Rules
+- Never keep large branded/colored panels in dark mode; instead use the same background color and add a light divider between sections
+- Style cards only slightly lighter than the page background (e.g. `dark:bg-gray-900` on a `dark:bg-gray-950` page); add a `dark:inset-ring dark:inset-ring-white/5` for definition
+- Make decorative quote marks in testimonials very faint (e.g. `dark:text-white/5`)
+- Never use multiple heading text colors in dark mode (e.g. dark gray + brand color); use a single light color like `white` or `gray-100` for all heading text
+### Raster Image Rules
+- When adding or improving dark mode, audit the page for rasterized images that need dark-mode versions: photos, screenshots, product mockups, decorative backgrounds, textures, and rasterized illustrations
+- Never use CSS filters (`invert`, `brightness`, `contrast`, `opacity`) as the final dark-mode treatment for raster images; always create real dark-mode image files
+- Generate dark-mode raster image variants with the `dark-mode-image` skill, which MUST load and use the `imagegen` skill before creating or editing any raster image assets
+### SVG Rules
+- For inline `<svg>` elements, style dark mode with Tailwind `dark:*` classes (e.g. `dark:fill-*`, `dark:stroke-*`, `dark:text-*`)
+- For external SVG files referenced via `<img>`, always create a dark-mode version alongside the original (e.g. `logo.svg` and `logo-dark.svg`); never substitute CSS filters (`invert`, `brightness`) or opacity adjustments for a true dark variant
+## Guardrails
+- Do not generate, edit, or replace raster image assets directly from this skill; `dark-mode-image` owns that work and MUST use the `imagegen` skill.
+- Require the `dark-mode-image` + `imagegen` handoff even when the image change seems simple, decorative, or incidental.
+## Verify
+- Check light and dark modes for contrast, missing variants, and images that still assume a light background.

package/.agents/skills/brand-kit/SKILL.md ADDED Viewed

@@ -0,0 +1,61 @@
+---
+name: brand-kit
+description: Generate a complete visual identity and marketing-site mockup board from a product idea.
+---
+# Brand Kit
+## Overview
+Run the brand kit workflow from concept to one finished 3840 x 2160 image. This skill wraps [Brand Kit Prompt](./brand-kit-prompt.md) and then renders the generated prompt directly through the `imagegen` skill.
+Use this workflow when the output should emphasize memorable frontend art direction, distinctive website composition, production-grade public-facing marketing pages, and avoidance of generic AI aesthetics. The final image should follow the fixed structure defined by [Brand Kit Prompt](./brand-kit-prompt.md): two large website page mockups plus a narrow design-system rail that documents only typography and hierarchical color values.
+## Load First
+- Read [Brand Kit Prompt](./brand-kit-prompt.md) before generating the intermediate image prompt.
+- Load and follow the `imagegen` skill before rendering the final image.
+## Workflow
+1. Treat the user's concept, brief, notes, constraints, references, audience, tone, avoid-list items, and attached images as the source input.
+2. Use [Brand Kit Prompt](./brand-kit-prompt.md) with the source input to generate one production-ready mockup-first image prompt. If images are attached, describe them as visual inspiration only using the rules in `Attached Images`.
+3. Capture the full prompt text from step 2 as intermediate working content. Do not present it as the final answer unless the user explicitly asks to see it.
+4. Use `$imagegen` with the full generated prompt from step 2 as its input, including any attached images as visual references when the imagegen interface supports reference images.
+5. Generate exactly one high-quality 3840 x 2160 px 16:9 landscape image: a fixed three-column marketing-site case-study board with page mockup 1 in the left 40%, page mockup 2 in the middle 40%, and a right-side design-system details rail in the final 20%.
+6. Return the rendered image. Keep final commentary minimal.
+## Attached Images
+If the user attaches images, use them as design inspiration only:
+- Use attached images to infer aesthetic direction, composition style, visual density, color atmosphere, type mood, spacing feel, texture, lighting, layout rhythm, and interaction/presentation patterns.
+- Do not copy or recreate attached-image content, logos, wordmarks, brand marks, icons, mascots, characters, product names, readable text, photography subjects, proprietary UI, exact layouts, or distinctive artwork.
+- Do not treat attached images as mandatory content for the generated brand kit unless the user explicitly says the image is their own brand asset and asks to use it.
+- When passing the generated prompt to `$imagegen`, explicitly state that attached images are style references only and must not be replicated.
+- If attached images conflict with the user's written concept, preserve the written concept and use the images only for visual direction.
+## Routing Rules
+- If the user provides only a thin but usable concept, make careful creative inferences in the prompt-generation step.
+- Ask a follow-up only when there is no usable brand, product, company, idea, or concept information.
+- Preserve all user-supplied constraints through both steps, especially names, audience, positioning, tone, visual references, attached-image inspiration, required deliverables, and avoid-list items.
+- If the user asks for the image plus the generated prompt, render the image first, then include the prompt text afterward.
+- If the prompt-generation step produces multiple boards, extra alternatives, a flexible metadata placement, or any output shape other than the fixed structure, normalize the result to match `brand-kit-prompt` before passing it to `imagegen`.
+- Do not route this workflow through `brand-kit-images`.
+## Output Discipline
+- Do not stop after producing the intermediate prompt.
+- Do not summarize or rewrite the intermediate prompt so heavily that brand details are lost.
+- Treat [Brand Kit Prompt](./brand-kit-prompt.md) as the source of truth for image structure and content. If this wrapper conflicts with that file, follow [Brand Kit Prompt](./brand-kit-prompt.md).
+- Do not generate a separate design-system board.
+- Do not generate multiple images, a contact sheet, or a two-board split.
+- Do not copy attached images or import their content, logos, text, brand marks, exact layouts, or proprietary UI into the generated image.
+- Do not generate a 2:1 board, a 4096 x 2048 board, or a flexible metadata strip/sidebar/footer/overlay layout.
+- Make the final image exactly two large public-facing website page mockups plus the right-side design-system rail.
+- Include a consistent logo, wordmark, or brand mark inside the page mockups where a production website would naturally show one.
+- Keep the design-system rail compact but legible at full 4K size, preserving only font names/typeface directions, dominant color values, supporting color values, palette hierarchy, and short color role labels.
+- In the rail, distinguish dominant/load-bearing colors from infrequent supporting accents. Dominant colors should appear larger, grouped as the main palette, and labeled by role; supporting/accent/signal colors should appear as smaller chips.
+- Do not put logo notes, spacing scales, border radius, grid specs, motion notes, component inventories, component state details, icon notes, elevation/shadow specs, or arbitrary brand copy in the design-system rail.
+- Do not create extra files or resource directories for this wrapper skill.

package/.agents/skills/brand-kit/brand-kit-prompt.md ADDED Viewed

@@ -0,0 +1,158 @@
+---
+name: brand-kit-prompt
+description: Generate an image prompt for one fixed-structure 4K marketing-site brand case-study board with two large page mockups and a narrow design-system rail documenting typography and hierarchical colors. Use when Codex is asked to write a brand kit prompt, website mockup prompt, marketing site prompt, landing page prompt, product mockup prompt, or image-generation prompt for a visual brand identity.
+---
+# Brand Kit Prompt
+## Purpose
+Generate one complete, production-ready image prompt for a fixed-structure 4K marketing-site brand case-study image. Output prompt text only; do not generate images.
+This skill prioritizes distinctive frontend art direction, production-grade public-facing marketing website mockups, generous whitespace, and consistent side-by-side comparison. Even when the concept is a web app, desktop app, mobile app, SaaS product, or other software interface, the board should show the public marketing site for that product. The final image must feel like two real, spacious website surfaces plus a concise typography/color rail, not a cramped moodboard, component inventory, app UI board, or traditional brand-system sheet.
+## Source Handling
+- Use only the user's concept, brief, notes, constraints, references, attached images, audience, tone, required pages, and avoid-list items.
+- If the input is thin but usable, make careful creative inferences.
+- Ask a question only when there is no usable brand, product, company, idea, or concept.
+- Preserve user-supplied vocabulary, constraints, page requests, examples, references, attached-image inspiration, and avoid-list items.
+- Output only the final prompt, with no preamble, rationale, commentary, follow-up, or setup text.
+## Attached Images
+If the user attaches images, inspect them and translate their visual qualities into prompt language. Use them as design inspiration only:
+- Extract aesthetic direction, composition style, visual density, color atmosphere, type mood, spacing feel, texture, lighting, layout rhythm, and interaction/presentation patterns.
+- Do not copy or recreate attached-image content, logos, wordmarks, brand marks, icons, mascots, characters, product names, readable text, photography subjects, proprietary UI, exact layouts, or distinctive artwork.
+- Do not treat attached images as mandatory content for the generated brand kit unless the user explicitly says the image is their own brand asset and asks to use it.
+- If attached images conflict with the written concept, preserve the written concept and use the images only for visual direction.
+- In the final prompt, include a short "Reference Image Use" note when images are attached: describe the style inspiration to borrow and explicitly state that attached images are style references only, not content or logo sources.
+## Workflow
+1. Infer the purpose, audience, positioning, product context, and brand personality.
+2. Choose one clear, memorable aesthetic direction that fits the concept.
+3. Choose the two public marketing-site page examples:
+   - Page mockup 1 defaults to the homepage.
+   - Page mockup 2 defaults to a concept-appropriate supporting page with a different content pattern from the homepage.
+   - If the user asks for specific pages, use those instead.
+   - If the concept is an app or software product, choose pages that can naturally show product screenshots inside the marketing site.
+4. If images are attached, summarize their reusable visual qualities using `Attached Images`.
+5. Assemble one internally consistent image-generation prompt using the structure in `Final Prompt Structure`.
+## Canonical Board Spec
+The generated prompt must request this exact image structure unless the user explicitly asks for a different structure:
+- Canvas: one single 3840 x 2160 px, 16:9 landscape, high-quality 4K image.
+- Layout: three full-height vertical columns with clean gutters.
+- Widths: page mockup 1 = 40%, page mockup 2 = 40%, design-system rail = 20%; equivalent ratio 2 : 2 : 1.
+- Left column: page mockup 1.
+- Middle column: page mockup 2.
+- Right column: design-system details rail.
+- The two page mockups must dominate and read as large, inspectable website pages.
+- The rail must be quieter than the mockups but legible at full 4K size.
+- Keep the page mockups spacious and breathable, with clear margins, open section rhythm, and enough negative space that the design does not feel busy.
+- Do not add extra panels, page thumbnails, floating device mockups, moodboard imagery, standalone logo explorations, component inventories, callout overlays, or decorative filler.
+- Do not generate a separate design-system board, a two-board split, multiple images, unreadably tiny UI fragments, or a dashboard/workspace/app UI board unless the user explicitly requests an interface-only board instead of a marketing site.
+## Page Mockups
+The two mockups should be substantial public-facing marketing website pages with generous spacing, strong breathing room, and restrained content density. Treat an app concept as a product that needs a marketing site, not as permission to make the board an app UI study. Product/app UI may appear only as supporting content embedded inside a page mockup.
+If the concept is a web app, desktop app, mobile app, SaaS product, marketplace, creator tool, productivity tool, or other software product, include at least one realistic screenshot or framed view of the app inside the marketing pages. These screenshots should help explain the product and provide brand inspiration, while the surrounding page remains the main subject.
+Page mockup 1:
+- Default to the homepage.
+- Make it the clearest expression of the marketing promise.
+- Include primary navigation with an appropriate logo, wordmark, or brand mark; a strong hero system; primary CTA; and enough below-the-fold content to show section pacing.
+- For app/software concepts, include a prominent but embedded product screenshot, device frame, desktop/webapp frame, mobile screen, or interface crop.
+Page mockup 2:
+- Default to a supporting page that reveals a different side of the system.
+- Prefer pages that add new content patterns: pricing, booking, signup, product/service detail, collection/category, editorial/content, comparison, case study, lead-capture, checkout, account creation, search/results, commerce, structured data, forms, tables, cards, proof blocks, dense typography, or screenshot-led feature explanation.
+- Reuse the same logo, wordmark, or mark from the homepage in realistic page chrome when appropriate.
+For each page, define:
+- Page type and purpose.
+- Layout structure, hierarchy, key components, and copy tone.
+- Logo/wordmark/mark placement when a real site would include one.
+- Product screenshot placement when the concept is an app/software product.
+- Visible design behavior: grid/composition, generous spacing feel, low-to-moderate density, type scale, navigation, CTAs, forms, cards, pricing tables, proof blocks, product tiles, filters, commerce modules, editorial modules, or other relevant components.
+- Whitespace strategy: wide margins, clear gutters, open hero composition, fewer simultaneous content blocks, and section pacing that feels calm rather than crowded.
+- Distinctive frontend composition: asymmetry, overlap, strict grid, dense utility, editorial pacing, diagonal flow, immersive media, tactile states, active/hover states, scroll moments, or another concept-appropriate idea.
+## Design-System Rail
+The right rail documents only values that are hard to recover from the mockups without OCR.
+Include:
+- Typography: display/headline, body, and UI/label/numeric/mono typeface names or typeface directions; include brief hierarchy, casing, weight, tracking, or pairing notes only when useful.
+- Color: dominant/core colors separated from supporting/accent colors; approximate hex-style values; short role labels such as background, foreground, primary, surface, border, signal, accent, semantic, or category.
+- Color hierarchy: dominant/load-bearing colors shown as larger swatches or bars; supporting/accent/signal colors shown as smaller grouped chips.
+- Rail text optimized for full-4K readability: short labels, large enough type, clear spacing, no dense captions.
+Do not include in the rail:
+- Logo, wordmark, mark construction, lockups, logo notes, logo variations, or logo-spec content.
+- Spacing scales, border radius, grid specs, motion notes, component inventories, component states, icon notes, elevation/shadow specs, or arbitrary brand copy.
+- Slogans, positioning paragraphs, mood words, or any text that does not directly document typography or color values used in the page mockups.
+## Creative Direction
+Choose a bold but concept-appropriate aesthetic direction, such as brutally minimal, maximalist, retro-futuristic, organic, luxury, playful, editorial, brutalist, art deco, soft, industrial, utilitarian, or another direction inferred from the brief.
+Define:
+- Purpose: what visitors should understand, trust, and do.
+- Marketing focus: how the site introduces, explains, proves, and sells the brand.
+- Tone: 3-5 strong adjectives, not a neutral default.
+- Differentiation: the one visual, typographic, interaction, material, motif, or page-structure idea someone would remember.
+- Constraints: production-grade, functional, accessible, plausible for a real frontend.
+- Intensity: maximalist systems may be rich; refined systems should rely on restraint, proportion, and precision.
+- Spacing: preserve generous whitespace even for expressive or maximalist concepts; use scale, contrast, and composition for impact instead of cramming in more modules.
+Avoid:
+- Defaulting to Inter, Roboto, Arial, system fonts, or overused neutral typography unless requested.
+- Cliche purple-blue gradients on white, generic glassmorphism, bland SaaS dashboards, default rounded cards, cookie-cutter component layouts, unrelated gradient blobs, or decorative effects unrelated to the brand.
+- Cramped layouts, busy collages, overfilled sections, dense rows of tiny cards, excessive annotations, or too many simultaneous UI fragments.
+- Reusing the same trendy typefaces or color systems across concepts.
+## Final Prompt Structure
+Assemble the final answer as the image prompt itself, using these sections:
+1. Brand Positioning
+   - Target audience, market positioning, 3-5 tone adjectives, brand personality, relevant comparables/references, and avoid list.
+2. Aesthetic Concept
+   - Core frontend art direction in one vivid phrase, why it fits, memorable design idea, intensity/restraint, and what makes it specific to this brand.
+3. Reference Image Use
+   - Include only when images are attached. Summarize reusable visual qualities and state that references are for style inspiration only, not for copied content, logos, text, exact layouts, or proprietary UI.
+4. Board Layout
+   - Restate the canonical 3840 x 2160, 40% / 40% / 20%, three-column layout and the prohibition on extra panels or alternate layouts.
+5. Page Mockups
+   - Define the homepage and supporting page using the `Page Mockups` requirements, or use the user's requested pages.
+6. Design-System Rail
+   - Define only the typography block and hierarchical color block using the `Design-System Rail` requirements.
+7. Visual Style Constraints
+   - State what to avoid, what to emphasize, anti-generic constraints, generous whitespace requirements, and that the fixed layout still applies even when the aesthetic is expressive.
+8. Rendering / Style Hints
+   - End with one concise rendering line: one 3840 x 2160 px 16:9 high-quality 4K presentation image; fixed 40% page mockup 1 / 40% page mockup 2 / 20% typography-and-color rail; crisp readable UI and rail text; production-grade marketing website mockups; bold concept-specific art direction; generous margins, open section rhythm, and calm whitespace; realistic polished visual design.
+## Rules
+- Be specific and concrete; maintain internal consistency across all sections.
+- Make the aesthetic direction memorable and concept-specific.
+- Keep the website mockups spacious; do not trade readability and whitespace for extra content.
+- Use specific typeface names or precise typeface directions and approximate color values.
+- Specify which colors are dominant/load-bearing and which are supporting/rare accents, and require that hierarchy to be visible.
+- Keep all visible rail text short enough for image generation to render legibly.
+- Do not hardcode examples from one concept into another concept.
+- Do not ask for a separate design-system board or two images.
+- Do not explain your reasoning.

package/.agents/skills/canonicalize-tailwind/SKILL.md ADDED Viewed

@@ -0,0 +1,86 @@
+---
+name: canonicalize-tailwind
+description: Sort, normalize, deduplicate, and resolve conflicting Tailwind utility classes.
+---
+# Canonicalize Tailwind
+Use this when the user wants to clean up, canonicalize, or normalize Tailwind class lists.
+## Activation
+### Use For
+- cleaning up Tailwind classes
+- canonicalizing Tailwind utility lists
+- sorting, normalizing, or deduplicating Tailwind classes
+- resolving conflicting Tailwind utilities in class strings
+### Do Not Use For
+- new design or layout work
+- component extraction or code organization
+- visual changes rather than class-list cleanup
+## Load First
+- No companion modules are required.
+## Progress Updates
+Keep the user informed so longer runs do not look stuck.
+- One-line status update before each major phase.
+- Concrete and lightweight: what you are doing now, not verbose logs.
+## Workflow
+1. Identify Tailwind class strings in the requested files or components.
+2. Canonicalize class strings with `npx @tailwindcss/cli canonicalize`.
+3. Apply changed class strings back to the source.
+4. Run the project's formatter or relevant checks when available.
+## Commands
+- Use `npx @tailwindcss/cli canonicalize` to clean up Tailwind class lists — collapses shorthands (`mt-2 mr-2 mb-2 ml-2` → `m-2`), resolves overrides (`py-3 p-1 px-3` → `p-3`), canonicalizes arbitrary values to named utilities, and sorts classes; pass `--css path/to/input.css` if the project uses a custom CSS entry file
+  Single class string:
+  ```sh
+  npx @tailwindcss/cli canonicalize "mt-2 mr-2 mb-2 ml-2"
+  # m-2
+  ```
+  Multiple class strings as positional args (each returned on its own line):
+  ```sh
+  npx @tailwindcss/cli canonicalize "py-3 p-1 px-3" "mt-2 mr-2 mb-2 ml-2"
+  # p-3
+  # m-2
+  ```
+  Pipe class strings via stdin (one per line):
+  ```sh
+  echo "py-3 p-1 px-3\nmt-2 mr-2 mb-2 ml-2" | npx @tailwindcss/cli canonicalize
+  # p-3
+  # m-2
+  ```
+  Use `--format json` or `--format jsonl` for structured output with `input`/`output`/`changed` fields:
+  ```sh
+  npx @tailwindcss/cli canonicalize --format json "py-3 p-1 px-3"
+  # [{ "input": "py-3 p-1 px-3", "output": "p-3", "changed": true }]
+  ```
+  Use `--stream` to process stdin line-by-line without buffering:
+  ```sh
+  npx @tailwindcss/cli canonicalize --stream
+  ```
+## Verify
+- Confirm class strings still express the same visual intent after canonicalization.
+- Run relevant lint, typecheck, or formatting commands when available.

package/.agents/skills/componentize/SKILL.md ADDED Viewed

@@ -0,0 +1,60 @@
+---
+name: componentize
+description: Extract and organize existing UI into reusable components with thoughtful APIs.
+---
+# Componentize
+Use this when the user wants to componentize, extract, or organize UI code into reusable components.
+## Activation
+### Use For
+- componentizing an existing page, section, or prototype
+- extracting a page or section into components
+- extracting repeated UI into reusable components
+- reducing duplication in UI code
+- turning a draft implementation into production-ready code structure
+- splitting a large UI file into smaller, focused modules
+### Do Not Use For
+- brand-new design or layout work
+- visual polish without code structure changes
+- Tailwind class cleanup without component extraction
+- responsive behavior, dark mode, or image adaptation only
+## Load First
+- No companion modules are required.
+## Progress Updates
+Keep the user informed so longer runs do not look stuck.
+- One-line status update before each major phase.
+- Concrete and lightweight: what you are doing now, not verbose logs.
+## Workflow
+1. Inspect existing project component patterns before creating new components.
+2. Identify repeated patterns, logical sections, and self-contained UI blocks.
+3. Extract components with call-site spacing and configurable class merging.
+4. Reuse or extend existing project components where available.
+5. Re-scan extracted components for remaining duplication.
+## Rules
+- Break designs into small, focused components instead of rendering everything in a single large component — extract repeated patterns, logical sections, and self-contained UI blocks into their own components
+- Never bake margins into components — apply margins at the call site instead; every component must accept a `class` attribute and merge it with the classes on the component's top-level element
+- Use `clsx` or similar to merge classes together in client-side components
+- Always extract form controls into reusable components organized by HTML element — one `Input` component for all `<input>` types (text, email, password, etc.), one `Select` for `<select>`, one `Textarea` for `<textarea>`; never create type-specific components like `EmailInput` or `PasswordInput`; check the project for existing ones before creating new ones
+- When two or more elements share the same structure and styling but differ only in props like labels, placeholders, or types — extract them into a single reusable component parameterized by those differences
+- After extracting components, scan them for duplicated patterns and extract shared elements into reusable components — e.g. repeated section container/max-width/padding wrappers, repeated heading group structures (eyebrow + heading + subheading), repeated card shells, repeated button styles
+- Always use existing project components when they are available — reuse or extend them instead of creating new ones; buttons and form elements are especially common candidates
+## Verify
+- Run relevant formatting, lint, typecheck, or tests when available.
+- Confirm extracted components preserve the original UI and behavior.

package/.agents/skills/dark-mode-image/SKILL.md ADDED Viewed

@@ -0,0 +1,64 @@
+---
+name: dark-mode-image
+description: Create dark-mode variants of raster images for dark UI contexts.
+---
+# Dark Mode Image
+Use this when the user wants to adapt a standalone source image into a dark-mode-suitable version.
+## Activation
+### Use For
+- creating a dark-mode version of an image, illustration, screenshot, photo, product mockup, decorative background, or texture
+- adapting an existing raster image so it presents correctly on a dark background
+- generating a dark-mode image variant for use in a dark-mode UI
+### Do Not Use For
+- adding dark mode to a page, section, component, or site
+- SVG-only assets
+- general image styling in a UI without dark-mode conversion
+When the `add-dark-mode` skill identifies raster images that need dark-mode variants, use this skill for that image-generation work. This skill is the required handoff point between dark-mode UI work and raster image generation.
+## Load First
+- Before image generation or editing, load and follow the `imagegen` skill.
+## Progress Updates
+Keep the user informed so longer runs do not look stuck.
+- One-line status update before each major phase.
+- Concrete and lightweight: what you are doing now, not verbose logs.
+## Workflow
+1. Load `imagegen`.
+2. Inspect the source image and the dark-mode UI context.
+3. Generate or edit a dark-mode version with the same dimensions as the original.
+4. Save the dark-mode image with a `-dark` suffix alongside the original.
+5. Return the saved project path for the caller to wire into the UI.
+## Rules
+- Before doing any image generation or editing, you MUST load and follow the `imagegen` skill
+- The `imagegen` skill invocation is not optional: do not skip it, do not replace it with an ad hoc image-generation workflow, and do not call image tooling directly without first applying `imagegen`
+- Let `imagegen` choose and run the correct image workflow; for normal dark-mode image variants, that will usually mean its default built-in `image_gen` tool mode
+- If the source image is a local file, follow `imagegen`'s local-image guidance before editing so the image is visible in the conversation context
+- Follow `imagegen`'s save-path policy: move or copy project-bound generated outputs into the workspace, and never leave a project-referenced dark-mode asset only under `$CODEX_HOME/*`
+- When generating a dark-mode image, choose a background color that feels like an appropriate inversion of the original background color: black or dark gray for white, dark gray for off-white, or the specific dark color provided by the user; if the original image's background matched the site background, match the dark-mode site background instead
+- Preserve the same contrast characteristics as the original image; light sections should become darker while relative separation and readability stay intact
+- Preserve blurs and softness; never sharpen anything that was blurry in the original image
+- Preserve the foreground color palette hues, adjusting saturation and lightness only as needed so the image presents correctly on a dark background
+- Preserve the original vibe as much as possible: bright and intense images should stay bright and intense, while subtle and muted images should stay subtle and muted
+- Pay attention to areas that fade out and preserve those fades in the dark-mode version
+- The generated dark-mode image must be exactly the same dimensions as the original image
+- Save dark-mode images with a `-dark` suffix, for example `bg.jpg` and `bg-dark.jpg`
+## Verify
+- Confirm the generated image dimensions match the original exactly.
+- Confirm the dark-mode image preserves the original composition, softness, fades, and foreground palette.

package/.agents/skills/design/SKILL.md ADDED Viewed

@@ -0,0 +1,58 @@
+---
+name: design
+description: Design and build new UI with the complete ui.sh design guideline system.
+---
+# Design
+Use this when the user wants to create new UI that follows the full ui.sh design guideline system.
+## Activation
+### Use For
+- designing new UI, layouts, sections, components, or pages from scratch
+- implementing visually polished Tailwind CSS UI
+- adding a new section or page to an existing UI
+- applying reusable design, markup, and Tailwind authoring rules while building UI
+### Do Not Use For
+- UI picker scaffolding only
+- semantic unstyled markup from screenshots, Figma exports, mockups, wireframes, or UI images
+- component extraction or code organization only
+- Tailwind class cleanup only
+- adding dark mode to an existing UI only
+- making an existing desktop-oriented UI responsive only
+## Load First
+- Read [UI Design Guidelines](./design-guidelines.md) before writing UI code.
+- Scan the rule-file index and load every guideline file that could apply.
+- Load reference modules only when the request needs that reference material.
+## Progress Updates
+Keep the user informed so longer runs do not look stuck.
+- One-line status update before each major phase.
+- Concrete and lightweight: what you are doing now, not verbose logs.
+## Workflow
+1. Inspect the user's request, target files, existing design conventions, and available components.
+2. Load [UI Design Guidelines](./design-guidelines.md) plus every applicable rule file.
+3. Implement the UI using the project's existing framework, component patterns, assets, and Tailwind conventions.
+4. Check the result across responsive breakpoints and interaction states.
+## Rules
+- Treat the guideline files in this skill as the source of truth for new UI design work.
+- Err on the side of loading too many applicable guideline files rather than too few.
+- Preserve user constraints unless a guideline explicitly requires asking about a design conflict.
+## Verify
+- Check desktop and mobile layouts.
+- Confirm every applicable guideline file was loaded and followed.
+- Run relevant formatting, lint, typecheck, or tests when available.

package/.agents/skills/design/design-guidelines.md ADDED Viewed

@@ -0,0 +1,74 @@
+# UI Design Guidelines
+Use this when designing or building new UI with the top-level `design` skill, or when a workflow tells you to load design guidance before editing UI code.
+## Load Contract
+- Before writing UI code, scan the rule-file index below and load every rule file that could apply.
+- Err on the side of loading too many rule files rather than too few.
+- Treat rules as applicable even when they are indirect: heading group rules apply to hero sections; landing page rules apply to individual page sections; surface rules apply to dashboard cards and list items.
+- Load reference modules only when the user's request needs that reference material.
+## General Design Principles
+- Every layout must adapt from mobile to desktop — use responsive breakpoint classes to adjust the design at different screen sizes; see [Responsive Design](./guidelines/responsive-design.md) for detailed rules
+## Rule Files
+Follow these rules when designing or building UI. Each rule file covers a specific topic:
+- [Avatars](./guidelines/avatars.md) — profile photos, user thumbnails, and people images used in testimonials, team sections, comments, and anywhere a person's face appears
+- [Badges](./guidelines/badges.md) — badges, tags, pills, status indicators, labels, and chips with or without icons
+- [Border Radius](./guidelines/border-radius.md) — rounding corners on cards, containers, buttons, images, screenshots, and nested elements with concentric radii
+- [Buttons](./guidelines/buttons.md) — primary and secondary buttons, CTAs, icon buttons, destructive/danger actions, and touch targets
+- [Colors](./guidelines/colors.md) — brand colors, accent colors, color palette selection, and default color choices
+- [Copywriting](./guidelines/copywriting.md) — punctuation, periods, headings, taglines, subtitles, descriptions, and list items
+- [Custom Fonts](./guidelines/custom-fonts.md) — loading custom fonts via `<link>` tags or `@import url()`, registering fonts in `@theme` with `--font-*`, font-feature-settings, and font-variation-settings
+- [Dark Mode](./guidelines/dark-mode.md) — dark theme styling, contrast ratios, colored panels, card backgrounds, shadow removal, decorative elements, heading colors, dark-mode image handoff, and inline/external SVG dark-mode handling
+- [Description Lists](./guidelines/description-lists.md) — `<dl>`, `<dt>`, and `<dd>` styling, term/detail contrast and font weight hierarchy
+- [Dashboards](./guidelines/dashboards.md) — dashboard layouts, stat grids, KPI cards, metric cards, admin panels, analytics views, and any section displaying key statistics, charts, or summary data
+- [Feature Lists](./guidelines/feature-lists.md) — feature grids, feature sections, benefit lists, and any section that lists multiple features with titles and descriptions
+- [Flexbox Layout](./guidelines/flexbox-layout.md) — flex containers, flex children, `min-w-0` shrinking behavior, `shrink-0` on icons/images/SVGs, fluid vs fixed layouts, sidebar + content patterns, and any layout using `flex-1` or flexible sizing
+- [Footers](./guidelines/footers.md) — page footers, footer logos, footer links, social media icons, and site-wide bottom navigation
+- [Form Controls](./guidelines/form-controls.md) — inputs, selects, checkboxes, radio buttons, login forms, sign-up forms, checkout forms, search bars, newsletter sign-up fields, and input + button combos
+- [General](./guidelines/general.md) — general markup rules (class placement on block vs inline elements, redundant display classes, `role="list"`) and Tailwind CSS authoring rules (utility preferences, spacing conventions, arbitrary value syntax, variant patterns, deprecated utilities) that apply across all components
+- [Headers](./guidelines/headers.md) — site headers, navigation bars, navbars, top bars, logos, mobile menus, and hamburger menus
+- [Heading Groups](./guidelines/heading-groups.md) — the headline, subheadline, and optional eyebrow at the top of marketing and landing page sections (hero, features, team, pricing, CTA, etc.); does not apply to blog posts, articles, or editorial content
+- [Icons](./guidelines/icons.md) — SVG icons, icon sizing, icon alignment with text, Heroicons, filled vs stroked icons, and inline list icons like checkmarks
+- [Images](./guidelines/images.md) — photos, thumbnails, screenshots, app UI mockups, and image borders/outlines
+- [Interactivity](./guidelines/interactivity.md) — hover states, transitions, animations, and interactive behavior on clickable vs non-clickable elements
+- [Landing Pages](./guidelines/landing-pages.md) — full page consistency rules for buttons, fonts, containers, border radius, column gaps, layout alignment, and responsive constraints across all sections on a page
+- [Login Pages](./guidelines/login-pages.md) — login, sign-in, sign-up, and authentication page backgrounds and layout rules
+- [Logo Clouds](./guidelines/logo-clouds.md) — logo grids, client logo rows, partner logos, trust bars, and any section displaying a collection of brand logos
+- [Navigation](./guidelines/navigation.md) — sidebar nav, header nav, mobile nav menus, tabs, tab bars, vertical menus, active/selected states, and current page indicators in any navigation pattern
+- [Pagination](./guidelines/pagination.md) — page number links, previous/next buttons, and paged navigation controls
+- [Placeholder Content](./guidelines/placeholder-content.md) — dummy logos, placeholder avatars, app screenshots, wallpapers, and the assets API for generating realistic placeholder content
+- [Prose Content](./guidelines/prose-content.md) — styling raw HTML from markdown, CMS, or database content where Tailwind classes can't be applied to individual elements; replaces the `@tailwindcss/typography` plugin with a custom `.prose` class
+- [Pricing Cards](./guidelines/pricing-cards.md) — pricing tiers, pricing tables, plan cards, emphasized/popular plan styling, and button alignment across pricing columns
+- [Responsive Design](./guidelines/responsive-design.md) — responsive breakpoints, container queries, `@container` placement, and mobile-to-desktop layout adaptation
+- [SVG](./guidelines/svg.md) — inline SVG elements, `xmlns` attributes, SVG color styling (`fill`, `stroke`, `currentColor`), and SVG markup conventions used anywhere in HTML/JSX
+- [Section Layout](./guidelines/section-layout.md) — left-aligned vs centered section layouts, content width constraints, and aligning containers across stacked page sections
+- [Shadows](./guidelines/shadows.md) — box shadows on cards, modals, popovers, dropdowns, and elevated elements, including border pairing rules
+- [Surfaces](./guidelines/surfaces.md) — cards, wells, borders, dividers, and white space as surface treatments; when to use cards vs subtle dividers vs recessed backgrounds vs no separation at all; applies to stat grids, dashboard metrics, list items, sidebars, and any content grouping decision
+- [Tables](./guidelines/tables.md) — data tables, comparison tables, table headings, row dividers, and table containers
+- [Team Sections](./guidelines/team-sections.md) — team grids, team member cards, staff listings, about-us sections, and people galleries with photos and bios
+- [Testimonials](./guidelines/testimonials.md) — customer quotes, reviews, social proof sections, testimonial cards, hanging punctuation, and attribution layout
+- [Typography](./guidelines/typography.md) — font weights, line heights, text sizes, heading styles, max-width constraints, text-pretty/text-balance, tracking, and eyebrow text
+## Reference Modules
+Load these only when the request needs the reference:
+- [Assets API](./guidelines/assets-api.md) — placeholder asset URLs, query parameters, and examples for marks, avatars, logos, screenshots, and wallpapers
+- [Font Recommendations](./guidelines/font-recommendations.md) — optional font suggestions for when the user asks for help choosing a font or wants to try different fonts across design variations; includes sourcing notes, feature settings, and tips for each font
+## Design Conflicts
+When a rule says **⚠️ ask-user**, the user's input conflicts with a design guideline. Do not silently override the user or silently follow their request. Instead:
+1. Use the `AskUserQuestion` tool to flag the conflict
+2. Explain what the guideline recommends and why the input doesn't fit
+3. Offer a concrete alternative (e.g. a rewritten version of their copy, a different layout)
+4. Wait for the user to choose before proceeding
+Never skip this — even if it feels minor. The user should always be aware when their input bumps up against a design rule.