docs: update all documentation and add AI tooling configs
- Rewrite README.md with current architecture, features and stack - Update docs/API.md with all current endpoints (corporate, BI, client 360) - Update docs/ARCHITECTURE.md with cache, modular queries, services, ETL - Update docs/GUIA-USUARIO.md for all roles (admin, corporate, agente) - Add docs/INDEX.md documentation index - Add PROJETO.md comprehensive project reference - Add BI-CCC-Implementation-Guide.md - Include AI agent configs (.claude, .agents, .gemini, _bmad) - Add netbird VPN configuration - Add status report Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,156 @@
|
||||
---
|
||||
name: 'step-01-identify-target'
|
||||
description: 'Define what to reverse engineer, how to access it, and what to extract'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-02-explore-and-capture.md'
|
||||
---
|
||||
|
||||
# Step 1: Identify Target
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define what to reverse engineer, how to access it, and what to extract.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on defining the target, determining access method, defining extraction goals, and documenting the target overview
|
||||
- 🚫 FORBIDDEN to begin exploring or capturing the target — that is the next step
|
||||
- 💬 Approach: Help user clearly define what they want to reverse engineer and what they need from it
|
||||
- 📋 Access method must be verified before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Clear target definition with access method and extraction goals
|
||||
- 💾 Document target overview in dialog file
|
||||
- 📖 Reference the target type table and extraction goals checklist
|
||||
- 🚫 Do not begin exploring or capturing any content
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: User's initial request or target description
|
||||
- Focus: Target identification — what, how, and what to extract
|
||||
- Limits: No exploration, no capturing
|
||||
- Dependencies: None — this is the first step
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Define the Target
|
||||
|
||||
Identify what you are reverse engineering:
|
||||
|
||||
| Target Type | Examples |
|
||||
|-------------|----------|
|
||||
| **Website** | Public marketing site, SaaS application, e-commerce store |
|
||||
| **Web application** | Dashboard, admin panel, booking system |
|
||||
| **Component library** | Design system documentation site, Storybook instance |
|
||||
| **Mobile app** | iOS/Android app (via screenshots or simulator) |
|
||||
| **Source code** | Your own codebase, open source project |
|
||||
|
||||
Write a clear target description:
|
||||
|
||||
```
|
||||
Target: [Name / URL / Project]
|
||||
Type: [Website / Web app / Component library / Mobile app / Source code]
|
||||
Owner: [Own product / Client product / Public / Competitor]
|
||||
```
|
||||
|
||||
### 2. Determine Access Method
|
||||
|
||||
How will you explore the target?
|
||||
|
||||
| Access Method | When to Use | Tools |
|
||||
|---------------|-------------|-------|
|
||||
| **URL (browser)** | Public websites, web apps with demo | Puppeteer, browser DevTools |
|
||||
| **Source code** | Own codebase, open source | File reading, code analysis |
|
||||
| **Screenshots** | No live access, mobile apps, provided by client | Image analysis |
|
||||
| **Combination** | Source code + live URL | Both code and browser |
|
||||
|
||||
Note any access limitations (login required, rate limits, geo-restrictions).
|
||||
|
||||
### 3. Define Extraction Goals
|
||||
|
||||
What do you need to extract? Check all that apply:
|
||||
|
||||
- [ ] **Page specifications** — Layout, structure, content for each page
|
||||
- [ ] **Design system** — Colors, typography, spacing, shadows, tokens
|
||||
- [ ] **Component inventory** — Reusable UI components, variants, states
|
||||
- [ ] **Content strategy** — Copy patterns, tone, content hierarchy
|
||||
- [ ] **Architecture** — Tech stack, routing, data flow (requires source access)
|
||||
- [ ] **User flows** — Multi-page journeys, interaction patterns
|
||||
- [ ] **All of the above** — Full extraction for rebuild or migration
|
||||
|
||||
### 4. Document Target Overview
|
||||
|
||||
Create a brief overview to guide the exploration:
|
||||
|
||||
```
|
||||
Target Overview:
|
||||
- Name: [Name]
|
||||
- URL: [URL or "source code at /path/"]
|
||||
- Access: [Browser / Source / Screenshots]
|
||||
- Goals: [What to extract]
|
||||
- Output language: [Language for generated specs]
|
||||
- Pages estimated: [Rough count if known]
|
||||
- Notes: [Login required? Special states? Known complexity?]
|
||||
```
|
||||
|
||||
### 5. Verify Checklist
|
||||
|
||||
- [ ] Target clearly identified with name and type
|
||||
- [ ] Access method determined and verified (URL loads, source exists, screenshots provided)
|
||||
- [ ] Extraction goals defined
|
||||
- [ ] Target overview documented
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [C] Continue to Step 2: Explore and Capture"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN the target is defined with access method verified and extraction goals documented will you then load and read fully `{nextStepFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- Target clearly identified with name and type
|
||||
- Access method determined and verified
|
||||
- Extraction goals defined
|
||||
- Target overview documented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Beginning exploration before target is fully defined
|
||||
- Not verifying access method
|
||||
- Not defining extraction goals
|
||||
- Skipping target documentation
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,173 @@
|
||||
---
|
||||
name: 'step-02-explore-and-capture'
|
||||
description: 'Systematically explore the target and capture a complete inventory of pages, components, patterns, and design tokens'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-03-generate-specs.md'
|
||||
---
|
||||
|
||||
# Step 2: Explore and Capture
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Systematically explore the target and capture a complete inventory of pages, components, patterns, and design tokens.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on crawling pages, capturing structure, noting interactions, and extracting design tokens
|
||||
- 🚫 FORBIDDEN to begin generating specs — that is the next step
|
||||
- 💬 Approach: Systematically explore using the access method, documenting everything as inventories
|
||||
- 📋 Use the appropriate exploration method (URL, source code, or screenshots) as determined in Step 1
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Complete inventories of pages, navigation, components, colors, typography, and spacing
|
||||
- 💾 Document all inventories in the dialog file
|
||||
- 📖 Reference the access method and extraction goals from Step 1
|
||||
- 🚫 Do not generate specs during exploration
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Target definition and access method from Step 1
|
||||
- Focus: Exploration and capturing — inventorying everything found
|
||||
- Limits: No spec generation, no design system document creation
|
||||
- Dependencies: Step 1 must be complete (target defined, access verified)
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### If URL (Browser Access)
|
||||
|
||||
#### 1a. Crawl Pages
|
||||
|
||||
1. Start at the home page or main entry point
|
||||
2. Follow navigation links to discover all pages
|
||||
3. For each page, note: URL, page title, primary purpose, key content sections, interactive elements
|
||||
4. Check for hidden pages: sitemap.xml, footer links, search results
|
||||
|
||||
#### 1b. Capture Structure
|
||||
|
||||
For each page: Header, Main content, Footer, Sidebar (if present)
|
||||
|
||||
#### 1c. Note Interactions
|
||||
|
||||
Hover states, dropdown behavior, form validation, modal triggers, loading states, responsive breakpoints
|
||||
|
||||
#### 1d. Extract CSS and Design Tokens
|
||||
|
||||
From browser DevTools or computed styles: colors, fonts, spacing, border radius, shadows, breakpoints
|
||||
|
||||
### If Source Code Access
|
||||
|
||||
#### 1e. Read Code Structure
|
||||
|
||||
Identify component directory, list and categorize components, map routes, identify shared styles and theme config
|
||||
|
||||
#### 1f. Map Routes
|
||||
|
||||
Create a route inventory mapping URLs to pages/views
|
||||
|
||||
### If Screenshots
|
||||
|
||||
#### 1g. Analyze Visual Patterns
|
||||
|
||||
For each screenshot: identify page type, sketch layout grid, list components, note typography hierarchy, extract colors, note spacing rhythm
|
||||
|
||||
### Document Results (All Methods)
|
||||
|
||||
Compile findings into these inventories:
|
||||
|
||||
#### Page Inventory
|
||||
|
||||
| # | Page | URL / Route | Type | Key Sections |
|
||||
|---|------|-------------|------|--------------|
|
||||
| 1 | Home | / | Landing | Hero, Features, Testimonials, CTA |
|
||||
| 2 | About | /about | Content | Story, Team, Values |
|
||||
|
||||
#### Navigation Structure
|
||||
|
||||
Primary nav, secondary nav, footer nav, mobile nav
|
||||
|
||||
#### Component Inventory
|
||||
|
||||
| Component | Variants | Used On |
|
||||
|-----------|----------|---------|
|
||||
|
||||
#### Color Palette
|
||||
|
||||
| Name | Value | Usage |
|
||||
|------|-------|-------|
|
||||
|
||||
#### Typography Scale
|
||||
|
||||
| Level | Size | Weight | Line Height | Usage |
|
||||
|-------|------|--------|-------------|-------|
|
||||
|
||||
#### Spacing Patterns
|
||||
|
||||
Note the base spacing unit and common values.
|
||||
|
||||
### Verify Checklist
|
||||
|
||||
- [ ] All pages discovered and inventoried
|
||||
- [ ] Navigation structure documented
|
||||
- [ ] Component inventory created
|
||||
- [ ] Color palette extracted
|
||||
- [ ] Typography scale documented
|
||||
- [ ] Spacing patterns noted
|
||||
- [ ] Interactive patterns observed (hover, modal, form behavior)
|
||||
|
||||
### Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [C] Continue to Step 3: Generate Specs"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN all inventories are captured and documented will you then load and read fully `{nextStepFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- All pages discovered and inventoried
|
||||
- Navigation structure documented
|
||||
- Component inventory created
|
||||
- Color palette extracted
|
||||
- Typography scale documented
|
||||
- Spacing patterns noted
|
||||
- Interactive patterns observed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Beginning spec generation before exploration is complete
|
||||
- Missing pages or components in inventory
|
||||
- Not extracting design tokens
|
||||
- Skipping interaction observation
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,146 @@
|
||||
---
|
||||
name: 'step-03-generate-specs'
|
||||
description: 'Create WDS-format page specifications from the observations captured in Step 02'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-04-extract-design-system.md'
|
||||
---
|
||||
|
||||
# Step 3: Generate Specs
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Create WDS-format page specifications from the observations captured in Step 02. Generate all output in `document_output_language`.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on prioritizing pages, generating page specifications, creating scenario outlines, and cross-referencing with components
|
||||
- 🚫 FORBIDDEN to begin extracting the design system — that is the next step
|
||||
- 💬 Approach: Generate specifications collaboratively, starting with foundational pages
|
||||
- 📋 Every component mentioned in specs must appear in the component inventory from Step 02
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Complete page specifications and scenario outlines generated in WDS format
|
||||
- 💾 Save all specifications to the output folder
|
||||
- 📖 Reference page inventory and component inventory from Step 02
|
||||
- 🚫 Do not create the design system document yet
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All inventories from Step 02 (pages, components, colors, typography, spacing)
|
||||
- Focus: Spec generation — page specs, scenario outlines, cross-referencing
|
||||
- Limits: No design system extraction
|
||||
- Dependencies: Step 02 must be complete (inventories captured)
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Prioritize Pages
|
||||
|
||||
From the page inventory (Step 02), decide which pages to spec first:
|
||||
|
||||
- Start with the most representative or foundational pages
|
||||
- Group pages that share layout patterns
|
||||
- Skip pages that are nearly identical (spec one, note variations)
|
||||
|
||||
### 2. Generate Page Specification for Each Page
|
||||
|
||||
For each page, create a specification document following the WDS page spec structure:
|
||||
|
||||
- Overview (purpose, URL, type)
|
||||
- Layout Structure (desktop layout, sections top to bottom)
|
||||
- Component List (component, location, variant, notes)
|
||||
- Content Strategy (headline pattern, body copy, CTA language, images)
|
||||
- Responsive Behavior (breakpoint changes)
|
||||
- Interactions (hover, click, scroll, form validation, modal triggers)
|
||||
|
||||
### 3. Create Scenario Outlines from User Flows
|
||||
|
||||
If the target has multi-page flows (sign up, checkout, onboarding), document them as scenario outlines with steps, success path, and error states.
|
||||
|
||||
### 4. Cross-Reference with Components
|
||||
|
||||
Ensure every component mentioned in page specs appears in the component inventory from Step 02. Flag any components that appear in specs but were not captured.
|
||||
|
||||
### 5. Save Output
|
||||
|
||||
Save all specifications to the output folder using consistent naming:
|
||||
|
||||
```
|
||||
output/
|
||||
specs/
|
||||
page-home.md
|
||||
page-about.md
|
||||
page-products.md
|
||||
scenarios/
|
||||
scenario-checkout.md
|
||||
scenario-onboarding.md
|
||||
```
|
||||
|
||||
### 6. Verify Checklist
|
||||
|
||||
- [ ] Pages prioritized and ordered
|
||||
- [ ] Page specification created for each key page
|
||||
- [ ] Layout structure documented (desktop and sections)
|
||||
- [ ] Component list matches component inventory from Step 02
|
||||
- [ ] Content strategy noted per page
|
||||
- [ ] Responsive behavior described
|
||||
- [ ] User flow scenarios documented (if applicable)
|
||||
- [ ] All output generated in `document_output_language`
|
||||
- [ ] Specs saved to output folder
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [C] Continue to Step 4: Extract Design System"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN all page specifications and scenario outlines are generated and saved will you then load and read fully `{nextStepFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- Pages prioritized and ordered
|
||||
- Page specification created for each key page
|
||||
- Layout structure documented
|
||||
- Component list matches inventory
|
||||
- Content strategy noted
|
||||
- Responsive behavior described
|
||||
- Specs saved to output folder
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Beginning design system extraction before specs are complete
|
||||
- Missing pages in specifications
|
||||
- Component list does not match inventory
|
||||
- Not saving output
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
name: 'step-04-extract-design-system'
|
||||
description: 'Consolidate all design tokens and component patterns into a structured WDS-compatible design system document'
|
||||
|
||||
# File References
|
||||
activityWorkflowFile: '../workflow-reverse-engineering.md'
|
||||
---
|
||||
|
||||
# Step 4: Extract Design System
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Consolidate all design tokens and component patterns into a structured WDS-compatible design system document.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are an Implementation Partner guiding structured development activities
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
|
||||
- ✅ Maintain clear and structured tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on extracting design tokens, cataloging components, documenting variants/states, mapping tokens to components, and creating the design system document
|
||||
- 🚫 FORBIDDEN to modify page specifications — they are final from Step 03
|
||||
- 💬 Approach: Organize raw values into a structured token system with user input
|
||||
- 📋 Token-to-component mapping must be explicit
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Complete design system document in WDS format
|
||||
- 💾 Save design system document to output folder alongside page specs
|
||||
- 📖 Reference inventories from Step 02 and page specs from Step 03
|
||||
- 🚫 Do not modify existing page specifications
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All inventories from Step 02; page specs from Step 03
|
||||
- Focus: Design system extraction — tokens, components, patterns
|
||||
- Limits: No page spec modifications
|
||||
- Dependencies: Steps 02 and 03 must be complete
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Extract Design Tokens
|
||||
|
||||
Take the raw values captured in Step 02 and organize them into a structured token system:
|
||||
|
||||
#### Colors
|
||||
Group colors by purpose: brand, text, background, border, feedback
|
||||
|
||||
#### Typography
|
||||
Document font families, scale (h1 through caption) with size, weight, and line-height
|
||||
|
||||
#### Spacing
|
||||
Document base unit and scale, note common patterns (section padding, card padding, element gap)
|
||||
|
||||
#### Other Tokens
|
||||
Border radius, shadows, breakpoints
|
||||
|
||||
### 2. Catalog Reusable Components
|
||||
|
||||
For each component in the inventory (from Step 02), document as a component specification with variants, sizes, and states.
|
||||
|
||||
### 3. Document Component Variants and States
|
||||
|
||||
For each component, capture:
|
||||
- **Variants** — Visual variations (primary/secondary, small/medium/large)
|
||||
- **States** — Interactive states (default, hover, focus, active, disabled, loading, error, success)
|
||||
- **Content slots** — What content goes where (icon, label, description, image)
|
||||
- **Responsive behavior** — How the component adapts at different breakpoints
|
||||
|
||||
### 4. Map Token Usage to Components
|
||||
|
||||
Show which tokens each component uses, connecting the token system to the component system.
|
||||
|
||||
| Component | Colors Used | Typography | Spacing | Border Radius |
|
||||
|-----------|------------|------------|---------|---------------|
|
||||
|
||||
### 5. Output in WDS Design System Format
|
||||
|
||||
Compile everything into a single design system document with: Design Tokens, Components, Patterns, and Notes.
|
||||
|
||||
Save to the output folder alongside the page specs from Step 03.
|
||||
|
||||
### 6. Verify Checklist
|
||||
|
||||
- [ ] Color tokens organized by purpose (brand, text, background, border, feedback)
|
||||
- [ ] Typography scale documented (families, sizes, weights, line heights)
|
||||
- [ ] Spacing system extracted (base unit + scale)
|
||||
- [ ] Additional tokens captured (radii, shadows, breakpoints)
|
||||
- [ ] Each component cataloged with variants and states
|
||||
- [ ] Token-to-component mapping created
|
||||
- [ ] Design system document saved in WDS format
|
||||
- [ ] Output is consistent with page specs from Step 03
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF M: Update design log, then load, read entire file, then execute {activityWorkflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed when user selects 'M'
|
||||
- User can chat or ask questions - always respond and then redisplay menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN the design system document is complete and saved will you then load and read fully `{activityWorkflowFile}` to execute.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- Color tokens organized by purpose
|
||||
- Typography scale documented
|
||||
- Spacing system extracted
|
||||
- Each component cataloged with variants and states
|
||||
- Token-to-component mapping created
|
||||
- Design system document saved in WDS format
|
||||
- Output is consistent with page specs
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- Missing token categories (colors, typography, spacing)
|
||||
- Not cataloging components with variants and states
|
||||
- No token-to-component mapping
|
||||
- Design system document not saved
|
||||
- Inconsistency with page specs
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
Reference in New Issue
Block a user