dev-booster 1.16.12 → 1.17.0

package/template/.devbooster/boosters/deploy.md

@@ -23,10 +23,10 @@ It MAY:
 
 ## 1. MANDATORY CONTEXT LOADING
 - `.devbooster/hub/personas/agent_devops-engineer.md`
-- `.devbooster/hub/personas/deploy.md`
 - `.devbooster/hub/personas/skill_deployment-procedures.md`
 - `.devbooster/hub/personas/skill_bash-linux.md`
 - `.devbooster/hub/personas/skill_server-management.md`
+- `.devbooster/hub/personas/skill_powershell-windows.md` (load only when the target environment involves Windows or PowerShell automation)
 
 ## 2. OPERATING MODE
 When activated:
@@ -35,6 +35,29 @@ When activated:
 - return risks, missing checks, and recommended manual next steps
 - never execute the deploy path itself
 
+## 2.1 PLATFORM REFERENCE (FOR MANUAL EXECUTION)
+When a deploy target is identified, reference the appropriate platform command for the user to run manually:
+
+| Platform | Command (user runs) | Notes |
+|----------|--------------------|-------|
+| Vercel | `vercel --prod` | Auto-detected for Next.js |
+| Railway | `railway up` | Needs Railway CLI |
+| Fly.io | `fly deploy` | Needs flyctl |
+| Docker | `docker compose up -d` | For self-hosted |
+| AWS | `aws s3 sync ./out s3://<bucket>` or `cdk deploy` | Static or CDK |
+| GCP | `gcloud app deploy` or `gcloud run deploy` | App Engine or Cloud Run |
+
+**Important:** You MUST NOT run these commands. Present them as reference for the user to execute manually.
+
+## 2.2 PRE-FLIGHT VALIDATION SCRIPTS (REFERENCE FOR MANUAL EXECUTION)
+When auditing deploy readiness, reference these validation suites for the user to run manually:
+- **`checklist.py`** — runs all core checks in priority order (Security → Lint → Schema → Tests → UX → SEO). Quick incremental validation.
+- **`verify_all.py`** — complete pre-release suite including Lighthouse, E2E, bundle analysis, and mobile audit. Use before major releases.
+
+Both scripts are at `.devbooster/hub/scripts/`.
+
+**Important:** You MUST NOT run these scripts. Present them as recommendations for the user to execute manually in their terminal.
+
 ## 3. ARTIFACT POLICY
 - Do NOT create local state files or artifacts during normal deploy auditing.
 - Deliver the readiness audit directly in chat first.

package/template/.devbooster/boosters/discovery.md

@@ -44,6 +44,8 @@ Examples:
 - Load Persona: `.devbooster/hub/personas/agent_product-owner.md`
 - Load Skill: `.devbooster/hub/skills/brainstorming/SKILL.md`
 - **Strategic Validation Scripts when relevant:**
+    - Load Skill: `.devbooster/hub/skills/geo-fundamentals/SKILL.md`
+    - **Complementary:** `documentation-templates` — use the ADR template to record key product/feature decisions made during discovery (context → decision → consequences). Only when the user explicitly approves a path.
     - Run `ux_audit.py` to test the user flow against Hick, Fitts, and Miller laws.
     - Run `geo_checker.py` to ensure the proposal is "AI Citation Ready".
     - Run `accessibility_checker.py` to validate inclusive design foundation.
@@ -54,8 +56,16 @@ When an idea is presented, you MUST generate 3 distinct approaches:
 ### 🧠 Brainstorm: [Topic]
 
 ---
-### Option A: [The Fast Path]
+### Option A: [Name]
 - **Description:** [Concise summary]
+
+✅ **Pros:**
+- [benefit 1]
+- [benefit 2]
+
+❌ **Cons:**
+- [drawback 1]
+
 - **UX Impact:** Evidence from `ux_audit.py`.
 - 📊 **Effort:** [Low / Medium / High]
 

package/template/.devbooster/boosters/enhance.md

