stitch-forge 0.3.1

package/.claude/skills/forge-build/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: forge-build
+description: >
+  Build a deployable site from generated Stitch screens. Use when the user
+  wants to export, ship, publish, or turn their screens into a real website.
+  Maps screens to routes and generates a static HTML, Astro, or Next.js project.
+---
+
+Build a deployable site from Stitch screens.
+
+## Step 1: Select Framework
+
+Present these options to the user before doing anything else:
+
+| Framework | Best For | What It Generates |
+|-----------|----------|-------------------|
+| **static** (default) | Simple sites, GitHub Pages | Plain HTML files with shared nav, ready to deploy anywhere |
+| **astro** | Content sites, blogs | Astro project via Stitch MCP `build_site` tool |
+| **nextjs** | Apps, dynamic sites | Next.js App Router project with static export |
+
+Check `.forgerc.json` for a saved `framework` preference. If set, confirm with the user: "Your config prefers [framework]. Use that, or choose a different one?"
+
+## Step 2: Select Project & Screens
+
+1. List all projects using `mcp__stitch__list_projects`. If multiple exist, ask which to build from.
+2. List all screens using `mcp__stitch__list_screens`.
+3. Present the route mapping for confirmation:
+
+```
+Screen              Route
+Landing Page    ->  /
+About Us        ->  /about-us
+Pricing         ->  /pricing
+```
+
+Rules:
+- First screen or any named "home/landing/hero/main" maps to `/`
+- Others map to `/{screen-name-lowercase}`
+- Ask if the user wants to adjust any routes
+
+## Step 3: Build
+
+### Static HTML
+For each screen:
+1. Retrieve HTML using `mcp__stitch__get_screen_code` (or `mcp__stitch__get_screen` + download URL)
+2. Save to `dist/{route}/index.html`
+3. Inject shared navigation at the top of each page
+4. Inject the Stitch Forge signature comment: `<!-- Built with Stitch Forge -->`
+
+Tell the user: "Your site is in the `dist/` folder. Open `dist/index.html` in your browser to preview. To deploy to GitHub Pages, push the `dist/` folder. For Netlify/Vercel, point to the `dist/` directory."
+
+### Astro
+1. Call `mcp__stitch__build_site` with the project ID and route mapping
+2. Follow the Stitch MCP output instructions
+
+Tell the user: "Stitch generated an Astro project. Follow the output instructions to install dependencies and run the dev server."
+
+### Next.js
+For each screen:
+1. Retrieve HTML using `mcp__stitch__get_screen_code`
+2. Generate `app/{route}/page.tsx` with the HTML as a React component
+3. Generate `package.json`, `next.config.js`, `tsconfig.json`, `app/layout.tsx`
+4. Inject the Stitch Forge signature as a JSX comment
+
+Tell the user: "Your Next.js project is in `dist/`. To run it: open a terminal, navigate to `dist/`, run `npm install`, then `npm run dev`. To deploy: push to Vercel or run `npm run build` for static export."
+
+## Step 4: Next Steps
+
+After building, suggest:
+- "Open `dist/index.html` in your browser to review" (static)
+- "If you want to refine a page, use `/forge-generate` with a specific change"
+- "To deploy, push the `dist/` folder to your hosting provider"
+
+## Guardrails
+
+- ALWAYS confirm the framework choice before building
+- ALWAYS show the route mapping before proceeding
+- NEVER output raw CLI commands without context — explain what each step does
+- If no screens exist, suggest running `/forge-generate` first