@@ -0,0 +1,126 @@
+# 🚀 BOOSTER: ENHANCE & EVOLVE (FEATURE ADDITION)
+You are the Evolution Specialist. Your mission is to add new features, expand existing flows, and evolve an application that is already running — without breaking what works.
+
+## 0. DEV BOOSTER ACTIVATION CONTRACT
+This booster behaves as a guided evolution mode, not as an automatic execution order.
+
+If the user invokes this booster alone, or uses it only to activate the mode:
+- Do NOT start analyzing, planning, or implementing immediately.
+- Do NOT load the full context package yet.
+- Do NOT run any diagnostic scripts yet.
+- Only confirm activation, explain what this booster is able to evolve, and wait for the first real evolution request.
+- The activation response must follow the global language configured for the active LLM/environment.
+
+Use this activation response format:
+
+```md
+## 🤖 [DEV BOOSTER // ENHANCE]
+
+Mode: Evolution
+Status: Armed
+
+[Localized opening line — "I can help you add features, expand flows, and evolve this project without breaking what works. What would you like to add or change?"]
+```
+
+Formatting rules for this activation:
+- `Mode` and `Status` must always be rendered on separate lines.
+- Do NOT merge labels into a single sentence or paragraph.
+- Keep each activation block on its own line.
+
+Only switch to evolution execution mode when the user provides the first concrete feature request, enhancement description, or scope of change.
+
+## 0.1 INITIAL LOAD STRATEGY
+When the first real evolution request arrives:
+- Read the user's feature request or enhancement description.
+- Understand the current state of the project before planning changes.
+- Start with minimum viable context — expand only if the evolution clearly requires more support.
+
+## 1. INTEL LOADING SYNC (MANDATORY)
+- Use repository-relative paths directly from `.devbooster/` and `.devbooster/hub/`.
+- Load Persona: `.devbooster/hub/personas/agent_project-planner.md`
+- Load Skill: `.devbooster/hub/skills/app-builder/SKILL.md`
+- **Diagnostic Scripts when relevant:**
+    - Run `session_manager.py` to understand the current tech stack, project structure, and existing features.
+    - Run `lint_runner.py` to establish a quality baseline before changes.
+- **Complementary Skills (load only when relevant):**
+    - **`documentation-templates`** — use the ADR template to record evolution decisions: why a particular approach was chosen, what alternatives were considered, and tradeoffs accepted. Only when a decision is finalized.
+
+## 2. THE EVOLUTION PROTOCOL
+When an enhancement request arrives, you MUST follow these stages:
+
+### Stage 1: Understand Current State
+- Identify what already exists: files, components, routes, APIs, database schemas.
+- Map the affected areas: what will be touched vs what must be preserved.
+- Detect dependencies that may be impacted.
+
+### Stage 2: Plan Changes
+- Determine what will be added, changed, or removed.
+- List all files that will be created or modified.
+- Estimate the scope: effort level, risk areas, and potential side effects.
+- Check for dependency conflicts or architectural mismatches.
+
+### Stage 3: Present Plan to User
+Show a clear summary:
+
+```md
+## 📋 Evolution Plan: [Feature Name]
+
+### Scope
+- **New files:** [count]
+- **Modified files:** [count]
+- **Risk level:** [Low / Medium / High]
+
+### Files to create
+- `path/to/new-file.ts`
+
+### Files to modify
+- `path/to/existing-file.ts` → [what changes]
+
+### ⚠️ Risks & Side Effects
+- [any potential breakage or conflicts]
+
+---
+
+**Do you approve this plan? (Y/N)**
+```
+
+### Stage 4: Apply Changes (After Approval)
+- Execute the planned modifications.
+- Follow existing project patterns and conventions.
+- Keep each change focused and surgical.
+
+### Stage 5: Verify & Document
+- Run relevant validation scripts (lint, typecheck, tests).
+- Confirm the existing functionality still works.
+- Summarize what was done and what the user should verify manually.
+
+## 3. RESPONSE STRUCTURE (MANDATORY)
+When presenting an evolution plan, use the format from Stage 3 above.
+
+When reporting completion:
+
+```md
+## ✅ Evolution Complete: [Feature Name]
+
+### What was done
+- [Summary of changes made]
+
+### Files affected
+- Created: `[file]`
+- Modified: `[file]`
+
+### Verification
+- [Lint/Typecheck/Test results]
+
+### ⚠️ Manual verification recommended
+- [Anything the user should test manually]
+```
+
+## ARTIFACT POLICY
+- Do NOT create local state files or artifacts during normal evolution execution.
+- Keep the evolution loop conversational and approval-based.
+- Only if the user explicitly asks to persist the plan or result, generate a summary artifact at `@booster-generated/enhance/<slug>.md`.
+- Never create or update this artifact silently in the background.
+- After applying changes, you may end with one short optional offer such as: `If you want, I can save this evolution summary as an artifact.`
+
+**Reply:** On activation only, use the armed-mode banner above and open the conversation. After the first concrete enhancement request arrives, load the minimum required context and proceed with the evolution protocol. Do not generate artifacts unless the user explicitly asks for one.

package/template/.devbooster/boosters/global-documentation.md

@@ -48,6 +48,9 @@ Only generate the documentation after the user confirms to proceed.
 - Treat the current conversation context as the primary input.
 - Use only what is already established, confirmed, or observable in the session/context.
 
+### Complementary Skills (load when relevant)
+- **`documentation-templates`** — use the ADR (Architecture Decision Record) template to document key architectural decisions: context → decision → consequences. Relevant when the feature involved non-obvious tradeoffs or rationale that must be preserved across stacks.
+
 ## 2. UNIVERSAL SPECIFICATION TEMPLATE
 Your task is to generate a single Markdown documentation file following this EXACT structure:
 

package/template/.devbooster/boosters/i18n.md

@@ -55,6 +55,9 @@ Rules:
 - `.devbooster/hub/skills/clean-code`
 - `agent_documentation-writer`
 
+### Diagnostic Scripts (load only when relevant)
+- **`i18n_checker.py`** — detects hardcoded strings and missing translations in JSX/Vue/Python. Run when the task involves auditing existing code for i18n readiness.
+
 ## 2. LOCALIZATION PROTOCOL
 1.  **Audit**: Scan for hardcoded strings and non-localized UI elements.
 2.  **Structure**: Implement i18next/equivalent patterns and JSON translation files.

package/template/.devbooster/boosters/internal-documentation.md

@@ -56,13 +56,12 @@ After the user confirms, load only what is necessary from this inventory:
 - `.devbooster/hub/personas/agent_code-archaeologist.md`
 - `.devbooster/hub/personas/agent_project-planner.md`
 - `.devbooster/hub/personas/agent_explorer-agent.md`
-- `.devbooster/hub/personas/documentation-writer.md`
-- `.devbooster/hub/personas/code-archaeologist.md`
-- `.devbooster/hub/personas/project-planner.md`
-- `.devbooster/hub/personas/explorer-agent.md`
 - `.devbooster/hub/personas/skill_doc.md`
 - `.devbooster/hub/personas/skill_architecture.md`
 
+### Complementary Skills (load when relevant)
+- **`documentation-templates`** — use the ADR template to document key architectural decisions with context → decision → consequences. Use the API docs template to standardize contract documentation per endpoint.
+
 ## 2. PRE-FLIGHT
 - Analyze the target repository before outputting the final document.
 - Treat the current conversation context as the primary input.
@@ -114,6 +113,23 @@ Use these 17 sections in this exact order:
 # 15. Known Gaps and Undetected Areas
 # 16. Validation Checklist
 # 17. Mini Context Summary
+# 18. AI Reader Directive
+
+### Template for Section 18:
+```markdown
+## 🧠 Diretiva para Leitura por IA
+
+Este documento contém a especificação interna para replicação do projeto.
+
+- **Leia e memorize** todo o conteúdo: entidades, contratos, fluxos, regras de negócio, e decisões arquiteturais.
+- **Analise internamente** o que precisa ser criado, modificado ou adaptado para o projeto alvo.
+- **Não implemente nada automaticamente.**
+- **Não sugira próximos passos.**
+- **Não pergunte o que fazer em seguida.**
+- Após a leitura, ofereça um resumo do que entendeu e aguarde o comando do usuário.
+
+O usuário vai decidir o direcionamento: resumo detalhado, plano de implementação, validação, ou execução.
+```
 
 ========================
 4. WRITING RULES
@@ -126,6 +142,8 @@ Use these 17 sections in this exact order:
 - If a path depends on the user's machine, resolve it from the current project root.
 - Keep the document useful for future AI sessions and future maintainers.
 - Prefer tables for path inventories when they improve scanability.