package/.claude/skills/forge-design/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: forge-design
+description: >
+  Generate a DESIGN.md from a brand brief. Use when the user wants to
+  create a visual identity, design system, or brand style guide for a
+  web project. Also use when starting a new website from scratch. Asks
+  for company name, industry, target audience, and aesthetic direction.
+  Outputs an 8-section design spec with colors, typography, and anti-slop rules.
+---
+
+Generate a complete DESIGN.md for a web project using Google Stitch.
+
+## Instructions
+
+1. If the user provided a brand brief as argument, use it. Otherwise ask for:
+   - Company/product name
+   - Industry or domain
+   - Target audience
+   - Aesthetic direction (e.g., "premium corporate", "playful startup", "minimal SaaS")
+
+2. Generate a DESIGN.md with exactly these 8 sections:
+
+   1. **Visual Theme & Atmosphere** — 2-3 evocative sentences describing overall aesthetic. Use specific adjectives and references, not generic terms.
+   2. **Color Palette & Roles** — Markdown table with columns: Role, Name, Hex, Usage. Minimum 5 roles (Primary, Secondary, Surface, On-Surface, Error). All colors as hex values, never descriptions like "trustworthy blue". Give each color a descriptive name (e.g., "Deep Navy" not just "Primary").
+   3. **Typography** — Font families from Google Fonts (avoid Inter, Poppins as primary — they signal AI-generated design). Sizes in rem/px, weights as numbers (400/600/700), line heights. Include heading, body, and mono. Use a serif/sans-serif pairing for contrast.
+   4. **Spacing & Layout** — Base unit (e.g., 4px), scale, max content width, grid system, breakpoints.
+   5. **Component Patterns** — At least 3 components (buttons, cards, inputs, etc.) with structure and style rules. Vary border-radius and shadow styles.
+   6. **Iconography** — Style (outline/solid/duotone), default size, source library.
+   7. **Imagery Guidelines** — Photo style, illustration style, aspect ratios. Be specific about what imagery communicates.
+   8. **Do's and Don'ts** — At least 3 of each. MUST include these anti-slop defaults:
+
+   ### Do
+   - Do use asymmetric or non-standard layouts for at least one feature section
+   - Do vary card sizes and spacing to create visual rhythm
+   - Do use the specified color palette exclusively (no AI-chosen colors)
+   - Do maintain high contrast (4.5:1 minimum) for all text
+   - Do vary section backgrounds (alternate between light/dark surfaces)
+
+   ### Don't
+   - Don't use Inter, Poppins, or system sans-serif as the primary font
+   - Don't use purple-to-blue gradients anywhere
+   - Don't use uniform border-radius (>12px) on all elements
+   - Don't use standard three-column icon grids as the second page section
+   - Don't center-align body text longer than 2 lines
+   - Don't use generic stock photo illustrations (3D blobs, abstract shapes)
+
+3. Validation rules:
+   - All colors must be hex values (#RRGGBB)
+   - Font sizes in rem or px only
+   - At least 5 color roles, 3 component patterns, 3 Do's and 3 Don'ts
+   - Keep total under ~3000 tokens (Stitch reads it as context on every generation)
+
+4. If DESIGN.md already exists, ask before overwriting.
+
+5. Write the file to `DESIGN.md` at the project root.
+
+6. After writing, check if a Stitch design system exists using `mcp__stitch__list_design_systems`. If the user has a Stitch project:
+   - Offer to create a design system with `mcp__stitch__create_design_system`
+   - Or update an existing one with `mcp__stitch__update_design_system`
+   - Apply it to the project with `mcp__stitch__apply_design_system` so all future generations respect it
+
+7. **Next step**: Suggest running `/forge-generate` to create the first screen using the new design system.
+
+Reference: See `docs/design-md-guide.md` for the full specification.

package/.claude/skills/forge-discover/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: forge-discover
+description: >
+  Research a business and generate a tailored DESIGN.md. Use when the user
+  wants to redesign a website, create a design system, or build a web
+  presence for a specific business. Investigates the business model,
+  analyzes competitors, understands the audience, and only generates
+  when confident enough. The recommended entry point for any real
+  business project.
+---
+
+Research a business and generate a tailored DESIGN.md with autonomous investigation.
+
+## Core Principle: Understand Before Designing
+
+NEVER generate a DESIGN.md until you understand the business. A beautiful design for the wrong business model is worse than no design at all.
+
+## Phase 1: Gather Context (REQUIRED — cannot skip)
+
+Before ANY research or generation, establish these fundamentals:
+
+1. **What the business IS**: 
+   - If only a company name is given, ask: "What does [company] do? What products or services do they offer?"
+   - If unclear whether physical or digital: "Do they sell online, in physical stores, or both?"
+
+2. **Who the customers are**:
+   - "Who are their primary customers? (families, developers, enterprises, etc.)"
+
+3. **What the website should achieve**:
+   - "What is the main goal of this website? (drive store visits, sell online, generate leads, inform)"
+   - This is CRITICAL — it determines the entire page structure
+
+4. **Current web presence**:
+   - "Do they have a current website? What URL?"
+
+If the user provides a detailed brief, extract answers from it. But if any critical info is missing (especially #1 and #3), ASK before proceeding. Do NOT assume.
+
+## Phase 2: Research (autonomous)
+
+Once you have the basics, research to validate and enrich:
+
+5. **Search for the business**: Use WebSearch for "[company name]" and "[company name] business model"
+   - Determine: Is this physical retail? E-commerce? SaaS? Service?
+   - Find: Store count, locations, revenue model, market position
+   - Find: Slogan, tagline, brand messaging
+
+6. **Analyze current website** (if URL available): Use WebFetch on the homepage
+   - Look at navigation items — what do they tell you about the business?
+     - "Sucursales/Stores/Locations" → physical retail
+     - "Cart/Checkout/Shop" → e-commerce
+     - "Login/Dashboard/API" → SaaS
+     - "Contact/Book/Schedule" → service
+   - Extract current brand colors from CSS
+   - Identify current fonts
+   - Note CTAs — what action does the site want visitors to take?
+
+7. **Research competitors**: Use WebSearch for "[company name] competitors" or "[industry] [market] companies"
+   - Analyze 1-2 competitor websites via WebFetch
+   - Note their color schemes, fonts, and layout patterns
+   - Identify what to differentiate FROM
+
+## Confidence Check (MUST pass before generating)
+
+Rate your confidence on each dimension (0-100):
+
+| Dimension | Minimum Required | What It Means |
+|-----------|-----------------|---------------|
+| Business model | >= 80 | You know what they do and how they make money |
+| Website purpose | >= 80 | You know what the site should achieve |
+| Audience | >= 60 | You know who the customers are |
+| Visual identity | >= 40 | You have colors/fonts (can use presets if needed) |
+| Competitive | >= 30 | You know at least who competitors are |
+
+**Weighted average must be >= 70 to proceed.**
+
+If below threshold:
+- Ask the user for missing information
+- Do more research
+- DO NOT proceed until confident
+
+Report your confidence: "My understanding confidence: [X]%. Business model: [type]. Proceeding to generate."
+
+## Phase 3: Generate DESIGN.md
+
+8. Generate DESIGN.md with **9 effective sections** (Section 1 expanded):
+
+### Section 1: Visual Theme & Business Context
+
+This section is the most important — Stitch reads it on every generation.
+
+Include:
+- 2-3 sentences describing the visual direction
+- **Business Model**: What the company IS (e.g., "Physical retail grocery chain with 3,300+ stores")
+- **Website Purpose**: What the site should DO (e.g., "Drive foot traffic to stores. NOT an e-commerce site.")
+- **Primary User Goals**: Numbered list of what visitors want to accomplish
+- **Key Page Elements**: What the site MUST have (e.g., "Store locator, weekly deals, category browse")
+- **Avoid**: What the site must NOT have (e.g., "Shopping cart, checkout, add-to-cart buttons")
+
+### Sections 2-7: Standard design tokens
+Colors, typography, spacing, components, iconography, imagery — as before.
+
+### Section 8: Do's and Don'ts
+Standard anti-slop rules PLUS business-model-specific rules:
+- Physical retail: "Do make store locator the primary CTA", "Don't add shopping cart"
+- SaaS: "Do show product screenshots", "Don't use generic feature icons"
+- Service: "Do make booking/contact primary", "Don't hide contact info"
+
+## Phase 4: Validate & Present
+
+9. Before writing, self-check:
+   - Does Section 1 include business model context? (REQUIRED)
+   - Does it explicitly state what the site is NOT? (REQUIRED for physical retail)
+   - Are Do's/Don'ts business-specific, not just visual? (REQUIRED)
+   - Are all colors hex values? (REQUIRED)
+   - Is it under 3000 tokens? (REQUIRED)
+   - Does it reference the actual audience? (REQUIRED)
+
+10. Present findings to user:
+    - "Business type: [type]"
+    - "Website purpose: [purpose]"
+    - "Brand colors found: [colors]"
+    - "Competitor differentiation: [approach]"
+    - "Confidence: [X]%"
+
+11. Write DESIGN.md and save research to `.forge-research/`.
+
+12. Suggest first screen prompt that ALIGNS with the business model:
+    - Physical retail: "A landing page with hero, store locator as primary CTA, weekly deals section, and category browse"
+    - SaaS: "A landing page with product demo hero, feature section, pricing tiers, and signup CTA"
+    - Service: "A landing page with service overview, booking CTA, testimonials, and team section"
+
+## Guardrails
+
+- NEVER generate before understanding the business model
+- NEVER assume e-commerce — most businesses in the world are NOT online stores
+- ALWAYS include business context in Section 1 of DESIGN.md
+- ALWAYS include what the site should NOT have (notFeatures)
+- If unsure about the business model, ASK the user
+- The DESIGN.md is not just a style guide — it's the business context that prevents wrong designs

package/.claude/skills/forge-generate/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: forge-generate
+description: >
+  Generate a screen in Google Stitch from a text description. Use when
+  the user wants to create a new web page, landing page, dashboard,
+  pricing page, about page, or any UI design. Also use when the user
+  says "design a page", "create a screen", or "build a webpage".
+  Uses DESIGN.md if available for visual consistency.
+---
+
+Generate a screen in Google Stitch from a description.
+
+## Guardrails (MUST follow)
+
+Before sending any prompt to Stitch:
+1. Verify prompt is under 5000 characters
+2. Verify prompt targets ONE screen only (not multiple pages)
+3. For refinements: verify ONE change only (not compound changes)
+4. Reject vague requests ("make it better", "improve it") — ask for specifics
+5. Check quota before generating: read `.forgerc.json` to see current usage
+6. If DESIGN.md exists, reference it for visual consistency
+7. Flag generic terms ("modern", "clean", "professional") and suggest specific UI/UX vocabulary replacements (e.g., "asymmetric hero layout", "bento grid", "sticky nav with CTA")
+
+## Instructions
+
+1. **Read DESIGN.md** if it exists at the project root. Use it as context for visual consistency.
+
+2. **Guide the user** through building a good prompt using the zoom-out-zoom-in framework:
+
+   **Zoom out (context ~30%):**
+   - Product name and what it does
+   - Target user/audience
+   - Overall aesthetic direction
+
+   **Zoom in (specifics ~70%):**
+   - Page type (landing page, dashboard, pricing, about, contact, etc.)
+   - Goal of this screen
+   - Each section with specific descriptions
+   - UI patterns: "bento grid", "sticky header", "card layout"
+   - Specific numbers: "3 pricing tiers", "4 testimonials"
+
+3. **Build the prompt** following this structure:
+   ```
+   A [adjective] [page type] for "[Product Name]," a [product description].
+   Designed for [target user]. [Visual tone].
+
+   Include these sections:
+   1. [Section with brief description]
+   2. [Section with brief description]
+   ...
+   ```
+
+4. **Generate the screen** by calling `mcp__stitch__generate_screen_from_text` with the prompt.
+
+5. **After generation**, retrieve the screen code and save the HTML to `screens/[screen-name].html`.
+
+6. **Preview the screen** after saving:
+   - Call `mcp__stitch__get_screen_image` with the project ID and screen ID to get a base64 PNG.
+   - Display the image inline so the user can see the result immediately.
+
+7. For **refinements**, use this structure (one change at a time):
+   ```
+   On the [specific section] of [screen name], [specific change]:
+   - [Detail 1]
+   - [Detail 2]
+   ```
+
+8. If generating multiple screens for a project, prefix subsequent prompts with:
+   "Following the same design language as the homepage..."
+
+9. For **variants**, offer to call `mcp__stitch__generate_variants` to produce 2-3 alternative designs the user can compare before committing to one direction.
+
+10. For **inline edits** to an existing screen, use `mcp__stitch__edit_screens` instead of regenerating from scratch.
+
+11. **Next step**: Suggest "Preview with `/forge-preview` or generate another screen with `/forge-generate`"
+
+Reference: See `docs/prompting-guide.md` for examples and strategies.

package/.claude/skills/forge-preview/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: forge-preview
+description: >
+  Preview generated Stitch screens. Use when the user says "show me the
+  page", "what does it look like", or wants to see a screenshot of a
+  screen they generated. Displays screen images inline or opens HTML
+  files in the browser.
+---
+
+Preview generated Stitch screens.
+
+## Instructions
+
+1. **Check for screens** in the `screens/` directory. If none exist, tell the user to run `/forge-generate` first.
+
+2. **If a screen name was provided as argument**, find the matching `.html` file in `screens/`.
+
+3. **If no argument**, list available screens and ask the user which one to preview.
+
+4. **Get the screen image** by calling `mcp__stitch__get_screen_image` with the project ID and screen ID from `.forgerc.json`. This returns a base64-encoded PNG.
+
+5. **Display the image inline** so the user can see the screen preview directly in the conversation.
+
+6. **Also mention** that the user can open the HTML file in their browser: "You can also open `screens/{name}.html` in your browser for a full interactive preview."
+
+7. **Next step**: "Refine with `/forge-generate` or build with `/forge-build`"

package/.claude/skills/forge-research/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: forge-research
+description: >
+  Check for Google Stitch updates and refresh the local knowledge base.
+  Use when the user asks "what's new with Stitch", "are there any updates",
+  or wants to know about current Stitch capabilities, models, or quotas.
+  Searches official docs, blogs, and forums.
+---
+
+Check for Google Stitch updates and refresh the local knowledge base.
+
+## Instructions
+
+1. **Search for recent Stitch updates** from these sources:
+   - Google Stitch documentation (stitch.withgoogle.com)
+   - Google AI blog posts about Stitch
+   - Google AI developer forums discussing Stitch
+
+2. **Compare findings** against the current known state in `src/research/known-state.json`. Check for:
+   - New or changed AI models (names, quotas)
+   - New export options
+   - New or removed MCP tools
+   - Changed limitations
+   - New features or capabilities
+
+3. **Report changes** with severity:
+   - **Breaking**: Changes that affect existing workflows (model removed, tool renamed)
+   - **Warning**: Changes that may affect usage (quota changes, new limitations)
+   - **Info**: New features, improvements, blog posts
+
+4. **If changes found**, update:
+   - `src/research/known-state.json` with new data and current timestamp
+   - `docs/known-state.md` with human-readable version
+
+5. **If no changes**, report "Knowledge base is current" with the last update date.
+
+6. **Always show** the current known state summary:
+   - Available models and their monthly quotas
+   - Available MCP tools
+   - Known limitations
+
+7. **Next step**: "Check if any changes affect your current project."

package/.claude/skills/forge-sync/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: forge-sync
+description: >
+  Sync local files with a Google Stitch project. Downloads all screens
+  and updates local config. Use when the user has made changes in
+  Stitch's web UI and wants to pull them into their local project.
+---
+
+Sync local files with a Google Stitch project.
+
+## Instructions
+
+1. **Find the project** to sync from:
+   - If a project ID was provided as argument, use it
+   - Otherwise, call `mcp__stitch__list_projects` and show available projects
+   - Let the user pick which project to sync
+
+2. **List all screens** in the project using `mcp__stitch__list_screens`.
+
+3. **Show what will be synced**:
+   ```
+   Project: [name] ([id])
+   Screens to sync: [count]
+   - Screen Name 1
+   - Screen Name 2
+   ...
+   ```
+
+4. **Confirm** with the user before downloading.
+
+5. **Download each screen** using `mcp__stitch__get_screen_code` and save the HTML to `screens/[screen-name].html`.
+
+6. **Update `.forgerc.json`** with:
+   - `projectId`: the synced project ID
+   - `screens`: array of synced screen records (id, name, lastSynced timestamp)
+   - `lastSync`: current timestamp
+
+7. **Report results**:
+   - How many screens were synced
+   - Which files were created/updated in `screens/`
+   - Any screens that failed to download
+
+8. **Check for design system** using `mcp__stitch__list_design_systems`. If one exists and no local DESIGN.md is found, suggest running `/forge-design` to create one.
+
+9. **Next step**: "Run `/forge-preview` to see synced screens."

package/DESIGN.md

@@ -0,0 +1,113 @@
+# Stitch Forge — Design System
+
+## 1. Visual Theme & Business Context
+
+Dark futuristic terminal aesthetic with neon accents — inspired by IDE color schemes and cyberpunk UI. The design feels like a premium developer tool: precise, technical, confident. Glassmorphism cards with subtle backdrop blur create depth against the dark canvas. The visual language says "this is built by developers, for developers" while remaining approachable enough for designers exploring AI-powered workflows.
+
+**Business Model**: Open source CLI framework — free to use, community-driven, MIT licensed.
+**Website Purpose**: Drive tool adoption (npm install / GitHub clone) and grow the open source community (GitHub stars, contributions, discussions). NOT a SaaS product — no pricing, no signup, no user accounts.
+**Primary User Goals**:
+1. Understand what Stitch Forge does in under 30 seconds
+2. See the workflow in action (design → generate → build)
+3. Install and start using the CLI
+4. Explore Claude Code slash commands
+5. Star the repo or contribute
+
+**Key Page Elements**: Hero with clear value proposition, workflow visualization, feature highlights, Claude Code integration showcase, installation command, GitHub CTA.
+**Avoid on this site**: Pricing pages, login/signup flows, user dashboards, enterprise contact forms, SaaS trial CTAs, testimonial carousels with fake headshots.
+
+## 2. Color Palette & Roles
+
+| Role | Name | Hex | Usage |
+|------|------|-----|-------|
+| Primary | Forge Purple | #6C5CE7 | CTAs, active states, key highlights, command prefixes |
+| Secondary | Neon Cyan | #00CEC9 | Accent links, code syntax, secondary emphasis |
+| Tertiary | Hot Pink | #FD79A8 | Badges, notifications, warning highlights |
+| Surface | Void Black | #0F0F1A | Page background, card backgrounds |
+| On-Surface | Cloud White | #E8E8F0 | Body text, descriptions |
+| Heading | Pure White | #FFFFFF | H1, H2, nav links, strong emphasis |
+| Muted | Smoke | #2D2D3F | Borders, disabled states, code block backgrounds |
+| Glass | Glass White | rgba(255,255,255,0.05) | Card surfaces, glassmorphism overlays |
+
+## 3. Typography
+
+- **Heading**: "Space Grotesk", sans-serif
+- **Body**: "DM Sans", sans-serif
+- **Mono**: "JetBrains Mono", monospace (for code blocks, terminal output, commands)
+
+| Element | Size | Weight | Line Height |
+|---------|------|--------|-------------|
+| H1 | 3.5rem | 700 | 1.1 |
+| H2 | 2.25rem | 700 | 1.15 |
+| H3 | 1.5rem | 600 | 1.3 |
+| Body | 1rem | 400 | 1.7 |
+| Small | 0.875rem | 400 | 1.5 |
+| Code | 0.9rem | 400 | 1.6 |
+| Command | 1.125rem | 500 | 1.4 |
+
+## 4. Spacing & Layout
+
+- **Base unit**: 4px
+- **Scale**: 4, 8, 12, 16, 24, 32, 48, 64, 96, 128
+- **Max content width**: 1140px
+- **Grid**: 12-column, 24px gutter
+- **Breakpoints**: 640px (sm), 768px (md), 1024px (lg), 1280px (xl)
+- **Section vertical padding**: 80px desktop, 48px mobile
+
+## 5. Component Patterns
+
+### Buttons
+- Primary: Forge Purple fill, white text, 8px radius, 14px 28px padding, subtle glow on hover
+- Secondary: transparent with 1px Forge Purple border, Forge Purple text, fill on hover
+- Ghost: transparent, Cloud White text, Muted background on hover
+- Install CTA: Mono font, Muted background, Neon Cyan text, copy-to-clipboard icon
+
+### Glass Cards
+- Glass White background with `backdrop-filter: blur(12px)`, 1px border Muted, 12px radius, 24px padding
+- Hover: border shifts to Forge Purple at 30% opacity
+- Used for features, workflow steps, command showcases
+
+### Code Blocks
+- Muted background (#1E1E2E), JetBrains Mono font, 8px radius, 16px padding
+- Syntax highlighting: strings in Neon Cyan, keywords in Forge Purple, comments in #636381
+- Copy button top-right, Ghost style
+
+### Terminal Mockup
+- Muted background with fake window chrome (three dots: #FF5F57, #FEBC2E, #28C840)
+- Content in JetBrains Mono with realistic command output
+- Used in hero to show the forge workflow
+
+## 6. Iconography
+
+Lucide icons, 24px default, 1.5px stroke, outline style. Forge Purple for interactive icons, Cloud White for decorative. Use terminal-related icons: Terminal, Code, Palette, Layers, Zap, GitBranch, Package, Eye.
+
+## 7. Imagery Guidelines
+
+No photography — this is a developer tool. Use: terminal mockups showing real CLI output, code editor screenshots with syntax highlighting, abstract geometric patterns (low-poly mesh, grid lines, particle effects) as section backgrounds. Animated gradient orbs (purple-to-cyan) as decorative elements. All imagery should reinforce the "built in the terminal" identity.
+
+Avoid: stock photos of people at computers, generic SaaS dashboard screenshots, AI-generated robot/brain imagery, clipart-style illustrations.
+
+## 8. Do's and Don'ts
+
+### Do
+- Use the terminal mockup as the hero centerpiece — show the actual workflow
+- Display real CLI commands with copy-to-clipboard functionality
+- Show the slash commands (`/forge-design`, `/forge-generate`, etc.) as interactive elements
+- Use glassmorphism cards consistently for content sections
+- Keep the dark background throughout — no light sections
+- Use Neon Cyan for links and interactive code elements
+- Include the GitHub star count and npm install command prominently
+- Use monospace font for any command, path, or technical term
+- Add subtle glow effects on interactive elements (buttons, cards on hover)
+
+### Don't
+- Don't use Inter, Poppins, or system sans-serif as the primary font
+- Don't use purple-to-blue gradients (use purple-to-cyan instead for brand consistency)
+- Don't add pricing, signup, or login elements — this is free open source software
+- Don't use light backgrounds for any main content section
+- Don't use photography or realistic illustrations
+- Don't use uniform border-radius (>16px) on all elements
+- Don't use standard three-column icon grids as the second page section
+- Don't include testimonials with stock headshots
+- Don't use generic SaaS language ("revolutionize your workflow", "seamless integration")
+- Don't use a hamburger menu on desktop — keep nav items visible

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Fernando Rodriguez Memije
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.