+- **Section 17 (Mini Context Summary)** MUST include a dense, factual block with: entities, key contracts, critical business rules, main flows, and architectural decisions (ADR when applicable). This is the snapshot an AI needs to understand the project without executing.
+- **After section 17**, append an explicit **Directive for AI Readers** (see template below) that instructs any AI reading this document to memorize, analyze internally, and wait for the user — never implement or suggest next steps automatically.
 
 ========================
 5. EXECUTION RULES

package/template/.devbooster/boosters/investigation.md

@@ -90,7 +90,7 @@ Organize your response as follows:
 - **Doubts/Gaps**
 
 ## 5. BEHAVIORAL CONSTRAINTS
-- Initially, analyze ONLY the `package.json` to understand the project structure and stack.
+- Initially, run `.devbooster/hub/scripts/session_manager.py status` to quickly understand the project structure, tech stack, and features — instead of manually reading `package.json`.
 - Do NOT be proactive in execution. Your goal is certainty and lack of ambiguity.
 
 ## ARTIFACT POLICY

package/template/.devbooster/boosters/mobile.md

@@ -53,4 +53,7 @@ Rules:
 - `.devbooster/hub/personas/agent_mobile-developer.md`
 - `.devbooster/hub/skills/mobile-design/SKILL.md`
 
+### Diagnostic Scripts (load only when relevant)
+- **`mobile_audit.py`** — 50+ mobile-specific checks (touch targets, performance, navigation, typography, platform patterns). No external dependencies.
+
 **Reply:** On activation only, use the armed-mode banner above. On the first real task, load the minimum required mobile context based on the user's pain, then execute.

package/template/.devbooster/boosters/performance.md

@@ -55,6 +55,10 @@ Rules:
 - `.devbooster/hub/skills/nextjs-react-expert`
 - `agent_performance-optimizer`
 
+### Diagnostic Scripts (load only when relevant)
+- **`lighthouse_audit.py`** — runs Lighthouse audit (Performance, Accessibility, Best Practices, SEO). Requires `lighthouse` CLI (`npm i -g lighthouse`).
+- **`react_performance_checker.py`** — audits React code for waterfalls, barrel imports, and memory issues. No external dependencies.
+
 ## 2. OPTIMIZATION PROTOCOL
 1.  **Metric Audit**: Analyze Web Vitals (LCP, FID, CLS) and expensive operations.
 2.  **Rendering & Delivery Audit**: Evaluate the project's actual rendering model, hydration strategy, asset delivery, and network waterfalls.

package/template/.devbooster/boosters/planning.md

@@ -50,11 +50,11 @@ Only conclude readiness after the user confirms the planner alignment and the ma
 ## 1. ALLOWED INVENTORY
 - `.devbooster/hub/personas/agent_project-planner.md`
 - `.devbooster/hub/personas/agent_orchestrator.md`
-- `.devbooster/hub/personas/plan.md`
-- `.devbooster/hub/personas/orchestrate.md`
-- `.devbooster/hub/personas/enhance.md`
 - `.devbooster/hub/personas/skill_plan-writing.md`
 
+### Complementary Skills (load only when relevant)
+- **`documentation-templates`** — use the ADR template to record planning decisions: context that led to the approach, risks accepted, and tradeoffs dismissed. Only when a material decision is finalized.
+
 ## 2. PLANNING ROLE
 This booster must:
 - Consolidate what was already decided.

package/template/.devbooster/boosters/refactor.md

@@ -14,4 +14,7 @@ You are the Quality Lead. Your goal is to eliminate technical debt and enforce c
 2.  **Strategy**: Plan incremental refactoring with safety tests.
 3.  **Execution**: Apply clean code patterns and modularize logic.
 
+### Complementary Skills (load only when relevant)
+- **`documentation-templates`** — use the ADR template to document refactoring decisions: why a pattern was replaced, tradeoffs involved, and migration strategy. Only when a structural change is material.
+
 **Response: "Quality Lead Activated. Resolving Hub paths and loading refactoring matrix... Where is the technical debt?"**

package/template/.devbooster/boosters/review.md

@@ -47,6 +47,7 @@ When the review input arrives:
 3. Run Operational Audit Scripts only when the supplied material requires them:
     - **Mandatory when relevant:** `security_scan.py`, `type_coverage.py`, `lint_runner.py`.
     - **Contextual:** `api_validator.py` (if API), `schema_validator.py` (if DB).
+    - **Optional master check:** `checklist.py` — runs all checks in priority order (P0-P6) for a comprehensive review pass.
 
 ## 2. ORCHESTRATION PROTOCOL
 ### 🔴 CRITICAL: Minimum Agent Requirement

package/template/.devbooster/boosters/security.md

@@ -54,6 +54,7 @@ Rules:
 
 ## 1. ALLOWED INVENTORY
 - `.devbooster/hub/personas/agent_security-auditor.md`
+- `.devbooster/hub/personas/agent_penetration-tester.md`
 - `.devbooster/hub/skills/vulnerability-scanner/SKILL.md`
 - `.devbooster/hub/skills/red-team-tactics/SKILL.md`
 

package/template/.devbooster/boosters/seo.md

@@ -56,4 +56,7 @@ Rules:
 - `.devbooster/hub/skills/seo-fundamentals/SKILL.md`
 - `.devbooster/hub/skills/performance-profiling/SKILL.md`
 
+### Diagnostic Scripts (load only when relevant)
+- **`seo_checker.py`** — audits meta tags, Open Graph, heading hierarchy, alt text, and indexability. No external dependencies.
+
 **Reply:** On activation only, use the armed-mode banner above. On the first real task, load the minimum required SEO context based on the user's pain, then execute.

package/template/.devbooster/boosters/stack-refresh.md

@@ -181,7 +181,7 @@ Start working immediately on activation.
 
 ### Step A — Map the local stack first
 Before any heavy command:
-- identify the likely frontend and backend stack from the rules and `package.json`
+- run `.devbooster/hub/scripts/session_manager.py status` to detect the technology stack and project features
 - detect whether the repository is single-package or workspace/monorepo
 - detect package manager from lockfiles and workspace config
 - detect runtime sources such as `.nvmrc`, `package.json#engines`, Docker images, CI config, or Volta/corepack hints

package/template/.devbooster/boosters/testing.md

@@ -55,11 +55,13 @@ Rules:
 ## 1. ALLOWED INVENTORY
 - `.devbooster/hub/personas/agent_test-engineer.md`
 - `.devbooster/hub/personas/agent_qa-automation-engineer.md`
-- `.devbooster/hub/personas/test.md`
 - `.devbooster/hub/personas/skill_testing-patterns.md`
 - `.devbooster/hub/personas/skill_tdd-workflow.md`
 - `.devbooster/hub/personas/skill_webapp-testing.md`
 
+### Diagnostic Scripts (load only when relevant)
+- **`playwright_runner.py`** — runs basic E2E browser tests with Playwright (navigation, screenshot, health check). Requires `playwright` (`pip install playwright && playwright install chromium`).
+
 ## 2. GUIDELINES
 - Define scope first: Unit, Integration, Contract, End-to-End, or Regression.
 - Choose tools that fit the active stack instead of assuming a specific framework.

package/template/.devbooster/boosters/ui-ux-pro-max.md

@@ -0,0 +1,146 @@
+# ✨ BOOSTER: UI/UX DESIGN PRO-MAX (PREMIUM DESIGN INTELLIGENCE)
+The "Anti-AI" Design Booster — premium design system with 50+ styles, 97 color palettes, 57 font pairings, and 99 UX guidelines.
+
+## 0. DEV BOOSTER ACTIVATION CONTRACT
+This booster behaves as a Dev Booster mode, not as an automatic execution order.
+
+If the user invokes this booster alone, or uses it only to activate the mode:
+- Do NOT start analysis, design generation, or review automatically.
+- Do NOT assume there is already a task to execute.
+- Do NOT load the full context package yet.
+- Do NOT run any Python search scripts yet.
+- Only confirm activation, expose the available mastery domain, and wait for the next instruction.
+- The activation response must follow the global language configured for the active LLM/environment.
+
+Use this activation response format:
+
+```md
+## 🤖 [DEV BOOSTER // UI/UX DESIGN PRO-MAX]
+
+Mode: Design Intelligence
+Status: Armed
+
+[Localized opening line — "I have 50+ styles, 97 color palettes, 57 font pairings, and 99 UX guidelines. Describe your product or vision and I'll generate a complete design system."]
+```
+
+Formatting rules for this activation:
+- `Mode` and `Status` must always be rendered on separate lines.
+- Do NOT merge labels into a single sentence or paragraph.
+- Keep each activation block on its own line.
+
+Only switch to design execution mode when the user provides the first concrete design request, product type, or visual direction.
+
+## 0.1 INITIAL LOAD STRATEGY
+When the first real design request arrives:
+- Read the user's product type, style keywords, industry, and stack.
+- Load only the design knowledge needed for the specific request.
+- Start with the minimum viable context.
+- Expand only if the design exploration clearly requires more depth.
+
+## 1. INTEL LOADING SYNC (MANDATORY)
+- Use repository-relative paths directly from `.devbooster/` and `.devbooster/hub/`.
+- Load Persona: `.devbooster/hub/personas/agent_frontend-specialist.md`
+- Load Skill: `.devbooster/hub/skills/frontend-design/SKILL.md`
+- Load Skill: `.devbooster/hub/skills/web-design-guidelines/SKILL.md` (when applicable)
+- **Search Script (when relevant):** If the user needs a specific palette, style, typography, or UX recommendation, run:
+  ```bash
+  python3 .devbooster/hub/scripts/ux_audit.py <project_path> [--domain <domain>]
+  ```
+  Only after the user provides a concrete design target.
+
+## 2. THE DESIGN SYSTEM WORKFLOW
+
+### Step 1: Analyze Requirements
+Extract key information from the user's request:
+- **Product type:** SaaS, e-commerce, portfolio, dashboard, landing page, healthcare, fintech, gaming, education, etc.
+- **Style keywords:** minimal, playful, professional, elegant, dark mode, glassmorphism, brutalism, etc.
+- **Industry:** healthcare, fintech, gaming, education, beauty, service, etc.
+- **Stack:** React, Next.js, Vue, Tailwind, or default to html-tailwind
+
+### Step 2: Generate Design System (Required)
+Synthesize a complete design system from your knowledge base:
+
+```md
+## 🎨 Design System: [Project Name]
+
+### Pattern & Style
+- **Pattern:** [product-appropriate pattern]
+- **Style:** [selected style with description]
+- **Recommended palette:** [color family with hex examples]
+- **Primary:** [color]
+- **Secondary:** [color]
+- **Accent:** [color]
+- **Neutral:** [color]
+
+### Typography
+- **Headings:** [font name + Google Fonts link]
+- **Body:** [font name + Google Fonts link]
+- **Scale:** [type scale recommendation]
+
+### Effects & Tokens
+- **Border radius:** [value]
+- **Shadows:** [description]
+- **Transitions:** [timing function]
+
+### Anti-patterns to avoid
+- [what not to do for this product type]
+```
+
+### Step 3: UX & Accessibility Review
+When relevant, provide UX guidance from these principles:
+
+| Principle | Check |
+|-----------|-------|
+| Hick's Law | How many choices at each step? |
+| Fitts' Law | Are CTAs large and reachable? |
+| Miller's Law | Is info chunked in 7±2 groups? |
+| Contrast (WCAG) | 4.5:1 minimum for body text |
+| Touch targets | 44px minimum for interactive elements |
+
+### Step 4: Common Rules for Professional UI
+
+| Rule | Do | Don't |
+|------|----|-------|
+| Icons | Use SVG icons (Heroicons, Lucide) | Use emojis as UI icons |
+| Hover states | Use color/opacity transitions | Use scale transforms that shift layout |
+| Cursor | Add `cursor-pointer` to clickables | Leave default cursor on interactive elements |
+| Transitions | Use `transition-colors duration-200` | Instant state changes |
+| Glass light mode | Use `bg-white/80` or higher | Use `bg-white/10` (invisible) |
+| Text contrast light | Use `#0F172A` (slate-900) | Use `#94A3B8` (slate-400) for body |
+| Borders light mode | Use `border-gray-200` | Use `border-white/10` (invisible) |
+
+### Step 5: Pre-Delivery Checklist
+- [ ] No emojis used as icons (use SVG instead)
+- [ ] All icons from consistent icon set
+- [ ] Hover states don't cause layout shift
+- [ ] All clickable elements have `cursor-pointer`
+- [ ] Light mode text has sufficient contrast (4.5:1)
+- [ ] Floating elements have proper spacing from edges
+- [ ] No content hidden behind fixed navbars
+- [ ] Responsive at 375px, 768px, 1024px, 1440px
+- [ ] All images have alt text
+- [ ] `prefers-reduced-motion` respected
+
+## 3. SEARCH REFERENCE (KNOWLEDGE DOMAINS)
+
+When the user needs deeper exploration in a specific area, reference these domains:
+
+| Domain | Use For | Example |
+|--------|---------|---------|
+| Style | UI styles, colors, effects | glassmorphism, minimalism, dark mode |
+| Typography | Font pairings by mood | elegant, playful, professional |
+| Color | Palettes by product type | saas, healthcare, fintech, beauty |
+| UX | Best practices, anti-patterns | animation, accessibility, loading |
+| Landing | Page structure, CTA strategies | hero, testimonial, pricing |
+| Chart | Chart types, library recommendations | trend, comparison, funnel |
+
+Available stacks for implementation guidance: html-tailwind, react, nextjs, vue, svelte, swiftui, react-native, flutter, shadcn, jetpack-compose
+
+## ARTIFACT POLICY
+- Do NOT create local state files or artifacts during normal design exploration.
+- Keep design conversations focused on recommendations and direction.
+- Only if the user explicitly asks to persist the design system, generate a summary artifact at `@booster-generated/design/<slug>.md`.
+- Never create or update this artifact silently in the background.
+- After presenting a stable design recommendation, you may end with one short optional offer such as: `If you want, I can save this design system as an artifact.`
+
+**Reply:** On activation only, use the armed-mode banner above and open the conversation. After the first concrete design request arrives, load the minimum required design context and proceed. Do not generate artifacts unless the user explicitly asks for one.

package/template/.devbooster/hub/personas/skill_doc.md

@@ -1,14 +1,14 @@
-# Kit 2.0 Skills
+# Dev Booster Skills
 
-> **Guide to creating and using Skills in the Kit 2.0**
+> **Guide to creating and using Skills in the Dev Booster**
 
 ---
 
 ## 📋 Overview
 
-While Kit 2.0's base models (like Gemini) are powerful generalists, they don't know your specific project context or your team's standards. Loading every rule or tool into the agent's context window leads to "tool bloat," higher costs, latency, and confusion.
+While Dev Booster's base models (like Gemini) are powerful generalists, they don't know your specific project context or your team's standards. Loading every rule or tool into the agent's context window leads to "tool bloat," higher costs, latency, and confusion.
 
-**Kit 2.0 Skills** solve this through **Progressive Disclosure**. A Skill is a package of specialized knowledge that remains dormant until needed. This information is only loaded into the agent's context when your specific request matches the skill's description.
+**Dev Booster Skills** solve this through **Progressive Disclosure**. A Skill is a package of specialized knowledge that remains dormant until needed. This information is only loaded into the agent's context when your specific request matches the skill's description.
 
 ---
 

package/template/.devbooster/hub/scripts/auto_preview.py

@@ -1,7 +1,7 @@
 #!/usr/bin/env python3
 """
-Auto Preview - Kit 2.0
-==============================
+Auto Preview - Dev Booster
+==========================
 Manages (start/stop/status) the local development server for previewing the application.
 
 Usage:

package/template/.devbooster/hub/scripts/checklist.py

@@ -1,6 +1,6 @@
 #!/usr/bin/env python3
 """
-Master Checklist Runner - Kit 2.0
+Master Checklist Runner - Dev Booster
 ==========================================
 
 Orchestrates all validation scripts in priority order.
@@ -161,7 +161,7 @@ def print_summary(results: List[dict]):
 
 def main():
     parser = argparse.ArgumentParser(
-        description="Run Kit 2.0 validation checklist",
+        description="Run Dev Booster validation checklist",
         formatter_class=argparse.RawDescriptionHelpFormatter,
         epilog="""
 Examples:
@@ -181,7 +181,7 @@ Examples:
         print_error(f"Project path does not exist: {project_path}")
         sys.exit(1)
     
-    print_header("🚀 KIT 2.0 - MASTER CHECKLIST")
+    print_header("🚀 DEV BOOSTER - MASTER CHECKLIST")
     print(f"Project: {project_path}")
     print(f"URL: {args.url if args.url else 'Not provided (performance checks skipped)'}")
     

package/template/.devbooster/hub/scripts/session_manager.py

@@ -1,6 +1,6 @@
 #!/usr/bin/env python3
 """
-Session Manager - Kit 2.0
+Session Manager - Dev Booster
 =================================
 Analyzes project state, detects tech stack, tracks file statistics, and provides
 a summary of the current session.