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,131 @@
|
||||
# Content Purpose Examples
|
||||
|
||||
**Three examples demonstrating how to define clear, testable content purpose**
|
||||
|
||||
---
|
||||
|
||||
## Example 1: Landing Page Hero
|
||||
|
||||
```yaml
|
||||
content_purpose:
|
||||
content_type: "Landing page hero section"
|
||||
|
||||
purpose_statement: "Hook Problem Aware hairdressers by validating their frustration and promising transformation"
|
||||
|
||||
audience:
|
||||
who: "Harriet (hairdresser, ambitious, small-town)"
|
||||
state: "Problem Aware - feels behind when clients ask about trends"
|
||||
context: "Landing on site from Google search or Instagram ad"
|
||||
|
||||
success_criteria:
|
||||
- "User immediately recognizes themselves in the problem"
|
||||
- "User feels validated, not alone"
|
||||
- "User wants to continue reading (doesn't bounce)"
|
||||
|
||||
model_priorities:
|
||||
primary: ["Customer Awareness ⭐⭐⭐", "Golden Circle ⭐⭐⭐"]
|
||||
secondary: ["Badass Users ⭐⭐", "Trigger Map ⭐⭐"]
|
||||
tertiary: ["Action Mapping ⭐"]
|
||||
|
||||
review_question: "Does a Problem Aware hairdresser feel seen and want to learn more?"
|
||||
```
|
||||
|
||||
**Analysis:**
|
||||
- **Specific audience state:** Problem Aware (not just "hairdressers")
|
||||
- **Measurable outcome:** "Recognizes themselves" and "doesn't bounce"
|
||||
- **Model priority:** Customer Awareness and Golden Circle emphasized for landing page hook
|
||||
- **Testable:** Can observe if users recognize themselves and continue reading
|
||||
|
||||
---
|
||||
|
||||
## Example 2: Error Message
|
||||
|
||||
```yaml
|
||||
content_purpose:
|
||||
content_type: "Form validation error message"
|
||||
|
||||
purpose_statement: "Help user fix invalid email while maintaining confidence and reducing frustration"
|
||||
|
||||
audience:
|
||||
who: "New user attempting signup"
|
||||
state: "Frustrated - made a typo, wants to fix it quickly"
|
||||
context: "Just clicked submit and saw error"
|
||||
|
||||
success_criteria:
|
||||
- "User understands what's wrong"
|
||||
- "User knows exactly how to fix it"
|
||||
- "User doesn't feel stupid or blamed"
|
||||
- "User successfully resubmits"
|
||||
|
||||
model_priorities:
|
||||
primary: ["Badass Users ⭐⭐⭐", "Action Mapping ⭐⭐⭐"]
|
||||
secondary: ["Customer Awareness ⭐"]
|
||||
tertiary: ["Golden Circle ⭐", "Trigger Map ⭐"]
|
||||
|
||||
review_question: "Can user fix error quickly without feeling frustrated?"
|
||||
```
|
||||
|
||||
**Analysis:**
|
||||
- **Emotional state:** Frustrated (critical for error messages)
|
||||
- **Dual focus:** Fix problem AND maintain confidence
|
||||
- **Model priority:** Badass Users and Action Mapping for functional content
|
||||
- **Testable:** Can measure successful resubmission and user sentiment
|
||||
|
||||
---
|
||||
|
||||
## Example 3: Product Comparison Feature
|
||||
|
||||
```yaml
|
||||
content_purpose:
|
||||
content_type: "Shelf life comparison row in feature table"
|
||||
|
||||
purpose_statement: "Convince value-conscious users that 3x longer shelf life saves them money and hassle"
|
||||
|
||||
audience:
|
||||
who: "Product Aware users comparing us to competitors"
|
||||
state: "Evaluating features, looking for differentiators"
|
||||
context: "In active comparison mode, possibly has competitor tab open"
|
||||
|
||||
success_criteria:
|
||||
- "User understands the 3x advantage"
|
||||
- "User connects longer shelf life to personal benefit (saves money/waste)"
|
||||
- "User sees this as competitive advantage worth paying for"
|
||||
|
||||
model_priorities:
|
||||
primary: ["Trigger Map ⭐⭐⭐", "Badass Users ⭐⭐"]
|
||||
secondary: ["Action Mapping ⭐⭐", "Customer Awareness ⭐"]
|
||||
tertiary: ["Golden Circle ⭐"]
|
||||
|
||||
review_question: "Does user see 3x shelf life as a compelling reason to choose us?"
|
||||
```
|
||||
|
||||
**Analysis:**
|
||||
- **Comparison context:** User actively evaluating competitors
|
||||
- **Value connection:** Not just "3x longer" but "saves money/hassle"
|
||||
- **Model priority:** Trigger Map emphasized for understanding driving forces
|
||||
- **Testable:** Can assess if users understand and value the advantage
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference: Purpose Templates
|
||||
|
||||
**Persuasion:**
|
||||
- "Convince [audience] that [claim] by [strategy]"
|
||||
- "Activate [driving force] through [benefit/proof]"
|
||||
- "Move [start awareness] to [end awareness] by [approach]"
|
||||
|
||||
**Education:**
|
||||
- "Enable [user] to [action] with [confidence level]"
|
||||
- "Help [user] understand [concept] in [timeframe]"
|
||||
|
||||
**Functional:**
|
||||
- "Guide [user] to [action] with zero [friction]"
|
||||
- "Maintain [emotion] while [outcome]"
|
||||
|
||||
**Brand:**
|
||||
- "Connect [audience] to our [value]"
|
||||
- "Inspire [emotion] through [story]"
|
||||
|
||||
---
|
||||
|
||||
_Examples demonstrating content purpose definition across different content types_
|
||||
@@ -0,0 +1,97 @@
|
||||
# Action Filter Example: Hairdresser Newsletter
|
||||
|
||||
**Trigger Map Context:** Hairdresser newsletter signup
|
||||
|
||||
**Action Filter:**
|
||||
|
||||
```yaml
|
||||
action_filter:
|
||||
required_action:
|
||||
description: "Click the 'Start Staying Ahead' button to begin email signup"
|
||||
success_criteria: "User clicks with confidence, clear on what they'll get"
|
||||
|
||||
business_impact:
|
||||
connection: "Email capture drives 500 newsletter signups goal"
|
||||
logic: "Click button → Enter email → Confirm subscription → New subscriber"
|
||||
|
||||
user_motivation:
|
||||
positive_driver: "Satisfies wish to 'be local beauty authority' by getting trend info"
|
||||
negative_driver: "Addresses fear of 'missing industry trends' with regular updates"
|
||||
|
||||
essential_information:
|
||||
- "WHAT they'll get: Weekly trend alerts (enables confident click)"
|
||||
- "HOW OFTEN: Every Monday (sets expectation, reduces uncertainty)"
|
||||
- "TIME INVESTMENT: 60 seconds per trend (shows it's manageable)"
|
||||
- "SOCIAL PROOF: 2,000 stylists (reduces risk, builds trust)"
|
||||
- "COMMITMENT LEVEL: Free, cancel anytime (removes fear barrier)"
|
||||
|
||||
cut_list:
|
||||
- "Company founding story (doesn't enable signup action)"
|
||||
- "Technical newsletter platform details (irrelevant to action)"
|
||||
- "Full team bios (nice but doesn't reduce barriers)"
|
||||
|
||||
action_barriers:
|
||||
- barrier: "Fear of email overload"
|
||||
solution: "Weekly (not daily), 60-second reads, unsubscribe anytime"
|
||||
- barrier: "Uncertainty about value"
|
||||
solution: "Specific: 'Top 5 trends' + testimonial about client reactions"
|
||||
- barrier: "Distrust of free offers"
|
||||
solution: "2,000 stylists already using it (social proof)"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Analysis
|
||||
|
||||
**Required Action:**
|
||||
"Click signup button with confidence" - specific, observable behavior
|
||||
|
||||
**Business Connection:**
|
||||
Click → Email capture → Subscription → 500 signups goal
|
||||
|
||||
**User Motivation:**
|
||||
- Wish: "Be beauty authority" → Gets trend info
|
||||
- Fear: "Miss trends" → Regular updates
|
||||
|
||||
**Essential Information (5 elements):**
|
||||
All focused on enabling confident click by addressing barriers:
|
||||
1. What: Weekly trend alerts (clarifies offering)
|
||||
2. When: Every Monday (sets expectation)
|
||||
3. Time: 60 seconds (shows manageable)
|
||||
4. Proof: 2,000 stylists (builds trust)
|
||||
5. Commitment: Free, cancel anytime (removes risk)
|
||||
|
||||
**Cut List (3 elements):**
|
||||
All "nice to know" but don't enable the action:
|
||||
- Company story (impressive but irrelevant)
|
||||
- Technical details (doesn't reduce barriers)
|
||||
- Team bios (interesting but unnecessary)
|
||||
|
||||
**Barriers Addressed (3):**
|
||||
Each barrier gets specific content solution:
|
||||
- Email overload → "Weekly, 60 seconds, unsubscribe"
|
||||
- Uncertainty → "Top 5 trends + testimonial"
|
||||
- Distrust → "2,000 using it" (social proof)
|
||||
|
||||
---
|
||||
|
||||
## Key Insights
|
||||
|
||||
**Information is filtered through action:**
|
||||
- Only 5 essential elements kept
|
||||
- 3 "nice to know" elements cut
|
||||
- Everything serves the signup action
|
||||
|
||||
**Barriers drive content:**
|
||||
- Each barrier identified gets targeted content
|
||||
- Not generic "benefits" but specific barrier removal
|
||||
- Content is strategic, not decorative
|
||||
|
||||
**Business + User alignment:**
|
||||
- Action serves business goal (email capture → signups)
|
||||
- Action serves user motivation (authority wish, trends fear)
|
||||
- Win-win: both parties get what they need
|
||||
|
||||
---
|
||||
|
||||
_Example demonstrating Action Mapping for hairdresser newsletter signup_
|
||||
@@ -0,0 +1,159 @@
|
||||
# Badass Users Principles
|
||||
|
||||
**Kathy Sierra's framework for user-centered content**
|
||||
|
||||
---
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
> "Users don't care about your product. They care about being awesome at what your product helps them do."
|
||||
|
||||
**The Insight:** Don't make a better product. Make a better USER.
|
||||
|
||||
---
|
||||
|
||||
## The Five Key Principles
|
||||
|
||||
### 1. Make Them Better, Not Your Product Better
|
||||
|
||||
**Focus on THEIR capability, not your features**
|
||||
|
||||
**Bad (product-focused):**
|
||||
- "Our AI analyzes 10,000 beauty sources"
|
||||
- "We send weekly emails with 5 trends"
|
||||
- "Our platform has been trusted since 2018"
|
||||
|
||||
**Good (capability-focused):**
|
||||
- "You'll spot trends before your competitors"
|
||||
- "You'll always have something new to talk about with clients"
|
||||
- "You'll feel confident when clients ask about the latest looks"
|
||||
|
||||
**Frame:** "You'll be able to..." not "Our product has..."
|
||||
|
||||
---
|
||||
|
||||
### 2. Show The Transformation
|
||||
|
||||
**From: Current state → To: Badass state**
|
||||
|
||||
**Make the path visible:**
|
||||
- Where they are (current state: struggling, uncertain)
|
||||
- Where they're going (badass state: capable, confident)
|
||||
- That the path is real and achievable
|
||||
|
||||
**Examples:**
|
||||
- Specific numbers: "60 seconds per trend" (concrete, not vague)
|
||||
- Social proof: "2,000 stylists already there" (others did it)
|
||||
- Quick win: "Try it on your next client" (immediate application)
|
||||
|
||||
---
|
||||
|
||||
### 3. Create "Aha Moments"
|
||||
|
||||
**Insights that shift perspective and build confidence**
|
||||
|
||||
**Not just understanding—perspective shift:**
|
||||
|
||||
**Examples:**
|
||||
- "Oh! I don't need to follow 100 accounts—I just need THIS digest!"
|
||||
- "Oh! This is about my CLIENT'S reactions, not just knowing trends!"
|
||||
- "Oh! 60 seconds is all I need—I thought it would take hours!"
|
||||
|
||||
**Characteristics:**
|
||||
- Specific insight (not vague "understanding")
|
||||
- Removes a barrier or misconception
|
||||
- Unlocks confidence to act
|
||||
- Memorable and quotable
|
||||
|
||||
---
|
||||
|
||||
### 4. Reduce Cognitive Load
|
||||
|
||||
**Don't make them think unnecessarily**
|
||||
|
||||
**Strategies:**
|
||||
- Too many choices? → Reduce options or guide selection
|
||||
- Too much jargon? → Use plain language
|
||||
- Too many steps? → Break down or simplify
|
||||
- Unclear what to do? → Make next step obvious
|
||||
|
||||
**Cognitive load reduction often means cutting 30-40% of planned content**
|
||||
|
||||
**Remove:**
|
||||
- Unnecessary decisions
|
||||
- Complex explanations
|
||||
- Industry jargon
|
||||
- Multiple CTAs
|
||||
- Non-essential features
|
||||
|
||||
---
|
||||
|
||||
### 5. Focus on Skills, Not Tools
|
||||
|
||||
**What skill or capability are we helping them develop?**
|
||||
|
||||
**Not (tool-focused):**
|
||||
- "Using our platform"
|
||||
- "Receiving emails"
|
||||
- "Accessing our database"
|
||||
|
||||
**But (skill-focused):**
|
||||
- "Staying current effortlessly"
|
||||
- "Impressing your clients"
|
||||
- "Becoming the local authority"
|
||||
|
||||
**The tool is the vehicle, the skill is what matters**
|
||||
|
||||
---
|
||||
|
||||
## Application Framework
|
||||
|
||||
**For each piece of content, ask:**
|
||||
|
||||
1. **Does this make THEM feel capable?** (not us look good)
|
||||
2. **Does it show transformation?** (current → badass with visible path)
|
||||
3. **Does it create an "aha moment"?** (perspective shift that unlocks confidence)
|
||||
4. **Does it reduce cognitive load?** (or add unnecessary complexity)
|
||||
5. **Does it focus on skills gained?** (not just tools used)
|
||||
|
||||
---
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
**Mistake #1: Feature Focus**
|
||||
- Talking about product capabilities instead of user capabilities
|
||||
- "We have..." instead of "You'll be able to..."
|
||||
|
||||
**Mistake #2: Vague Transformation**
|
||||
- Aspirational marketing fluff without concrete path
|
||||
- No specifics on how transformation happens
|
||||
|
||||
**Mistake #3: No Aha Moment**
|
||||
- Just explaining features
|
||||
- Missing the key insight that shifts perspective
|
||||
|
||||
**Mistake #4: Cognitive Overload**
|
||||
- Trying to say everything
|
||||
- Multiple options without guidance
|
||||
- Complex language
|
||||
|
||||
**Mistake #5: Tool Obsession**
|
||||
- Focusing on using the product
|
||||
- Missing the skill they're actually developing
|
||||
|
||||
---
|
||||
|
||||
## Key Quotes
|
||||
|
||||
**On Product vs. User:**
|
||||
> "Nobody cares about your product. They care about being badass at what your product helps them do."
|
||||
|
||||
**On Transformation:**
|
||||
> "Make the user awesome, not your product awesome."
|
||||
|
||||
**On Skills:**
|
||||
> "People want to be great photographers, not great at using Photoshop."
|
||||
|
||||
---
|
||||
|
||||
_Badass Users principles reference for Step 4 - Empowerment Frame_
|
||||
@@ -0,0 +1,88 @@
|
||||
# Example: Badass Users Framework Applied to Hairdresser Newsletter
|
||||
|
||||
**Trigger Map Context:** Hairdresser newsletter signup
|
||||
|
||||
**Empowerment Frame:**
|
||||
|
||||
```yaml
|
||||
empowerment_frame:
|
||||
transformation:
|
||||
current_state:
|
||||
description: "Harriet feels behind when clients ask about trends she hasn't heard of"
|
||||
feelings: ["frustrated", "embarrassed", "uncertain"]
|
||||
capabilities: "Can't confidently discuss latest trends with clients"
|
||||
|
||||
badass_state:
|
||||
description: "Harriet is always ahead—clients see her as their beauty authority"
|
||||
feelings: ["confident", "proud", "expert"]
|
||||
capabilities: "Spots trends before competitors, impresses clients, leads conversations"
|
||||
|
||||
visibility: "2,000 stylists already there + 'Try it on next client Monday' = immediate, real path"
|
||||
|
||||
aha_moment:
|
||||
insight: "Oh! I don't need to follow 100 accounts or read for hours—60 seconds on Monday morning is enough!"
|
||||
why_powerful: "Removes the overwhelm barrier. Being ahead doesn't require massive effort—just smart curation."
|
||||
|
||||
capability_framing:
|
||||
- feature: "AI analyzes 10,000 beauty sources weekly"
|
||||
reframed: "You'll spot trends before your competitors even hear about them"
|
||||
|
||||
- feature: "Weekly email with 5 top trends"
|
||||
reframed: "You'll always have something new and exciting to talk about with clients"
|
||||
|
||||
- feature: "60-second explainers for each trend"
|
||||
reframed: "You'll understand trends fast enough to use them the same day"
|
||||
|
||||
- feature: "2,000 stylist subscribers"
|
||||
reframed: "You'll join successful stylists who are already ahead"
|
||||
|
||||
cognitive_load:
|
||||
potential_issues:
|
||||
- issue: "Fear of email overload / another thing to manage"
|
||||
solution: "Emphasize: 'Weekly, not daily' + '60 seconds' + 'Monday morning ritual'"
|
||||
|
||||
- issue: "Uncertainty about what trends are or how to use them"
|
||||
solution: "'Client conversation starters included' = no guesswork"
|
||||
|
||||
simplifications:
|
||||
- "Cut: Technical details about AI or sources (doesn't help capability)"
|
||||
- "Cut: Company history (irrelevant to their transformation)"
|
||||
- "Simplify: One clear CTA, not multiple options"
|
||||
|
||||
skill_focus:
|
||||
primary_skill: "Staying ahead of beauty trends effortlessly"
|
||||
supporting_skills:
|
||||
- "Impressing clients with current knowledge"
|
||||
- "Leading beauty conversations in their town"
|
||||
- "Building authority and reputation"
|
||||
tools_secondary: "Newsletter is the vehicle, but skill is what matters"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Transformations
|
||||
|
||||
**Current → Badass:**
|
||||
- From: "Behind and embarrassed" → To: "Ahead and confident"
|
||||
- From: "Can't discuss trends" → To: "Leads trend conversations"
|
||||
- Path made real: 2,000 already there + immediate application
|
||||
|
||||
**The Aha Moment:**
|
||||
"60 seconds is enough" - removes the massive barrier of thinking staying ahead requires hours of work
|
||||
|
||||
**Feature → Capability Reframing:**
|
||||
- "AI analyzes sources" → "You'll spot trends first" (about THEM, not us)
|
||||
- "Weekly email" → "Always something new to discuss" (capability, not delivery)
|
||||
- "60-second explainers" → "Understand fast enough to use same day" (skill outcome)
|
||||
|
||||
**Cognitive Load Reduction:**
|
||||
- Addressed fear of "another thing to manage" → "Weekly + 60 seconds + ritual"
|
||||
- Removed uncertainty → "Conversation starters included"
|
||||
- Cut all non-essential: company history, technical details, multiple CTAs
|
||||
|
||||
**Skill Focus:**
|
||||
Primary skill is "staying ahead effortlessly" - not "using a newsletter"
|
||||
|
||||
---
|
||||
|
||||
_Example demonstrating Badass Users framework application for hairdresser newsletter_
|
||||
@@ -0,0 +1,96 @@
|
||||
# Example: Golden Circle Applied to Hairdresser Newsletter
|
||||
|
||||
**Trigger Map Context:** Hairdresser newsletter signup
|
||||
|
||||
**Structural Order:**
|
||||
|
||||
```yaml
|
||||
structural_order:
|
||||
section_why:
|
||||
purpose: "Emotional connection—problem recognition and aspiration"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "Headline: 'Are Your Clients Asking About Trends You Haven't Heard Of?'"
|
||||
rationale: "Opens with emotional pain point—immediate recognition"
|
||||
|
||||
- order: 2
|
||||
element: "Subhead: 'Stop feeling behind. Become your town's go-to beauty authority.'"
|
||||
rationale: "Validation (you're not alone) + aspiration (badass state)"
|
||||
|
||||
- order: 3
|
||||
element: "Visual: Split image—uncertain hairdresser → confident trendsetter"
|
||||
rationale: "Shows transformation visually, reinforces emotional journey"
|
||||
|
||||
section_how:
|
||||
purpose: "Solution approach—how stylists stay ahead"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "Heading: 'Here's How Stylists Stay Ahead:'"
|
||||
rationale: "Introduces solution category (trend newsletters) to Problem Aware users"
|
||||
|
||||
- order: 2
|
||||
element: "Weekly trend alerts delivered Monday morning"
|
||||
rationale: "Explains the method—simple, regular, manageable"
|
||||
|
||||
- order: 3
|
||||
element: "60-second explainers—understand it fast"
|
||||
rationale: "Key differentiator—reduces cognitive load fear"
|
||||
|
||||
- order: 4
|
||||
element: "Client conversation starters included"
|
||||
rationale: "Shows transformation path—immediate application"
|
||||
|
||||
section_what:
|
||||
purpose: "Product naming, proof, and action"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "Heading: 'Join TrendWeek—Free for Stylists'"
|
||||
rationale: "NOW we can name the product (moved to Product Aware)"
|
||||
|
||||
- order: 2
|
||||
element: "2,000 stylists already ahead"
|
||||
rationale: "Social proof builds credibility before ask"
|
||||
|
||||
- order: 3
|
||||
element: "Button: 'Start Staying Ahead'"
|
||||
rationale: "Capability-framed CTA (not 'sign up')"
|
||||
|
||||
- order: 4
|
||||
element: "Subtext: 'Free. No credit card. Cancel anytime.'"
|
||||
rationale: "Risk removal last—addresses final barrier"
|
||||
|
||||
flow_validation:
|
||||
feels_natural: "Yes—emotion → method → specifics flows smoothly"
|
||||
persuasive_arc: "WHY connects emotionally, HOW builds confidence, WHAT enables action without jumping too fast"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Analysis
|
||||
|
||||
**WHY Section:**
|
||||
- Opens with emotional pain (problem recognition)
|
||||
- Validates feeling (not alone)
|
||||
- Shifts to aspiration (can become authority)
|
||||
- **Flow:** Problem → Validation → Aspiration
|
||||
|
||||
**HOW Section:**
|
||||
- Introduces solution approach
|
||||
- Explains method (weekly delivery)
|
||||
- Shows differentiator (60-second format)
|
||||
- Demonstrates transformation path (conversation starters)
|
||||
- **Flow:** Introduction → Method → Differentiator → Application
|
||||
|
||||
**WHAT Section:**
|
||||
- Names the product (now user is Product Aware)
|
||||
- Provides social proof (credibility)
|
||||
- Capability-framed CTA (action)
|
||||
- Removes risk (final barrier)
|
||||
- **Flow:** Naming → Proof → Action → Risk Removal
|
||||
|
||||
**Persuasive Arc:**
|
||||
Emotion (WHY) → Method (HOW) → Specifics (WHAT) creates smooth journey from pain recognition to empowered action.
|
||||
|
||||
---
|
||||
|
||||
_Example demonstrating Golden Circle sequencing for hairdresser newsletter content_
|
||||
@@ -0,0 +1,160 @@
|
||||
# Golden Circle Framework Guide
|
||||
|
||||
**Simon Sinek's WHY → HOW → WHAT model for persuasive content sequencing**
|
||||
|
||||
---
|
||||
|
||||
## The Golden Circle Model
|
||||
|
||||
```
|
||||
WHY (Core)
|
||||
↓
|
||||
HOW (Process)
|
||||
↓
|
||||
WHAT (Proof)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## The Three Levels
|
||||
|
||||
### WHY - The Purpose, Cause, Belief
|
||||
|
||||
**Purpose:** Connect emotionally, establish motivation
|
||||
|
||||
**Questions:**
|
||||
- Why does this matter?
|
||||
- Why should the user care?
|
||||
- What's the emotional truth?
|
||||
|
||||
**Good WHY Examples:**
|
||||
- "Are your clients asking about trends you haven't heard of?" (emotional truth)
|
||||
- "You deserve to feel ahead, not behind" (aspiration)
|
||||
- "Every stylist feels this—you're not alone" (validation)
|
||||
|
||||
**Bad WHY Examples:**
|
||||
- "Our company was founded in 2018" (not emotional)
|
||||
- "TrendWeek is a beauty newsletter" (WHAT, not WHY)
|
||||
- "Sign up now" (jumping to action without motivation)
|
||||
|
||||
**Connects to:**
|
||||
- User's driving forces (from Trigger Map)
|
||||
- Current emotional state (from Empowerment Frame)
|
||||
- The problem or aspiration that matters
|
||||
|
||||
---
|
||||
|
||||
### HOW - The Process, Approach, Differentiator
|
||||
|
||||
**Purpose:** Bridge emotion to specifics, show the method
|
||||
|
||||
**Questions:**
|
||||
- How does this work?
|
||||
- How do you do it differently?
|
||||
- What's the method?
|
||||
|
||||
**Example HOW Content:**
|
||||
- "Here's how stylists stay ahead: Weekly trend alerts delivered Monday morning"
|
||||
- "60-second explainers—understand trends fast enough to use them same day"
|
||||
- "Client conversation starters included—no guesswork"
|
||||
|
||||
**Connects to:**
|
||||
- Essential information (Action Filter)
|
||||
- Capability framing (Empowerment Frame)
|
||||
- The transformation path
|
||||
|
||||
---
|
||||
|
||||
### WHAT - The Tangible, Proof, Specifics
|
||||
|
||||
**Purpose:** Provide concrete details and enable action
|
||||
|
||||
**Questions:**
|
||||
- What exactly do you do/offer?
|
||||
- What are the features?
|
||||
- What's the concrete evidence?
|
||||
|
||||
**Example WHAT Content:**
|
||||
- "Join TrendWeek—Free for Stylists"
|
||||
- "2,000 stylists already ahead"
|
||||
- "Start Staying Ahead" (CTA button)
|
||||
- "Free. Cancel anytime."
|
||||
|
||||
**Includes:**
|
||||
- Specific features or offers
|
||||
- Tangible evidence
|
||||
- Social proof
|
||||
- The ask/action
|
||||
|
||||
---
|
||||
|
||||
## Key Insights
|
||||
|
||||
**Start with WHY:**
|
||||
- People don't buy WHAT you do, they buy WHY you do it
|
||||
- Emotion drives decisions, logic justifies them
|
||||
- WHY creates connection before presenting solution
|
||||
|
||||
**Bridge with HOW:**
|
||||
- HOW explains the approach that delivers on the WHY
|
||||
- Shows your unique method or differentiator
|
||||
- Builds confidence in the transformation
|
||||
|
||||
**Prove with WHAT:**
|
||||
- WHAT provides concrete specifics after buy-in
|
||||
- Only effective after WHY and HOW establish context
|
||||
- Enables action with confidence
|
||||
|
||||
---
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
**Mistake #1: Starting with WHAT**
|
||||
- ❌ "TrendWeek is a weekly newsletter for hairdressers..."
|
||||
- ✅ "Are your clients asking about trends you haven't heard of?"
|
||||
|
||||
**Mistake #2: Missing WHY**
|
||||
- Content feels cold and transactional
|
||||
- No emotional connection
|
||||
- Features without context
|
||||
|
||||
**Mistake #3: WHAT before WHY**
|
||||
- Content feels salesy and pushy
|
||||
- User isn't ready to hear specifics
|
||||
- Premature call to action
|
||||
|
||||
---
|
||||
|
||||
## Sequencing Within Sections
|
||||
|
||||
The Golden Circle is fractal—apply it at page level AND within each section:
|
||||
|
||||
**WHY Section Micro-sequence:**
|
||||
1. Problem recognition (emotional hook)
|
||||
2. Validation (you're not alone)
|
||||
3. Aspiration (you can feel different)
|
||||
|
||||
**HOW Section Micro-sequence:**
|
||||
1. Introduce solution approach
|
||||
2. Explain key differentiator
|
||||
3. Show transformation path
|
||||
|
||||
**WHAT Section Micro-sequence:**
|
||||
1. Name the product/offer
|
||||
2. Social proof
|
||||
3. Clear CTA
|
||||
4. Risk removal
|
||||
|
||||
---
|
||||
|
||||
## Application Notes
|
||||
|
||||
- The "aha moment" from Step 4 often lives in the HOW section (the insight that bridges emotion to action)
|
||||
- If WHAT comes before WHY, content feels salesy and pushy
|
||||
- If WHY is missing, content feels cold and transactional
|
||||
- This structure works for pages, sections, paragraphs, even sentences
|
||||
- The Golden Circle creates natural persuasive flow: emotion → method → specifics
|
||||
|
||||
---
|
||||
|
||||
_Golden Circle framework guide for Step 5 - Structural Order_
|
||||
@@ -0,0 +1,136 @@
|
||||
# Example: Hairdresser Newsletter Signup
|
||||
|
||||
**Trigger Map Context:** Hairdresser newsletter signup
|
||||
|
||||
**Content Generations:**
|
||||
|
||||
---
|
||||
|
||||
## Variation A: Wish-Focused (Become the Authority)
|
||||
|
||||
**Rationale:**
|
||||
Emphasizes the positive driving force: "Wish to be local beauty authority." This variation speaks to aspiration and confidence. Works best for users who are motivated by status and recognition.
|
||||
|
||||
**Content:**
|
||||
|
||||
**WHY Section:**
|
||||
- Headline: **"Become Your Town's Go-To Beauty Authority"**
|
||||
- Subhead: "The trends your clients are asking about? You'll spot them first."
|
||||
- Visual: Confident hairdresser surrounded by admiring clients
|
||||
|
||||
**HOW Section:**
|
||||
- Heading: "Here's How Stylists Stay Ahead:"
|
||||
- Every Monday morning: Top 5 trends in your inbox
|
||||
- 60-second explainers—understand and apply the same day
|
||||
- Client conversation starters included—lead the discussion
|
||||
|
||||
**WHAT Section:**
|
||||
- Heading: "Join 2,000 Stylists Who Are Already Ahead"
|
||||
- Button: **"Start Leading Trends"**
|
||||
- Subtext: "Free. No credit card. Cancel anytime."
|
||||
|
||||
**Why This Might Resonate:**
|
||||
For hairdressers who are confident but want to level up. Aspirational tone matches their ambition.
|
||||
|
||||
---
|
||||
|
||||
## Variation B: Fear-Focused (Stop Falling Behind)
|
||||
|
||||
**Rationale:**
|
||||
Addresses the negative driving force: "Fear of missing industry trends." This variation acknowledges the pain point directly. Works best for users feeling frustrated or embarrassed.
|
||||
|
||||
**Content:**
|
||||
|
||||
**WHY Section:**
|
||||
- Headline: **"Are Your Clients Asking About Trends You Haven't Heard Of?"**
|
||||
- Subhead: "Stop feeling behind. Never miss a trend again."
|
||||
- Visual: Split image—uncertain hairdresser → confident trendsetter
|
||||
|
||||
**HOW Section:**
|
||||
- Heading: "Here's How to Never Miss a Trend:"
|
||||
- Weekly alerts delivered Monday morning—stay current effortlessly
|
||||
- 60-second reads—no time wasted
|
||||
- Client conversation starters—no more guesswork
|
||||
|
||||
**WHAT Section:**
|
||||
- Heading: "Join TrendWeek—Free for Stylists"
|
||||
- "2,000 stylists already staying ahead"
|
||||
- Button: **"Stop Missing Out"**
|
||||
- Subtext: "Free. No credit card. Cancel anytime."
|
||||
|
||||
**Why This Might Resonate:**
|
||||
For hairdressers actively experiencing the pain. Direct problem recognition creates immediate connection.
|
||||
|
||||
---
|
||||
|
||||
## Variation C: Balanced (Recognition + Aspiration)
|
||||
|
||||
**Rationale:**
|
||||
Combines both driving forces naturally—opens with problem recognition (fear), bridges to aspiration (wish). Works for most users by meeting them where they are and showing where they can go.
|
||||
|
||||
**Content:**
|
||||
|
||||
**WHY Section:**
|
||||
- Headline: **"Your Clients Are Asking. You Should Be Leading."**
|
||||
- Subhead: "Stop playing catch-up. Become the trendsetter your town needs."
|
||||
- Visual: Transformation sequence—uncertain → confident → authority
|
||||
|
||||
**HOW Section:**
|
||||
- Heading: "Here's How Stylists Go From Behind to Ahead:"
|
||||
- Monday mornings: Top 5 trends delivered to your inbox
|
||||
- 60 seconds per trend—fast enough to use the same day
|
||||
- Conversation starters included—turn knowledge into client impact
|
||||
|
||||
**WHAT Section:**
|
||||
- Heading: "Join TrendWeek—Free for Stylists"
|
||||
- "2,000 stylists made the shift. Your turn."
|
||||
- Button: **"Start Staying Ahead"**
|
||||
- Subtext: "Free. No credit card. Cancel anytime."
|
||||
|
||||
**Why This Might Resonate:**
|
||||
Balanced approach works broadly. Acknowledges pain without dwelling, focuses on transformation.
|
||||
|
||||
---
|
||||
|
||||
## Refinement Process
|
||||
|
||||
**User selects:** "I like Variation B's headline and opening, but prefer Variation C's HOW section and Variation A's CTA framing."
|
||||
|
||||
**Agent refines and combines:**
|
||||
|
||||
---
|
||||
|
||||
## FINAL CONTENT
|
||||
|
||||
**WHY Section:**
|
||||
- Headline: **"Are Your Clients Asking About Trends You Haven't Heard Of?"**
|
||||
- Subhead: "Stop feeling behind. Become your town's go-to beauty authority."
|
||||
- Visual: Split image—uncertain hairdresser → confident trendsetter
|
||||
|
||||
**HOW Section:**
|
||||
- Heading: "Here's How Stylists Go From Behind to Ahead:"
|
||||
- Monday mornings: Top 5 trends delivered
|
||||
- 60 seconds per trend—fast enough to use the same day
|
||||
- Conversation starters included—lead the discussion
|
||||
|
||||
**WHAT Section:**
|
||||
- Heading: "Join TrendWeek—Free for Stylists"
|
||||
- "2,000 stylists already ahead"
|
||||
- Button: **"Start Leading Trends"**
|
||||
- Subtext: "Free. No credit card. Cancel anytime."
|
||||
|
||||
---
|
||||
|
||||
**Strategic Traceability:**
|
||||
|
||||
- **Business Goal:** Increase newsletter signups
|
||||
- **Driving Forces Addressed:**
|
||||
- Fear: Missing industry trends (opening headline)
|
||||
- Wish: Be local beauty authority (subhead, CTA)
|
||||
- **Awareness Journey:** Problem Aware → Solution Aware (recognizes problem, sees how to solve it)
|
||||
- **Action Enabled:** Sign up for free newsletter
|
||||
- **Empowerment Achieved:** "You'll be able to lead trends" (not just follow)
|
||||
|
||||
---
|
||||
|
||||
_Example demonstrating how variations combine strategic context into final content_
|
||||
@@ -0,0 +1,95 @@
|
||||
# Content Generation Instructions
|
||||
|
||||
**How to generate strategically grounded content variations**
|
||||
|
||||
---
|
||||
|
||||
## 1. Synthesize All Context
|
||||
|
||||
Before generating, review and confirm you understand:
|
||||
- [ ] WHO the user is and what drives them (Trigger Map)
|
||||
- [ ] WHERE they are in awareness (START → END)
|
||||
- [ ] WHAT action this content must enable (Action Filter)
|
||||
- [ ] HOW to make them feel capable (Empowerment Frame)
|
||||
- [ ] WHAT order creates persuasive flow (Golden Circle)
|
||||
|
||||
---
|
||||
|
||||
## 2. Generate Multiple Variations
|
||||
|
||||
Create **2-3 content variations** that differ in:
|
||||
|
||||
**Variation A: Wish-Focused**
|
||||
- Emphasizes positive driving forces
|
||||
- Aspirational tone
|
||||
- "Become the authority," "Stay ahead," "Impress your clients"
|
||||
|
||||
**Variation B: Fear-Focused**
|
||||
- Addresses negative driving forces
|
||||
- Problem-recognition tone
|
||||
- "Stop feeling behind," "Never miss a trend," "No more embarrassment"
|
||||
|
||||
**Variation C: Balanced OR Awareness-Shifted** (choose one):
|
||||
- **Balanced:** Combines wish + fear naturally
|
||||
- **Awareness-Shifted:** Uses different starting awareness level (if user was uncertain)
|
||||
|
||||
**For each variation, include:**
|
||||
- Complete content (headlines, body, CTA)
|
||||
- Rationale explaining the approach
|
||||
- Why this might resonate
|
||||
|
||||
---
|
||||
|
||||
## 3. Presentation Format
|
||||
|
||||
Use this format:
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## Variation A: [Name - e.g., "Wish-Focused"]
|
||||
|
||||
### Rationale
|
||||
[Why this approach, what driving force it emphasizes, when this works best]
|
||||
|
||||
### Content
|
||||
|
||||
**WHY Section:**
|
||||
[Content for WHY]
|
||||
|
||||
**HOW Section:**
|
||||
[Content for HOW]
|
||||
|
||||
**WHAT Section:**
|
||||
[Content for WHAT]
|
||||
|
||||
### Why This Might Resonate
|
||||
[Specific user insight or context that makes this effective]
|
||||
|
||||
---
|
||||
|
||||
## Variation B: [Name]
|
||||
[Same structure]
|
||||
|
||||
---
|
||||
|
||||
## Variation C: [Name]
|
||||
[Same structure]
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Explain Strategic Choices
|
||||
|
||||
For each variation, show how you applied the strategic context:
|
||||
- "This opens with [X] because the user is Problem Aware—they need problem validation first"
|
||||
- "This uses 'you'll be able to' framing because of Badass Users principle"
|
||||
- "This puts social proof before CTA because Action Filter identified trust as a barrier"
|
||||
|
||||
**Make the strategy visible.**
|
||||
|
||||
---
|
||||
|
||||
_Reference for generating content variations in Step 6_
|
||||
@@ -0,0 +1,319 @@
|
||||
# Content Creation Workshop Guide
|
||||
|
||||
**Strategic, Multi-Model Content Generation for WDS**
|
||||
|
||||
---
|
||||
|
||||
## What Is This?
|
||||
|
||||
The Content Creation Workshop is a disciplined, multi-model framework for generating strategically grounded content. Instead of "blurting out versions," agents use five strategic models in sequence to create content that is:
|
||||
|
||||
- ✅ **Strategically grounded** (serves business goals)
|
||||
- ✅ **Awareness-appropriate** (speaks to user's current understanding)
|
||||
- ✅ **Action-focused** (enables specific user behaviors)
|
||||
- ✅ **Empowering** (makes users feel capable)
|
||||
- ✅ **Structurally persuasive** (WHY → HOW → WHAT flow)
|
||||
|
||||
---
|
||||
|
||||
## When to Use
|
||||
|
||||
**Use this workshop whenever creating:**
|
||||
- Page headlines and hero content
|
||||
- Section content and feature descriptions
|
||||
- Value propositions and benefit statements
|
||||
- CTAs with strategic importance
|
||||
- About/mission statements
|
||||
- Landing page content
|
||||
- Onboarding narratives
|
||||
- Feature announcements
|
||||
- Case studies and testimonials
|
||||
- Any user-facing text where **purpose and context matter**
|
||||
|
||||
**Skip this workshop for:**
|
||||
- ❌ Standard UI microcopy (form labels, generic buttons, tooltips)
|
||||
- ❌ System messages (loading, generic errors, confirmations)
|
||||
- ❌ Navigation labels
|
||||
- ❌ Standard form instructions
|
||||
- ❌ Technical documentation
|
||||
- ❌ Code comments
|
||||
- ❌ Internal notes
|
||||
- ❌ Placeholder content during prototyping
|
||||
|
||||
**For UI microcopy:** Use **Tone of Voice** guidelines (defined in Product Brief)
|
||||
- Form labels: "Email" vs "Email address" (tone-dependent)
|
||||
- Buttons: "Submit" vs "Continue" vs "Let's go" (tone-dependent)
|
||||
- Errors: "Invalid input" vs "Hmm, that doesn't look right" (tone-dependent)
|
||||
- See [Tone of Voice Guide](../../../docs/method/tone-of-voice-guide.md)
|
||||
|
||||
---
|
||||
|
||||
## The Five-Model Framework
|
||||
|
||||
### 0. Content Purpose = The Job To Do
|
||||
- Defines: WHAT must this content accomplish? HOW will we know it worked?
|
||||
- Answers: What's the measurable outcome? Which models should we emphasize?
|
||||
|
||||
### 1. Trigger Map = Strategic Foundation
|
||||
- Provides: Business goal, solution, user, driving forces, customer awareness positioning
|
||||
- Answers: WHO are we serving? WHAT motivates them? WHERE are they in their journey?
|
||||
|
||||
### 2. Customer Awareness Cycle = Content Strategy
|
||||
- Provides: Language appropriate to awareness level, information priorities, required proof
|
||||
- Answers: WHAT can they understand? WHAT do they need to know? WHAT will they believe?
|
||||
|
||||
### 3. Action Mapping = Content Filter
|
||||
- Provides: Required user action, relevance test
|
||||
- Answers: WHAT must they DO after reading this? Is this content necessary?
|
||||
|
||||
### 4. Badass Users = Tone & Frame
|
||||
- Provides: Empowerment framing, transformation narrative, cognitive load reduction
|
||||
- Answers: HOW does this make them feel capable? WHAT's the "aha moment"?
|
||||
|
||||
### 5. Golden Circle = Structural Order
|
||||
- Provides: WHY → HOW → WHAT sequence
|
||||
- Answers: WHAT order creates the most persuasive flow?
|
||||
|
||||
---
|
||||
|
||||
## Workshop Structure
|
||||
|
||||
The workshop follows **7 sequential considerations** (agents can adapt flow naturally):
|
||||
|
||||
0. **Define Content Purpose** - What job must this content do?
|
||||
1. **Load Trigger Map Context** - Establish strategic foundation
|
||||
2. **Apply Customer Awareness Strategy** - Determine appropriate language & information
|
||||
3. **Define Required Action** - Filter for relevance
|
||||
4. **Frame User Empowerment** - Set tone and transformation narrative
|
||||
5. **Determine Structural Order** - Sequence content for persuasion
|
||||
6. **Generate & Review Content** - Create options and select
|
||||
|
||||
**Duration:** 15-30 minutes per content section
|
||||
|
||||
**Mode Options:**
|
||||
- **Quick Mode:** Agent synthesizes internally, presents reasoning + variants
|
||||
- **Workshop Mode:** Collaborative conversation through each consideration
|
||||
|
||||
---
|
||||
|
||||
## How to Use
|
||||
|
||||
### For Agents
|
||||
|
||||
When you encounter content creation in a workflow:
|
||||
|
||||
1. **Define Purpose First** - "What job must this content do?"
|
||||
- If user provides purpose → Use it
|
||||
- If not → Ask: "What should this content accomplish?"
|
||||
- Define success criteria: "How will we know it worked?"
|
||||
|
||||
2. **Select Mode:**
|
||||
- **Quick Mode:** User says "Suggest content for [X]"
|
||||
- Synthesize all strategic considerations internally
|
||||
- Present: Purpose → Reasoning → Multiple variants → Selection
|
||||
- **Workshop Mode:** User says "Let's work through content for [X]"
|
||||
- Collaborative conversation through considerations
|
||||
- Adapt flow naturally (skip/combine as appropriate)
|
||||
|
||||
3. **Check for Trigger Map** - Does the current context have a Trigger Map?
|
||||
- If YES → Proceed with strategic generation
|
||||
- If NO → Suggest creating a Trigger Map first (route to Phase 2)
|
||||
|
||||
4. **Execute Strategically:**
|
||||
- Consider all strategic layers (Trigger Map, Awareness, Action, Empowerment, Structure)
|
||||
- Emphasize models based on content purpose (see Content Purpose Guide)
|
||||
- Don't force rigid steps - adapt naturally
|
||||
|
||||
5. **Present Options** - Offer 2-3 variations:
|
||||
- Different driving force angles (wish vs fear)
|
||||
- Different awareness approaches (if uncertain)
|
||||
- Different structural emphases
|
||||
|
||||
6. **Enable Review:**
|
||||
- Does content achieve its stated purpose?
|
||||
- Objective criteria, not "I like it"
|
||||
|
||||
### For Designers
|
||||
|
||||
You control the strategic context and mode:
|
||||
|
||||
1. **Define content purpose** - Be specific about what the content must accomplish
|
||||
2. **Choose your mode:**
|
||||
- Need quick suggestions? → "Suggest content for this hero section"
|
||||
- Want to explore together? → "Let's work through the homepage hero"
|
||||
3. **Provide context** or let agent find it (Trigger Map, page purpose, user state)
|
||||
4. **Review against purpose** - Does it do its job? (objective criteria)
|
||||
5. **Select or refine** - Choose variant or combine elements
|
||||
6. **Iterate if needed** - Purpose not achieved? Refine and regenerate
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### In Phase 4: UX Design - Sketch Review Flow
|
||||
|
||||
**When designer presents a sketch:**
|
||||
|
||||
1. **Agent identifies text elements** (headlines, CTAs, sections, microcopy)
|
||||
2. **Agent suggests purposes** for each element based on:
|
||||
- Position on page (hero vs. footer)
|
||||
- Content type (headline vs. error message)
|
||||
- Page context (landing vs. onboarding)
|
||||
3. **Agent recommends model priorities** for each purpose
|
||||
4. **Designer confirms/refines** purposes
|
||||
5. **Agent generates content** for approved purposes
|
||||
6. **Content is documented** in page specification
|
||||
|
||||
**Granularity Options:**
|
||||
- **Element-by-element:** For critical content (hero headline, primary CTA)
|
||||
- **Section-level:** For cohesive blocks (feature section, testimonials)
|
||||
- **Batch:** For repetitive elements (form labels, tooltips)
|
||||
|
||||
**Example Sketch Review:**
|
||||
|
||||
```
|
||||
DESIGNER: "Here's the landing page sketch [wireframe]"
|
||||
|
||||
AGENT: "I see several text elements. Let me suggest purposes:
|
||||
|
||||
📝 Hero Headline
|
||||
Purpose: Hook Problem Aware users by validating frustration
|
||||
Models: Customer Awareness ⭐⭐⭐, Golden Circle ⭐⭐⭐
|
||||
|
||||
📝 Hero Subhead
|
||||
Purpose: Promise transformation, reduce anxiety
|
||||
Models: Badass Users ⭐⭐, Customer Awareness ⭐⭐
|
||||
|
||||
📝 Feature Section (whole section)
|
||||
Purpose: Show how solution works, enable understanding
|
||||
Models: Action Mapping ⭐⭐⭐, Badass Users ⭐⭐
|
||||
|
||||
📝 CTA Button
|
||||
Purpose: Make signup feel empowering and low-risk
|
||||
Models: Badass Users ⭐⭐⭐, Action Mapping ⭐⭐
|
||||
|
||||
Does this match your intent?"
|
||||
|
||||
DESIGNER: "Yes, generate content"
|
||||
[OR]
|
||||
DESIGNER: "Make headline more fear-focused"
|
||||
→ AGENT: Updates purpose, generates accordingly
|
||||
```
|
||||
|
||||
### In Phase 4: UX Design - Page Specifications
|
||||
|
||||
**When creating page specifications:**
|
||||
- Hero sections → Purpose-driven content generation
|
||||
- Key feature descriptions → Purpose-driven content generation
|
||||
- CTAs and conversion points → Purpose-driven content generation
|
||||
- Error/empty state messages → Purpose-driven content generation
|
||||
|
||||
**When working with Freya:**
|
||||
- Freya identifies text elements in sketches
|
||||
- Suggests purposes automatically
|
||||
- Generates content after confirmation
|
||||
- Documents everything in page specifications
|
||||
|
||||
### In Phase 1: Product Brief (Pitch)
|
||||
|
||||
**When creating pitch deck content:**
|
||||
- Problem statement → Run this workshop
|
||||
- Solution description → Run this workshop
|
||||
- Value propositions → Run this workshop
|
||||
|
||||
---
|
||||
|
||||
## What You Get
|
||||
|
||||
**For each content section:**
|
||||
|
||||
1. **Purpose Statement** (what this content must do)
|
||||
- Clear job definition
|
||||
- Success criteria
|
||||
- Model priority emphasis
|
||||
|
||||
2. **Strategic Context Document** (shows your thinking)
|
||||
- Trigger Map reference
|
||||
- Awareness journey map
|
||||
- Action requirement
|
||||
- Empowerment frame
|
||||
- Structural sequence
|
||||
|
||||
3. **Content Options** (2-3 variations)
|
||||
- Fully written content
|
||||
- Different angles/approaches
|
||||
- Rationale for each option
|
||||
- Model emphasis explained
|
||||
|
||||
4. **Selected Content** (final version)
|
||||
- Refined and approved
|
||||
- Ready for implementation
|
||||
- Traceable to strategic context
|
||||
- Reviewable against purpose
|
||||
|
||||
---
|
||||
|
||||
## Alpha Status Notice
|
||||
|
||||
⚠️ **This workshop is in Alpha** - first real-world usage pending.
|
||||
|
||||
**What this means:**
|
||||
- Structure is theoretically sound but untested in practice
|
||||
- Steps may need refinement based on actual usage
|
||||
- Timing estimates may be inaccurate
|
||||
- You may discover missing elements or unnecessary steps
|
||||
|
||||
**Please provide feedback:**
|
||||
- What worked well?
|
||||
- What felt clunky or unnecessary?
|
||||
- What's missing?
|
||||
- How could this be more efficient?
|
||||
|
||||
**Alpha will be removed when:**
|
||||
- Successfully used in 3+ real projects
|
||||
- Timing validated and adjusted
|
||||
- Feedback integrated
|
||||
- No major structural changes needed for 2 months
|
||||
|
||||
---
|
||||
|
||||
## Files
|
||||
|
||||
**Entry Point:**
|
||||
- `content-creation-workshop.md` - Start here
|
||||
|
||||
**Micro-Steps:**
|
||||
- `steps/workflow.md` - Sequential execution guide
|
||||
- `steps/step-00-define-purpose.md`
|
||||
- `steps/step-01-load-trigger-map-context.md`
|
||||
- `steps/step-02-awareness-strategy.md`
|
||||
- `steps/step-03-action-filter.md`
|
||||
- `steps/step-04-empowerment-frame.md`
|
||||
- `steps/step-05-structural-order.md`
|
||||
- `steps/step-06-generate-content.md`
|
||||
|
||||
**Output Template:**
|
||||
- `content-output.template.md` - Structured output format
|
||||
|
||||
---
|
||||
|
||||
## Related Resources
|
||||
|
||||
**Strategic Models:**
|
||||
- [Customer Awareness Cycle](../../../docs/models/customer-awareness-cycle.md)
|
||||
- [Golden Circle](../../../docs/models/golden-circle.md)
|
||||
- [Action Mapping](../../../docs/models/action-mapping.md)
|
||||
- [Kathy Sierra Badass Users](../../../docs/models/kathy-sierra-badass-users.md)
|
||||
|
||||
**Whiteport Methods:**
|
||||
- [Trigger Mapping Guide](../../../docs/method/trigger-mapping-guide.md)
|
||||
- [Content Purpose Guide](../../../docs/method/content-purpose-guide.md) - **Start here for content effectiveness**
|
||||
|
||||
**Workflows:**
|
||||
- [Phase 4: UX Design](../../../docs/method/phase-4-ux-design-guide.md)
|
||||
- [Phase 1: Product Exploration](../../../docs/method/phase-1-product-exploration-guide.md)
|
||||
|
||||
---
|
||||
|
||||
**Let's create strategically grounded content, not guesswork.** 🎯
|
||||
|
||||
@@ -0,0 +1,687 @@
|
||||
# Figma Designer Guide for WDS
|
||||
|
||||
**Purpose:** Step-by-step instructions for designers creating components in Figma for WDS projects.
|
||||
|
||||
**Audience:** Visual designers, UX designers, design system maintainers
|
||||
|
||||
---
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Figma account with edit access to design system file
|
||||
- Understanding of WDS component structure
|
||||
- Familiarity with Figma components and variants
|
||||
- Access to WDS project repository
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Set Up Your Figma File
|
||||
|
||||
### Create Design System File
|
||||
|
||||
**File structure:**
|
||||
|
||||
```
|
||||
[Project Name] Design System
|
||||
├── 📄 Cover
|
||||
├── 🎨 Foundation
|
||||
│ ├── Colors
|
||||
│ ├── Typography
|
||||
│ ├── Spacing
|
||||
│ └── Effects
|
||||
├── ⚛️ Components
|
||||
│ ├── Buttons
|
||||
│ ├── Inputs
|
||||
│ ├── Cards
|
||||
│ └── [more types]
|
||||
└── 📱 Examples
|
||||
```
|
||||
|
||||
**Tips:**
|
||||
|
||||
- Use clear page names
|
||||
- Organize by component type
|
||||
- Keep foundation separate
|
||||
- Include usage examples
|
||||
|
||||
---
|
||||
|
||||
### Set Up Design Tokens
|
||||
|
||||
**Create Figma variables:**
|
||||
|
||||
**Colors:**
|
||||
|
||||
```
|
||||
Collection: Colors
|
||||
├── primary/50
|
||||
├── primary/100
|
||||
├── primary/500
|
||||
├── primary/600
|
||||
├── gray/50
|
||||
├── gray/900
|
||||
└── [more colors]
|
||||
```
|
||||
|
||||
**Spacing:**
|
||||
|
||||
```
|
||||
Collection: Spacing
|
||||
├── spacing/1 = 4px
|
||||
├── spacing/2 = 8px
|
||||
├── spacing/4 = 16px
|
||||
├── spacing/6 = 24px
|
||||
└── [more spacing]
|
||||
```
|
||||
|
||||
**Typography:**
|
||||
|
||||
```
|
||||
Styles: Typography
|
||||
├── Display/Large
|
||||
├── Heading/1
|
||||
├── Heading/2
|
||||
├── Body/Regular
|
||||
└── [more styles]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 2: Create Your First Component
|
||||
|
||||
### Example: Button Component
|
||||
|
||||
**1. Create Base Frame**
|
||||
|
||||
```
|
||||
Frame name: Button/Primary [btn-001]
|
||||
Size: Hug contents (width), Fixed 44px (height)
|
||||
Auto Layout: Horizontal
|
||||
Padding: 16px (horizontal), 12px (vertical)
|
||||
Gap: 8px
|
||||
```
|
||||
|
||||
**2. Add Content**
|
||||
|
||||
```
|
||||
├── Icon (optional)
|
||||
│ └── Size: 20x20px
|
||||
└── Text
|
||||
└── Style: Body/Medium
|
||||
└── Content: "Button Text"
|
||||
```
|
||||
|
||||
**3. Apply Design Tokens**
|
||||
|
||||
```
|
||||
Background: primary/600 (variable)
|
||||
Text Color: white (variable)
|
||||
Border Radius: 8px
|
||||
```
|
||||
|
||||
**4. Create Component**
|
||||
|
||||
```
|
||||
Select frame → Create Component
|
||||
Name: Button/Primary [btn-001]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Add Component Description
|
||||
|
||||
**In component description field:**
|
||||
|
||||
```
|
||||
Button Primary [btn-001]
|
||||
|
||||
Primary action button for main user actions.
|
||||
|
||||
**When to use:**
|
||||
- Submit forms
|
||||
- Confirm actions
|
||||
- Proceed to next step
|
||||
|
||||
**When not to use:**
|
||||
- Secondary actions (use Button/Secondary)
|
||||
- Navigation (use Link component)
|
||||
|
||||
**WDS Component:** Button.primary [btn-001]
|
||||
**Variants:** primary, secondary, ghost
|
||||
**States:** default, hover, active, disabled, loading
|
||||
**Sizes:** small, medium, large
|
||||
|
||||
**Accessibility:**
|
||||
- role="button"
|
||||
- aria-disabled when disabled
|
||||
- Keyboard: Enter/Space to activate
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 3: Add Variants
|
||||
|
||||
### Create Variant Properties
|
||||
|
||||
**Select component → Add variant property:**
|
||||
|
||||
**Property 1: Type**
|
||||
|
||||
```
|
||||
Values: Primary, Secondary, Ghost, Outline
|
||||
```
|
||||
|
||||
**Property 2: Size**
|
||||
|
||||
```
|
||||
Values: Small, Medium, Large
|
||||
```
|
||||
|
||||
**Property 3: State**
|
||||
|
||||
```
|
||||
Values: Default, Hover, Active, Disabled, Loading
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Design Each Variant
|
||||
|
||||
**Type=Primary, Size=Medium, State=Default:**
|
||||
|
||||
```
|
||||
Background: primary/600
|
||||
Text: white
|
||||
Padding: 16px × 12px
|
||||
```
|
||||
|
||||
**Type=Primary, Size=Medium, State=Hover:**
|
||||
|
||||
```
|
||||
Background: primary/700 (darker)
|
||||
Text: white
|
||||
Scale: 1.02 (slightly larger)
|
||||
```
|
||||
|
||||
**Type=Primary, Size=Medium, State=Active:**
|
||||
|
||||
```
|
||||
Background: primary/800 (darkest)
|
||||
Text: white
|
||||
Scale: 0.98 (slightly smaller)
|
||||
```
|
||||
|
||||
**Type=Primary, Size=Medium, State=Disabled:**
|
||||
|
||||
```
|
||||
Background: gray/300
|
||||
Text: gray/500
|
||||
Opacity: 0.6
|
||||
Cursor: not-allowed
|
||||
```
|
||||
|
||||
**Type=Primary, Size=Medium, State=Loading:**
|
||||
|
||||
```
|
||||
Background: primary/600
|
||||
Text: white
|
||||
Add: Spinner icon
|
||||
Opacity: 0.8
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Adjust for Sizes
|
||||
|
||||
**Small:**
|
||||
|
||||
```
|
||||
Padding: 12px × 8px
|
||||
Text: Body/Small
|
||||
Icon: 16x16px
|
||||
Height: 36px
|
||||
```
|
||||
|
||||
**Medium (default):**
|
||||
|
||||
```
|
||||
Padding: 16px × 12px
|
||||
Text: Body/Medium
|
||||
Icon: 20x20px
|
||||
Height: 44px
|
||||
```
|
||||
|
||||
**Large:**
|
||||
|
||||
```
|
||||
Padding: 20px × 16px
|
||||
Text: Body/Large
|
||||
Icon: 24x24px
|
||||
Height: 52px
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 4: Document States
|
||||
|
||||
### Visual State Indicators
|
||||
|
||||
**Create a documentation frame:**
|
||||
|
||||
```
|
||||
Frame: Button States Documentation
|
||||
├── Default
|
||||
│ └── Normal appearance
|
||||
├── Hover
|
||||
│ └── Background darker, slight scale
|
||||
├── Active
|
||||
│ └── Background darkest, scale down
|
||||
├── Disabled
|
||||
│ └── Grayed out, reduced opacity
|
||||
└── Loading
|
||||
└── Spinner, disabled interaction
|
||||
```
|
||||
|
||||
**Add annotations:**
|
||||
|
||||
- State name
|
||||
- Visual changes
|
||||
- Interaction behavior
|
||||
- Transition duration
|
||||
|
||||
---
|
||||
|
||||
## Step 5: Get Figma Node ID
|
||||
|
||||
### Copy Component Link
|
||||
|
||||
**1. Select component in Figma**
|
||||
|
||||
**2. Right-click → "Copy link to selection"**
|
||||
|
||||
**3. Extract node ID from URL:**
|
||||
|
||||
```
|
||||
URL: https://www.figma.com/file/abc123/Design-System?node-id=456:789
|
||||
|
||||
File ID: abc123
|
||||
Node ID: 456:789
|
||||
|
||||
Full reference: figma://file/abc123/node/456:789
|
||||
```
|
||||
|
||||
**4. Add to WDS mapping file:**
|
||||
|
||||
```yaml
|
||||
# D-Design-System/figma-mappings.md
|
||||
Button [btn-001] → figma://file/abc123/node/456:789
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 6: Sync with WDS
|
||||
|
||||
### Manual Sync Process
|
||||
|
||||
**1. Create component in Figma** (steps above)
|
||||
|
||||
**2. Notify WDS system:**
|
||||
|
||||
- Add component ID to Figma description
|
||||
- Copy Figma node ID
|
||||
- Update `figma-mappings.md`
|
||||
|
||||
**3. Generate WDS specification:**
|
||||
|
||||
- Use Figma MCP to read component
|
||||
- Generate component specification
|
||||
- Review and confirm
|
||||
|
||||
**4. Verify sync:**
|
||||
|
||||
- Check WDS component file created
|
||||
- Verify all variants captured
|
||||
- Confirm states documented
|
||||
- Test component reference
|
||||
|
||||
---
|
||||
|
||||
### Using Figma MCP (Automated)
|
||||
|
||||
**If Figma MCP is configured:**
|
||||
|
||||
**1. Create/update component in Figma**
|
||||
|
||||
**2. Run MCP sync command:**
|
||||
|
||||
```bash
|
||||
# In WDS project
|
||||
wds figma sync Button/Primary
|
||||
```
|
||||
|
||||
**3. MCP will:**
|
||||
|
||||
- Read component from Figma
|
||||
- Extract variants and states
|
||||
- Generate WDS specification
|
||||
- Update figma-mappings.md
|
||||
|
||||
**4. Review generated spec:**
|
||||
|
||||
- Check accuracy
|
||||
- Add missing details
|
||||
- Confirm and commit
|
||||
|
||||
---
|
||||
|
||||
## Step 7: Maintain Components
|
||||
|
||||
### Updating Existing Components
|
||||
|
||||
**When updating a component:**
|
||||
|
||||
**1. Update in Figma:**
|
||||
|
||||
- Modify component
|
||||
- Update description if needed
|
||||
- Maintain component ID
|
||||
|
||||
**2. Sync to WDS:**
|
||||
|
||||
- Run MCP sync (if available)
|
||||
- Or manually update WDS spec
|
||||
- Update version history
|
||||
|
||||
**3. Notify team:**
|
||||
|
||||
- Document changes
|
||||
- Update affected pages
|
||||
- Test implementations
|
||||
|
||||
---
|
||||
|
||||
### Version Control
|
||||
|
||||
**Track component changes:**
|
||||
|
||||
**In Figma:**
|
||||
|
||||
- Use Figma version history
|
||||
- Add version notes
|
||||
- Tag major changes
|
||||
|
||||
**In WDS:**
|
||||
|
||||
```markdown
|
||||
## Version History
|
||||
|
||||
**Created:** 2024-12-09
|
||||
**Last Updated:** 2024-12-15
|
||||
|
||||
**Changes:**
|
||||
|
||||
- 2024-12-09: Created component
|
||||
- 2024-12-12: Added loading state
|
||||
- 2024-12-15: Updated hover animation
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO ✅
|
||||
|
||||
**1. Use Design Tokens**
|
||||
|
||||
- Always use variables for colors
|
||||
- Use variables for spacing
|
||||
- Apply text styles consistently
|
||||
|
||||
**2. Document Thoroughly**
|
||||
|
||||
- Clear component descriptions
|
||||
- Usage guidelines
|
||||
- Accessibility notes
|
||||
|
||||
**3. Maintain Consistency**
|
||||
|
||||
- Follow naming conventions
|
||||
- Use consistent spacing
|
||||
- Apply standard states
|
||||
|
||||
**4. Test Instances**
|
||||
|
||||
- Create example instances
|
||||
- Test all variants
|
||||
- Verify responsive behavior
|
||||
|
||||
**5. Keep Organized**
|
||||
|
||||
- Logical component grouping
|
||||
- Clear page structure
|
||||
- Clean component hierarchy
|
||||
|
||||
---
|
||||
|
||||
### DON'T ❌
|
||||
|
||||
**1. Hardcode Values**
|
||||
|
||||
- Don't use hex colors directly
|
||||
- Don't use pixel values without variables
|
||||
- Don't skip design tokens
|
||||
|
||||
**2. Detach Instances**
|
||||
|
||||
- Don't break component connections
|
||||
- Don't create one-off variations
|
||||
- Don't lose main component link
|
||||
|
||||
**3. Skip Documentation**
|
||||
|
||||
- Don't leave descriptions empty
|
||||
- Don't forget WDS component ID
|
||||
- Don't skip usage guidelines
|
||||
|
||||
**4. Ignore States**
|
||||
|
||||
- Don't create only default state
|
||||
- Don't forget hover/active
|
||||
- Don't skip disabled state
|
||||
|
||||
**5. Break Naming Conventions**
|
||||
|
||||
- Don't use inconsistent names
|
||||
- Don't forget component IDs
|
||||
- Don't use unclear abbreviations
|
||||
|
||||
---
|
||||
|
||||
## Common Workflows
|
||||
|
||||
### Creating a New Component Type
|
||||
|
||||
**1. Research:**
|
||||
|
||||
- Check if similar component exists
|
||||
- Review WDS component boundaries guide
|
||||
- Decide: new component or variant?
|
||||
|
||||
**2. Design:**
|
||||
|
||||
- Create base component
|
||||
- Add all required states
|
||||
- Apply design tokens
|
||||
|
||||
**3. Document:**
|
||||
|
||||
- Write clear description
|
||||
- Add WDS component ID
|
||||
- Document usage guidelines
|
||||
|
||||
**4. Sync:**
|
||||
|
||||
- Get Figma node ID
|
||||
- Update WDS mappings
|
||||
- Generate specification
|
||||
|
||||
**5. Test:**
|
||||
|
||||
- Create example instances
|
||||
- Test all variants
|
||||
- Verify responsive behavior
|
||||
|
||||
---
|
||||
|
||||
### Adding a Variant to Existing Component
|
||||
|
||||
**1. Assess:**
|
||||
|
||||
- Is this truly a variant?
|
||||
- Or should it be a new component?
|
||||
- Check with WDS assessment flow
|
||||
|
||||
**2. Add Variant:**
|
||||
|
||||
- Add new variant property value
|
||||
- Design variant appearance
|
||||
- Document differences
|
||||
|
||||
**3. Update Documentation:**
|
||||
|
||||
- Update component description
|
||||
- Add variant to list
|
||||
- Document when to use
|
||||
|
||||
**4. Sync:**
|
||||
|
||||
- Update WDS specification
|
||||
- Add variant to component file
|
||||
- Update version history
|
||||
|
||||
---
|
||||
|
||||
### Updating Component Styling
|
||||
|
||||
**1. Plan Change:**
|
||||
|
||||
- Document what's changing
|
||||
- Check impact on instances
|
||||
- Notify team
|
||||
|
||||
**2. Update Component:**
|
||||
|
||||
- Modify main component
|
||||
- Test all variants
|
||||
- Verify instances update
|
||||
|
||||
**3. Sync to WDS:**
|
||||
|
||||
- Update WDS specification
|
||||
- Document changes
|
||||
- Update version history
|
||||
|
||||
**4. Verify:**
|
||||
|
||||
- Check all instances
|
||||
- Test in examples
|
||||
- Confirm with team
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Component Not Syncing
|
||||
|
||||
**Problem:** MCP can't read component
|
||||
|
||||
**Solutions:**
|
||||
|
||||
- Check component name format
|
||||
- Verify WDS component ID in description
|
||||
- Ensure component is published
|
||||
- Check Figma API access
|
||||
|
||||
---
|
||||
|
||||
### Variants Not Appearing
|
||||
|
||||
**Problem:** Some variants missing in WDS
|
||||
|
||||
**Solutions:**
|
||||
|
||||
- Check variant property names
|
||||
- Verify all combinations exist
|
||||
- Ensure consistent naming
|
||||
- Re-sync component
|
||||
|
||||
---
|
||||
|
||||
### Design Tokens Not Applied
|
||||
|
||||
**Problem:** Hardcoded values instead of variables
|
||||
|
||||
**Solutions:**
|
||||
|
||||
- Replace hex colors with variables
|
||||
- Use spacing variables
|
||||
- Apply text styles
|
||||
- Re-sync component
|
||||
|
||||
---
|
||||
|
||||
### Instance Overrides Lost
|
||||
|
||||
**Problem:** Updates break instance overrides
|
||||
|
||||
**Solutions:**
|
||||
|
||||
- Don't change component structure
|
||||
- Add new properties instead
|
||||
- Maintain backward compatibility
|
||||
- Communicate changes to team
|
||||
|
||||
---
|
||||
|
||||
## Checklist
|
||||
|
||||
### Before Creating Component
|
||||
|
||||
- [ ] Checked if similar component exists
|
||||
- [ ] Reviewed component boundaries guide
|
||||
- [ ] Decided on component vs variant
|
||||
- [ ] Prepared design tokens
|
||||
- [ ] Planned all required states
|
||||
|
||||
### During Component Creation
|
||||
|
||||
- [ ] Used design tokens (no hardcoded values)
|
||||
- [ ] Created all required states
|
||||
- [ ] Applied auto layout properly
|
||||
- [ ] Added clear description
|
||||
- [ ] Included WDS component ID
|
||||
- [ ] Documented usage guidelines
|
||||
|
||||
### After Component Creation
|
||||
|
||||
- [ ] Copied Figma node ID
|
||||
- [ ] Updated figma-mappings.md
|
||||
- [ ] Generated WDS specification
|
||||
- [ ] Created example instances
|
||||
- [ ] Tested all variants
|
||||
- [ ] Notified team
|
||||
|
||||
---
|
||||
|
||||
## Resources
|
||||
|
||||
- **Figma Component Structure:** `data/design-system/figma-component-structure.md`
|
||||
- **Token Architecture:** `data/design-system/token-architecture.md`
|
||||
- **Component Boundaries:** `data/design-system/component-boundaries.md`
|
||||
- **Figma MCP Integration:** `figma-mcp-integration.md`
|
||||
|
||||
---
|
||||
|
||||
**Following this guide ensures your Figma components integrate seamlessly with WDS and maintain design system consistency.**
|
||||
@@ -0,0 +1,37 @@
|
||||
# Figma to Code Workshop
|
||||
|
||||
**Status:** Coming Soon
|
||||
|
||||
**Purpose:** Extract design specifications from Figma and implement them in code
|
||||
|
||||
**Tool:** Figma Desktop MCP Server
|
||||
**Direction:** Figma → Code
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This workshop will guide AI agents through importing design specifications from Figma to generate or update code implementations.
|
||||
|
||||
### When to Use Figma to Code
|
||||
|
||||
Import from Figma when:
|
||||
- ✅ Designer has updated visual specifications in Figma
|
||||
- ✅ New design system components need implementation
|
||||
- ✅ Design tokens (colors, spacing, typography) need extraction
|
||||
- ✅ Component states have been refined visually
|
||||
- ✅ Design-code sync is needed after visual iteration
|
||||
|
||||
---
|
||||
|
||||
## Planned Workflow
|
||||
|
||||
1. **Connection Check** - Verify Figma Desktop MCP server
|
||||
2. **Select Figma Node** - Identify what to import
|
||||
3. **Extract Design Specs** - Get colors, spacing, typography, layout
|
||||
4. **Generate/Update Code** - Create or update components
|
||||
5. **Verify Implementation** - Compare code output to Figma design
|
||||
|
||||
---
|
||||
|
||||
*This workshop will be developed to complement the Code to Figma workflow.*
|
||||
@@ -0,0 +1,458 @@
|
||||
# Figma Integration - Summary
|
||||
|
||||
**Last Updated:** January 9, 2026
|
||||
**Version:** WDS v6
|
||||
**Status:** Active Development
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This integration enables bidirectional workflow between code and Figma for design system development and visual refinement.
|
||||
|
||||
### Bidirectional Workflow
|
||||
|
||||
```
|
||||
Code ⇄ Figma
|
||||
```
|
||||
|
||||
**Two Main Workflows:**
|
||||
|
||||
1. **Code to Figma (C2F):** Send code implementations to Figma for visual documentation and refinement
|
||||
2. **Figma to Code (F2C):** Import design specifications from Figma to generate or update code
|
||||
|
||||
**Key Innovation:** Specification-driven approach ensures design-code parity through shared OBJECT IDs, enabling traceability and consistency across both directions.
|
||||
|
||||
---
|
||||
|
||||
## Workshop Structure
|
||||
|
||||
### Code to Figma (C2F) Workshop
|
||||
**Location:** `code-to-figma/`
|
||||
|
||||
**Purpose:** Send code implementations to Figma for design review, documentation, and visual iteration
|
||||
|
||||
**Workflow Steps:**
|
||||
1. Connection Check - Verify html.to.design MCP server
|
||||
2. Identify Type - Determine export scenario (prototype page, design system component, or frontend view)
|
||||
3. Prepare Specifications - Find or create OBJECT IDs for proper Figma layer naming
|
||||
4. Generate & Validate - Create Figma-compatible HTML with validation
|
||||
5. Send to Figma - Execute export and verify success
|
||||
|
||||
**Key Features:**
|
||||
- Specification-driven OBJECT ID naming
|
||||
- Three export scenarios with specific ID patterns
|
||||
- Automated validation before export
|
||||
- Reverse engineering for missing specifications
|
||||
|
||||
---
|
||||
|
||||
### Figma to Code (F2C) Workshop
|
||||
**Location:** `figma-to-code/`
|
||||
|
||||
**Status:** Coming Soon
|
||||
|
||||
**Purpose:** Import design specifications from Figma to generate or update code implementations
|
||||
|
||||
**Planned Workflow:**
|
||||
1. Connection Check - Verify Figma Desktop MCP server
|
||||
2. Select Figma Node - Identify what to import
|
||||
3. Extract Design Specs - Get colors, spacing, typography, layout
|
||||
4. Generate/Update Code - Create or update components
|
||||
5. Verify Implementation - Compare code output to Figma design
|
||||
|
||||
---
|
||||
|
||||
## Reference Documentation
|
||||
|
||||
**Location:** `reference/`
|
||||
|
||||
Supporting documentation for Figma integration workflows:
|
||||
|
||||
1. **`figma-designer-guide.md`** - Guide for designers creating components in Figma
|
||||
2. **`mcp-server-integration.md`** - MCP server setup and configuration
|
||||
3. **`tools-reference.md`** - Reference for Figma MCP tools and parameters
|
||||
4. **`when-to-extract-decision-guide.md`** - Decision tree for when to use Figma integration
|
||||
5. **`figma-mcp-integration.md`** - Technical documentation about MCP integration
|
||||
6. **`prototype-to-figma-workflow.md`** - Iterative refinement workflow documentation
|
||||
|
||||
---
|
||||
|
||||
## Folder Structure
|
||||
|
||||
```
|
||||
6-asset-generation/
|
||||
├── code-to-figma/ # C2F Workshop
|
||||
│ ├── workflow.md
|
||||
│ └── steps/
|
||||
│ ├── step-01-connection-check.md
|
||||
│ ├── step-02-identify-export-type.md
|
||||
│ ├── step-03-prepare-specifications.md
|
||||
│ ├── step-04-generate-validate.md
|
||||
│ ├── step-05-execute-export.md
|
||||
│ └── [substeps folders]
|
||||
│
|
||||
├── figma-to-code/ # F2C Workshop (coming soon)
|
||||
│ └── README.md
|
||||
│
|
||||
├── reference/ # Reference documentation
|
||||
│ ├── figma-designer-guide.md
|
||||
│ ├── mcp-server-integration.md
|
||||
│ ├── tools-reference.md
|
||||
│ ├── when-to-extract-decision-guide.md
|
||||
│ ├── figma-mcp-integration.md
|
||||
│ └── prototype-to-figma-workflow.md
|
||||
│
|
||||
└── INTEGRATION-SUMMARY.md # This file
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Core Concepts
|
||||
|
||||
### The Missing Dimension
|
||||
|
||||
**Before:** WDS created specifications and functional prototypes, but visual design creation was manual
|
||||
|
||||
**After:** WDS now supports iterative visual refinement through Figma extraction
|
||||
|
||||
### Design System Evolution
|
||||
|
||||
**Key Principle:** Design system grows organically as prototypes are built
|
||||
|
||||
**Process:**
|
||||
1. Create prototype with existing design system (may look basic)
|
||||
2. Extract to Figma when gaps identified
|
||||
3. Refine visuals and create missing components
|
||||
4. Update design system with new tokens/components
|
||||
5. Re-render prototype with enhanced design system
|
||||
6. Iterate until polished
|
||||
|
||||
### When to Extract
|
||||
|
||||
**Extract when:**
|
||||
- Design system is incomplete
|
||||
- Prototype needs visual polish
|
||||
- New components required
|
||||
- Stakeholder presentation needed
|
||||
|
||||
**Don't extract when:**
|
||||
- Design system covers all needs
|
||||
- Prototype looks sufficient
|
||||
- Rapid iteration more important
|
||||
- Early exploration phase
|
||||
|
||||
---
|
||||
|
||||
## Tool Integration
|
||||
|
||||
### html.to.design
|
||||
|
||||
**Role:** Convert HTML prototypes to Figma for visual refinement
|
||||
|
||||
**Process:**
|
||||
1. Upload HTML prototype
|
||||
2. Configure conversion options
|
||||
3. Import to Figma
|
||||
4. Refine design
|
||||
5. Extract design system updates
|
||||
|
||||
**Benefits:**
|
||||
- Preserves layout structure
|
||||
- Converts CSS to Figma styles
|
||||
- Maintains element hierarchy
|
||||
- Enables visual refinement
|
||||
|
||||
### Area Tag System
|
||||
|
||||
**Role:** Precise region mapping for image-based prototypes
|
||||
|
||||
**Usage:**
|
||||
- Map clickable regions on images
|
||||
- Include Object IDs for traceability
|
||||
- Extract coordinates via dev mode
|
||||
- Document region mappings
|
||||
|
||||
**Integration:**
|
||||
- Works with dev-mode.js component
|
||||
- Supports image-based prototypes
|
||||
- Enables precise click mapping
|
||||
|
||||
### Dev Mode Component
|
||||
|
||||
**Role:** Extract Object IDs and area coordinates from prototypes
|
||||
|
||||
**Features:**
|
||||
- Shift + Click to copy Object IDs
|
||||
- Visual highlights
|
||||
- Area tag detection
|
||||
- Coordinate extraction
|
||||
|
||||
**Benefit:** Maintains traceability through Figma extraction
|
||||
|
||||
---
|
||||
|
||||
## Workflow Integration
|
||||
|
||||
### Phase 4: UX Design
|
||||
|
||||
**Updated Step 4D (Prototype):**
|
||||
- Create functional prototype
|
||||
- Test functionality
|
||||
- **NEW:** Assess visual quality
|
||||
- **NEW:** Option to extract to Figma
|
||||
- Continue to PRD update
|
||||
|
||||
### Phase 7: Design System
|
||||
|
||||
**New Workflow Branch:**
|
||||
- Existing: Component specification → Design system
|
||||
- Existing: Figma manual creation → Design system
|
||||
- **NEW:** Prototype extraction → Figma → Design system
|
||||
|
||||
### Iteration Loop
|
||||
|
||||
**Complete Cycle:**
|
||||
```
|
||||
1. Sketch (concept)
|
||||
2. Specification (detailed)
|
||||
3. Prototype (functional)
|
||||
4. Figma extraction (if needed)
|
||||
5. Visual refinement
|
||||
6. Design system update
|
||||
7. Re-render prototype
|
||||
8. Assess → Iterate or Complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Benefits
|
||||
|
||||
### For Designers
|
||||
|
||||
**Flexibility:**
|
||||
- Start with functional prototypes
|
||||
- Refine visuals when needed
|
||||
- Iterate incrementally
|
||||
- Build design system organically
|
||||
|
||||
**Efficiency:**
|
||||
- Don't need complete design system upfront
|
||||
- Extract only when necessary
|
||||
- Reuse refined components
|
||||
- Reduce rework
|
||||
|
||||
### For Teams
|
||||
|
||||
**Collaboration:**
|
||||
- Shared design language
|
||||
- Clear handoff process
|
||||
- Bidirectional sync
|
||||
- Maintained traceability
|
||||
|
||||
**Quality:**
|
||||
- Polished final products
|
||||
- Consistent design system
|
||||
- Professional visuals
|
||||
- Stakeholder-ready
|
||||
|
||||
### For Projects
|
||||
|
||||
**Speed:**
|
||||
- Faster initial prototypes
|
||||
- Iterative refinement
|
||||
- Parallel work streams
|
||||
- Reduced bottlenecks
|
||||
|
||||
**Flexibility:**
|
||||
- Adapt to changing requirements
|
||||
- Grow design system as needed
|
||||
- Balance speed and polish
|
||||
- Ship working products
|
||||
|
||||
---
|
||||
|
||||
## Public Release Readiness
|
||||
|
||||
### Documentation Status
|
||||
|
||||
✅ **Complete:**
|
||||
- Prototype-to-Figma workflow
|
||||
- Decision guide
|
||||
- Tools reference
|
||||
- Phase 4D integration
|
||||
- Phase 7 README update
|
||||
|
||||
✅ **Tested:**
|
||||
- Workflow logic validated
|
||||
- Integration points confirmed
|
||||
- Decision framework practical
|
||||
- Tool capabilities verified
|
||||
|
||||
✅ **Ready for:**
|
||||
- Public documentation
|
||||
- User testing
|
||||
- Team adoption
|
||||
- Production use
|
||||
|
||||
### What's Not Included
|
||||
|
||||
**Out of Scope:**
|
||||
- MagicPatterns integration (not needed with html.to.design)
|
||||
- Automated extraction (manual process documented)
|
||||
- Real-time sync (manual iteration cycle)
|
||||
|
||||
**Future Enhancements:**
|
||||
- Automated design token extraction
|
||||
- Figma plugin for WDS
|
||||
- Real-time bidirectional sync
|
||||
- AI-powered component matching
|
||||
|
||||
---
|
||||
|
||||
## Migration Notes
|
||||
|
||||
### For Existing WDS Users
|
||||
|
||||
**No Breaking Changes:**
|
||||
- Existing workflows continue to work
|
||||
- New workflow is optional
|
||||
- Backward compatible
|
||||
- Incremental adoption
|
||||
|
||||
**How to Adopt:**
|
||||
1. Read prototype-to-Figma workflow
|
||||
2. Try with one prototype
|
||||
3. Refine in Figma
|
||||
4. Update design system
|
||||
5. Re-render and compare
|
||||
6. Expand to more pages
|
||||
|
||||
### For New WDS Users
|
||||
|
||||
**Recommended Approach:**
|
||||
1. Start with first page
|
||||
2. Create basic prototype
|
||||
3. Extract to Figma
|
||||
4. Build design system foundation
|
||||
5. Use for subsequent pages
|
||||
6. Extract only when gaps found
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Quality Indicators
|
||||
|
||||
✅ Prototypes look polished
|
||||
✅ Design system is comprehensive
|
||||
✅ Figma and code are in sync
|
||||
✅ Object IDs maintained throughout
|
||||
✅ Iterations are productive
|
||||
✅ Team aligned on visual direction
|
||||
|
||||
### Efficiency Indicators
|
||||
|
||||
✅ Fewer refinement cycles needed
|
||||
✅ Design system grows organically
|
||||
✅ Reusable components identified
|
||||
✅ Faster subsequent prototypes
|
||||
✅ Reduced rework
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### For Documentation
|
||||
|
||||
1. ✅ Core workflow documentation complete
|
||||
2. ✅ Decision guides created
|
||||
3. ✅ Tools reference documented
|
||||
4. ✅ Integration points updated
|
||||
5. 🔄 Session logs cleanup (in progress)
|
||||
6. ⏳ User testing and feedback
|
||||
7. ⏳ Video tutorials (future)
|
||||
8. ⏳ Example projects (future)
|
||||
|
||||
### For Implementation
|
||||
|
||||
1. ✅ Workflow files created
|
||||
2. ✅ Phase 4D updated
|
||||
3. ✅ Phase 7 updated
|
||||
4. ⏳ Test with real projects
|
||||
5. ⏳ Gather user feedback
|
||||
6. ⏳ Refine based on usage
|
||||
7. ⏳ Create example case studies
|
||||
|
||||
---
|
||||
|
||||
## Key Takeaways
|
||||
|
||||
### The Complete WDS Flow
|
||||
|
||||
**Concept-First Approach:**
|
||||
1. Sketch and specification are source of truth
|
||||
2. Generate functional prototypes from specs
|
||||
3. Apply design system (may be incomplete initially)
|
||||
4. Extract to Figma when visual refinement needed
|
||||
5. Refine design and extend design system
|
||||
6. Re-render with enhanced design system
|
||||
7. Iterate until polished
|
||||
|
||||
### Design System Philosophy
|
||||
|
||||
**Just-In-Time Design Definitions:**
|
||||
- Don't need complete design system upfront
|
||||
- Build definitions as needed
|
||||
- Extract from working prototypes
|
||||
- Grow organically with product
|
||||
- Reduce upfront investment
|
||||
|
||||
### Iterative Refinement
|
||||
|
||||
**Balanced Approach:**
|
||||
- Functional first, polish later
|
||||
- Extract strategically, not automatically
|
||||
- Iterate incrementally
|
||||
- Ship working products
|
||||
- Balance speed and quality
|
||||
|
||||
---
|
||||
|
||||
## Contact and Support
|
||||
|
||||
**Documentation Location:**
|
||||
- `workflows/6-asset-generation/6-asset-generation/`
|
||||
|
||||
**Related Documentation:**
|
||||
- Phase 4: UX Design workflows
|
||||
- Phase 7: Design System workflows
|
||||
- Interactive Prototypes guides
|
||||
- Figma Integration guides
|
||||
|
||||
**Questions or Issues:**
|
||||
- Review decision guide for common scenarios
|
||||
- Check tools reference for troubleshooting
|
||||
- Follow workflow documentation step-by-step
|
||||
- Test with simple prototype first
|
||||
|
||||
---
|
||||
|
||||
**This integration completes the WDS design workflow, enabling teams to create polished, production-ready designs through iterative refinement of functional prototypes.**
|
||||
|
||||
---
|
||||
|
||||
## Version History
|
||||
|
||||
**v1.0 - January 8, 2026**
|
||||
- Initial release
|
||||
- Prototype-to-Figma workflow
|
||||
- Decision guide
|
||||
- Tools reference
|
||||
- Phase 4D and Phase 7 integration
|
||||
|
||||
**Future Versions:**
|
||||
- User feedback integration
|
||||
- Enhanced automation
|
||||
- Additional tool integrations
|
||||
- Example case studies
|
||||
@@ -0,0 +1,661 @@
|
||||
# Figma MCP Integration for WDS
|
||||
|
||||
**Purpose:** Technical guide for integrating Figma with WDS using Model Context Protocol (MCP).
|
||||
|
||||
**Audience:** AI agents, developers, technical designers
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
**Figma MCP enables:**
|
||||
|
||||
- Reading component specifications from Figma
|
||||
- Extracting design tokens
|
||||
- Generating WDS component specifications
|
||||
- Maintaining Figma ↔ WDS sync
|
||||
|
||||
---
|
||||
|
||||
## MCP Server Setup
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Figma API access token
|
||||
- MCP server configured
|
||||
- WDS project initialized
|
||||
- Design system mode set to "custom"
|
||||
|
||||
---
|
||||
|
||||
### Configuration
|
||||
|
||||
**Add to MCP configuration:**
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"figma": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@modelcontextprotocol/server-figma"],
|
||||
"env": {
|
||||
"FIGMA_PERSONAL_ACCESS_TOKEN": "your-figma-token"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Get Figma API token:**
|
||||
|
||||
1. Go to Figma → Settings → Account
|
||||
2. Scroll to "Personal access tokens"
|
||||
3. Click "Generate new token"
|
||||
4. Copy token and add to configuration
|
||||
|
||||
---
|
||||
|
||||
## MCP Operations
|
||||
|
||||
### 1. Read Figma Component
|
||||
|
||||
**Purpose:** Extract component data from Figma
|
||||
|
||||
**Input:**
|
||||
|
||||
- Figma file ID
|
||||
- Node ID
|
||||
- Or component name
|
||||
|
||||
**Output:**
|
||||
|
||||
- Component structure
|
||||
- Variants
|
||||
- Properties
|
||||
- Design tokens used
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
Agent: Read Figma component Button/Primary
|
||||
|
||||
MCP Response:
|
||||
{
|
||||
"name": "Button/Primary [btn-001]",
|
||||
"type": "COMPONENT_SET",
|
||||
"variants": [
|
||||
{
|
||||
"name": "Type=Primary, Size=Medium, State=Default",
|
||||
"properties": {
|
||||
"Type": "Primary",
|
||||
"Size": "Medium",
|
||||
"State": "Default"
|
||||
},
|
||||
"styles": {
|
||||
"background": "primary/600",
|
||||
"padding": "16px 12px",
|
||||
"borderRadius": "8px"
|
||||
}
|
||||
},
|
||||
// ... more variants
|
||||
],
|
||||
"description": "Button Primary [btn-001]...",
|
||||
"nodeId": "456:789"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Extract Design Tokens
|
||||
|
||||
**Purpose:** Get design token values from Figma
|
||||
|
||||
**Input:**
|
||||
|
||||
- Figma file ID
|
||||
- Token type (colors, typography, spacing)
|
||||
|
||||
**Output:**
|
||||
|
||||
- Token definitions
|
||||
- Token values
|
||||
- Token mappings
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
Agent: Extract color tokens from Figma
|
||||
|
||||
MCP Response:
|
||||
{
|
||||
"colors": {
|
||||
"primary/50": "#eff6ff",
|
||||
"primary/500": "#3b82f6",
|
||||
"primary/600": "#2563eb",
|
||||
"gray/900": "#111827"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Get Component Node ID
|
||||
|
||||
**Purpose:** Find Figma node ID for component
|
||||
|
||||
**Input:**
|
||||
|
||||
- Component name or WDS component ID
|
||||
|
||||
**Output:**
|
||||
|
||||
- Figma node ID
|
||||
- File ID
|
||||
- Full Figma URL
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
Agent: Get node ID for Button [btn-001]
|
||||
|
||||
MCP Response:
|
||||
{
|
||||
"componentId": "btn-001",
|
||||
"fileId": "abc123",
|
||||
"nodeId": "456:789",
|
||||
"url": "figma://file/abc123/node/456:789"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. List Components
|
||||
|
||||
**Purpose:** Get all components in Figma file
|
||||
|
||||
**Input:**
|
||||
|
||||
- Figma file ID
|
||||
- Optional: filter by type
|
||||
|
||||
**Output:**
|
||||
|
||||
- List of components
|
||||
- Component names
|
||||
- Node IDs
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
Agent: List all button components
|
||||
|
||||
MCP Response:
|
||||
{
|
||||
"components": [
|
||||
{
|
||||
"name": "Button/Primary [btn-001]",
|
||||
"nodeId": "456:789",
|
||||
"type": "COMPONENT_SET"
|
||||
},
|
||||
{
|
||||
"name": "Button/Secondary [btn-001]",
|
||||
"nodeId": "456:790",
|
||||
"type": "COMPONENT_SET"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Sync Workflows
|
||||
|
||||
### Figma → WDS Sync
|
||||
|
||||
**When:** Component created or updated in Figma
|
||||
|
||||
**Process:**
|
||||
|
||||
**Step 1: Detect Change**
|
||||
|
||||
```
|
||||
Designer updates Button/Primary in Figma
|
||||
Designer notifies WDS system
|
||||
Or: Automated webhook triggers sync
|
||||
```
|
||||
|
||||
**Step 2: Read Component**
|
||||
|
||||
```
|
||||
Agent: Read Figma component Button/Primary [btn-001]
|
||||
|
||||
MCP reads:
|
||||
- Component structure
|
||||
- All variants
|
||||
- All states
|
||||
- Properties
|
||||
- Design tokens
|
||||
- Description
|
||||
```
|
||||
|
||||
**Step 3: Parse Component Data**
|
||||
|
||||
```
|
||||
Agent extracts:
|
||||
- Component type: Button
|
||||
- WDS ID: btn-001
|
||||
- Variants: primary, secondary, ghost
|
||||
- States: default, hover, active, disabled, loading
|
||||
- Sizes: small, medium, large
|
||||
- Design tokens: primary/600, spacing/4, radius/md
|
||||
```
|
||||
|
||||
**Step 4: Generate WDS Specification**
|
||||
|
||||
```
|
||||
Agent creates/updates:
|
||||
D-Design-System/components/button.md
|
||||
|
||||
Using template: component.template.md
|
||||
Filling in:
|
||||
- Component name and ID
|
||||
- Variants from Figma
|
||||
- States from Figma
|
||||
- Styling from design tokens
|
||||
- Description from Figma
|
||||
```
|
||||
|
||||
**Step 5: Update Mappings**
|
||||
|
||||
```
|
||||
Agent updates:
|
||||
D-Design-System/figma-mappings.md
|
||||
|
||||
Adds/updates:
|
||||
Button [btn-001] → figma://file/abc123/node/456:789
|
||||
```
|
||||
|
||||
**Step 6: Verify and Confirm**
|
||||
|
||||
```
|
||||
Agent presents generated spec to designer
|
||||
Designer reviews and confirms
|
||||
Spec is committed to repository
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### WDS → Figma Notification
|
||||
|
||||
**When:** WDS specification updated
|
||||
|
||||
**Process:**
|
||||
|
||||
**Step 1: Detect Change**
|
||||
|
||||
```
|
||||
WDS specification updated
|
||||
Git commit triggers notification
|
||||
```
|
||||
|
||||
**Step 2: Identify Figma Component**
|
||||
|
||||
```
|
||||
Agent reads figma-mappings.md
|
||||
Finds: Button [btn-001] → figma://file/abc123/node/456:789
|
||||
```
|
||||
|
||||
**Step 3: Notify Designer**
|
||||
|
||||
```
|
||||
Agent creates notification:
|
||||
"Button [btn-001] specification updated in WDS.
|
||||
Please review and update Figma component if needed.
|
||||
|
||||
Changes:
|
||||
- Added new loading state
|
||||
- Updated hover animation
|
||||
- Modified padding values
|
||||
|
||||
Figma component: [Link to Figma]"
|
||||
```
|
||||
|
||||
**Step 4: Designer Updates Figma**
|
||||
|
||||
```
|
||||
Designer reviews changes
|
||||
Updates Figma component
|
||||
Confirms sync complete
|
||||
```
|
||||
|
||||
**Note:** Full WDS → Figma automation requires Figma API write access (currently read-only for MCP).
|
||||
|
||||
---
|
||||
|
||||
## Component Specification Generation
|
||||
|
||||
### Template-Based Generation
|
||||
|
||||
**Agent uses component template:**
|
||||
|
||||
**Input:**
|
||||
|
||||
```
|
||||
Figma component data:
|
||||
{
|
||||
"name": "Button/Primary [btn-001]",
|
||||
"variants": [...],
|
||||
"states": [...],
|
||||
"tokens": {...},
|
||||
"description": "..."
|
||||
}
|
||||
```
|
||||
|
||||
**Template:** `templates/component.template.md`
|
||||
|
||||
**Output:** `D-Design-System/components/button.md`
|
||||
|
||||
**Process:**
|
||||
|
||||
1. Load component template
|
||||
2. Fill in component name and ID
|
||||
3. Extract and format variants
|
||||
4. Extract and format states
|
||||
5. Map design tokens to WDS tokens
|
||||
6. Add styling specifications
|
||||
7. Include description and usage
|
||||
8. Generate accessibility notes
|
||||
9. Add version history
|
||||
10. Save to design system folder
|
||||
|
||||
---
|
||||
|
||||
### Token Mapping
|
||||
|
||||
**Figma variables → WDS tokens:**
|
||||
|
||||
**Agent maps:**
|
||||
|
||||
```
|
||||
Figma: primary/600 → WDS: color-primary-600
|
||||
Figma: spacing/4 → WDS: spacing-4
|
||||
Figma: Text/Body → WDS: text-body
|
||||
Figma: shadow/sm → WDS: shadow-sm
|
||||
```
|
||||
|
||||
**Mapping rules:**
|
||||
|
||||
- Figma collection/variable → WDS category-name-value
|
||||
- Maintain semantic meaning
|
||||
- Consistent naming across systems
|
||||
- Document custom mappings
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Component Not Found
|
||||
|
||||
**Error:** Figma component doesn't exist
|
||||
|
||||
**Agent response:**
|
||||
|
||||
```
|
||||
⚠️ Component not found in Figma
|
||||
|
||||
Component: Button/Primary [btn-001]
|
||||
File ID: abc123
|
||||
Node ID: 456:789
|
||||
|
||||
Possible causes:
|
||||
- Component deleted in Figma
|
||||
- Node ID changed
|
||||
- File ID incorrect
|
||||
- Access permissions
|
||||
|
||||
Actions:
|
||||
1. Verify component exists in Figma
|
||||
2. Update node ID in figma-mappings.md
|
||||
3. Re-sync component
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Missing WDS Component ID
|
||||
|
||||
**Error:** Figma component has no WDS ID in description
|
||||
|
||||
**Agent response:**
|
||||
|
||||
```
|
||||
⚠️ WDS Component ID missing
|
||||
|
||||
Component: Button/Primary
|
||||
Figma node: 456:789
|
||||
|
||||
Please add WDS component ID to Figma description:
|
||||
Format: [component-id]
|
||||
Example: Button/Primary [btn-001]
|
||||
|
||||
After adding ID, re-sync component.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Token Mapping Failure
|
||||
|
||||
**Error:** Can't map Figma variable to WDS token
|
||||
|
||||
**Agent response:**
|
||||
|
||||
```
|
||||
⚠️ Token mapping failed
|
||||
|
||||
Figma variable: custom-blue-500
|
||||
No matching WDS token found
|
||||
|
||||
Options:
|
||||
1. Create new WDS token: color-custom-blue-500
|
||||
2. Map to existing token: color-primary-500
|
||||
3. Add custom mapping rule
|
||||
|
||||
Your choice:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Sync Conflict
|
||||
|
||||
**Error:** Figma and WDS have different versions
|
||||
|
||||
**Agent response:**
|
||||
|
||||
```
|
||||
⚠️ Sync conflict detected
|
||||
|
||||
Component: Button [btn-001]
|
||||
|
||||
Figma version:
|
||||
- Last updated: 2024-12-15
|
||||
- Changes: Added loading state
|
||||
|
||||
WDS version:
|
||||
- Last updated: 2024-12-14
|
||||
- Changes: Updated hover animation
|
||||
|
||||
Options:
|
||||
1. Figma wins (overwrite WDS)
|
||||
2. WDS wins (notify designer)
|
||||
3. Manual merge (review both)
|
||||
|
||||
Your choice:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### For AI Agents
|
||||
|
||||
**DO ✅**
|
||||
|
||||
- Always check for WDS component ID in Figma
|
||||
- Verify token mappings before generating specs
|
||||
- Present generated specs for designer review
|
||||
- Update figma-mappings.md after sync
|
||||
- Document sync operations in version history
|
||||
|
||||
**DON'T ❌**
|
||||
|
||||
- Don't overwrite WDS specs without confirmation
|
||||
- Don't create components without designer approval
|
||||
- Don't skip token mapping validation
|
||||
- Don't ignore sync conflicts
|
||||
- Don't forget to update mappings
|
||||
|
||||
---
|
||||
|
||||
### For Designers
|
||||
|
||||
**DO ✅**
|
||||
|
||||
- Add WDS component ID to all Figma components
|
||||
- Use design tokens (variables) consistently
|
||||
- Document component changes
|
||||
- Notify system when updating components
|
||||
- Review generated specs before committing
|
||||
|
||||
**DON'T ❌**
|
||||
|
||||
- Don't use hardcoded values
|
||||
- Don't skip component descriptions
|
||||
- Don't forget to sync after changes
|
||||
- Don't detach component instances
|
||||
- Don't change component IDs
|
||||
|
||||
---
|
||||
|
||||
## Integration Points
|
||||
|
||||
### Phase 4: UX Design
|
||||
|
||||
**When component is specified in Phase 4:**
|
||||
|
||||
1. Designer creates sketch
|
||||
2. Agent specifies component
|
||||
3. Design system router checks for similar components
|
||||
4. If new component needed:
|
||||
- Designer creates in Figma
|
||||
- MCP reads from Figma
|
||||
- Spec generated automatically
|
||||
|
||||
---
|
||||
|
||||
### Phase 5: Design System
|
||||
|
||||
**When component is added to design system:**
|
||||
|
||||
1. Component specification complete
|
||||
2. Agent checks: Figma component exists?
|
||||
3. If yes:
|
||||
- MCP reads Figma component
|
||||
- Extracts styling details
|
||||
- Updates WDS spec with Figma data
|
||||
4. If no:
|
||||
- Designer creates in Figma
|
||||
- MCP syncs to WDS
|
||||
|
||||
---
|
||||
|
||||
## Command Reference
|
||||
|
||||
### Read Component
|
||||
|
||||
```
|
||||
Agent: Read Figma component [component-name]
|
||||
MCP: Returns component data
|
||||
```
|
||||
|
||||
### Extract Tokens
|
||||
|
||||
```
|
||||
Agent: Extract [token-type] tokens from Figma
|
||||
MCP: Returns token definitions
|
||||
```
|
||||
|
||||
### Get Node ID
|
||||
|
||||
```
|
||||
Agent: Get Figma node ID for [component-id]
|
||||
MCP: Returns node ID and URL
|
||||
```
|
||||
|
||||
### List Components
|
||||
|
||||
```
|
||||
Agent: List Figma components [optional: filter]
|
||||
MCP: Returns component list
|
||||
```
|
||||
|
||||
### Sync Component
|
||||
|
||||
```
|
||||
Agent: Sync Figma component [component-name] to WDS
|
||||
MCP: Reads component, generates spec, updates mappings
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### MCP Server Not Responding
|
||||
|
||||
**Check:**
|
||||
|
||||
- MCP server is running
|
||||
- Figma API token is valid
|
||||
- Network connection is active
|
||||
- File ID and node ID are correct
|
||||
|
||||
---
|
||||
|
||||
### Invalid API Token
|
||||
|
||||
**Error:** 403 Forbidden
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. Generate new Figma API token
|
||||
2. Update MCP configuration
|
||||
3. Restart MCP server
|
||||
4. Retry operation
|
||||
|
||||
---
|
||||
|
||||
### Rate Limiting
|
||||
|
||||
**Error:** 429 Too Many Requests
|
||||
|
||||
**Solution:**
|
||||
|
||||
- Wait before retrying
|
||||
- Batch operations when possible
|
||||
- Cache component data
|
||||
- Reduce sync frequency
|
||||
|
||||
---
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
**Planned features:**
|
||||
|
||||
- Automated sync on Figma changes (webhooks)
|
||||
- Bidirectional sync (WDS → Figma write)
|
||||
- Batch component import
|
||||
- Design token extraction automation
|
||||
- Component usage tracking from Figma
|
||||
- Visual diff for sync conflicts
|
||||
|
||||
---
|
||||
|
||||
**This MCP integration enables seamless Figma ↔ WDS synchronization while maintaining designer control and design system consistency.**
|
||||
@@ -0,0 +1,55 @@
|
||||
# Figma Plugin Setup Guide
|
||||
|
||||
Reference for setting up the html.to.design plugin and MCP server connection.
|
||||
|
||||
---
|
||||
|
||||
## 1. Plugin Installation
|
||||
|
||||
Install the html.to.design plugin in Figma:
|
||||
|
||||
1. Open Figma (desktop app or web: figma.com)
|
||||
2. Click on your profile icon (top-right corner)
|
||||
3. Select "Community" from the menu
|
||||
4. In the search bar, type "html.to.design"
|
||||
5. Click on the "html.to.design" plugin result
|
||||
6. Click "Install" or "Try it out" button
|
||||
7. Plugin is now installed
|
||||
|
||||
---
|
||||
|
||||
## 2. Activate Plugin
|
||||
|
||||
Activate the plugin in your Figma file:
|
||||
|
||||
1. Open any Figma file (or create a new one for testing)
|
||||
2. Right-click anywhere on the canvas
|
||||
3. Select "Plugins" > "html.to.design"
|
||||
OR use the menu: Plugins > html.to.design
|
||||
4. The plugin panel should appear on the right side of your screen
|
||||
5. Keep the plugin panel open during the export process
|
||||
|
||||
---
|
||||
|
||||
## 3. Verify MCP Configuration
|
||||
|
||||
Confirm that the html.to.design MCP server is configured in the IDE:
|
||||
|
||||
1. Open your IDE Settings/Preferences
|
||||
2. Navigate to the MCP Servers section
|
||||
3. Look for "html.to.design" in the server list
|
||||
|
||||
**If configured:** MCP server is ready. Run a test export to verify connection.
|
||||
|
||||
**If not configured:** The html.to.design MCP server needs to be added to your IDE configuration. Refer to your IDE's MCP server documentation for configuration steps. The server should connect to the html.to.design plugin running in Figma.
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Issue | Solution |
|
||||
|-------|----------|
|
||||
| Plugin not found in Community | Search "html to design" (without dots) |
|
||||
| Plugin panel doesn't appear | Try closing and reopening Figma |
|
||||
| MCP server not connecting | Verify Figma plugin is running and panel is open |
|
||||
| Test export fails | Check both plugin and MCP server are active |
|
||||
@@ -0,0 +1,128 @@
|
||||
# Figma Specification Preparation
|
||||
|
||||
Reference for analyzing code and creating specifications with OBJECT IDs for Figma export.
|
||||
|
||||
---
|
||||
|
||||
## 1. Analyze Code
|
||||
|
||||
Extract component information from code to create specifications:
|
||||
|
||||
**Component Structure:**
|
||||
- Identify component name and file location
|
||||
- Map parent/child relationships
|
||||
- Note component hierarchy
|
||||
|
||||
**Props & States:**
|
||||
- Extract available props
|
||||
- Identify state variations (hover, active, disabled, focus, etc.)
|
||||
- Note conditional rendering logic
|
||||
|
||||
**Visual Properties:**
|
||||
- Extract CSS classes used
|
||||
- Note inline styles
|
||||
- Identify design tokens/CSS variables referenced
|
||||
- Document colors, spacing, typography
|
||||
|
||||
**Content:**
|
||||
- Extract text content
|
||||
- Note language variations (if i18n present)
|
||||
- Identify dynamic vs. static content
|
||||
|
||||
**Behavior:**
|
||||
- Document event handlers
|
||||
- Note interactive elements
|
||||
- Identify navigation/routing
|
||||
|
||||
---
|
||||
|
||||
## 2. Generate OBJECT IDs
|
||||
|
||||
Create OBJECT IDs following project naming conventions. Determine the pattern by analyzing existing IDs in specifications:
|
||||
|
||||
**Pattern A - Page-based:**
|
||||
- Format: `{page}-{section}-{element}`
|
||||
- Example: `start-hero-cta`, `start-message-headline`
|
||||
- Use when: Exporting full pages or page sections
|
||||
|
||||
**Pattern B - Component-based:**
|
||||
- Format: `{component}-{variant}-{state}`
|
||||
- Example: `btn-cta-primary-hover`, `input-text-disabled`
|
||||
- Use when: Exporting design system components
|
||||
|
||||
**Pattern C - Hierarchical:**
|
||||
- Format: `{parent}-{child}-{grandchild}`
|
||||
- Example: `header-nav-menu-item`, `footer-social-icon-twitter`
|
||||
- Use when: Exporting component blocks with nested elements
|
||||
|
||||
**For each component without OBJECT ID:**
|
||||
1. Identify component type and context
|
||||
2. Apply naming pattern
|
||||
3. Ensure uniqueness
|
||||
4. Add state suffix if applicable
|
||||
|
||||
---
|
||||
|
||||
## 3. Create Specification Document
|
||||
|
||||
Generate a specification document with the generated OBJECT IDs.
|
||||
|
||||
**Determine location:**
|
||||
- Design system component: `docs/D-Design-System/03-Atomic-Components/{category}/`
|
||||
- Page component: `docs/C-UX-Scenarios/{scenario}/{page}/`
|
||||
- Shared component: `docs/D-Design-System/04-Molecules/` or `05-Organisms/`
|
||||
|
||||
**Specification structure:**
|
||||
|
||||
```markdown
|
||||
# {Component/Page Name}
|
||||
|
||||
**OBJECT ID**: `{primary-object-id}`
|
||||
|
||||
## Purpose
|
||||
{Brief description from code analysis}
|
||||
|
||||
## Structure
|
||||
- **HTML Tag**: `<{tag}>`
|
||||
- **CSS Class**: `.{class-name}`
|
||||
- **Component File**: `{file-path}`
|
||||
- **OBJECT ID**: `{object-id}`
|
||||
|
||||
## Visual Style
|
||||
- **Typography**: {font-family}, {size}, {weight}, {color}
|
||||
- **Colors**: Background, Border, Text
|
||||
- **Spacing**: Padding, Margin
|
||||
- **Layout**: {display}, {positioning}
|
||||
|
||||
## States
|
||||
### {State Name}
|
||||
- **OBJECT ID**: `{component-id-state}`
|
||||
- **Visual Changes**: {description}
|
||||
- **Trigger**: {user action or condition}
|
||||
|
||||
## Behavior
|
||||
{Interactive behavior description}
|
||||
|
||||
## Content
|
||||
- **EN**: "{english-content}"
|
||||
- **SE**: "{swedish-content}" (if applicable)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Review with User
|
||||
|
||||
Present the generated specification for approval:
|
||||
|
||||
**Present:**
|
||||
- Location of specification document
|
||||
- Generated OBJECT IDs with descriptions
|
||||
- Naming pattern used
|
||||
- Component coverage count
|
||||
|
||||
**User options:**
|
||||
1. **Approve and proceed** - Use these OBJECT IDs for export
|
||||
2. **Modify IDs** - Adjust naming before proceeding
|
||||
3. **Review document** - See full specification first
|
||||
|
||||
Once approved, proceed to HTML generation with finalized OBJECT IDs.
|
||||
@@ -0,0 +1,922 @@
|
||||
# MCP Server Integration for Prototype-to-Figma Workflow
|
||||
|
||||
**Purpose:** Enable precise component injection from HTML prototypes into Figma using MCP server.
|
||||
|
||||
**Key Advantage:** Component-level precision - inject exactly what needs refinement, not entire pages.
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The MCP (Model Context Protocol) server integration enables WDS to communicate directly with Figma, allowing:
|
||||
|
||||
- **Selective component extraction** from HTML prototypes
|
||||
- **Direct injection** into specific Figma files/pages
|
||||
- **Object ID preservation** for traceability
|
||||
- **Automated mapping** between code and design
|
||||
- **Batch operations** for multiple components
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
### Component Flow
|
||||
|
||||
```
|
||||
HTML Prototype (with Object IDs)
|
||||
↓
|
||||
WDS Agent identifies components to extract
|
||||
↓
|
||||
MCP Server reads HTML/CSS for selected components
|
||||
↓
|
||||
Converts to Figma-compatible format
|
||||
↓
|
||||
Injects into target Figma file/page
|
||||
↓
|
||||
Designer refines in Figma
|
||||
↓
|
||||
MCP Server reads refined design
|
||||
↓
|
||||
Updates WDS Design System
|
||||
↓
|
||||
Re-render prototype with enhanced design system
|
||||
```
|
||||
|
||||
### MCP Server Role
|
||||
|
||||
**Bidirectional Bridge:**
|
||||
- **WDS → Figma:** Inject components for refinement
|
||||
- **Figma → WDS:** Read refined components back
|
||||
|
||||
**Capabilities:**
|
||||
- Read HTML/CSS structure
|
||||
- Convert to Figma nodes
|
||||
- Create frames, auto-layout, text layers
|
||||
- Apply styling (colors, spacing, typography)
|
||||
- Preserve Object IDs in layer names
|
||||
- Read Figma component definitions
|
||||
- Extract design tokens
|
||||
- Map component variants
|
||||
|
||||
---
|
||||
|
||||
## Commands
|
||||
|
||||
### Extract Component to Figma
|
||||
|
||||
**Command:**
|
||||
```bash
|
||||
wds figma inject <component-id> [options]
|
||||
```
|
||||
|
||||
**Parameters:**
|
||||
- `component-id`: Object ID of component to extract (e.g., "btn-login-submit")
|
||||
- `--file <file-id>`: Target Figma file ID
|
||||
- `--page <page-name>`: Target page within Figma file
|
||||
- `--position <x,y>`: Position to inject component (optional)
|
||||
- `--batch <file>`: Extract multiple components from list
|
||||
|
||||
**Example:**
|
||||
```bash
|
||||
# Inject single component (page name matches specification)
|
||||
wds figma inject btn-login-submit --file abc123 --page "01-Customer-Onboarding / 1.2-Sign-In"
|
||||
|
||||
# Inject multiple components to same scenario/page
|
||||
wds figma inject --batch components-to-refine.txt --file abc123 --page "01-Customer-Onboarding / 1.2-Sign-In"
|
||||
```
|
||||
|
||||
**Page Naming Convention:**
|
||||
- Format: `[Scenario-Number]-[Scenario-Name] / [Page-Number]-[Page-Name]`
|
||||
- Example: `01-Customer-Onboarding / 1.2-Sign-In`
|
||||
- Matches WDS specification structure in `docs/C-UX-Scenarios/`
|
||||
- Maintains traceability from spec → prototype → Figma
|
||||
|
||||
**Output:**
|
||||
```
|
||||
✓ Component btn-login-submit extracted from prototype
|
||||
✓ Converted to Figma format
|
||||
✓ Injected into Figma file abc123, page "Login Components"
|
||||
✓ Object ID preserved in layer name
|
||||
✓ Position: (100, 200)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Extract Section to Figma
|
||||
|
||||
**Command:**
|
||||
```bash
|
||||
wds figma inject-section <section-name> [options]
|
||||
```
|
||||
|
||||
**Parameters:**
|
||||
- `section-name`: Section identifier from specification
|
||||
- `--file <file-id>`: Target Figma file ID
|
||||
- `--page <page-name>`: Target page within Figma file
|
||||
- `--include-children`: Include all child components
|
||||
|
||||
**Example:**
|
||||
```bash
|
||||
# Inject entire login form section
|
||||
wds figma inject-section login-form --file abc123 --include-children
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Read Refined Component from Figma
|
||||
|
||||
**Command:**
|
||||
```bash
|
||||
wds figma read <component-id> [options]
|
||||
```
|
||||
|
||||
**Parameters:**
|
||||
- `component-id`: Object ID of component in Figma
|
||||
- `--file <file-id>`: Source Figma file ID
|
||||
- `--extract-tokens`: Extract design tokens
|
||||
- `--update-design-system`: Automatically update design system
|
||||
|
||||
**Example:**
|
||||
```bash
|
||||
# Read refined component and update design system
|
||||
wds figma read btn-login-submit --file abc123 --extract-tokens --update-design-system
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```
|
||||
✓ Component btn-login-submit read from Figma
|
||||
✓ Design tokens extracted:
|
||||
- Background: primary.600
|
||||
- Text: neutral.50
|
||||
- Padding: spacing.md spacing.lg
|
||||
- Border-radius: radius.md
|
||||
✓ Design system updated: D-Design-System/components/button.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Batch Operations
|
||||
|
||||
**Command:**
|
||||
```bash
|
||||
wds figma batch <operation> --list <file>
|
||||
```
|
||||
|
||||
**Operations:**
|
||||
- `inject`: Inject multiple components
|
||||
- `read`: Read multiple refined components
|
||||
- `sync`: Bidirectional sync
|
||||
|
||||
**Example batch file (components-to-refine.txt):**
|
||||
```
|
||||
btn-login-submit
|
||||
btn-signup-cta
|
||||
input-email
|
||||
input-password
|
||||
link-forgot-password
|
||||
```
|
||||
|
||||
**Command:**
|
||||
```bash
|
||||
wds figma batch inject --list components-to-refine.txt --file abc123
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Workflow Integration
|
||||
|
||||
### Phase 4D: After Prototype Creation
|
||||
|
||||
**Agent workflow:**
|
||||
|
||||
```markdown
|
||||
1. Prototype created and tested
|
||||
2. Visual quality assessment
|
||||
3. If needs refinement:
|
||||
a. Identify components that need polish
|
||||
b. Generate component list
|
||||
c. Offer to inject to Figma
|
||||
d. Execute MCP injection
|
||||
e. Provide Figma link to designer
|
||||
```
|
||||
|
||||
**Agent dialogue:**
|
||||
|
||||
```
|
||||
I've identified 5 components that could benefit from visual refinement:
|
||||
- Login button (btn-login-submit)
|
||||
- Email input (input-email)
|
||||
- Password input (input-password)
|
||||
- Forgot password link (link-forgot-password)
|
||||
- Sign up CTA (btn-signup-cta)
|
||||
|
||||
Would you like me to inject these into Figma for refinement?
|
||||
|
||||
[Y] Yes, inject all
|
||||
[S] Select specific components
|
||||
[N] No, continue as-is
|
||||
|
||||
Choice:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Phase 5: Reading Refined Components
|
||||
|
||||
**Agent workflow:**
|
||||
|
||||
```markdown
|
||||
1. Designer completes refinement in Figma
|
||||
2. Designer notifies agent
|
||||
3. Agent reads refined components via MCP
|
||||
4. Extracts design tokens
|
||||
5. Updates design system
|
||||
6. Offers to re-render prototype
|
||||
```
|
||||
|
||||
**Agent dialogue:**
|
||||
|
||||
```
|
||||
I see you've refined the components in Figma. Let me read them back:
|
||||
|
||||
Reading btn-login-submit... ✓
|
||||
Reading input-email... ✓
|
||||
Reading input-password... ✓
|
||||
Reading link-forgot-password... ✓
|
||||
Reading btn-signup-cta... ✓
|
||||
|
||||
Design tokens extracted:
|
||||
- 3 new colors added to palette
|
||||
- 2 new spacing values defined
|
||||
- 1 new typography style created
|
||||
|
||||
Design system updated:
|
||||
- Button component enhanced
|
||||
- Input component refined
|
||||
- Link component created
|
||||
|
||||
Would you like me to re-render the prototype with these improvements?
|
||||
|
||||
[Y] Yes, re-render now
|
||||
[R] Review changes first
|
||||
[L] Re-render later
|
||||
|
||||
Choice:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## MCP Server Configuration
|
||||
|
||||
### Setup
|
||||
|
||||
**1. Install MCP Server**
|
||||
```bash
|
||||
npm install -g @wds/figma-mcp-server
|
||||
```
|
||||
|
||||
**2. Configure Figma API Access**
|
||||
```bash
|
||||
# Set Figma personal access token
|
||||
export FIGMA_ACCESS_TOKEN="your-token-here"
|
||||
|
||||
# Or in .env file
|
||||
FIGMA_ACCESS_TOKEN=your-token-here
|
||||
```
|
||||
|
||||
**3. Initialize MCP Server**
|
||||
```bash
|
||||
wds figma init
|
||||
```
|
||||
|
||||
**4. Test Connection**
|
||||
```bash
|
||||
wds figma test-connection
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Configuration File
|
||||
|
||||
**Location:** `.wds/figma-mcp-config.yaml`
|
||||
|
||||
```yaml
|
||||
figma:
|
||||
access_token: ${FIGMA_ACCESS_TOKEN}
|
||||
default_file_id: "abc123def456"
|
||||
default_page: "WDS Components"
|
||||
|
||||
extraction:
|
||||
preserve_object_ids: true
|
||||
extract_design_tokens: true
|
||||
convert_to_components: true
|
||||
maintain_hierarchy: true
|
||||
|
||||
injection:
|
||||
auto_layout: true
|
||||
responsive_constraints: true
|
||||
component_naming: "object-id"
|
||||
page_naming: "scenario-page" # Matches WDS spec structure
|
||||
|
||||
sync:
|
||||
bidirectional: true
|
||||
auto_update_design_system: false
|
||||
conflict_resolution: "manual"
|
||||
|
||||
naming_conventions:
|
||||
page_format: "{scenario-number}-{scenario-name} / {page-number}-{page-name}"
|
||||
example: "01-Customer-Onboarding / 1.2-Sign-In"
|
||||
source: "docs/C-UX-Scenarios/"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Figma File Organization
|
||||
|
||||
### Recommended Structure
|
||||
|
||||
**Figma file should mirror WDS specification structure:**
|
||||
|
||||
```
|
||||
[Project Name] Design Refinement
|
||||
├── 01-Customer-Onboarding/
|
||||
│ ├── 1.1-Start-Page
|
||||
│ ├── 1.2-Sign-In
|
||||
│ ├── 1.3-Sign-Up
|
||||
│ └── ...
|
||||
├── 02-Family-Management/
|
||||
│ ├── 2.1-Family-Dashboard
|
||||
│ ├── 2.2-Add-Member
|
||||
│ └── ...
|
||||
└── Components/
|
||||
├── Buttons
|
||||
├── Inputs
|
||||
└── Cards
|
||||
```
|
||||
|
||||
**Benefits:**
|
||||
- Direct mapping to WDS specifications
|
||||
- Easy to locate components by scenario/page
|
||||
- Maintains project structure consistency
|
||||
- Clear handoff to developers
|
||||
|
||||
**Page Naming:**
|
||||
- Use exact scenario and page numbers from specs
|
||||
- Format: `[Number]-[Name]` (e.g., `1.2-Sign-In`)
|
||||
- Matches folder structure in `docs/C-UX-Scenarios/`
|
||||
|
||||
---
|
||||
|
||||
## Component Selection Strategies
|
||||
|
||||
### Strategy 1: Individual Components
|
||||
|
||||
**When to use:** Specific components need refinement
|
||||
|
||||
**Process:**
|
||||
```bash
|
||||
# Inject one component at a time
|
||||
wds figma inject btn-login-submit --file abc123
|
||||
wds figma inject input-email --file abc123
|
||||
```
|
||||
|
||||
**Advantages:**
|
||||
- Precise control
|
||||
- Focused refinement
|
||||
- Easy to track changes
|
||||
|
||||
---
|
||||
|
||||
### Strategy 2: Component Groups
|
||||
|
||||
**When to use:** Related components need consistent refinement
|
||||
|
||||
**Process:**
|
||||
```bash
|
||||
# Create component group file
|
||||
echo "btn-login-submit
|
||||
btn-signup-cta
|
||||
btn-cancel" > login-buttons.txt
|
||||
|
||||
# Inject group
|
||||
wds figma batch inject --list login-buttons.txt --file abc123
|
||||
```
|
||||
|
||||
**Advantages:**
|
||||
- Consistent design decisions
|
||||
- Efficient batch processing
|
||||
- Related components together
|
||||
|
||||
---
|
||||
|
||||
### Strategy 3: Section-Based
|
||||
|
||||
**When to use:** Entire section needs refinement
|
||||
|
||||
**Process:**
|
||||
```bash
|
||||
# Inject entire section with all components
|
||||
wds figma inject-section login-form --file abc123 --include-children
|
||||
```
|
||||
|
||||
**Advantages:**
|
||||
- Complete context
|
||||
- Layout refinement
|
||||
- Holistic design decisions
|
||||
|
||||
---
|
||||
|
||||
### Strategy 4: Iterative Refinement
|
||||
|
||||
**When to use:** Multiple refinement cycles needed
|
||||
|
||||
**Process:**
|
||||
```bash
|
||||
# Iteration 1: Inject basic components
|
||||
wds figma inject btn-login-submit --file abc123
|
||||
|
||||
# Designer refines in Figma
|
||||
|
||||
# Read back refined version
|
||||
wds figma read btn-login-submit --file abc123 --update-design-system
|
||||
|
||||
# Iteration 2: Re-inject with design system updates
|
||||
wds figma inject btn-login-submit --file abc123 --version 2
|
||||
|
||||
# Continue until satisfied
|
||||
```
|
||||
|
||||
**Advantages:**
|
||||
- Incremental improvement
|
||||
- Design system grows with each iteration
|
||||
- Reduced rework
|
||||
|
||||
---
|
||||
|
||||
## Object ID Mapping
|
||||
|
||||
### Preservation Strategy
|
||||
|
||||
**In HTML Prototype:**
|
||||
```html
|
||||
<button data-object-id="btn-login-submit" class="btn-primary">
|
||||
Log In
|
||||
</button>
|
||||
```
|
||||
|
||||
**In Figma (after injection):**
|
||||
```
|
||||
Layer name: "btn-login-submit"
|
||||
Description: "Object ID: btn-login-submit"
|
||||
```
|
||||
|
||||
**In Design System:**
|
||||
```yaml
|
||||
# D-Design-System/components/button.md
|
||||
Button Component [btn-001]
|
||||
|
||||
Object ID Mapping:
|
||||
- btn-login-submit → Login page submit button
|
||||
- btn-signup-cta → Signup page CTA button
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Traceability
|
||||
|
||||
**Benefits:**
|
||||
- Track component from spec → prototype → Figma → design system
|
||||
- Identify which Figma components map to which code elements
|
||||
- Update specific components without affecting others
|
||||
- Maintain consistency across iterations
|
||||
|
||||
**Workflow:**
|
||||
```
|
||||
Specification: "Login button" (conceptual)
|
||||
↓
|
||||
Prototype: data-object-id="btn-login-submit" (code)
|
||||
↓
|
||||
Figma: Layer "btn-login-submit" (design)
|
||||
↓
|
||||
Design System: Button.primary [btn-001] (documentation)
|
||||
↓
|
||||
Re-rendered Prototype: class="btn-primary" (enhanced code)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Design Token Extraction
|
||||
|
||||
### Automatic Token Detection
|
||||
|
||||
**MCP Server analyzes:**
|
||||
- Colors used in component
|
||||
- Spacing/padding values
|
||||
- Typography styles
|
||||
- Border radius
|
||||
- Shadows/effects
|
||||
|
||||
**Example extraction:**
|
||||
|
||||
**From Figma component:**
|
||||
```
|
||||
Background: #2563eb
|
||||
Text: #ffffff
|
||||
Padding: 12px 16px
|
||||
Border-radius: 8px
|
||||
Font: Inter, 16px, 600
|
||||
```
|
||||
|
||||
**To Design Tokens:**
|
||||
```yaml
|
||||
colors:
|
||||
primary:
|
||||
600: "#2563eb"
|
||||
neutral:
|
||||
50: "#ffffff"
|
||||
|
||||
spacing:
|
||||
md: 12px
|
||||
lg: 16px
|
||||
|
||||
radius:
|
||||
md: 8px
|
||||
|
||||
typography:
|
||||
button:
|
||||
font-family: "Inter"
|
||||
font-size: 16px
|
||||
font-weight: 600
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Token Mapping
|
||||
|
||||
**MCP Server can:**
|
||||
- Detect similar colors and suggest token names
|
||||
- Identify spacing patterns
|
||||
- Recognize typography scales
|
||||
- Propose token structure
|
||||
|
||||
**Agent dialogue:**
|
||||
|
||||
```
|
||||
I've analyzed the refined button component and detected these values:
|
||||
|
||||
Colors:
|
||||
- Background: #2563eb → Suggest: primary.600
|
||||
- Text: #ffffff → Suggest: neutral.50
|
||||
|
||||
Spacing:
|
||||
- Padding horizontal: 16px → Suggest: spacing.lg
|
||||
- Padding vertical: 12px → Suggest: spacing.md
|
||||
|
||||
Would you like to:
|
||||
[A] Accept all suggestions
|
||||
[C] Customize token names
|
||||
[R] Review each token
|
||||
|
||||
Choice:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Issue: Component not found in prototype**
|
||||
```
|
||||
Error: Component with Object ID "btn-login-submit" not found in prototype
|
||||
|
||||
Solution:
|
||||
- Verify Object ID exists in HTML
|
||||
- Check data-object-id attribute
|
||||
- Ensure prototype file is current
|
||||
```
|
||||
|
||||
**Issue: Figma file access denied**
|
||||
```
|
||||
Error: Cannot access Figma file abc123
|
||||
|
||||
Solution:
|
||||
- Verify Figma access token
|
||||
- Check file permissions
|
||||
- Ensure file ID is correct
|
||||
```
|
||||
|
||||
**Issue: Component structure too complex**
|
||||
```
|
||||
Warning: Component has deeply nested structure (8 levels)
|
||||
This may not convert cleanly to Figma
|
||||
|
||||
Suggestion:
|
||||
- Simplify HTML structure
|
||||
- Extract sub-components separately
|
||||
- Use flatter hierarchy
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Conflict Resolution
|
||||
|
||||
**Scenario: Component exists in both prototype and Figma**
|
||||
|
||||
**Options:**
|
||||
```
|
||||
Component btn-login-submit already exists in Figma.
|
||||
|
||||
[O] Overwrite with new version
|
||||
[M] Merge changes
|
||||
[V] Create new version
|
||||
[S] Skip this component
|
||||
|
||||
Choice:
|
||||
```
|
||||
|
||||
**Merge strategy:**
|
||||
- Preserve Figma refinements
|
||||
- Apply new structural changes
|
||||
- Prompt for conflicts
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO ✅
|
||||
|
||||
**1. Use Object IDs consistently**
|
||||
```html
|
||||
<!-- Good: Clear, consistent Object IDs -->
|
||||
<button data-object-id="btn-login-submit">
|
||||
<input data-object-id="input-email">
|
||||
<a data-object-id="link-forgot-password">
|
||||
```
|
||||
|
||||
**2. Extract components incrementally**
|
||||
```bash
|
||||
# Start with critical components
|
||||
wds figma inject btn-login-submit --file abc123
|
||||
|
||||
# Then expand to related components
|
||||
wds figma inject input-email --file abc123
|
||||
```
|
||||
|
||||
**3. Document extraction decisions**
|
||||
```markdown
|
||||
# extraction-log.md
|
||||
|
||||
## 2026-01-08: Login Page Components
|
||||
|
||||
Extracted to Figma:
|
||||
- btn-login-submit: Needs brand color refinement
|
||||
- input-email: Needs focus state design
|
||||
- input-password: Needs show/hide icon
|
||||
|
||||
Skipped:
|
||||
- link-terms: Standard link, no refinement needed
|
||||
```
|
||||
|
||||
**4. Sync regularly**
|
||||
```bash
|
||||
# After designer completes refinement
|
||||
wds figma read btn-login-submit --file abc123 --update-design-system
|
||||
|
||||
# Re-render to verify
|
||||
wds prototype render login-page --with-design-system
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### DON'T ❌
|
||||
|
||||
**1. Don't inject entire pages**
|
||||
```bash
|
||||
# Avoid: Too broad, loses precision
|
||||
wds figma inject-page login --file abc123
|
||||
|
||||
# Better: Specific components
|
||||
wds figma inject btn-login-submit --file abc123
|
||||
```
|
||||
|
||||
**2. Don't skip Object ID mapping**
|
||||
```html
|
||||
<!-- Avoid: No traceability -->
|
||||
<button class="btn-primary">
|
||||
|
||||
<!-- Better: Clear Object ID -->
|
||||
<button data-object-id="btn-login-submit" class="btn-primary">
|
||||
```
|
||||
|
||||
**3. Don't forget to read back**
|
||||
```bash
|
||||
# Incomplete workflow
|
||||
wds figma inject btn-login-submit --file abc123
|
||||
# Designer refines...
|
||||
# ❌ Never read back refined version
|
||||
|
||||
# Complete workflow
|
||||
wds figma inject btn-login-submit --file abc123
|
||||
# Designer refines...
|
||||
wds figma read btn-login-submit --file abc123 ✅
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Advanced Features
|
||||
|
||||
### Variant Detection
|
||||
|
||||
**MCP Server can detect component variants:**
|
||||
|
||||
```
|
||||
Analyzing button components in Figma...
|
||||
|
||||
Found 3 button variants:
|
||||
- btn-login-submit (primary variant)
|
||||
- btn-cancel (secondary variant)
|
||||
- btn-delete (danger variant)
|
||||
|
||||
Suggest creating Button component with variants?
|
||||
[Y/N]:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### State Extraction
|
||||
|
||||
**MCP Server extracts component states:**
|
||||
|
||||
```
|
||||
Reading btn-login-submit from Figma...
|
||||
|
||||
States detected:
|
||||
- Default: #2563eb background
|
||||
- Hover: #1d4ed8 background (darker)
|
||||
- Active: #1e40af background (darkest)
|
||||
- Disabled: #9ca3af background (gray)
|
||||
|
||||
Add all states to design system?
|
||||
[Y/N]:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Responsive Constraints
|
||||
|
||||
**MCP Server preserves responsive behavior:**
|
||||
|
||||
```
|
||||
Component has responsive constraints:
|
||||
- Width: Fill container
|
||||
- Height: Hug contents
|
||||
- Min width: 120px
|
||||
- Max width: 400px
|
||||
|
||||
Apply constraints in re-rendered prototype?
|
||||
[Y/N]:
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integration with Existing Figma Workflow
|
||||
|
||||
### Compatibility
|
||||
|
||||
**Works with existing Figma → WDS workflow:**
|
||||
|
||||
**Workflow A (Existing):** Designer creates in Figma → MCP reads → WDS spec
|
||||
**Workflow B (New):** Prototype → MCP injects → Figma → MCP reads → WDS spec
|
||||
|
||||
**Both workflows use same MCP server, same token extraction, same design system updates.**
|
||||
|
||||
---
|
||||
|
||||
### Unified Design System
|
||||
|
||||
**All paths lead to design system:**
|
||||
|
||||
```
|
||||
Path 1: Manual Figma design → MCP → Design System
|
||||
Path 2: Prototype → MCP → Figma → MCP → Design System
|
||||
Path 3: Specification → Prototype → Design System (no Figma)
|
||||
|
||||
Result: Single source of truth in Design System
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
### Batch Processing
|
||||
|
||||
**Efficient for multiple components:**
|
||||
|
||||
```bash
|
||||
# Sequential (slower)
|
||||
wds figma inject btn-1 --file abc123
|
||||
wds figma inject btn-2 --file abc123
|
||||
wds figma inject btn-3 --file abc123
|
||||
|
||||
# Batch (faster)
|
||||
wds figma batch inject --list buttons.txt --file abc123
|
||||
```
|
||||
|
||||
**Performance:**
|
||||
- Sequential: ~5 seconds per component
|
||||
- Batch: ~2 seconds per component (parallel processing)
|
||||
|
||||
---
|
||||
|
||||
### Caching
|
||||
|
||||
**MCP Server caches:**
|
||||
- Figma file structure
|
||||
- Component definitions
|
||||
- Design tokens
|
||||
- Object ID mappings
|
||||
|
||||
**Benefits:**
|
||||
- Faster subsequent operations
|
||||
- Reduced API calls
|
||||
- Offline capability (limited)
|
||||
|
||||
---
|
||||
|
||||
## Security
|
||||
|
||||
### API Token Management
|
||||
|
||||
**Best practices:**
|
||||
```bash
|
||||
# Never commit tokens to git
|
||||
echo "FIGMA_ACCESS_TOKEN=*" >> .gitignore
|
||||
|
||||
# Use environment variables
|
||||
export FIGMA_ACCESS_TOKEN="token"
|
||||
|
||||
# Or use secure credential storage
|
||||
wds figma set-token --secure
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Access Control
|
||||
|
||||
**Figma file permissions:**
|
||||
- MCP server requires edit access to inject components
|
||||
- Read-only access sufficient for reading refined components
|
||||
- Consider separate files for WDS injection vs production design
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Debug Mode
|
||||
|
||||
```bash
|
||||
# Enable verbose logging
|
||||
wds figma inject btn-login-submit --file abc123 --debug
|
||||
|
||||
# Output shows:
|
||||
# - HTML parsing steps
|
||||
# - Figma API calls
|
||||
# - Conversion process
|
||||
# - Injection details
|
||||
# - Error stack traces
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Validation
|
||||
|
||||
```bash
|
||||
# Validate before injection
|
||||
wds figma validate btn-login-submit
|
||||
|
||||
# Checks:
|
||||
# - Object ID exists
|
||||
# - HTML structure valid
|
||||
# - CSS parseable
|
||||
# - Figma file accessible
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
**MCP Server integration enables:**
|
||||
|
||||
✅ **Precision:** Inject specific components, not entire pages
|
||||
✅ **Automation:** Automated Object ID mapping and token extraction
|
||||
✅ **Bidirectional:** Prototype → Figma → Design System → Prototype
|
||||
✅ **Traceability:** Maintain Object ID connections throughout
|
||||
✅ **Efficiency:** Batch operations and caching
|
||||
✅ **Integration:** Works with existing Figma workflows
|
||||
|
||||
**Result:** Seamless, precise component refinement workflow that maintains traceability and enables iterative design improvement.
|
||||
|
||||
---
|
||||
|
||||
**This MCP server integration is the key to making the prototype-to-Figma workflow practical and efficient for production use.**
|
||||
@@ -0,0 +1,933 @@
|
||||
# Prototype to Figma Workflow
|
||||
|
||||
**Purpose:** Extract working HTML prototypes into Figma for visual design refinement when the design system is incomplete.
|
||||
|
||||
**When to Use:** When prototypes look incomplete or not visually appealing because design system components aren't fully developed yet.
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This workflow enables iterative visual refinement:
|
||||
|
||||
```
|
||||
Sketch → Spec → Prototype (basic) → Figma (refine) → Design System (extend) → Re-render → Iterate
|
||||
```
|
||||
|
||||
**Key Principle:** Code prototypes are functional but may lack visual polish. Extract to Figma for design refinement, then feed improvements back to design system.
|
||||
|
||||
---
|
||||
|
||||
## When to Extract to Figma
|
||||
|
||||
### Extract When:
|
||||
|
||||
✅ **Visual refinement needed**
|
||||
- Prototype works but looks unpolished
|
||||
- Design system lacks components for this view
|
||||
- Spacing/typography needs fine-tuning
|
||||
- Color palette needs expansion
|
||||
|
||||
✅ **Design system gaps identified**
|
||||
- Missing component variants
|
||||
- Incomplete state definitions
|
||||
- Need new design tokens
|
||||
- Pattern library needs expansion
|
||||
|
||||
✅ **Stakeholder presentation**
|
||||
- Need polished visuals for approval
|
||||
- Client review requires high-fidelity
|
||||
- Marketing materials needed
|
||||
|
||||
### Don't Extract When:
|
||||
|
||||
❌ **Prototype is sufficient**
|
||||
- Design system already covers all needs
|
||||
- Visual quality meets requirements
|
||||
- Focus is on functionality, not aesthetics
|
||||
|
||||
❌ **Early exploration**
|
||||
- Still validating concepts
|
||||
- Rapid iteration needed
|
||||
- Design decisions not finalized
|
||||
|
||||
---
|
||||
|
||||
## The Iterative Refinement Loop
|
||||
|
||||
### Iteration 1: Basic Prototype
|
||||
|
||||
**Input:** Specification from Phase 4C
|
||||
|
||||
**Phase 4D: Create Prototype**
|
||||
```
|
||||
Sketch → Spec → Generate HTML/CSS/JS
|
||||
Result: Functional but basic-looking prototype
|
||||
```
|
||||
|
||||
**Assessment:**
|
||||
- Does it work functionally? ✅
|
||||
- Does it look polished? ❌ (Design system incomplete)
|
||||
|
||||
**Decision:** Extract to Figma for visual refinement
|
||||
|
||||
---
|
||||
|
||||
### Iteration 2: Visual Refinement
|
||||
|
||||
**Step 1: Extract to Figma**
|
||||
|
||||
Use MCP server to inject components directly into Figma:
|
||||
|
||||
```bash
|
||||
# MCP server enables precise component injection
|
||||
# Select specific components to extract
|
||||
# Inject directly into Figma view
|
||||
# Maintain Object ID traceability
|
||||
```
|
||||
|
||||
**What gets extracted:**
|
||||
- Specific components (not entire page)
|
||||
- Layout structure (frames, auto-layout)
|
||||
- Text content (converted to text layers)
|
||||
- Colors (as fills)
|
||||
- Spacing (as padding/gaps)
|
||||
- Component boundaries preserved
|
||||
|
||||
**Step 2: Refine in Figma**
|
||||
|
||||
Designer works in Figma to:
|
||||
- Apply proper typography styles
|
||||
- Refine color palette
|
||||
- Adjust spacing/padding
|
||||
- Add visual polish (shadows, borders, effects)
|
||||
- Create missing component variants
|
||||
- Define proper states
|
||||
|
||||
**Step 3: Document Design Decisions**
|
||||
|
||||
Capture in Figma:
|
||||
- Design tokens (colors, spacing, typography)
|
||||
- Component specifications
|
||||
- State definitions
|
||||
- Variant rules
|
||||
|
||||
**Step 4: Extract Design System Updates**
|
||||
|
||||
From refined Figma design:
|
||||
- New design tokens → `D-Design-System/design-tokens.md`
|
||||
- New components → `D-Design-System/components/`
|
||||
- Updated variants → Existing component files
|
||||
- New states → Component state definitions
|
||||
|
||||
---
|
||||
|
||||
### Iteration 3: Re-render with Enhanced Design System
|
||||
|
||||
**Step 5: Update Design System**
|
||||
|
||||
Apply Figma refinements to design system:
|
||||
|
||||
```yaml
|
||||
# D-Design-System/design-tokens.md
|
||||
|
||||
Colors:
|
||||
primary:
|
||||
50: "#f0f9ff"
|
||||
600: "#2563eb" # From Figma refinement
|
||||
700: "#1d4ed8" # New from Figma
|
||||
|
||||
Spacing:
|
||||
xs: 4px
|
||||
sm: 8px
|
||||
md: 16px # Refined in Figma
|
||||
lg: 24px # New from Figma
|
||||
|
||||
Typography:
|
||||
heading-1:
|
||||
font: "Inter"
|
||||
size: 32px # Refined in Figma
|
||||
weight: 700
|
||||
line-height: 1.2
|
||||
```
|
||||
|
||||
**Step 6: Re-render Prototype**
|
||||
|
||||
Regenerate prototype with enhanced design system:
|
||||
|
||||
```
|
||||
Same HTML structure + Enhanced design system = Polished prototype
|
||||
```
|
||||
|
||||
**Assessment:**
|
||||
- Does it work functionally? ✅
|
||||
- Does it look polished? ✅ (Design system now complete)
|
||||
|
||||
**Decision:** Prototype complete, or iterate again if needed
|
||||
|
||||
---
|
||||
|
||||
## Detailed Workflow Steps
|
||||
|
||||
### Phase 1: Identify Need for Figma Refinement
|
||||
|
||||
**After Phase 4D prototype creation:**
|
||||
|
||||
<ask>
|
||||
**Prototype Assessment**
|
||||
|
||||
Your prototype is functional! Now let's assess visual quality:
|
||||
|
||||
1. **Looks good** - Design system covers everything needed
|
||||
2. **Needs refinement** - Missing components/polish, extract to Figma
|
||||
3. **Needs minor tweaks** - Quick CSS adjustments sufficient
|
||||
|
||||
Choice [1/2/3]:
|
||||
</ask>
|
||||
|
||||
<check if="choice == 2">
|
||||
<action>Proceed to Figma extraction workflow</action>
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
### Phase 2: Extract Prototype to Figma
|
||||
|
||||
**Agent:** Freya WDS Designer Agent (automated)
|
||||
|
||||
**Freya's Process:**
|
||||
|
||||
**1. Analyze prototype components**
|
||||
|
||||
Freya automatically:
|
||||
- Scans prototype for all components with Object IDs
|
||||
- Identifies components that need visual refinement
|
||||
- Compares against existing design system
|
||||
- Determines which components are missing or incomplete
|
||||
|
||||
**2. Present extraction options**
|
||||
|
||||
<ask>
|
||||
I've analyzed the prototype and identified components that could benefit from visual refinement:
|
||||
|
||||
**Missing from design system:**
|
||||
- Login button (btn-login-submit)
|
||||
- Email input (input-email)
|
||||
- Password input (input-password)
|
||||
|
||||
**Incomplete in design system:**
|
||||
- Forgot password link (link-forgot-password) - needs hover state
|
||||
|
||||
Would you like me to inject these into Figma for refinement?
|
||||
|
||||
[A] All components (4 total)
|
||||
[S] Select specific components
|
||||
[N] No, continue as-is
|
||||
|
||||
Choice:
|
||||
</ask>
|
||||
|
||||
**3. Inject via MCP server (automated)**
|
||||
|
||||
Freya automatically:
|
||||
- Determines target Figma file from project config
|
||||
- Creates/navigates to page matching scenario/page structure
|
||||
- Page naming: `[Scenario-Number]-[Scenario-Name] / [Page-Number]-[Page-Name]`
|
||||
- Example: `01-Customer-Onboarding / 1.2-Sign-In`
|
||||
- Injects selected components via MCP server
|
||||
- Preserves Object IDs in layer names
|
||||
- Maintains component boundaries
|
||||
|
||||
<output>
|
||||
✓ Injecting components to Figma...
|
||||
✓ Target: [Project] Design Refinement / 01-Customer-Onboarding / 1.2-Sign-In
|
||||
✓ btn-login-submit → Injected at (100, 200)
|
||||
✓ input-email → Injected at (100, 300)
|
||||
|
||||
All components injected successfully!
|
||||
|
||||
Figma link: <https://figma.com/file/abc123?node-id=...>
|
||||
|
||||
You can now refine these components in Figma. Let me know when you're ready to read them back.
|
||||
</output>
|
||||
|
||||
**4. Wait for designer refinement**
|
||||
|
||||
Freya pauses workflow and waits for user to:
|
||||
- Open Figma
|
||||
- Refine visual design
|
||||
- Apply design tokens
|
||||
- Create component variants
|
||||
- Define states
|
||||
- Notify when complete
|
||||
|
||||
**Output:**
|
||||
- Specific components injected into Figma
|
||||
- Layers named with Object IDs
|
||||
- Page structure matches specification
|
||||
- Figma link provided to designer
|
||||
- Freya ready to read refined components back
|
||||
|
||||
**Advantages:**
|
||||
- ✅ Fully automated by Freya
|
||||
- ✅ Component-level precision
|
||||
- ✅ Automatic Object ID mapping
|
||||
- ✅ Page structure matches specs
|
||||
- ✅ No manual commands needed
|
||||
- ✅ Seamless workflow integration
|
||||
|
||||
---
|
||||
|
||||
### Phase 3: Refine Design in Figma
|
||||
|
||||
**Designer tasks:**
|
||||
|
||||
**1. Apply Design Tokens**
|
||||
|
||||
Convert extracted values to proper tokens:
|
||||
|
||||
```
|
||||
Before (extracted):
|
||||
- Fill: #2563eb (hardcoded)
|
||||
|
||||
After (refined):
|
||||
- Fill: {primary.600} (design token)
|
||||
```
|
||||
|
||||
**2. Create/Update Components**
|
||||
|
||||
Identify reusable patterns:
|
||||
|
||||
```
|
||||
Extracted button → Create Figma component
|
||||
- Name: Button/Primary [btn-001]
|
||||
- Add variants: primary, secondary, ghost
|
||||
- Add states: default, hover, active, disabled
|
||||
- Document in description
|
||||
```
|
||||
|
||||
**3. Refine Visual Design**
|
||||
|
||||
Polish the design:
|
||||
- Typography hierarchy
|
||||
- Spacing consistency
|
||||
- Color harmony
|
||||
- Visual effects (shadows, borders)
|
||||
- Responsive behavior
|
||||
|
||||
**4. Document Decisions**
|
||||
|
||||
In Figma file, create documentation frame:
|
||||
|
||||
```
|
||||
Design Decisions:
|
||||
├── Color Palette (with token names)
|
||||
├── Typography Scale (with token names)
|
||||
├── Spacing System (with token names)
|
||||
├── Component Specifications
|
||||
└── State Definitions
|
||||
```
|
||||
|
||||
**Important:** If you discover better design solutions during refinement:
|
||||
- ✅ Explore new ideas and improvements
|
||||
- ✅ Document design decisions in Figma
|
||||
- ✅ **Update specifications to match new design**
|
||||
- ✅ Notify Freya of specification changes needed
|
||||
- ❌ Don't let Figma and specs diverge
|
||||
|
||||
**Workflow for design changes:**
|
||||
1. Refine design in Figma (explore improvements)
|
||||
2. Document what changed and why
|
||||
3. Update specification to reflect new design
|
||||
4. Freya reads refined design from Figma
|
||||
5. Design system updated
|
||||
6. Re-render prototype matches updated spec
|
||||
|
||||
---
|
||||
|
||||
### Phase 4: Extract Design System Updates
|
||||
|
||||
**Agent:** Freya WDS Designer Agent (automated)
|
||||
|
||||
**Freya's Process:**
|
||||
|
||||
**1. User notifies completion**
|
||||
|
||||
<ask>
|
||||
Have you finished refining the components in Figma?
|
||||
|
||||
[Y] Yes, read them back
|
||||
[N] Not yet, still working
|
||||
|
||||
Choice:
|
||||
</ask>
|
||||
|
||||
**2. Read refined components (automated)**
|
||||
|
||||
Freya automatically:
|
||||
- Connects to Figma via MCP server
|
||||
- Reads all injected components from target page
|
||||
- Extracts design tokens (colors, spacing, typography)
|
||||
- Identifies component variants and states
|
||||
- Analyzes design decisions
|
||||
|
||||
<output>
|
||||
✓ Reading refined components from Figma...
|
||||
✓ btn-login-submit → Read successfully
|
||||
✓ input-email → Read successfully
|
||||
✓ input-password → Read successfully
|
||||
✓ link-forgot-password → Read successfully
|
||||
|
||||
Analyzing design refinements...
|
||||
</output>
|
||||
|
||||
**3. Extract and present design tokens**
|
||||
|
||||
<output>
|
||||
**Design tokens extracted:**
|
||||
|
||||
Colors:
|
||||
- primary.600: #2563eb (new)
|
||||
- primary.700: #1d4ed8 (new)
|
||||
- neutral.50: #ffffff
|
||||
|
||||
Spacing:
|
||||
- spacing.md: 12px (refined from 16px)
|
||||
- spacing.lg: 16px (new)
|
||||
|
||||
Typography:
|
||||
- button.font-size: 16px (new)
|
||||
- button.font-weight: 600 (new)
|
||||
|
||||
**Component updates:**
|
||||
- Button component: Added primary variant, hover/active states
|
||||
- Input component: Added focus state, error state
|
||||
- Link component: Created new component with hover state
|
||||
</output>
|
||||
|
||||
<ask>
|
||||
Did you make any design changes that differ from the original specification?
|
||||
|
||||
[Y] Yes, I improved the design
|
||||
[N] No, stayed true to spec
|
||||
|
||||
Choice:
|
||||
</ask>
|
||||
|
||||
<check if="yes">
|
||||
<ask>Please describe what changed in the design and why:
|
||||
|
||||
(This helps me update the specification to match your refined design)
|
||||
</ask>
|
||||
|
||||
<output>Thank you! I'll note these changes for the specification update.
|
||||
|
||||
**Specification updates needed:**
|
||||
- {list design changes that differ from original spec}
|
||||
|
||||
After updating the design system, we should update the specification to reflect these improvements.</output>
|
||||
</check>
|
||||
|
||||
<ask>
|
||||
Would you like me to update the design system with these changes?
|
||||
|
||||
[Y] Yes, update design system
|
||||
[R] Review changes first
|
||||
[C] Customize before updating
|
||||
|
||||
Choice:
|
||||
</ask>
|
||||
|
||||
**4. Update design system (automated)**
|
||||
|
||||
Freya automatically updates `D-Design-System/design-tokens.md`:
|
||||
|
||||
```markdown
|
||||
## Colors (Updated from Figma)
|
||||
|
||||
### Primary
|
||||
- primary.50: #f0f9ff
|
||||
- primary.600: #2563eb (refined)
|
||||
- primary.700: #1d4ed8 (new)
|
||||
|
||||
### Spacing (Updated from Figma)
|
||||
- xs: 4px
|
||||
- sm: 8px
|
||||
- md: 16px (refined from 12px)
|
||||
- lg: 24px (new)
|
||||
```
|
||||
|
||||
**2. Component Specifications**
|
||||
|
||||
Create/update component files:
|
||||
|
||||
```markdown
|
||||
# D-Design-System/components/button.md
|
||||
|
||||
Button Component [btn-001]
|
||||
|
||||
**Figma Reference:** [Link to Figma component]
|
||||
|
||||
## Variants (From Figma refinement)
|
||||
- primary (updated styling)
|
||||
- secondary (new variant)
|
||||
- ghost (new variant)
|
||||
|
||||
## States (From Figma refinement)
|
||||
- default
|
||||
- hover (updated animation)
|
||||
- active (new state)
|
||||
- disabled (updated opacity)
|
||||
|
||||
## Styling (From Figma)
|
||||
- Background: {primary.600}
|
||||
- Text: {neutral.50}
|
||||
- Padding: {spacing.md} {spacing.lg}
|
||||
- Border-radius: {radius.md}
|
||||
```
|
||||
|
||||
**3. Update Figma Mappings**
|
||||
|
||||
```yaml
|
||||
# D-Design-System/figma-mappings.md
|
||||
|
||||
Button [btn-001] → figma://file/abc123/node/456:789
|
||||
Input [inp-001] → figma://file/abc123/node/456:790
|
||||
Card [crd-001] → figma://file/abc123/node/456:791
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Phase 5: Re-render Prototype with Enhanced Design System
|
||||
|
||||
**Back to Phase 4D:**
|
||||
|
||||
**1. Update prototype templates**
|
||||
|
||||
Apply new design tokens:
|
||||
|
||||
```html
|
||||
<!-- Before -->
|
||||
<button style="background: #2563eb; padding: 12px 16px;">
|
||||
|
||||
<!-- After (with design system) -->
|
||||
<button class="btn-primary">
|
||||
<!-- Styled via design system tokens -->
|
||||
</button>
|
||||
```
|
||||
|
||||
**2. Regenerate or update prototype**
|
||||
|
||||
<ask>
|
||||
**Re-render approach:**
|
||||
|
||||
1. **Regenerate** - Create fresh prototype with new design system
|
||||
2. **Update** - Apply design system to existing prototype
|
||||
3. **Hybrid** - Update critical sections, regenerate others
|
||||
|
||||
Choice [1/2/3]:
|
||||
</ask>
|
||||
|
||||
**3. Test updated prototype**
|
||||
|
||||
Verify:
|
||||
- Visual quality improved ✅
|
||||
- Functionality preserved ✅
|
||||
- Design system applied correctly ✅
|
||||
- All Object IDs maintained ✅
|
||||
|
||||
---
|
||||
|
||||
### Phase 6: Iterate or Complete
|
||||
|
||||
**Assessment:**
|
||||
|
||||
<ask>
|
||||
**Prototype quality check:**
|
||||
|
||||
1. **Complete** - Looks polished, ready for development
|
||||
2. **Iterate** - Needs another refinement cycle
|
||||
3. **Minor tweaks** - Small adjustments needed
|
||||
|
||||
Choice [1/2/3]:
|
||||
</ask>
|
||||
|
||||
<check if="choice == 2">
|
||||
<action>Return to Phase 2 (Extract to Figma again)</action>
|
||||
<output>Starting iteration 2 with enhanced design system as baseline</output>
|
||||
</check>
|
||||
|
||||
<check if="choice == 1">
|
||||
<output>✅ Prototype complete and polished!</output>
|
||||
<action>Mark prototype as final</action>
|
||||
<action>Update scenario tracking</action>
|
||||
</check>
|
||||
|
||||
---
|
||||
|
||||
## Tools Integration
|
||||
|
||||
### html.to.design
|
||||
|
||||
**Purpose:** Convert HTML prototypes to Figma
|
||||
|
||||
**Features:**
|
||||
- Preserves layout structure
|
||||
- Converts CSS to Figma styles
|
||||
- Maintains element hierarchy
|
||||
- Extracts design tokens
|
||||
- Creates Figma components
|
||||
|
||||
**Usage:**
|
||||
```
|
||||
1. Upload HTML file
|
||||
2. Configure conversion options
|
||||
3. Download Figma file
|
||||
4. Import to Figma workspace
|
||||
```
|
||||
|
||||
**Best Practices:**
|
||||
- Clean HTML structure before extraction
|
||||
- Use semantic HTML elements
|
||||
- Include Object IDs in data attributes
|
||||
- Document area tags for image sections
|
||||
### NanoBanana (Optional)
|
||||
|
||||
**Purpose:** Agent-driven asset creation and design inspiration tool
|
||||
|
||||
**Website:** <https://nanobanana.com>
|
||||
|
||||
**Use Case in WDS:** Create visual assets, design inspiration, and possibly export design elements
|
||||
|
||||
**Description:** Think of it as "agent-driven Photoshop" - an AI-powered tool for creating visual design assets and exploring design possibilities.
|
||||
|
||||
### Features
|
||||
|
||||
**Asset Creation:**
|
||||
- Visual design generation
|
||||
- Design inspiration and variations
|
||||
- Asset creation (images, graphics, icons)
|
||||
- Design exploration
|
||||
- Possibly code export for certain elements
|
||||
|
||||
### Integration with WDS
|
||||
|
||||
**Workflow:**
|
||||
```
|
||||
Design Concept
|
||||
→ NanoBanana (create assets/inspiration)
|
||||
→ Visual Assets
|
||||
→ Use in Figma or Prototypes
|
||||
→ Refine and integrate
|
||||
```
|
||||
|
||||
**When to use:**
|
||||
- Need visual design inspiration
|
||||
- Creating custom graphics/assets
|
||||
- Exploring design variations
|
||||
- Generating design ideas
|
||||
- Creating placeholder assets
|
||||
|
||||
**When to Skip:**
|
||||
- Have existing design assets
|
||||
- Working with established brand guidelines
|
||||
- Simple text/layout-only designs
|
||||
- Using stock assets
|
||||
|
||||
### Best Practices
|
||||
|
||||
**DO ✅**
|
||||
- Use for design exploration and inspiration
|
||||
- Generate multiple variations
|
||||
- Refine AI-generated assets in Figma
|
||||
- Use as creative starting point
|
||||
- Export and integrate into design system
|
||||
|
||||
**DON'T ❌**
|
||||
- Use as replacement for design thinking
|
||||
- Skip refinement of generated assets
|
||||
- Ignore brand guidelines
|
||||
- Use without customization
|
||||
- Rely solely on AI-generated designs
|
||||
### Design System Updates
|
||||
|
||||
```
|
||||
D-Design-System/
|
||||
design-tokens.md ← Updated from Figma
|
||||
components/
|
||||
button.md ← Updated from Figma
|
||||
input.md ← New from Figma
|
||||
figma-mappings.md ← Figma node references
|
||||
refinement-history.md ← Track iterations
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Decision Framework
|
||||
|
||||
### When to Extract to Figma?
|
||||
|
||||
**Extract if ANY of these are true:**
|
||||
|
||||
1. **Visual Quality Gap**
|
||||
- Prototype looks unpolished
|
||||
- Design system incomplete
|
||||
- Missing visual hierarchy
|
||||
|
||||
2. **Design System Gaps**
|
||||
- Need new components
|
||||
- Missing variants/states
|
||||
- Token palette incomplete
|
||||
|
||||
3. **Stakeholder Needs**
|
||||
- Client presentation required
|
||||
- High-fidelity mockups needed
|
||||
- Marketing materials
|
||||
|
||||
**Don't extract if ALL of these are true:**
|
||||
|
||||
1. Prototype looks good enough
|
||||
2. Design system covers all needs
|
||||
3. Focus is on functionality
|
||||
4. Rapid iteration more important
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO ✅
|
||||
|
||||
1. **Maintain Object IDs**
|
||||
- Keep Object IDs through extraction
|
||||
- Use as Figma layer names
|
||||
- Enables traceability
|
||||
|
||||
2. **Document Iterations**
|
||||
- Track version history
|
||||
- Note design decisions
|
||||
- Record token changes
|
||||
- **Update specifications when design evolves**
|
||||
- Document why design changed from original spec
|
||||
|
||||
3. **Sync Bidirectionally**
|
||||
- Figma → Design System
|
||||
- Design System → Prototype
|
||||
- Keep everything aligned
|
||||
|
||||
4. **Iterate Incrementally**
|
||||
- Small refinement cycles
|
||||
- Test after each iteration
|
||||
- Don't over-polish early
|
||||
|
||||
### DON'T ❌
|
||||
|
||||
1. **Don't Extract Too Early**
|
||||
- Wait until concept is validated
|
||||
- Ensure functionality works first
|
||||
- Don't polish throwaway work
|
||||
|
||||
2. **Don't Lose Traceability**
|
||||
- Maintain Object ID connections
|
||||
- Document Figma references
|
||||
- Track design system changes
|
||||
|
||||
3. **Don't Diverge Without Updating Specs**
|
||||
- New design ideas during Figma refinement are welcome
|
||||
- **BUT:** Update specifications to match new design decisions
|
||||
- Keep Figma, specs, and code in sync
|
||||
- Update design system consistently
|
||||
- Specifications remain the source of truth
|
||||
|
||||
4. **Don't Over-Iterate**
|
||||
- Know when "good enough" is sufficient
|
||||
- Balance polish with progress
|
||||
- Ship working products
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Extraction Issues
|
||||
|
||||
**Problem:** html.to.design doesn't preserve layout
|
||||
|
||||
**Solution:**
|
||||
- Use semantic HTML structure
|
||||
- Avoid complex CSS positioning
|
||||
- Simplify before extraction
|
||||
- Use Flexbox/Grid layouts
|
||||
|
||||
---
|
||||
|
||||
**Problem:** Object IDs lost in extraction
|
||||
|
||||
**Solution:**
|
||||
- Add Object IDs to data attributes
|
||||
- Use as CSS classes
|
||||
- Include in element IDs
|
||||
- Document mapping separately
|
||||
|
||||
---
|
||||
|
||||
### Figma Refinement Issues
|
||||
|
||||
**Problem:** Can't match design system tokens
|
||||
|
||||
**Solution:**
|
||||
- Create Figma variables first
|
||||
- Map extracted values to variables
|
||||
- Document token mappings
|
||||
- Use consistent naming
|
||||
|
||||
---
|
||||
|
||||
**Problem:** Components don't match code structure
|
||||
|
||||
**Solution:**
|
||||
- Align Figma component hierarchy with HTML
|
||||
- Use same naming conventions
|
||||
- Document component boundaries
|
||||
- Keep structures parallel
|
||||
|
||||
---
|
||||
|
||||
### Re-rendering Issues
|
||||
|
||||
**Problem:** Design system changes break prototype
|
||||
|
||||
**Solution:**
|
||||
- Test incrementally
|
||||
- Update one token at a time
|
||||
- Verify after each change
|
||||
- Keep rollback version
|
||||
|
||||
---
|
||||
|
||||
**Problem:** Prototype loses functionality after re-render
|
||||
|
||||
**Solution:**
|
||||
- Preserve JavaScript logic
|
||||
- Don't change HTML structure
|
||||
- Only update styling
|
||||
- Test all interactions
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
**Quality Indicators:**
|
||||
|
||||
✅ Prototype looks polished
|
||||
✅ Design system is comprehensive
|
||||
✅ Figma and code are in sync
|
||||
✅ Object IDs maintained throughout
|
||||
✅ Iterations are productive
|
||||
✅ Team alignment on visual direction
|
||||
|
||||
**Efficiency Indicators:**
|
||||
|
||||
✅ Fewer refinement cycles needed
|
||||
✅ Design system grows organically
|
||||
✅ Reusable components identified
|
||||
✅ Faster subsequent prototypes
|
||||
✅ Reduced rework
|
||||
|
||||
---
|
||||
|
||||
## Example: Complete Iteration Cycle
|
||||
|
||||
### Iteration 1: Basic Prototype
|
||||
|
||||
**Input:** Login page specification
|
||||
|
||||
**Output:** Functional HTML prototype
|
||||
- Form works
|
||||
- Validation functions
|
||||
- But looks basic (incomplete design system)
|
||||
|
||||
**Assessment:** Needs visual refinement
|
||||
|
||||
---
|
||||
|
||||
### Iteration 2: Figma Refinement
|
||||
|
||||
**Extract to Figma:**
|
||||
- Upload to html.to.design
|
||||
- Import to Figma
|
||||
- Structure preserved
|
||||
|
||||
**Refine in Figma:**
|
||||
- Apply proper typography (Inter font)
|
||||
- Refine color palette (brand colors)
|
||||
- Add button variants (primary, secondary)
|
||||
- Define input states (default, focus, error)
|
||||
- Add visual polish (shadows, borders)
|
||||
|
||||
**Extract to Design System:**
|
||||
- New tokens: colors, spacing, typography
|
||||
- New components: Button [btn-001], Input [inp-001]
|
||||
- Updated: design-tokens.md, components/
|
||||
|
||||
---
|
||||
|
||||
### Iteration 3: Re-render
|
||||
|
||||
**Update Prototype:**
|
||||
- Apply new design tokens
|
||||
- Use new component classes
|
||||
- Regenerate with design system
|
||||
|
||||
**Result:**
|
||||
- Same functionality ✅
|
||||
- Polished visuals ✅
|
||||
- Design system extended ✅
|
||||
|
||||
**Assessment:** Complete! Ready for development
|
||||
|
||||
---
|
||||
|
||||
## Integration with Existing Workflows
|
||||
|
||||
### Phase 4D: Prototype
|
||||
|
||||
**Updated decision point:**
|
||||
|
||||
```markdown
|
||||
After prototype creation:
|
||||
|
||||
1. Test functionality
|
||||
2. Assess visual quality
|
||||
3. If needs refinement → Extract to Figma
|
||||
4. If sufficient → Complete
|
||||
```
|
||||
|
||||
### Phase 5: Design System
|
||||
|
||||
**New workflow branch:**
|
||||
|
||||
```markdown
|
||||
Design System can be populated via:
|
||||
|
||||
A. Component specification (existing)
|
||||
B. Figma manual creation (existing)
|
||||
C. Prototype extraction (NEW - this workflow)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
**To implement this workflow:**
|
||||
|
||||
1. ✅ Read this guide
|
||||
2. ✅ Set up html.to.design account
|
||||
3. ✅ Create test prototype
|
||||
4. ✅ Practice extraction process
|
||||
5. ✅ Refine in Figma
|
||||
6. ✅ Update design system
|
||||
7. ✅ Re-render and compare
|
||||
8. ✅ Iterate until comfortable
|
||||
|
||||
---
|
||||
|
||||
**This workflow completes the WDS design refinement loop, enabling iterative improvement from functional prototypes to polished, production-ready designs.**
|
||||
@@ -0,0 +1,26 @@
|
||||
# 3D Render
|
||||
|
||||
## Overview
|
||||
Full 3D rendered objects or scenes with realistic materials, lighting, and depth.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | High — materials, reflections, environment |
|
||||
| **Lighting** | Studio or environmental lighting |
|
||||
| **Texture** | Realistic materials (metal, glass, plastic, fabric) |
|
||||
| **Color** | Full spectrum, material-dependent |
|
||||
| **Depth** | Full 3D with perspective |
|
||||
|
||||
## Prompt Keywords
|
||||
`3D render, 3D illustration, CGI, rendered, studio lighting, material design, glossy, matte, metallic`
|
||||
|
||||
## Best For
|
||||
- Product showcases, device mockups, abstract hero images
|
||||
- Technology brands, gaming, automotive
|
||||
|
||||
## Dimensions Guide
|
||||
- Product renders: 1:1 or 4:3
|
||||
- Hero scenes: 16:9 or 21:9
|
||||
- Device mockups: device-specific ratios
|
||||
@@ -0,0 +1,25 @@
|
||||
# Comic Book
|
||||
|
||||
## Overview
|
||||
Bold outlines, halftone dots, speech bubbles, and dynamic action-style compositions.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | Medium — simplified but expressive |
|
||||
| **Lighting** | High contrast, dramatic shadows |
|
||||
| **Texture** | Halftone dots, Ben-Day dots, ink splatter |
|
||||
| **Color** | Bold, saturated, limited palette |
|
||||
| **Depth** | Flat with dramatic perspective |
|
||||
|
||||
## Prompt Keywords
|
||||
`comic book, comic style, halftone, bold outlines, pop art, graphic novel, ink, dynamic, action`
|
||||
|
||||
## Best For
|
||||
- Gaming, entertainment, youth brands, marketing campaigns
|
||||
- Storytelling sequences, feature explanations, onboarding
|
||||
|
||||
## Dimensions Guide
|
||||
- Panels: various ratios, comic grid layout
|
||||
- Characters: variable, action poses
|
||||
@@ -0,0 +1,26 @@
|
||||
# Flat Design
|
||||
|
||||
## Overview
|
||||
No gradients, shadows, or 3D effects — pure shapes, clean colors, geometric simplicity.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | Low — maximally simplified |
|
||||
| **Lighting** | None — flat color fills |
|
||||
| **Texture** | None — smooth, uniform |
|
||||
| **Color** | Solid fills, limited palette |
|
||||
| **Depth** | None — purely 2D |
|
||||
|
||||
## Prompt Keywords
|
||||
`flat design, flat illustration, minimalist, geometric, solid colors, no shadows, 2D, clean shapes`
|
||||
|
||||
## Best For
|
||||
- UI elements, icons, infographics, onboarding illustrations
|
||||
- Fast-loading assets, scalable graphics
|
||||
|
||||
## Dimensions Guide
|
||||
- Icons: 24x24 to 256x256
|
||||
- Illustrations: variable
|
||||
- Infographics: full-width
|
||||
@@ -0,0 +1,26 @@
|
||||
# Hyper-realistic
|
||||
|
||||
## Overview
|
||||
Beyond photography — extreme detail, perfect lighting, idealized reality.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | Maximum — every pore, thread, reflection |
|
||||
| **Lighting** | Perfect studio or cinematic lighting |
|
||||
| **Texture** | Microscopic detail visible |
|
||||
| **Color** | Rich, enhanced but believable |
|
||||
| **Depth** | Shallow depth of field, bokeh |
|
||||
|
||||
## Prompt Keywords
|
||||
`hyper-realistic, ultra-detailed, 8K, macro detail, cinematic lighting, photographic, sharp focus, professional photography`
|
||||
|
||||
## Best For
|
||||
- Luxury brands, food photography, automotive, jewelry
|
||||
- Hero images that need to feel premium
|
||||
|
||||
## Dimensions Guide
|
||||
- Hero: 2560x1440 or higher
|
||||
- Product: 1:1, high resolution
|
||||
- Detail shots: macro crop ratios
|
||||
@@ -0,0 +1,26 @@
|
||||
# Illustration
|
||||
|
||||
## Overview
|
||||
Hand-crafted digital illustrations — custom, warm, and brand-unique.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | Medium — stylized, not photographic |
|
||||
| **Lighting** | Flat or gently shaded |
|
||||
| **Texture** | Smooth with subtle grain |
|
||||
| **Color** | Brand palette, can be limited |
|
||||
| **Depth** | Flat to moderate depth |
|
||||
|
||||
## Prompt Keywords
|
||||
`illustration, digital illustration, hand-drawn, custom art, vector style, flat illustration, character illustration`
|
||||
|
||||
## Best For
|
||||
- Brand storytelling, onboarding flows, empty states, error pages
|
||||
- Distinctive brand identity that photography can't deliver
|
||||
|
||||
## Dimensions Guide
|
||||
- Spot illustrations: 400x400 to 800x800
|
||||
- Scene illustrations: 16:9 or custom
|
||||
- Icons as illustrations: 64x64 to 256x256
|
||||
@@ -0,0 +1,26 @@
|
||||
# Isometric
|
||||
|
||||
## Overview
|
||||
3D-like objects rendered in isometric projection — no perspective, parallel lines.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | Medium to high — clean geometry |
|
||||
| **Lighting** | Flat or subtle ambient |
|
||||
| **Texture** | Smooth, clean surfaces |
|
||||
| **Color** | Brand palette, can be vibrant |
|
||||
| **Depth** | Isometric projection (30-degree angles) |
|
||||
|
||||
## Prompt Keywords
|
||||
`isometric, isometric illustration, 3D isometric, parallel projection, geometric, clean, technical illustration`
|
||||
|
||||
## Best For
|
||||
- Tech products, data visualization, process diagrams, feature showcases
|
||||
- Explaining complex systems or workflows visually
|
||||
|
||||
## Dimensions Guide
|
||||
- Scene: 16:9 or square
|
||||
- Individual objects: 1:1 ratio
|
||||
- Infographics: variable height
|
||||
@@ -0,0 +1,26 @@
|
||||
# Line Art
|
||||
|
||||
## Overview
|
||||
Pure outlines — no fill, no shading, just clean continuous lines.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | Low to medium — defined by lines only |
|
||||
| **Lighting** | None — no shading |
|
||||
| **Texture** | None — clean strokes |
|
||||
| **Color** | Single color (usually black) or thin color lines |
|
||||
| **Depth** | Implied through line weight variation |
|
||||
|
||||
## Prompt Keywords
|
||||
`line art, line drawing, outline, continuous line, single line, clean lines, black and white, monoline`
|
||||
|
||||
## Best For
|
||||
- Icons, technical diagrams, coloring-book style, decorative patterns
|
||||
- Minimalist brands, loading animations base art
|
||||
|
||||
## Dimensions Guide
|
||||
- Icons: 24x24 to 128x128
|
||||
- Decorative: variable
|
||||
- Diagrams: content-dependent
|
||||
@@ -0,0 +1,25 @@
|
||||
# Pencil Sketch
|
||||
|
||||
## Overview
|
||||
Hand-drawn pencil or charcoal look — raw, authentic, in-progress feel.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | Variable — from rough to refined |
|
||||
| **Lighting** | Tonal shading, crosshatch |
|
||||
| **Texture** | Paper grain, graphite smudge |
|
||||
| **Color** | Grayscale (or limited color accents) |
|
||||
| **Depth** | Tonal depth through shading |
|
||||
|
||||
## Prompt Keywords
|
||||
`pencil sketch, hand-drawn, graphite, charcoal, sketch style, rough drawing, crosshatch, tonal`
|
||||
|
||||
## Best For
|
||||
- Architecture, concept art, wireframe-style illustrations, draft previews
|
||||
- Conveying "in progress" or "behind the scenes" feel
|
||||
|
||||
## Dimensions Guide
|
||||
- Concept sketches: variable
|
||||
- Wireframe illustrations: page-width
|
||||
@@ -0,0 +1,26 @@
|
||||
# Photorealistic
|
||||
|
||||
## Overview
|
||||
Images that look like real photographs — natural lighting, real textures, believable scenes.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | High — realistic textures and materials |
|
||||
| **Lighting** | Natural or studio lighting |
|
||||
| **Texture** | True-to-life materials |
|
||||
| **Color** | Natural color palette |
|
||||
| **Depth** | Realistic depth of field |
|
||||
|
||||
## Prompt Keywords
|
||||
`photorealistic, realistic, photograph, natural lighting, high detail, lifelike, studio quality, DSLR`
|
||||
|
||||
## Best For
|
||||
- Product photography, hero images, team portraits, real estate
|
||||
- Any context where authenticity matters
|
||||
|
||||
## Dimensions Guide
|
||||
- Hero images: 1920x1080 or 2560x1440
|
||||
- Product shots: 1:1 or 4:3 ratio
|
||||
- Portraits: 3:4 ratio
|
||||
@@ -0,0 +1,25 @@
|
||||
# Watercolor
|
||||
|
||||
## Overview
|
||||
Soft, flowing artwork with transparent washes, organic edges, and painterly feel.
|
||||
|
||||
## Rendering Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Detail level** | Low to medium — suggestive, not precise |
|
||||
| **Lighting** | Soft, diffused through paint |
|
||||
| **Texture** | Paper grain visible, paint bleeding at edges |
|
||||
| **Color** | Soft, transparent, blended |
|
||||
| **Depth** | Atmospheric — fades into white |
|
||||
|
||||
## Prompt Keywords
|
||||
`watercolor, watercolour, painted, soft washes, paper texture, transparent paint, flowing color, artistic`
|
||||
|
||||
## Best For
|
||||
- Wedding sites, wellness, art galleries, stationery, boutique brands
|
||||
- Backgrounds, decorative elements, section dividers
|
||||
|
||||
## Dimensions Guide
|
||||
- Backgrounds: full-width, transparent edges
|
||||
- Decorative: variable, organic shapes
|
||||
@@ -0,0 +1,26 @@
|
||||
# Brutalist
|
||||
|
||||
## Overview
|
||||
Raw, bold, unapologetic design that breaks conventions intentionally.
|
||||
|
||||
## Visual Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Whitespace** | Irregular — sometimes dense, sometimes empty |
|
||||
| **Color palette** | High contrast — black/white, neon accents |
|
||||
| **Typography** | Bold, oversized, mixed weights, sometimes monospace |
|
||||
| **Borders** | Thick, visible, sometimes raw |
|
||||
| **Shadows** | Hard/offset shadows or none |
|
||||
| **Imagery** | Raw, unprocessed, collage-style |
|
||||
| **Icons** | Custom, hand-drawn, or deliberately crude |
|
||||
|
||||
## Prompt Keywords
|
||||
`brutalist, raw, bold, unconventional, stark, industrial, exposed structure, anti-design`
|
||||
|
||||
## Best For
|
||||
- Creative agencies, art portfolios, experimental projects, fashion
|
||||
- Brands that want to stand out through contrast
|
||||
|
||||
## Avoid
|
||||
- Healthcare, finance, government, accessibility-critical applications
|
||||
@@ -0,0 +1,26 @@
|
||||
# Corporate
|
||||
|
||||
## Overview
|
||||
Professional, trustworthy design that communicates reliability and authority.
|
||||
|
||||
## Visual Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Whitespace** | Moderate — structured but not sparse |
|
||||
| **Color palette** | Navy, gray, white + brand accent |
|
||||
| **Typography** | Sans-serif, regular to medium weight |
|
||||
| **Borders** | Clean, defined sections |
|
||||
| **Shadows** | Subtle card elevation |
|
||||
| **Imagery** | Professional photography, team shots, office environments |
|
||||
| **Icons** | Solid or duo-tone, consistent style |
|
||||
|
||||
## Prompt Keywords
|
||||
`corporate, professional, trustworthy, clean, business, authoritative, polished, structured`
|
||||
|
||||
## Best For
|
||||
- B2B software, financial services, consulting, enterprise tools
|
||||
- Sites that need to convey trust and competence
|
||||
|
||||
## Avoid
|
||||
- Creative agencies, children's products, casual/playful brands
|
||||
@@ -0,0 +1,26 @@
|
||||
# Editorial
|
||||
|
||||
## Overview
|
||||
Magazine-inspired design with strong typography hierarchy, editorial layouts, and storytelling focus.
|
||||
|
||||
## Visual Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Whitespace** | Strategic — frames content like a magazine spread |
|
||||
| **Color palette** | Restrained — often monochrome with one accent |
|
||||
| **Typography** | Strong hierarchy, serif headlines, elegant spacing |
|
||||
| **Borders** | Thin rules, column dividers |
|
||||
| **Shadows** | Minimal |
|
||||
| **Imagery** | Full-bleed photography, editorial style |
|
||||
| **Icons** | Minimal use — typography carries the design |
|
||||
|
||||
## Prompt Keywords
|
||||
`editorial, magazine, typographic, sophisticated, storytelling, grid-based, print-inspired, refined`
|
||||
|
||||
## Best For
|
||||
- Media, publications, blogs, luxury brands, cultural institutions
|
||||
- Content-heavy sites where reading experience matters
|
||||
|
||||
## Avoid
|
||||
- SaaS dashboards, e-commerce with many products, data-heavy apps
|
||||
@@ -0,0 +1,26 @@
|
||||
# Minimal
|
||||
|
||||
## Overview
|
||||
Clean, spacious design with maximum whitespace and restrained use of elements.
|
||||
|
||||
## Visual Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Whitespace** | Generous — elements breathe |
|
||||
| **Color palette** | Monochrome + one accent |
|
||||
| **Typography** | Sans-serif, thin to regular weight |
|
||||
| **Borders** | Hairline or none |
|
||||
| **Shadows** | None or very subtle |
|
||||
| **Imagery** | High-contrast, isolated subjects |
|
||||
| **Icons** | Line icons, consistent stroke width |
|
||||
|
||||
## Prompt Keywords
|
||||
`minimal, clean, whitespace, simple, uncluttered, modern, restrained, elegant simplicity`
|
||||
|
||||
## Best For
|
||||
- Portfolio sites, luxury brands, SaaS products, personal sites
|
||||
- Content-focused layouts where text is primary
|
||||
|
||||
## Avoid
|
||||
- Dense data displays, e-commerce with many products, playful brands
|
||||
@@ -0,0 +1,26 @@
|
||||
# Organic
|
||||
|
||||
## Overview
|
||||
Natural, warm design inspired by nature — soft shapes, earthy tones, flowing layouts.
|
||||
|
||||
## Visual Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Whitespace** | Flowing — irregular but comfortable |
|
||||
| **Color palette** | Earth tones — greens, browns, warm neutrals |
|
||||
| **Typography** | Rounded sans-serif or serif, medium weight |
|
||||
| **Borders** | Rounded corners, organic shapes |
|
||||
| **Shadows** | Soft, diffused |
|
||||
| **Imagery** | Nature photography, textures, hand-drawn elements |
|
||||
| **Icons** | Rounded, organic line style |
|
||||
|
||||
## Prompt Keywords
|
||||
`organic, natural, warm, earthy, soft, flowing, nature-inspired, handcrafted, textured`
|
||||
|
||||
## Best For
|
||||
- Wellness, food, sustainability, outdoor brands, local businesses
|
||||
- Sites that want to feel human and approachable
|
||||
|
||||
## Avoid
|
||||
- High-tech, finance, enterprise software
|
||||
@@ -0,0 +1,26 @@
|
||||
# Playful
|
||||
|
||||
## Overview
|
||||
Fun, energetic design with bold colors, rounded shapes, and a sense of joy.
|
||||
|
||||
## Visual Characteristics
|
||||
|
||||
| Property | Value |
|
||||
|----------|-------|
|
||||
| **Whitespace** | Moderate — lively but not cramped |
|
||||
| **Color palette** | Vibrant, multi-color, saturated |
|
||||
| **Typography** | Rounded, bold, sometimes quirky display fonts |
|
||||
| **Borders** | Rounded corners, chunky outlines |
|
||||
| **Shadows** | Colorful or offset shadows |
|
||||
| **Imagery** | Illustrations, cartoons, bright photography |
|
||||
| **Icons** | Filled, colorful, sometimes animated |
|
||||
|
||||
## Prompt Keywords
|
||||
`playful, fun, colorful, energetic, vibrant, cheerful, friendly, whimsical, bouncy`
|
||||
|
||||
## Best For
|
||||
- Children's products, games, education, creative tools, food delivery
|
||||
- Brands targeting younger audiences or wanting to feel approachable
|
||||
|
||||
## Avoid
|
||||
- Luxury, finance, healthcare, legal services
|
||||
665
_bmad/wds/workflows/6-asset-generation/data/tools-reference.md
Normal file
665
_bmad/wds/workflows/6-asset-generation/data/tools-reference.md
Normal file
@@ -0,0 +1,665 @@
|
||||
# Design Tools Reference for WDS
|
||||
|
||||
**Purpose:** Quick reference for design tools used in WDS workflows, particularly for prototype-to-Figma extraction.
|
||||
|
||||
---
|
||||
|
||||
## MCP Server (Primary Method)
|
||||
|
||||
**Purpose:** Precise component injection from HTML prototypes to Figma
|
||||
|
||||
**Use Case in WDS:** Extract specific components for visual refinement with full traceability
|
||||
|
||||
**See:** `mcp-server-integration.md` for complete documentation
|
||||
|
||||
### Features
|
||||
|
||||
**Component-Level Precision:**
|
||||
- Select specific components by Object ID
|
||||
- Inject individual components or sections
|
||||
- Batch component extraction
|
||||
- Granular control over what gets refined
|
||||
|
||||
**Conversion Capabilities:**
|
||||
- HTML structure → Figma frames
|
||||
- CSS styles → Figma styling
|
||||
- Layout (Flexbox/Grid) → Auto Layout
|
||||
- Text content → Text layers
|
||||
- Colors → Color fills
|
||||
- Spacing → Padding/gaps
|
||||
|
||||
**Preservation:**
|
||||
- Object IDs maintained in layer names
|
||||
- Element hierarchy preserved
|
||||
- Component boundaries respected
|
||||
- Traceability throughout workflow
|
||||
|
||||
### How to Use
|
||||
|
||||
**1. Prepare Prototype**
|
||||
```
|
||||
Ensure your HTML prototype:
|
||||
- Uses semantic HTML elements
|
||||
- Has Object IDs on all components (data-object-id)
|
||||
- Uses Flexbox or Grid for layouts
|
||||
- Has clean CSS structure
|
||||
```
|
||||
|
||||
**2. Inject via MCP Server**
|
||||
```bash
|
||||
# Single component
|
||||
wds figma inject btn-login-submit --file abc123
|
||||
|
||||
# Multiple components
|
||||
wds figma batch inject --list components.txt --file abc123
|
||||
|
||||
# Entire section
|
||||
wds figma inject-section login-form --file abc123
|
||||
```
|
||||
|
||||
**3. Verify in Figma**
|
||||
```
|
||||
- Open target Figma file
|
||||
- Navigate to injection page
|
||||
- Verify components injected correctly
|
||||
- Check Object IDs preserved
|
||||
```
|
||||
|
||||
**4. Read Refined Components Back**
|
||||
```bash
|
||||
# After designer refines in Figma
|
||||
wds figma read btn-login-submit --file abc123 --update-design-system
|
||||
```
|
||||
|
||||
### Advantages over Manual Upload
|
||||
|
||||
✅ **Component-level precision** - Inject only what needs refinement
|
||||
✅ **Object ID preservation** - Automatic mapping maintained
|
||||
✅ **Bidirectional sync** - Read refined components back
|
||||
✅ **Batch operations** - Efficient multi-component extraction
|
||||
✅ **Direct integration** - Seamless WDS workflow
|
||||
✅ **Automated token extraction** - Design system updates automatic
|
||||
|
||||
---
|
||||
|
||||
## html.to.design (Alternative Method)
|
||||
|
||||
**Purpose:** Manual HTML to Figma conversion (fallback option)
|
||||
|
||||
**Website:** <https://html.to.design>
|
||||
|
||||
**Use Case in WDS:** When MCP server unavailable or for full-page extraction
|
||||
|
||||
**Note:** MCP server approach is preferred for component-level precision and traceability.
|
||||
|
||||
### When to Use html.to.design
|
||||
|
||||
**Use when:**
|
||||
- MCP server not configured
|
||||
- Need to extract entire page at once
|
||||
- Quick one-off conversion needed
|
||||
- Exploring design possibilities
|
||||
|
||||
**Don't use when:**
|
||||
- MCP server available (use MCP instead)
|
||||
- Need component-level precision
|
||||
- Require Object ID traceability
|
||||
- Planning iterative refinement
|
||||
|
||||
### How to Use
|
||||
|
||||
**1. Prepare Prototype**
|
||||
```
|
||||
Ensure your HTML prototype:
|
||||
- Uses semantic HTML elements
|
||||
- Has clean CSS structure
|
||||
- Uses Flexbox or Grid for layouts
|
||||
```
|
||||
|
||||
**2. Upload to html.to.design**
|
||||
```
|
||||
1. Go to https://html.to.design
|
||||
2. Upload HTML file
|
||||
3. Include associated CSS files
|
||||
4. Select target: Figma
|
||||
```
|
||||
|
||||
**3. Import to Figma**
|
||||
```
|
||||
1. Download converted Figma file
|
||||
2. Open in Figma
|
||||
3. Manually add Object IDs to layers
|
||||
4. Begin refinement
|
||||
```
|
||||
|
||||
**Limitations:**
|
||||
- No automatic Object ID preservation
|
||||
- Entire page extraction (less precise)
|
||||
- Manual token extraction required
|
||||
- No automated design system sync
|
||||
|
||||
### Best Practices
|
||||
|
||||
**DO ✅**
|
||||
- Use semantic HTML (header, nav, main, section, article)
|
||||
- Apply consistent class naming
|
||||
- Use Flexbox/Grid for layouts
|
||||
- Include Object IDs for traceability
|
||||
- Clean up HTML before extraction
|
||||
- Test prototype before extracting
|
||||
|
||||
**DON'T ❌**
|
||||
- Use complex CSS positioning (absolute, fixed)
|
||||
- Rely on JavaScript-generated content
|
||||
- Use inline styles excessively
|
||||
- Have deeply nested structures
|
||||
- Include debug/test code
|
||||
- Extract incomplete prototypes
|
||||
|
||||
### Limitations
|
||||
|
||||
**What Works Well:**
|
||||
- Standard layouts (header, content, footer)
|
||||
- Flexbox and Grid layouts
|
||||
- Text content and typography
|
||||
- Basic styling (colors, spacing, borders)
|
||||
- Image placeholders
|
||||
- Component-based structures
|
||||
|
||||
**What May Need Manual Adjustment:**
|
||||
- Complex animations
|
||||
- JavaScript-driven interactions
|
||||
- Dynamic content
|
||||
- Custom SVG graphics
|
||||
- Advanced CSS effects
|
||||
- Responsive breakpoints
|
||||
|
||||
### Tips for Better Extraction
|
||||
|
||||
**1. Simplify Structure**
|
||||
```html
|
||||
<!-- Before: Complex nesting -->
|
||||
<div class="wrapper">
|
||||
<div class="container">
|
||||
<div class="inner">
|
||||
<div class="content">Text</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- After: Simplified -->
|
||||
<div class="content-wrapper">
|
||||
<p>Text</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
**2. Use Flexbox/Grid**
|
||||
```css
|
||||
/* Preferred: Flexbox */
|
||||
.container {
|
||||
display: flex;
|
||||
gap: 16px;
|
||||
padding: 24px;
|
||||
}
|
||||
|
||||
/* Avoid: Absolute positioning */
|
||||
.item {
|
||||
position: absolute;
|
||||
top: 50px;
|
||||
left: 100px;
|
||||
}
|
||||
```
|
||||
|
||||
**3. Include Object IDs**
|
||||
```html
|
||||
<!-- Good: Object ID for traceability -->
|
||||
<button data-object-id="btn-login-submit" class="btn-primary">
|
||||
Log In
|
||||
</button>
|
||||
```
|
||||
|
||||
**4. Clean CSS**
|
||||
```css
|
||||
/* Preferred: Token-based */
|
||||
.button {
|
||||
background: var(--color-primary-600);
|
||||
padding: var(--spacing-md) var(--spacing-lg);
|
||||
border-radius: var(--radius-md);
|
||||
}
|
||||
|
||||
/* Avoid: Hardcoded values scattered -->
|
||||
.button {
|
||||
background: #2563eb;
|
||||
padding: 12px 16px;
|
||||
border-radius: 8px;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## NanoBanana
|
||||
|
||||
**Purpose:** Agent-driven asset creation, design inspiration, and sketch envisioning tool
|
||||
|
||||
**Website:** <https://nanobanana.com>
|
||||
|
||||
**Use Cases in WDS:**
|
||||
1. Create visual design assets and explore design concepts
|
||||
2. Convert sketches/specifications to visual designs (images or code)
|
||||
3. Generate design inspiration and placeholder assets
|
||||
|
||||
**Output Formats:**
|
||||
- Images (visual designs, graphics)
|
||||
- Code snippets (HTML/CSS/React)
|
||||
|
||||
**Description:** Agent-driven Photoshop - AI-powered tool for visual asset creation and design exploration
|
||||
|
||||
### Features
|
||||
|
||||
**Asset Creation Capabilities:**
|
||||
- Visual design generation
|
||||
- Design inspiration and variations
|
||||
- Custom graphics and icons
|
||||
- Image assets
|
||||
- Design concept exploration
|
||||
- Possibly code export for certain elements
|
||||
|
||||
### Integration with WDS
|
||||
|
||||
**Workflow:**
|
||||
```
|
||||
Design Concept
|
||||
→ NanoBanana (create assets/inspiration)
|
||||
→ Visual Assets/Design Ideas
|
||||
→ Import to Figma for refinement
|
||||
→ Integrate into Design System
|
||||
→ Use in Prototypes
|
||||
```
|
||||
|
||||
**When to Use:**
|
||||
- Need visual design inspiration
|
||||
- Creating custom graphics/assets
|
||||
- Exploring design variations
|
||||
- Generating design concepts
|
||||
- Creating placeholder visuals
|
||||
- Brand identity exploration
|
||||
|
||||
**When to Skip:**
|
||||
- Have existing design assets
|
||||
- Working with established brand
|
||||
- Simple text/layout designs
|
||||
- Using stock assets
|
||||
- Strict brand guidelines
|
||||
|
||||
### Best Practices
|
||||
|
||||
**DO ✅**
|
||||
- Use for creative exploration
|
||||
- Generate multiple variations
|
||||
- Refine AI-generated assets
|
||||
- Use as inspiration starting point
|
||||
- Integrate refined assets into design system
|
||||
- Document asset sources
|
||||
|
||||
**DON'T ❌**
|
||||
- Replace human design thinking
|
||||
- Skip refinement process
|
||||
- Ignore brand guidelines
|
||||
- Use without customization
|
||||
- Rely solely on AI output
|
||||
- Skip quality review
|
||||
|
||||
---
|
||||
|
||||
## Area Tag System
|
||||
|
||||
**Purpose:** Precise region mapping in HTML prototypes for interactive hotspots
|
||||
|
||||
**Use Case in WDS:** Map clickable regions on image-based prototypes or complex UI elements
|
||||
|
||||
### What Are Area Tags?
|
||||
|
||||
HTML `<area>` elements within `<map>` tags that define clickable regions on images:
|
||||
|
||||
```html
|
||||
<img src="prototype-screenshot.png" usemap="#prototype-map" alt="Prototype">
|
||||
|
||||
<map name="prototype-map">
|
||||
<area shape="rect"
|
||||
coords="100,50,300,150"
|
||||
data-object-id="btn-login"
|
||||
alt="Login Button"
|
||||
href="#login">
|
||||
<area shape="rect"
|
||||
coords="100,200,300,250"
|
||||
data-object-id="link-signup"
|
||||
alt="Sign Up Link"
|
||||
href="#signup">
|
||||
</map>
|
||||
```
|
||||
|
||||
### When to Use Area Tags
|
||||
|
||||
**Use When:**
|
||||
- Working with image-based prototypes
|
||||
- Need precise click mapping
|
||||
- Complex UI with overlapping elements
|
||||
- Screenshot-based specifications
|
||||
- Testing click regions
|
||||
|
||||
**Don't Use When:**
|
||||
- HTML elements are clickable directly
|
||||
- Simple button/link interactions
|
||||
- Fully interactive prototype exists
|
||||
- Accessibility is primary concern
|
||||
|
||||
### Integration with Dev Mode
|
||||
|
||||
The dev-mode.js component can extract area tag coordinates:
|
||||
|
||||
```javascript
|
||||
// Dev mode detects area tags
|
||||
document.querySelectorAll('area').forEach(area => {
|
||||
const coords = area.coords;
|
||||
const objectId = area.dataset.objectId;
|
||||
console.log(`${objectId}: ${coords}`);
|
||||
});
|
||||
```
|
||||
|
||||
### Creating Area Tags
|
||||
|
||||
**1. Get Coordinates**
|
||||
```
|
||||
Use image editor or browser dev tools:
|
||||
- Top-left corner: (x1, y1)
|
||||
- Bottom-right corner: (x2, y2)
|
||||
- Format: "x1,y1,x2,y2"
|
||||
```
|
||||
|
||||
**2. Define Area**
|
||||
```html
|
||||
<area shape="rect"
|
||||
coords="x1,y1,x2,y2"
|
||||
data-object-id="unique-id"
|
||||
alt="Description"
|
||||
href="#target">
|
||||
```
|
||||
|
||||
**3. Link to Map**
|
||||
```html
|
||||
<img src="image.png" usemap="#mapname">
|
||||
<map name="mapname">
|
||||
<!-- area tags here -->
|
||||
</map>
|
||||
```
|
||||
|
||||
### Best Practices
|
||||
|
||||
**DO ✅**
|
||||
- Include Object IDs in data attributes
|
||||
- Provide descriptive alt text
|
||||
- Test all clickable regions
|
||||
- Document area mappings
|
||||
- Use for image-based prototypes
|
||||
|
||||
**DON'T ❌**
|
||||
- Use for fully interactive HTML prototypes
|
||||
- Forget accessibility considerations
|
||||
- Overlap areas without purpose
|
||||
- Skip testing on different screen sizes
|
||||
- Use as replacement for proper HTML
|
||||
|
||||
### Accessibility Considerations
|
||||
|
||||
Area tags have limitations:
|
||||
- Not keyboard accessible by default
|
||||
- Screen readers may not announce properly
|
||||
- Better to use actual HTML elements when possible
|
||||
|
||||
**Workaround:**
|
||||
```html
|
||||
<!-- Add keyboard support -->
|
||||
<area shape="rect"
|
||||
coords="100,50,300,150"
|
||||
data-object-id="btn-login"
|
||||
alt="Login Button"
|
||||
href="#login"
|
||||
tabindex="0"
|
||||
role="button">
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Dev Mode Component
|
||||
|
||||
**Purpose:** Interactive tool for extracting Object IDs and area coordinates from prototypes
|
||||
|
||||
**Location:** `workflows/4-ux-design/agentic-development/templates/components/dev-mode.js`
|
||||
|
||||
### Features
|
||||
|
||||
**Object ID Extraction:**
|
||||
- Hold Shift + Click to copy Object IDs
|
||||
- Visual highlights when Shift held
|
||||
- Tooltip display on hover
|
||||
- Success feedback when copied
|
||||
- Form field protection
|
||||
|
||||
**Area Tag Extraction:**
|
||||
- Detect area tags in prototype
|
||||
- Extract coordinates
|
||||
- Map to Object IDs
|
||||
- Export for documentation
|
||||
|
||||
### Usage
|
||||
|
||||
**1. Include in Prototype**
|
||||
```html
|
||||
<script src="shared/dev-mode.js"></script>
|
||||
```
|
||||
|
||||
**2. Activate Dev Mode**
|
||||
```
|
||||
- Click "Dev Mode" button, or
|
||||
- Press Ctrl+E (Cmd+E on Mac)
|
||||
```
|
||||
|
||||
**3. Extract Object IDs**
|
||||
```
|
||||
- Hold Shift
|
||||
- Click on element
|
||||
- Object ID copied to clipboard
|
||||
```
|
||||
|
||||
**4. Extract Area Coordinates**
|
||||
```
|
||||
- Dev mode detects area tags
|
||||
- Displays coordinates
|
||||
- Exports mapping data
|
||||
```
|
||||
|
||||
### Integration with html.to.design
|
||||
|
||||
**Workflow:**
|
||||
```
|
||||
1. Create prototype with Object IDs
|
||||
2. Use dev mode to verify Object IDs
|
||||
3. Extract to Figma via html.to.design
|
||||
4. Object IDs preserved in layer names
|
||||
5. Maintain traceability
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Tool Comparison
|
||||
|
||||
| Tool | Category | Primary Use | Input | Output | WDS Use Case |
|
||||
|------|----------|-------------|-------|--------|--------------|
|
||||
| **MCP Server** | Figma Integration | Automated sync | HTML + Object ID | Figma components | Precise refinement (PRIMARY) |
|
||||
| **html.to.design** | HTML → Figma | Full-page conversion | HTML/CSS | Figma file | Fallback method (OPTIONAL) |
|
||||
| **NanoBanana** | AI Design | Asset creation + Sketch envisioning | Text/Sketch/Spec | Images or Code | Early exploration OR sketch-to-design (OPTIONAL) |
|
||||
| **Area Tags** | Region mapping | Clickable regions | Image + coords | Clickable map | Image prototypes |
|
||||
| **Dev Mode** | ID extraction | Object ID tracking | Prototype | Object IDs | Traceability |
|
||||
|
||||
---
|
||||
|
||||
## Recommended Workflow
|
||||
|
||||
### Standard Flow (MCP Server - Recommended)
|
||||
|
||||
```
|
||||
1. Create specification (Phase 4C)
|
||||
2. Build HTML prototype manually (Phase 4D)
|
||||
3. Add Object IDs to all components
|
||||
4. Test functionality
|
||||
5. Inject specific components to Figma via MCP server (if needed)
|
||||
6. Refine in Figma
|
||||
7. Read refined components via MCP server
|
||||
8. Design system auto-updated
|
||||
9. Re-render prototype
|
||||
```
|
||||
|
||||
**Advantages:**
|
||||
- Component-level precision
|
||||
- Object ID traceability maintained
|
||||
- Automated design system updates
|
||||
- Bidirectional sync
|
||||
|
||||
### Alternative Flow (Manual Upload - Fallback)
|
||||
|
||||
```
|
||||
1. Create specification (Phase 4C)
|
||||
2. Build HTML prototype manually (Phase 4D)
|
||||
3. Add Object IDs to all elements
|
||||
4. Test functionality
|
||||
5. Upload to html.to.design (if MCP unavailable)
|
||||
6. Manually add Object IDs to Figma layers
|
||||
7. Refine in Figma
|
||||
8. Manually extract design tokens
|
||||
9. Update design system manually
|
||||
10. Re-render prototype
|
||||
```
|
||||
|
||||
**Use when:** MCP server not available
|
||||
|
||||
### With Asset Creation (NanoBanana - Optional)
|
||||
|
||||
```
|
||||
1. Create specification (Phase 4C)
|
||||
2. Use NanoBanana for design inspiration/assets (optional)
|
||||
3. Import assets to Figma
|
||||
4. Build HTML prototype manually (Phase 4D)
|
||||
5. Add Object IDs to all components
|
||||
6. Test functionality
|
||||
7. Inject to Figma via MCP server (if needed)
|
||||
8. Refine in Figma (with NanoBanana assets)
|
||||
9. Read back via MCP server
|
||||
10. Design system auto-updated
|
||||
11. Re-render prototype
|
||||
```
|
||||
|
||||
**Use NanoBanana for:**
|
||||
- Creating custom graphics/icons
|
||||
- Generating design inspiration
|
||||
- Exploring visual concepts
|
||||
- Creating placeholder assets
|
||||
|
||||
### Image-Based Flow (With Area Tags)
|
||||
|
||||
```
|
||||
1. Create specification (Phase 4C)
|
||||
2. Create image-based prototype
|
||||
3. Add area tags for clickable regions
|
||||
4. Include Object IDs in area tags
|
||||
5. Test click regions
|
||||
6. Extract to Figma via html.to.design
|
||||
7. Refine in Figma
|
||||
8. Convert to HTML prototype
|
||||
9. Update design system
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cost Considerations
|
||||
|
||||
### html.to.design
|
||||
- Free tier available
|
||||
- Paid plans for advanced features
|
||||
- Check current pricing at website
|
||||
|
||||
### NanoBanana
|
||||
- Pricing varies by usage
|
||||
- Check current pricing at website
|
||||
- Consider cost vs time savings
|
||||
|
||||
### Area Tags
|
||||
- Free (standard HTML)
|
||||
- No additional cost
|
||||
|
||||
### Dev Mode
|
||||
- Free (included in WDS)
|
||||
- No additional cost
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### html.to.design Issues
|
||||
|
||||
**Problem:** Layout not preserved
|
||||
**Solution:** Use Flexbox/Grid, simplify structure
|
||||
|
||||
**Problem:** Styles not converted
|
||||
**Solution:** Use standard CSS properties, avoid complex selectors
|
||||
|
||||
**Problem:** Text content missing
|
||||
**Solution:** Ensure text is in HTML, not JavaScript-generated
|
||||
|
||||
### NanoBanana Issues
|
||||
|
||||
**Problem:** Generated code doesn't match design system
|
||||
**Solution:** Customize output, apply design system manually
|
||||
|
||||
**Problem:** Complex interactions not generated correctly
|
||||
**Solution:** Review and rewrite interaction logic
|
||||
|
||||
### Area Tag Issues
|
||||
|
||||
**Problem:** Clicks not registering
|
||||
**Solution:** Verify coordinates, check map name matches
|
||||
|
||||
**Problem:** Accessibility concerns
|
||||
**Solution:** Add keyboard support, use actual HTML when possible
|
||||
|
||||
### Dev Mode Issues
|
||||
|
||||
**Problem:** Object IDs not copying
|
||||
**Solution:** Check Shift key, verify Object IDs exist
|
||||
|
||||
**Problem:** Dev mode not activating
|
||||
**Solution:** Check script loaded, try Ctrl+E
|
||||
|
||||
---
|
||||
|
||||
## Resources
|
||||
|
||||
**html.to.design:**
|
||||
- Website: <https://html.to.design>
|
||||
- Documentation: Check website for latest docs
|
||||
|
||||
**NanoBanana:**
|
||||
- Website: <https://nanobanana.com>
|
||||
- Documentation: Check website for latest docs
|
||||
|
||||
**HTML Area Tags:**
|
||||
- MDN Reference: <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/area>
|
||||
- W3C Spec: <https://www.w3.org/TR/html52/semantics-embedded-content.html#the-area-element>
|
||||
|
||||
**WDS Documentation:**
|
||||
- Prototype Workflow: `workflows/4-ux-design/agentic-development/`
|
||||
- Figma Integration: `workflows/6-asset-generation/workflow-figma.md`
|
||||
- Dev Mode: `workflows/4-ux-design/agentic-development/templates/components/`
|
||||
|
||||
---
|
||||
|
||||
**This reference provides quick access to tool information for WDS design workflows. For detailed workflows, see the specific workflow documentation files.**
|
||||
@@ -0,0 +1,663 @@
|
||||
# When to Extract Prototypes to Figma - Decision Guide
|
||||
|
||||
**Purpose:** Help designers decide when to extract HTML prototypes to Figma for visual refinement.
|
||||
|
||||
**Quick Answer:** Extract when the design system is incomplete and the prototype needs visual polish.
|
||||
|
||||
---
|
||||
|
||||
## Decision Tree
|
||||
|
||||
```
|
||||
Prototype Created
|
||||
↓
|
||||
Does it look polished?
|
||||
↓
|
||||
┌─────┴─────┐
|
||||
YES NO
|
||||
↓ ↓
|
||||
Complete Is design system incomplete?
|
||||
↓
|
||||
┌─────┴─────┐
|
||||
YES NO
|
||||
↓ ↓
|
||||
Extract to Quick CSS fixes
|
||||
Figma sufficient
|
||||
↓
|
||||
Refine design
|
||||
↓
|
||||
Update design system
|
||||
↓
|
||||
Re-render prototype
|
||||
↓
|
||||
Iterate or Complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Assessment Checklist
|
||||
|
||||
### ✅ Extract to Figma if:
|
||||
|
||||
- [ ] Prototype not visually appealing or unpolished
|
||||
- [ ] Design system missing components for this view
|
||||
- [ ] Need to define new design tokens (colors, spacing, typography)
|
||||
- [ ] Stakeholder presentation requires high-fidelity
|
||||
- [ ] Multiple similar components need standardization
|
||||
- [ ] Visual hierarchy unclear
|
||||
- [ ] Spacing/alignment inconsistent
|
||||
|
||||
### ❌ Don't Extract if:
|
||||
|
||||
- [ ] Prototype already looks good
|
||||
- [ ] Design system covers all needs
|
||||
- [ ] Still validating functionality
|
||||
- [ ] Rapid iteration more important than polish
|
||||
- [ ] Early exploration phase
|
||||
- [ ] Internal testing only
|
||||
|
||||
---
|
||||
|
||||
## Scenarios
|
||||
|
||||
### Scenario 1: First Page in Project
|
||||
|
||||
**Situation:** Creating first prototype, design system is empty
|
||||
|
||||
**Decision:** ✅ **Extract to Figma**
|
||||
|
||||
**Reason:** Need to establish design foundation
|
||||
- Define color palette
|
||||
- Set typography scale
|
||||
- Create spacing system
|
||||
- Build first components
|
||||
|
||||
**Workflow:**
|
||||
1. Create basic prototype (functional)
|
||||
2. Extract to Figma
|
||||
3. Define complete design system
|
||||
4. Re-render with design system
|
||||
5. Use for all subsequent pages
|
||||
|
||||
---
|
||||
|
||||
### Scenario 2: Similar to Existing Pages
|
||||
|
||||
**Situation:** Design system already has most components needed
|
||||
|
||||
**Decision:** ❌ **Don't Extract**
|
||||
|
||||
**Reason:** Design system sufficient
|
||||
- Reuse existing components
|
||||
- Apply existing tokens
|
||||
- Minor variations can be CSS tweaks
|
||||
|
||||
**Workflow:**
|
||||
1. Create prototype with design system
|
||||
2. Test functionality
|
||||
3. Make minor CSS adjustments if needed
|
||||
4. Complete
|
||||
|
||||
---
|
||||
|
||||
### Scenario 3: New Component Type Needed
|
||||
|
||||
**Situation:** Page needs component type not in design system (e.g., data table)
|
||||
|
||||
**Decision:** ✅ **Extract to Figma**
|
||||
|
||||
**Reason:** Need to design new component properly
|
||||
- Define component structure
|
||||
- Create variants and states
|
||||
- Document design tokens
|
||||
- Add to design system
|
||||
|
||||
**Workflow:**
|
||||
1. Create basic prototype
|
||||
2. Extract to Figma
|
||||
3. Design new component thoroughly
|
||||
4. Add to design system
|
||||
5. Re-render prototype
|
||||
6. Component now available for future use
|
||||
|
||||
---
|
||||
|
||||
### Scenario 4: Stakeholder Presentation
|
||||
|
||||
**Situation:** Working prototype exists but looks basic, client review tomorrow
|
||||
|
||||
**Decision:** ✅ **Extract to Figma**
|
||||
|
||||
**Reason:** Need polished visuals for presentation
|
||||
- Apply professional styling
|
||||
- Refine visual hierarchy
|
||||
- Add polish (shadows, effects)
|
||||
- Create presentation-ready mockups
|
||||
|
||||
**Workflow:**
|
||||
1. Extract current prototype
|
||||
2. Polish in Figma quickly
|
||||
3. Present Figma mockups
|
||||
4. After approval, update design system
|
||||
5. Re-render for development
|
||||
|
||||
---
|
||||
|
||||
### Scenario 5: Rapid Prototyping Phase
|
||||
|
||||
**Situation:** Testing multiple concepts quickly, designs will change
|
||||
|
||||
**Decision:** ❌ **Don't Extract**
|
||||
|
||||
**Reason:** Too early for polish
|
||||
- Focus on functionality
|
||||
- Validate concepts first
|
||||
- Avoid polishing throwaway work
|
||||
|
||||
**Workflow:**
|
||||
1. Create basic prototypes
|
||||
2. Test with users
|
||||
3. Iterate on functionality
|
||||
4. Once concept validated, then extract for polish
|
||||
|
||||
---
|
||||
|
||||
## Design System Maturity Levels
|
||||
|
||||
### Level 1: Empty (0-5 components)
|
||||
|
||||
**Typical Decision:** Extract to Figma
|
||||
**Reason:** Need to build foundation
|
||||
**Focus:** Establish design tokens and core components
|
||||
|
||||
### Level 2: Growing (6-15 components)
|
||||
|
||||
**Typical Decision:** Extract when gaps found
|
||||
**Reason:** Fill missing pieces
|
||||
**Focus:** Expand component library strategically
|
||||
|
||||
### Level 3: Mature (16+ components)
|
||||
|
||||
**Typical Decision:** Rarely extract
|
||||
**Reason:** Most needs covered
|
||||
**Focus:** Reuse existing, minor variations only
|
||||
|
||||
---
|
||||
|
||||
## Cost-Benefit Analysis
|
||||
|
||||
### Benefits of Extracting
|
||||
|
||||
**Design Quality:**
|
||||
- Professional visual polish
|
||||
- Consistent design system
|
||||
- Reusable components
|
||||
- Better stakeholder buy-in
|
||||
|
||||
**Long-term Efficiency:**
|
||||
- Design system grows
|
||||
- Future prototypes faster
|
||||
- Reduced design debt
|
||||
- Team alignment
|
||||
|
||||
### Costs of Extracting
|
||||
|
||||
**Time Investment:**
|
||||
- Extraction process: 15-30 min
|
||||
- Figma refinement: 1-3 hours
|
||||
- Design system update: 30-60 min
|
||||
- Re-rendering: 15-30 min
|
||||
- **Total: 2-5 hours per page**
|
||||
|
||||
**Workflow Overhead:**
|
||||
- Context switching
|
||||
- Tool learning curve
|
||||
- Sync maintenance
|
||||
- Version tracking
|
||||
|
||||
---
|
||||
|
||||
## When Time is Limited
|
||||
|
||||
### High Priority: Extract
|
||||
|
||||
**These pages justify the time investment:**
|
||||
- Landing pages (first impression)
|
||||
- Onboarding flows (user retention)
|
||||
- Checkout/payment (conversion critical)
|
||||
- Dashboard (frequent use)
|
||||
- Marketing pages (brand representation)
|
||||
|
||||
### Lower Priority: Skip
|
||||
|
||||
**These pages can stay basic:**
|
||||
- Admin panels (internal use)
|
||||
- Error pages (rare views)
|
||||
- Settings pages (utility focus)
|
||||
- Debug/test pages (temporary)
|
||||
|
||||
---
|
||||
|
||||
## Team Collaboration Factors
|
||||
|
||||
### Extract When:
|
||||
|
||||
**Designer-Developer Collaboration:**
|
||||
- Designer needs to define visual direction
|
||||
- Developer needs clear component specs
|
||||
- Team needs shared design language
|
||||
|
||||
**Stakeholder Communication:**
|
||||
- Client needs to approve visuals
|
||||
- Marketing needs branded materials
|
||||
- Sales needs demo materials
|
||||
|
||||
### Skip When:
|
||||
|
||||
**Solo Development:**
|
||||
- One person doing design + dev
|
||||
- Direct implementation faster
|
||||
- No handoff needed
|
||||
|
||||
**Internal Tools:**
|
||||
- Team understands context
|
||||
- Functionality over aesthetics
|
||||
- Rapid iteration valued
|
||||
|
||||
---
|
||||
|
||||
## Quality Thresholds
|
||||
|
||||
### Extract if Prototype Has:
|
||||
|
||||
**Visual Issues:**
|
||||
- Inconsistent spacing
|
||||
- Poor typography hierarchy
|
||||
- Clashing colors
|
||||
- Misaligned elements
|
||||
- Unclear visual hierarchy
|
||||
|
||||
**Missing Design Elements:**
|
||||
- No hover states
|
||||
- Missing loading states
|
||||
- Incomplete error states
|
||||
- No disabled states
|
||||
- Basic placeholder styling
|
||||
|
||||
**Component Gaps:**
|
||||
- Custom components needed
|
||||
- Existing components insufficient
|
||||
- New patterns required
|
||||
- Variant expansion needed
|
||||
|
||||
### Don't Extract if Prototype Has:
|
||||
|
||||
**Sufficient Quality:**
|
||||
- Consistent spacing
|
||||
- Clear hierarchy
|
||||
- Appropriate colors
|
||||
- Aligned elements
|
||||
- Professional appearance
|
||||
|
||||
**Complete Design System Coverage:**
|
||||
- All components available
|
||||
- States defined
|
||||
- Variants sufficient
|
||||
- Tokens applied
|
||||
|
||||
---
|
||||
|
||||
## Iteration Strategy
|
||||
|
||||
### First Iteration
|
||||
|
||||
**Always extract if:**
|
||||
- Establishing design foundation
|
||||
- First page in project
|
||||
- Setting visual direction
|
||||
|
||||
### Subsequent Iterations
|
||||
|
||||
**Extract only if:**
|
||||
- Significant design system gaps
|
||||
- New component types needed
|
||||
- Visual quality insufficient
|
||||
|
||||
### Final Iteration
|
||||
|
||||
**Extract if:**
|
||||
- Stakeholder presentation
|
||||
- Production launch
|
||||
- Marketing materials needed
|
||||
|
||||
---
|
||||
|
||||
## Practical Examples
|
||||
|
||||
### Example 1: E-commerce Product Page
|
||||
|
||||
**Phase 1: Sketch (Concept)**
|
||||
- Designer creates hand-drawn sketch of product page
|
||||
- Shows product gallery, reviews section, rating display
|
||||
- Rough layout and component placement
|
||||
|
||||
**Phase 2: Specification (Phase 4C)**
|
||||
- Freya analyzes sketch
|
||||
- Creates detailed specification:
|
||||
- Product gallery: Image carousel with thumbnails
|
||||
- Reviews component: User avatar, rating, text, date
|
||||
- Rating stars: 5-star display with half-star support
|
||||
- All Object IDs defined
|
||||
- Content and interactions specified
|
||||
|
||||
**Phase 3: Prototype (Phase 4D)**
|
||||
- Freya builds functional HTML prototype
|
||||
- Uses existing design system (buttons, inputs, cards)
|
||||
- Product gallery, reviews, ratings are basic/functional but unpolished
|
||||
|
||||
**Initial Assessment:**
|
||||
- Prototype works functionally ✅
|
||||
- Design system has: buttons, inputs, cards
|
||||
- Missing: product gallery, reviews component, rating stars (visual refinement needed)
|
||||
|
||||
**Decision:** ✅ Extract to Figma
|
||||
|
||||
**Phase 4: Figma Refinement**
|
||||
|
||||
Freya automatically:
|
||||
1. Analyzes prototype components
|
||||
2. Identifies missing components (gallery, reviews, ratings)
|
||||
3. Injects to Figma via MCP server
|
||||
4. Page: `02-Product-Catalog / 2.3-Product-Detail`
|
||||
|
||||
Designer in Figma:
|
||||
5. Designs product gallery component (image zoom, transitions)
|
||||
6. Designs reviews component (typography, spacing, layout)
|
||||
7. Designs rating component (star icons, colors, states)
|
||||
8. Applies design tokens (colors, spacing, typography)
|
||||
|
||||
**Phase 5: Design System Update**
|
||||
|
||||
Freya automatically:
|
||||
9. Reads refined components from Figma
|
||||
10. Extracts design tokens
|
||||
11. Updates design system:
|
||||
- `D-Design-System/components/product-gallery.md`
|
||||
- `D-Design-System/components/review-card.md`
|
||||
- `D-Design-System/components/rating-stars.md`
|
||||
|
||||
**Phase 6: Re-render**
|
||||
12. Freya re-renders prototype with enhanced design system
|
||||
13. Prototype now polished and professional
|
||||
|
||||
**Result:**
|
||||
- ✅ Polished product page
|
||||
- ✅ 3 new reusable components in design system
|
||||
- ✅ Specification updated (if design evolved)
|
||||
- ✅ All future product pages can use these components
|
||||
|
||||
---
|
||||
|
||||
### Example 2: Settings Page
|
||||
|
||||
**Phase 1: Sketch (Concept)**
|
||||
- Designer creates simple sketch of settings page
|
||||
- Shows form fields, toggles, save button
|
||||
- Standard layout, no custom components
|
||||
|
||||
**Phase 2: Specification (Phase 4C)**
|
||||
- Freya analyzes sketch
|
||||
- Creates specification:
|
||||
- Form fields: Email, password, notifications
|
||||
- Toggle switches: Email notifications, push notifications
|
||||
- Save button: Standard primary button
|
||||
- All components exist in design system
|
||||
|
||||
**Phase 3: Prototype (Phase 4D)**
|
||||
- Freya builds HTML prototype
|
||||
- Uses existing design system components:
|
||||
- Form inputs (already designed)
|
||||
- Toggle switches (already designed)
|
||||
- Buttons (already designed)
|
||||
- Prototype looks polished immediately
|
||||
|
||||
**Initial Assessment:**
|
||||
- Prototype works functionally ✅
|
||||
- Prototype looks polished ✅
|
||||
- Design system has: forms, toggles, buttons
|
||||
- All components available
|
||||
- Internal use only
|
||||
|
||||
**Decision:** ❌ Don't Extract
|
||||
|
||||
**Actions:**
|
||||
1. Apply existing design system ✅ (already done)
|
||||
2. Minor CSS tweaks for spacing (if needed)
|
||||
3. Test functionality ✅
|
||||
4. Complete ✅
|
||||
|
||||
**Result:**
|
||||
- ✅ Functional, polished page in 30 minutes
|
||||
- ✅ No Figma extraction needed
|
||||
- ✅ Design system reuse successful
|
||||
|
||||
---
|
||||
|
||||
### Example 3: Landing Page
|
||||
|
||||
**Phase 1: Sketch (Concept)**
|
||||
- Designer creates detailed sketch of landing page
|
||||
- Hero section with headline, subtext, CTA
|
||||
- Feature cards with icons and descriptions
|
||||
- Testimonials with photos and quotes
|
||||
- Multiple CTA sections throughout
|
||||
|
||||
**Phase 2: Specification (Phase 4C)**
|
||||
- Freya analyzes sketch
|
||||
- Creates comprehensive specification:
|
||||
- Hero section: Large headline, supporting text, primary CTA
|
||||
- Feature cards: Icon, title, description, learn more link
|
||||
- Testimonials: User photo, quote, name, company
|
||||
- CTA sections: Headline, button, background treatment
|
||||
- All Object IDs defined
|
||||
- Multi-language content specified
|
||||
|
||||
**Phase 3: Prototype (Phase 4D)**
|
||||
- Freya builds functional HTML prototype
|
||||
- Uses basic design system components
|
||||
- Hero, features, testimonials are functional but basic
|
||||
- Client presentation in one week (high priority!)
|
||||
|
||||
**Initial Assessment:**
|
||||
- Prototype works functionally ✅
|
||||
- Design system has basic components
|
||||
- Needs visual refinement: hero section, feature cards, testimonials, CTA sections
|
||||
- Client presentation next week (high stakes!)
|
||||
|
||||
**Decision:** ✅ Extract to Figma
|
||||
|
||||
**Phase 4: Figma Refinement**
|
||||
|
||||
Freya automatically:
|
||||
1. Analyzes prototype components
|
||||
2. Identifies components needing refinement (hero, features, testimonials, CTAs)
|
||||
3. Injects to Figma via MCP server
|
||||
4. Page: `01-Marketing / 1.1-Landing-Page`
|
||||
|
||||
Designer in Figma:
|
||||
5. Designs hero component (brand-critical, high impact)
|
||||
6. Designs feature cards (icons, layout, spacing)
|
||||
7. Designs testimonial component (photos, typography)
|
||||
8. Polishes CTA sections (visual hierarchy, contrast)
|
||||
9. Applies brand colors, typography, spacing tokens
|
||||
|
||||
**Phase 5: Design System Update**
|
||||
|
||||
Freya automatically:
|
||||
10. Reads refined components from Figma
|
||||
11. Extracts design tokens and components
|
||||
12. Updates design system:
|
||||
- `D-Design-System/components/hero-section.md`
|
||||
- `D-Design-System/components/feature-card.md`
|
||||
- `D-Design-System/components/testimonial.md`
|
||||
- `D-Design-System/components/cta-section.md`
|
||||
|
||||
**Phase 6: Re-render for Presentation**
|
||||
13. Freya re-renders prototype with enhanced design system
|
||||
14. Prototype now presentation-ready
|
||||
|
||||
**Result:**
|
||||
- ✅ Polished, professional landing page
|
||||
- ✅ 4 new reusable components for future marketing pages
|
||||
- ✅ Client presentation ready
|
||||
- ✅ Design system significantly expanded
|
||||
|
||||
---
|
||||
|
||||
## Red Flags: When NOT to Extract
|
||||
|
||||
### 🚩 Premature Optimization
|
||||
|
||||
**Sign:** Polishing before validating concept
|
||||
**Problem:** Wasting time on designs that may change
|
||||
**Solution:** Validate functionality first, polish later
|
||||
|
||||
### 🚩 Over-Engineering
|
||||
|
||||
**Sign:** Creating design system for one-off pages
|
||||
**Problem:** Overhead exceeds benefit
|
||||
**Solution:** Keep it simple for unique pages
|
||||
|
||||
### 🚩 Analysis Paralysis
|
||||
|
||||
**Sign:** Endless refinement cycles
|
||||
**Problem:** Never shipping
|
||||
**Solution:** Set "good enough" threshold
|
||||
|
||||
### 🚩 Tool Obsession
|
||||
|
||||
**Sign:** Using Figma because you can, not because you should
|
||||
**Problem:** Process over progress
|
||||
**Solution:** Focus on outcomes, not tools
|
||||
|
||||
---
|
||||
|
||||
## Decision Matrix
|
||||
|
||||
| Factor | Extract | Don't Extract |
|
||||
|--------|---------|---------------|
|
||||
| **Design System Maturity** | Empty/Growing | Mature |
|
||||
| **Visual Quality** | Needs polish | Sufficient |
|
||||
| **Component Coverage** | Gaps exist | Complete |
|
||||
| **Stakeholder Needs** | Presentation | Internal |
|
||||
| **Time Available** | 2-5 hours | < 1 hour |
|
||||
| **Page Importance** | High priority | Low priority |
|
||||
| **Iteration Phase** | First/Final | Middle |
|
||||
| **Team Size** | Collaborative | Solo |
|
||||
|
||||
**Score:** 5+ "Extract" factors → Extract to Figma
|
||||
**Score:** 5+ "Don't Extract" factors → Skip extraction
|
||||
|
||||
---
|
||||
|
||||
## Questions to Ask
|
||||
|
||||
Before deciding, ask yourself:
|
||||
|
||||
1. **Does the design system have what I need?**
|
||||
- Yes → Don't extract
|
||||
- No → Consider extracting
|
||||
|
||||
2. **Is this page important enough to polish?**
|
||||
- Yes → Extract
|
||||
- No → Skip
|
||||
|
||||
3. **Do I have 2-5 hours for refinement?**
|
||||
- Yes → Can extract
|
||||
- No → Skip
|
||||
|
||||
4. **Will this create reusable components?**
|
||||
- Yes → Extract (investment pays off)
|
||||
- No → Skip (one-off work)
|
||||
|
||||
5. **Is the concept validated?**
|
||||
- Yes → Safe to polish
|
||||
- No → Too early
|
||||
|
||||
6. **Do stakeholders need polished visuals?**
|
||||
- Yes → Extract
|
||||
- No → Skip
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO ✅
|
||||
|
||||
1. **Extract strategically**
|
||||
- First page in project
|
||||
- High-priority pages
|
||||
- When design system gaps identified
|
||||
|
||||
2. **Batch extractions**
|
||||
- Extract multiple pages together
|
||||
- Efficient use of time
|
||||
- Consistent design decisions
|
||||
|
||||
3. **Document decisions**
|
||||
- Why extracted
|
||||
- What was refined
|
||||
- Design system updates
|
||||
|
||||
4. **Set time limits**
|
||||
- Don't over-polish
|
||||
- Good enough is sufficient
|
||||
- Ship working products
|
||||
|
||||
### DON'T ❌
|
||||
|
||||
1. **Don't extract everything**
|
||||
- Selective extraction
|
||||
- Focus on high-value pages
|
||||
- Skip low-priority pages
|
||||
|
||||
2. **Don't extract too early**
|
||||
- Validate concepts first
|
||||
- Ensure functionality works
|
||||
- Don't polish throwaway work
|
||||
|
||||
3. **Don't extract too late**
|
||||
- Don't accumulate design debt
|
||||
- Address gaps early
|
||||
- Build design system progressively
|
||||
|
||||
4. **Don't extract without plan**
|
||||
- Know what needs refinement
|
||||
- Have clear goals
|
||||
- Update design system after
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
**Extract to Figma when:**
|
||||
- Design system is incomplete
|
||||
- Prototype needs visual polish
|
||||
- New components required
|
||||
- Stakeholder presentation needed
|
||||
- High-priority page
|
||||
- Time available for refinement
|
||||
|
||||
**Skip extraction when:**
|
||||
- Design system covers all needs
|
||||
- Prototype looks sufficient
|
||||
- Rapid iteration more important
|
||||
- Low-priority page
|
||||
- Time constrained
|
||||
- Early exploration phase
|
||||
|
||||
**Remember:** The goal is shipping polished, functional products. Extract strategically, not automatically.
|
||||
|
||||
---
|
||||
|
||||
**Use this guide to make informed decisions about when to invest time in Figma refinement versus moving forward with code-based prototypes.**
|
||||
@@ -0,0 +1,150 @@
|
||||
---
|
||||
name: 'step-00-define-purpose'
|
||||
description: 'Define the measurable job and purpose for content before generation begins'
|
||||
nextStepFile: './step-01-load-trigger-map-context.md'
|
||||
---
|
||||
|
||||
# Step 0: Define Content Purpose
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define a clear, testable purpose statement for the content to be created — answering what it must accomplish, for whom, and how success is measured — so that all subsequent strategic steps have a focused target.
|
||||
|
||||
## 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 a strategic content analyst guiding purpose definition
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring strategic content methodology, user brings their domain knowledge and context
|
||||
- ✅ Maintain a focused, outcome-oriented tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on defining the content's measurable job
|
||||
- 🚫 FORBIDDEN to generate any actual content text in this step
|
||||
- 💬 Push for specific, testable purpose statements — reject vague goals
|
||||
- 📋 Ensure model priority emphasis is discussed before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document purpose definition as structured output
|
||||
- 📖 Validate all five areas (context, job, audience, criteria, model priorities) before proceeding
|
||||
- 🚫 FORBIDDEN to proceed without a specific, outcome-focused purpose statement
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Project configuration, page specifications, design system
|
||||
- Focus: What job this content must do and for whom
|
||||
- Limits: Do not create content — only define its purpose
|
||||
- Dependencies: None — this is the first step in the content creation workflow
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Establish Content Context
|
||||
|
||||
Ask the user: **"What content are we creating?"**
|
||||
|
||||
Examples: Landing page hero section, Product comparison table, Error message for invalid email, CTA button on pricing page, About page mission statement.
|
||||
|
||||
### 2. Define the Job To Do
|
||||
|
||||
Ask: **"What must this content accomplish?"**
|
||||
|
||||
Guide toward outcome-focused statements, not descriptions:
|
||||
|
||||
**Good:** "Convince Problem Aware users that shelf life matters" / "Enable confident product selection between us and competitors" / "Remove final purchase barrier with risk reversal"
|
||||
|
||||
**Bad:** "Describe the product" / "Explain benefits" / "Make it sound good"
|
||||
|
||||
### 3. Identify Target Audience and State
|
||||
|
||||
Ask: **"Who will read this? What state are they in?"**
|
||||
|
||||
Be specific: persona type, awareness level, emotional/mental state when they encounter this content.
|
||||
|
||||
### 4. Establish Success Criteria
|
||||
|
||||
Ask: **"How will we know this content succeeded?"**
|
||||
|
||||
Define measurable or observable outcomes: "User recognizes themselves and continues reading" / "User can choose the right tier in < 30 seconds" / "User clicks CTA feeling confident, not anxious"
|
||||
|
||||
### 5. Discuss Model Priority Emphasis
|
||||
|
||||
Ask: **"Which strategic models matter most for THIS job?"**
|
||||
|
||||
Present the Model Priority Matrix from the Content Purpose Guide. Different content types emphasize different models (Customer Awareness, Golden Circle, Badass Users, Trigger Map, Action Mapping). Discuss and assign star ratings per model.
|
||||
|
||||
### 6. Document Purpose Definition
|
||||
|
||||
Compile all answers into a structured purpose definition:
|
||||
|
||||
```yaml
|
||||
content_purpose:
|
||||
content_type: "[e.g., Landing page hero, Error message, CTA button]"
|
||||
purpose_statement: "[Action verb] + [specific audience/state] + [desired outcome]"
|
||||
audience:
|
||||
who: "[User persona or type]"
|
||||
state: "[Mental/emotional state, awareness level]"
|
||||
context: "[When/where they encounter this content]"
|
||||
success_criteria:
|
||||
- "[Observable outcome 1]"
|
||||
- "[Observable outcome 2]"
|
||||
model_priorities:
|
||||
primary: ["[Model 1]", "[Model 2]"]
|
||||
secondary: ["[Model 3]"]
|
||||
tertiary: ["[Model 4]"]
|
||||
review_question: "[How will we know this achieved its purpose?]"
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save purpose definition, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the purpose definition is documented will you load {nextStepFile} to begin loading Trigger Map context.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Content type/context is clear
|
||||
- Purpose is specific and outcome-focused (not vague)
|
||||
- Audience and their state are defined
|
||||
- Success criteria are measurable or observable
|
||||
- Model priorities are selected based on purpose
|
||||
- Purpose statement is documented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Accepting vague purpose statements like "describe the product"
|
||||
- Generating actual content text in this step
|
||||
- Skipping model priority discussion
|
||||
- Proceeding without documented success criteria
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
name: 'step-01-load-trigger-map-context'
|
||||
description: 'Establish the strategic foundation by loading relevant Trigger Map context for content creation'
|
||||
nextStepFile: './step-02-awareness-strategy.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Trigger Map Context
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load the relevant Trigger Map context — WHO we are serving, WHAT motivates them, and WHERE they are in their awareness journey — so that all content decisions are anchored in strategy, not guesswork.
|
||||
|
||||
## 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 a strategic content analyst loading the Trigger Map foundation
|
||||
- If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- We engage in collaborative dialogue, not command-response
|
||||
- You bring strategic methodology, user brings their project knowledge
|
||||
- Maintain a thorough, investigative tone — the context must be correct before proceeding
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- Focus ONLY on loading and validating the Trigger Map context
|
||||
- FORBIDDEN to generate content text or apply awareness strategy in this step
|
||||
- If no Trigger Map exists, flag the gap and work with whatever context is available
|
||||
- Ensure all fields are populated before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- Follow the Sequence of Instructions exactly
|
||||
- Document Trigger Map context for traceability
|
||||
- Check for Trigger Map in project documentation before asking user
|
||||
- FORBIDDEN to proceed without confirmed strategic context
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Purpose definition from Step 0, project configuration
|
||||
- Focus: Loading and validating the correct Trigger Map context for this content
|
||||
- Limits: Do not apply the context yet — just load and confirm it
|
||||
- Dependencies: Purpose definition from Step 0
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load the Trigger Map
|
||||
|
||||
Search project documentation:
|
||||
- Check `{output_folder}/B-Trigger-Map/00-trigger-map.md` (the hub document)
|
||||
- Check persona documents in `{output_folder}/B-Trigger-Map/`
|
||||
- If no Trigger Map folder exists, check Product Brief for business context
|
||||
|
||||
### 2. Identify the Relevant Context
|
||||
|
||||
Ask: **"Which business goal and persona does this content serve?"**
|
||||
|
||||
- Present the business goals from the Trigger Map — which one applies?
|
||||
- Present the personas — which one is the target audience for this content?
|
||||
- Present driving forces for that persona — which are most relevant?
|
||||
|
||||
### 3. Present and Confirm Context
|
||||
|
||||
Display the selected context:
|
||||
|
||||
```
|
||||
Business Goal: [selected goal from Trigger Map]
|
||||
Persona: [persona name and description]
|
||||
Driving Forces:
|
||||
- Positive: [relevant positive drivers]
|
||||
- Negative: [relevant negative drivers]
|
||||
Customer Awareness: [START level] → [END level]
|
||||
```
|
||||
|
||||
Ask: **"Is this the right strategic context for this content? Any adjustments?"**
|
||||
|
||||
### 4. Handle Missing Trigger Map
|
||||
|
||||
If no Trigger Map exists:
|
||||
- Explain that the Trigger Map (Phase 2) provides the strategic foundation for content
|
||||
- Recommend completing Phase 2 first for best results
|
||||
- If the user wants to proceed anyway, use whatever context is available from the Product Brief
|
||||
- Note the gap and flag that content may need revision after the Trigger Map is completed
|
||||
|
||||
### 5. Document Context
|
||||
|
||||
Save the confirmed context:
|
||||
|
||||
```yaml
|
||||
trigger_map_context:
|
||||
business_goal: "[goal text]"
|
||||
persona:
|
||||
name: "[persona name]"
|
||||
description: "[brief persona description]"
|
||||
driving_forces:
|
||||
positive: "[relevant positive drivers]"
|
||||
negative: "[relevant negative drivers]"
|
||||
customer_awareness:
|
||||
start: "[awareness level where user begins]"
|
||||
end: "[awareness level we want them to reach]"
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save context, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the Trigger Map context is confirmed and documented will you load {nextStepFile} to begin applying the Customer Awareness Strategy.
|
||||
|
||||
---
|
||||
|
||||
## SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### SUCCESS:
|
||||
|
||||
- Trigger Map context is identified and loaded
|
||||
- All fields are populated (goal, persona, driving forces, awareness)
|
||||
- User confirms this is the correct context for this content
|
||||
- Context is documented for traceability
|
||||
|
||||
### FAILURE:
|
||||
|
||||
- Proceeding without confirmed strategic context
|
||||
- Generating content text in this step
|
||||
- Applying awareness strategy before context is loaded
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,167 @@
|
||||
---
|
||||
name: 'step-02-awareness-strategy'
|
||||
description: 'Apply Customer Awareness Cycle to determine language, information, and proof strategy'
|
||||
nextStepFile: './step-03-action-filter.md'
|
||||
---
|
||||
|
||||
# Step 2: Apply Customer Awareness Strategy
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Translate the Trigger Map's awareness positioning into a concrete content strategy — determining what language the user can understand, what information they need, what proof is required, and what emotional journey we are facilitating.
|
||||
|
||||
## 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 a strategic content analyst applying the Customer Awareness Cycle
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring awareness level methodology, user brings audience insight
|
||||
- ✅ Maintain an empathetic, audience-focused tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on awareness strategy — language, information, proof, emotion
|
||||
- 🚫 FORBIDDEN to generate actual content text in this step
|
||||
- 💬 Explore each awareness dimension collaboratively with the user
|
||||
- 📋 All six areas must be addressed before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document the awareness strategy in structured format
|
||||
- 📖 Reference the 5 awareness levels (Unaware, Problem Aware, Solution Aware, Product Aware, Most Aware)
|
||||
- 🚫 FORBIDDEN to proceed without a complete awareness strategy
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Purpose definition (Step 0), Trigger Map context (Step 1)
|
||||
- Focus: Translating awareness levels into content strategy decisions
|
||||
- Limits: Do not write content — define the strategy for it
|
||||
- Dependencies: Confirmed Trigger Map with awareness START and END levels
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Validate Starting Awareness Level
|
||||
|
||||
Present the START level from the Trigger Map and describe what it means. Confirm with user: does this match where users are when they encounter this content?
|
||||
|
||||
### 2. Clarify Target Awareness Level
|
||||
|
||||
Present the END level from the Trigger Map and describe the shift. Confirm: is this the right awareness goal for this content?
|
||||
|
||||
### 3. Determine Awareness-Appropriate Language
|
||||
|
||||
Explore together: What words will resonate vs. confuse at their starting level?
|
||||
|
||||
- Problem Aware: Speak in problem language first, product names later
|
||||
- Solution Aware: Can use solution category terminology
|
||||
- Product Aware: Specific features and comparisons matter
|
||||
|
||||
### 4. Define Information Priorities
|
||||
|
||||
What do they NEED to know at this stage?
|
||||
|
||||
- Problem Aware: Problem validation, emotional recognition, hint solutions exist
|
||||
- Solution Aware: How solutions work, what makes them good/bad
|
||||
- Product Aware: Specific features, proof, competitive comparison
|
||||
|
||||
Separate essential from overwhelming.
|
||||
|
||||
### 5. Identify Credibility Requirements
|
||||
|
||||
What proof do they need to believe us?
|
||||
|
||||
- Problem Aware: Personal stories, emotional validation
|
||||
- Solution Aware: Expert credentials, how-it-works explanations
|
||||
- Product Aware: Social proof, testimonials, data, comparisons
|
||||
|
||||
### 6. Map Emotional Journey
|
||||
|
||||
What emotional shift happens from START to END?
|
||||
|
||||
- Starting emotion: How they feel at START level
|
||||
- Ending emotion: How they should feel at END level
|
||||
- The emotional bridge we are building
|
||||
|
||||
### 7. Document Awareness Strategy
|
||||
|
||||
```yaml
|
||||
awareness_strategy:
|
||||
start_level: "[awareness level]"
|
||||
start_characteristics:
|
||||
- "[what they know]"
|
||||
- "[what they don't know]"
|
||||
- "[how they feel]"
|
||||
end_level: "[awareness level]"
|
||||
end_characteristics:
|
||||
- "[what they'll know]"
|
||||
- "[what they'll understand]"
|
||||
- "[how they'll feel]"
|
||||
language_guidelines:
|
||||
use: ["[appropriate terms]"]
|
||||
avoid: ["[confusing jargon]"]
|
||||
tone: "[conversational, authoritative, empathetic, etc.]"
|
||||
information_priorities:
|
||||
essential: ["[must include]"]
|
||||
helpful: ["[nice to include if space]"]
|
||||
avoid: ["[too advanced, confusing, or premature]"]
|
||||
credibility_required:
|
||||
type: "[personal story, expert credentials, data, social proof]"
|
||||
examples: ["[specific proof elements]"]
|
||||
emotional_journey:
|
||||
starting_emotion: "[frustrated, confused, etc.]"
|
||||
bridge: "[how we facilitate the shift]"
|
||||
ending_emotion: "[hopeful, confident, etc.]"
|
||||
```
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save awareness strategy, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the awareness strategy is fully documented will you load {nextStepFile} to begin defining the required action.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Start awareness level confirmed and understood
|
||||
- End awareness level confirmed and understood
|
||||
- Appropriate language identified (what words to use/avoid)
|
||||
- Information priorities clear (what to include/exclude)
|
||||
- Credibility requirements identified
|
||||
- Emotional journey mapped
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating content text in this step
|
||||
- Skipping any of the six awareness dimensions
|
||||
- Not confirming awareness levels with user
|
||||
- Proceeding without documented strategy
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
name: 'step-03-action-filter'
|
||||
description: 'Apply Action Mapping to define the required user action and filter content for relevance'
|
||||
nextStepFile: './step-04-empowerment-frame.md'
|
||||
---
|
||||
|
||||
# Step 3: Define Required Action
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Apply Action Mapping (Cathy Moore) to identify the specific action the user must be able to take after reading this content, and use that to filter what information is truly necessary versus nice-to-know fluff.
|
||||
|
||||
## 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 a strategic content analyst applying Action Mapping methodology
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring action-focused filtering methodology, user brings domain context
|
||||
- ✅ Maintain a sharp, purposeful tone — challenge anything that does not serve the action
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on identifying the required action and filtering information
|
||||
- 🚫 FORBIDDEN to generate content text in this step
|
||||
- 💬 Push for specific behavioral actions, not vague "understanding"
|
||||
- 📋 Challenge nice-to-know content that does not enable the action
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document the action filter in structured format
|
||||
- 📖 Work backward from action to essential information
|
||||
- 🚫 FORBIDDEN to proceed without a specific action and information filter
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Purpose (Step 0), Trigger Map (Step 1), Awareness Strategy (Step 2)
|
||||
- Focus: What action must the user take, and what information enables it
|
||||
- Limits: Do not write content — filter what information to include
|
||||
- Dependencies: Trigger Map and Awareness Strategy from previous steps
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Identify the Required Action
|
||||
|
||||
Ask: **"After reading this content, what must the user be able to DO?"**
|
||||
|
||||
Push for specific behaviors, not vague understanding:
|
||||
|
||||
**Good:** "Click the signup button with confidence" / "Choose the right pricing tier" / "Complete the first onboarding step"
|
||||
|
||||
**Bad:** "Understand our features" / "Learn about our company" / "Be aware of the benefits"
|
||||
|
||||
### 2. Connect Action to Business Goal
|
||||
|
||||
Trace the logic: User does [action] → which leads to [outcome] → which drives [business goal from Trigger Map].
|
||||
|
||||
Ask: **"Does this action clearly serve the Trigger Map's business goal?"**
|
||||
|
||||
### 3. Connect Action to Driving Forces
|
||||
|
||||
From the Trigger Map driving forces: **"By taking this action, how does the user move toward their wish or away from their fear?"**
|
||||
|
||||
### 4. Determine Essential Information
|
||||
|
||||
Work backward from the action:
|
||||
- To do the action, the user must understand X
|
||||
- To understand X, they need to know Y
|
||||
- To know Y, we must tell them Z
|
||||
|
||||
Ask: **"What can we cut without preventing the action?"** Strip away everything else.
|
||||
|
||||
### 5. Identify Action Barriers
|
||||
|
||||
Ask: **"What might prevent the user from taking this action?"**
|
||||
|
||||
Common barriers: Confusion, Fear, Effort, Distrust, Irrelevance.
|
||||
|
||||
For each barrier, identify what content removes it.
|
||||
|
||||
### 6. Document Action Filter
|
||||
|
||||
```yaml
|
||||
action_filter:
|
||||
required_action:
|
||||
description: "[Specific action user must be able to take]"
|
||||
success_criteria: "[How we know they can do it]"
|
||||
business_impact:
|
||||
connection: "[How this action drives the business goal]"
|
||||
logic: "[Action → Outcome → Goal]"
|
||||
user_motivation:
|
||||
positive_driver: "[How action satisfies their wish]"
|
||||
negative_driver: "[How action addresses their fear]"
|
||||
essential_information:
|
||||
- "[Information element 1 — WHY needed for action]"
|
||||
- "[Information element 2 — WHY needed for action]"
|
||||
- "[Information element 3 — WHY needed for action]"
|
||||
cut_list:
|
||||
- "[Nice-to-know info that doesn't enable action]"
|
||||
- "[Impressive but irrelevant content]"
|
||||
action_barriers:
|
||||
- barrier: "[e.g., confusion about next steps]"
|
||||
solution: "[Content that removes this barrier]"
|
||||
- barrier: "[e.g., fear of commitment]"
|
||||
solution: "[Content that addresses this fear]"
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save action filter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the action filter is documented will you load {nextStepFile} to begin framing user empowerment.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Specific action identified (not vague "understanding")
|
||||
- Action connects to Trigger Map business goal
|
||||
- Action satisfies user's driving forces
|
||||
- Essential information determined (what enables the action)
|
||||
- Unnecessary information identified (what does not enable action)
|
||||
- Action barriers identified and addressed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Accepting vague goals like "learn about us"
|
||||
- Generating content text in this step
|
||||
- Not challenging nice-to-know content
|
||||
- Proceeding without a specific required action
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,167 @@
|
||||
---
|
||||
name: 'step-04-empowerment-frame'
|
||||
description: 'Apply Badass Users principles to frame content around user capability and transformation'
|
||||
nextStepFile: './step-05-structural-order.md'
|
||||
---
|
||||
|
||||
# Step 4: Frame User Empowerment
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Apply Kathy Sierra's Badass Users framework to frame content around user capability and transformation — making users feel capable, showing their transformation path, creating "aha moments," and reducing cognitive load.
|
||||
|
||||
## 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 a strategic content analyst applying Badass Users methodology
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring empowerment framing expertise, user brings their audience understanding
|
||||
- ✅ Maintain a user-centric, empowering tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on empowerment framing — transformation, capability, cognitive load
|
||||
- 🚫 FORBIDDEN to generate content text in this step
|
||||
- 💬 Reframe all feature-focused language to capability-focused language
|
||||
- 📋 All five Badass Users principles must be addressed
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document empowerment framing in structured format
|
||||
- 📖 Reference Badass Users principles data file when needed
|
||||
- 🚫 FORBIDDEN to proceed without transformation and capability framing defined
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Purpose (Step 0), Trigger Map (Step 1), Awareness (Step 2), Action Filter (Step 3)
|
||||
- Focus: Framing content around user capability, not product features
|
||||
- Limits: Do not write content — define the empowerment frame for it
|
||||
- Dependencies: Action Filter from Step 3
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Define Current vs. Badass State
|
||||
|
||||
Ask: **"What's the user's CURRENT state?"** — What are they struggling with? How do they feel?
|
||||
|
||||
Ask: **"What's their BADASS state after success?"** — What will they be able to do? How will they feel?
|
||||
|
||||
### 2. Identify the "Aha Moment"
|
||||
|
||||
Ask: **"What insight or realization will make them say 'Oh! I get it!'?"**
|
||||
|
||||
The aha moment is a perspective shift, not just understanding. It unlocks confidence.
|
||||
|
||||
### 3. Frame Around Capability
|
||||
|
||||
Ask: **"How do we frame this content to highlight THEIR capability, not our features?"**
|
||||
|
||||
Transform feature-focused language to capability-focused language:
|
||||
- Before: "Our AI analyzes 10,000 sources"
|
||||
- After: "You'll spot trends before your competitors"
|
||||
|
||||
### 4. Show the Transformation Path
|
||||
|
||||
Ask: **"How do we make the transformation visible and achievable?"**
|
||||
|
||||
Users need to see where they are, where they are going, and that the path is real and manageable. Use specific numbers, social proof, and quick wins.
|
||||
|
||||
### 5. Reduce Cognitive Load
|
||||
|
||||
Ask: **"Where might this content overwhelm or confuse?"**
|
||||
|
||||
Look for: too many choices, too much jargon, too many steps, unclear next actions. Identify what to simplify or cut.
|
||||
|
||||
### 6. Focus on Skills Over Tools
|
||||
|
||||
Ask: **"What skill or capability are we helping them develop?"**
|
||||
|
||||
Not "using our platform" but "staying current effortlessly" or "becoming the local authority."
|
||||
|
||||
### 7. Document Empowerment Frame
|
||||
|
||||
```yaml
|
||||
empowerment_frame:
|
||||
transformation:
|
||||
current_state:
|
||||
description: "[Where user is now]"
|
||||
feelings: ["frustrated", "uncertain", "behind"]
|
||||
capabilities: "[What they can't do yet]"
|
||||
badass_state:
|
||||
description: "[Where they're going]"
|
||||
feelings: ["confident", "capable", "ahead"]
|
||||
capabilities: "[What they'll be able to do]"
|
||||
visibility: "[How we make the transformation visible and achievable]"
|
||||
aha_moment:
|
||||
insight: "[Key realization that shifts perspective]"
|
||||
why_powerful: "[Why this unlocks confidence]"
|
||||
capability_framing:
|
||||
- feature: "[Product feature]"
|
||||
reframed: "[What USER can do because of it]"
|
||||
- feature: "[Product feature]"
|
||||
reframed: "[What USER can do because of it]"
|
||||
cognitive_load:
|
||||
potential_issues:
|
||||
- issue: "[Where content might overwhelm]"
|
||||
solution: "[How we reduce load]"
|
||||
simplifications:
|
||||
- "[What we simplified or cut]"
|
||||
skill_focus:
|
||||
primary_skill: "[Main capability user develops]"
|
||||
supporting_skills: ["[Related capabilities]"]
|
||||
tools_secondary: "[Tools are means to skill, not the focus]"
|
||||
```
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save empowerment frame, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the empowerment frame is documented will you load {nextStepFile} to begin determining structural order.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Current state clearly defined
|
||||
- Badass state clearly defined
|
||||
- "Aha moment" identified
|
||||
- Content framed around user capability (not features)
|
||||
- Transformation path visible and achievable
|
||||
- Cognitive load issues identified and addressed
|
||||
- Focus on skills gained, not tools used
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating content text in this step
|
||||
- Leaving content framed around product features
|
||||
- Not identifying the "aha moment"
|
||||
- Skipping cognitive load analysis
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,174 @@
|
||||
---
|
||||
name: 'step-05-structural-order'
|
||||
description: 'Apply the Golden Circle to create persuasive WHY-HOW-WHAT content flow'
|
||||
nextStepFile: './step-06-generate-content.md'
|
||||
---
|
||||
|
||||
# Step 5: Determine Structural Order
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Apply Simon Sinek's Golden Circle to sequence all content from previous steps into a persuasive WHY-HOW-WHAT flow that moves users emotionally first, then logically, then to action.
|
||||
|
||||
## 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 a strategic content architect applying Golden Circle methodology
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring structural persuasion expertise, user brings their content priorities
|
||||
- ✅ Maintain a clear, structured tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on sequencing content into WHY-HOW-WHAT structure
|
||||
- 🚫 FORBIDDEN to generate final content text in this step
|
||||
- 💬 Map all essential information from previous steps to WHY, HOW, or WHAT
|
||||
- 📋 Validate the persuasive flow end-to-end before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document the structural order in structured format
|
||||
- 📖 Reference all content elements from Steps 3-4 (Action Filter + Empowerment Frame)
|
||||
- 🚫 FORBIDDEN to proceed without a validated WHY-HOW-WHAT structure
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Purpose (Step 0), Trigger Map (Step 1), Awareness (Step 2), Action Filter (Step 3), Empowerment Frame (Step 4)
|
||||
- Focus: Sequencing existing content elements into persuasive order
|
||||
- Limits: Do not write final content — organize the structure for it
|
||||
- Dependencies: All previous steps provide the content elements to sequence
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Identify the WHY
|
||||
|
||||
Ask: **"What's the emotional opening that connects to their driving forces?"**
|
||||
|
||||
Opens with user's current emotional state, connects to driving forces from the Trigger Map, makes them care before explaining the solution.
|
||||
|
||||
### 2. Identify the HOW
|
||||
|
||||
Ask: **"What's the method that bridges emotional need to specific solution?"**
|
||||
|
||||
Explains the approach, shows how transformation happens, uses capability framing from Step 4, contains the "aha moment" insight.
|
||||
|
||||
### 3. Identify the WHAT
|
||||
|
||||
Ask: **"What are the concrete specifics and call to action?"**
|
||||
|
||||
Names the product/offer, provides social proof, clear CTA with capability framing, risk removal.
|
||||
|
||||
### 4. Map Content to Structure
|
||||
|
||||
Present all content elements from Steps 3-4. Work together to assign each piece to WHY (emotional opening), HOW (method/bridge), or WHAT (specifics/proof).
|
||||
|
||||
### 5. Sequence Within Sections
|
||||
|
||||
Within each section, determine the most persuasive order:
|
||||
|
||||
- **WHY section:** Problem → Validation → Aspiration
|
||||
- **HOW section:** Approach → Differentiator → Transformation
|
||||
- **WHAT section:** Naming → Proof → Action → Risk Removal
|
||||
|
||||
### 6. Validate Persuasive Flow
|
||||
|
||||
Ask: **"Does WHY → HOW → WHAT create natural emotional → logical → action flow?"**
|
||||
|
||||
- Can user understand WHY without knowing WHAT yet?
|
||||
- Does HOW bridge the gap naturally?
|
||||
- Does WHAT feel like a natural conclusion (not premature)?
|
||||
|
||||
### 7. Document Structural Order
|
||||
|
||||
```yaml
|
||||
structural_order:
|
||||
section_why:
|
||||
purpose: "Emotional truth / Why user should care"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "[Opening hook]"
|
||||
rationale: "[Why this opens]"
|
||||
- order: 2
|
||||
element: "[Validation or aspiration]"
|
||||
rationale: "[Why this comes second]"
|
||||
section_how:
|
||||
purpose: "Method / Bridge from emotion to specifics"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "[Solution approach]"
|
||||
rationale: "[Why this bridges first]"
|
||||
- order: 2
|
||||
element: "[Key differentiator]"
|
||||
rationale: "[Why this matters here]"
|
||||
- order: 3
|
||||
element: "[Transformation path]"
|
||||
rationale: "[Why this comes last in HOW]"
|
||||
section_what:
|
||||
purpose: "Specifics / Proof / Action"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "[Product/offer name]"
|
||||
rationale: "[Why we can name it now]"
|
||||
- order: 2
|
||||
element: "[Social proof]"
|
||||
rationale: "[Why proof comes here]"
|
||||
- order: 3
|
||||
element: "[CTA]"
|
||||
rationale: "[Why action comes last]"
|
||||
flow_validation:
|
||||
feels_natural: "[yes/no + notes]"
|
||||
persuasive_arc: "[Does WHY → HOW → WHAT create emotional → logical → action flow?]"
|
||||
```
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save structural order, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the structural order is documented will you load {nextStepFile} to begin generating and reviewing content.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- WHY is identified (emotional opening, purpose)
|
||||
- HOW is identified (method, bridge, differentiator)
|
||||
- WHAT is identified (specifics, proof, CTA)
|
||||
- All essential information assigned to WHY, HOW, or WHAT
|
||||
- Content sequenced within each section
|
||||
- Flow feels natural and persuasive
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating final content text in this step
|
||||
- Putting WHAT before WHY (salesy, pushy)
|
||||
- Missing the WHY section entirely (cold, transactional)
|
||||
- Not mapping all essential information to a section
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
name: 'step-06-generate-content'
|
||||
description: 'Generate strategically grounded content variations, review, and finalize'
|
||||
workflowFile: '../workflow.md'
|
||||
---
|
||||
|
||||
# Step 6: Generate and Review Content
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate 2-3 strategically grounded content variations based on all strategic context from Steps 0-5, guide user through selection and refinement, and produce the final content with full strategic traceability.
|
||||
|
||||
## 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 a strategic content creator synthesizing all previous analysis
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring content synthesis expertise, user brings final creative direction
|
||||
- ✅ Maintain a creative yet strategic tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Generate content variations that differ in driving force emphasis, not random rewrites
|
||||
- 🚫 FORBIDDEN to skip strategic traceability in the final output
|
||||
- 💬 Present each variation with clear rationale for strategic choices
|
||||
- 📋 Verify final content against all strategic context (Steps 0-5)
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Save final content with strategic traceability using content-output template
|
||||
- 📖 Reference generation instructions data file for detailed variation guidance
|
||||
- 🚫 FORBIDDEN to finalize without user review and confirmation
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All outputs from Steps 0-5 (Purpose, Trigger Map, Awareness, Action, Empowerment, Structure)
|
||||
- Focus: Synthesizing strategy into actual content text, then refining with user
|
||||
- Limits: Variations are strategic alternatives, not random drafts
|
||||
- Dependencies: Complete WHY-HOW-WHAT structure from Step 5
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Synthesize All Context
|
||||
|
||||
Review and synthesize all strategic outputs from Steps 0-5 before generating.
|
||||
|
||||
### 2. Generate 2-3 Variations
|
||||
|
||||
Create variations that differ in which driving forces they emphasize:
|
||||
- **Variation A (Wish-focused):** Emphasizes positive driving force / aspiration
|
||||
- **Variation B (Fear-focused):** Emphasizes negative driving force / pain avoidance
|
||||
- **Variation C (Balanced):** Blends both, may shift awareness emphasis
|
||||
|
||||
Present each with clear rationale explaining strategic choices.
|
||||
|
||||
### 3. Gather Initial Reaction
|
||||
|
||||
Ask: **"Which variation resonates most with you?"** Allow selection, combination, or element picking across variations.
|
||||
|
||||
### 4. Alignment Check
|
||||
|
||||
Ask: **"Does this feel aligned with the strategic context?"**
|
||||
|
||||
Check against: Trigger Map business goal, driving forces, awareness level, required action, capability framing, WHY-HOW-WHAT structure.
|
||||
|
||||
### 5. Refinement
|
||||
|
||||
Ask: **"What would you adjust or combine?"** Guide through specific changes: headline from A but body from B, stronger emphasis on X, softer tone on Y.
|
||||
|
||||
### 6. Verify Completeness
|
||||
|
||||
Ask: **"Is anything missing that we identified in previous steps?"** Check against essential information (Step 3), barriers (Step 3), aha moment (Step 4), cognitive load reductions (Step 4).
|
||||
|
||||
### 7. Validate Awareness Journey
|
||||
|
||||
Ask: **"Does this move the user from START to END awareness?"** Verify the journey is smooth, not jarring.
|
||||
|
||||
### 8. Document Final Content
|
||||
|
||||
Save using content-output template with full strategic traceability:
|
||||
- Trigger Map reference, awareness journey, action enabled, empowerment achieved
|
||||
- Implementation notes (technical, design, language tags, asset needs)
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF M: Save final content, update design log, return to Activity Menu in {workflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#9-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- User can chat or ask questions — always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step of the Content Creation workflow. When M is selected and final content is saved with traceability, return to the Activity Menu.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Multiple variations generated with clear rationale
|
||||
- Strategic choices explained and visible
|
||||
- User reviewed and selected/combined approach
|
||||
- Final content aligns with all strategic context (Steps 0-5)
|
||||
- Required action is enabled
|
||||
- Awareness journey is smooth
|
||||
- Strategic traceability documented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating only one variation without alternatives
|
||||
- Not explaining strategic choices per variation
|
||||
- Skipping traceability documentation
|
||||
- Finalizing without user confirmation
|
||||
- Not checking against all previous step outputs
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
name: 'step-01-connection-check'
|
||||
description: 'Verify html.to.design MCP server connection and guide setup if needed'
|
||||
nextStepFile: './step-02-identify-export-type.md'
|
||||
---
|
||||
|
||||
# Step 1: Connection Check and Installation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Verify that the html.to.design MCP server is connected and functional before proceeding with the Figma export workflow, guiding the user through setup if needed.
|
||||
|
||||
## 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 a technical integration specialist verifying the Figma export pipeline
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring MCP integration expertise, user brings their Figma environment setup
|
||||
- ✅ Maintain a helpful, technical tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on verifying MCP tool availability and connection
|
||||
- 🚫 FORBIDDEN to proceed to export without verified connection
|
||||
- 💬 If tool is not available, guide through setup or suggest alternative
|
||||
- 📋 A successful test export must be confirmed before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Record connection status
|
||||
- 📖 Reference Figma Plugin Setup Guide if setup is needed
|
||||
- 🚫 FORBIDDEN to skip connection verification
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Project configuration, MCP tool availability
|
||||
- Focus: Verifying html.to.design MCP server connection
|
||||
- Limits: Do not start any export work — just verify the connection
|
||||
- Dependencies: Figma account with project access, html.to.design plugin
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Check MCP Tool Availability
|
||||
|
||||
Check if `mcp2_import-html` tool is accessible in current session. Tool should be from "html.to.design MCP server."
|
||||
|
||||
- If tool available: Skip to step 4 (verification)
|
||||
- If tool not available: Continue with setup guidance
|
||||
|
||||
### 2. Guide Setup (If Needed)
|
||||
|
||||
Inform user that setup requires:
|
||||
1. Figma account with project access
|
||||
2. html.to.design plugin installed in Figma
|
||||
3. MCP server configured in IDE
|
||||
|
||||
Ask: **"Would you like me to guide you through the setup process?"**
|
||||
|
||||
- If Yes: Reference the Figma Plugin Setup Guide at `../data/figma-plugin-setup.md`
|
||||
- If No: Stop workflow, suggest alternative approach
|
||||
|
||||
### 3. Verify After Setup
|
||||
|
||||
Once setup is complete, return to verification.
|
||||
|
||||
### 4. Execute Test Export
|
||||
|
||||
Execute a test export to verify connection:
|
||||
|
||||
```javascript
|
||||
mcp2_import-html({
|
||||
name: "Connection Test",
|
||||
html: "<div style='padding: 20px; background: #f0f0f0; border-radius: 8px; font-family: sans-serif;'>Connection Test Successful</div>"
|
||||
})
|
||||
```
|
||||
|
||||
Ask: **"Can you see the 'Connection Test' layer in your Figma file?"**
|
||||
|
||||
- If Yes: Connection verified
|
||||
- If No: Execute troubleshooting steps
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Record connection as verified, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the connection is verified will you load {nextStepFile} to begin identifying the export type.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- MCP tool availability checked
|
||||
- Connection verified with test export
|
||||
- User confirms test layer visible in Figma
|
||||
- Setup guidance provided if needed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding to export without verified connection
|
||||
- Not offering setup guidance when tool is unavailable
|
||||
- Skipping test export verification
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,108 @@
|
||||
---
|
||||
name: 'step-02-identify-export-type'
|
||||
description: 'Determine the code-to-Figma export scenario type for proper ID naming and structure'
|
||||
nextStepFile: './step-03-prepare-specifications.md'
|
||||
---
|
||||
|
||||
# Step 2: Identify Code to Figma Type
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Determine which code-to-Figma export scenario applies to the current request — Prototype Page, Design System Component, or Frontend View/Component Block — to ensure proper ID naming and structure.
|
||||
|
||||
## 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 a technical export specialist classifying the export scenario
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring export scenario expertise, user brings their specific export needs
|
||||
- ✅ Maintain a clear, analytical tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on identifying the export scenario type
|
||||
- 🚫 FORBIDDEN to start generating HTML or preparing specifications
|
||||
- 💬 Confirm scenario type with user before proceeding
|
||||
- 📋 Document the selected scenario and its ID naming pattern
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document selected scenario type and ID naming pattern
|
||||
- 📖 Use the decision tree to classify the request
|
||||
- 🚫 FORBIDDEN to proceed without user confirmation of scenario type
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Verified MCP connection, user's export request
|
||||
- Focus: Classifying the export into one of three scenario types
|
||||
- Limits: Do not start HTML generation — just classify and confirm
|
||||
- Dependencies: Verified connection from Step 1
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Analyze User Request
|
||||
|
||||
Examine the user's request and extract: component/page name, scope (full page vs. component vs. block), purpose (design system, prototype, visual adjustment), states/variations mentioned.
|
||||
|
||||
### 2. Apply Decision Tree
|
||||
|
||||
- Full page/screen, multiple sections, user flow → **Scenario A: Prototype Page Export** (ID: `{page}-{section}-{element}`)
|
||||
- Component states, design system docs, reusable component → **Scenario B: Design System Component** (ID: `{component}-{variant}-{state}`)
|
||||
- Visual adjustments, spacing iteration, specific UI block → **Scenario C: Frontend View/Component Block** (ID: `{component}-{element}-{descriptor}`)
|
||||
- Unclear → Ask user for clarification
|
||||
|
||||
### 3. Confirm with User
|
||||
|
||||
Present the identified scenario with its description, ID naming pattern, and expected outcome. Ask: **"Proceed with this scenario, or would you like to adjust the scope?"**
|
||||
|
||||
Wait for user confirmation.
|
||||
|
||||
### 4. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save scenario type and ID pattern, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the scenario type is confirmed will you load {nextStepFile} to begin preparing specifications.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Export request analyzed and classified
|
||||
- Scenario type confirmed with user
|
||||
- ID naming pattern documented
|
||||
- Expected outcome communicated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting HTML generation before scenario is confirmed
|
||||
- Not confirming scenario type with user
|
||||
- Using wrong ID naming pattern
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
name: 'step-03-prepare-specifications'
|
||||
description: 'Locate or create specifications with OBJECT IDs for consistent Figma layer naming'
|
||||
nextStepFile: './step-04-generate-validate.md'
|
||||
---
|
||||
|
||||
# Step 3: Prepare Specifications
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Locate existing specifications with OBJECT IDs for all components in the export scope, or create them if they do not exist, ensuring consistent Figma layer naming.
|
||||
|
||||
## 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 a specification analyst ensuring design-code parity through OBJECT IDs
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring specification methodology, user brings project context
|
||||
- ✅ Maintain a meticulous, detail-oriented tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on locating or creating specifications with OBJECT IDs
|
||||
- 🚫 FORBIDDEN to generate HTML in this step
|
||||
- 💬 Offer to reverse-engineer specifications from code if none exist
|
||||
- 📋 Achieve 100% specification coverage before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document specification coverage report
|
||||
- 📖 Search in `docs/C-UX-Scenarios/` and `docs/D-Design-System/` for existing specs
|
||||
- 🚫 FORBIDDEN to proceed without OBJECT IDs for all components
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Export scenario type, ID naming pattern from Step 2
|
||||
- Focus: Finding or creating OBJECT IDs for all components in scope
|
||||
- Limits: Do not generate HTML — just prepare the ID specifications
|
||||
- Dependencies: Confirmed scenario type from Step 2
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Search for Specification Documents
|
||||
|
||||
Search for specification files containing OBJECT IDs:
|
||||
- `docs/C-UX-Scenarios/` for scenario specifications
|
||||
- `docs/D-Design-System/` for component documentation
|
||||
- Search for files containing "OBJECT ID"
|
||||
- Look for markdown files matching component/page name
|
||||
|
||||
### 2. Handle Found Specifications
|
||||
|
||||
If specifications exist with OBJECT IDs: extract all OBJECT ID field values, map to components in code, store mapping for HTML generation.
|
||||
|
||||
### 3. Handle Missing Specifications
|
||||
|
||||
If no specifications exist, offer to:
|
||||
1. Analyze the code and reverse-engineer specifications
|
||||
2. Generate OBJECT IDs following project conventions
|
||||
3. Create a specification document for review
|
||||
|
||||
Reference `../data/figma-spec-preparation.md` for detailed guidance.
|
||||
|
||||
### 4. Validate Coverage
|
||||
|
||||
For each component in export scope, verify it has an OBJECT ID. Generate a coverage report showing validated components and any gaps.
|
||||
|
||||
### 5. Resolve Gaps
|
||||
|
||||
If partial coverage: offer to create missing specs or auto-generate IDs. Target 100% coverage before proceeding.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save specification mapping, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all components have OBJECT IDs will you load {nextStepFile} to begin generating and validating HTML.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Specification search completed across all relevant locations
|
||||
- OBJECT IDs found or created for all components
|
||||
- 100% specification coverage achieved
|
||||
- Coverage report presented to user
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting HTML generation without OBJECT IDs
|
||||
- Not searching all specification locations
|
||||
- Proceeding with partial coverage without user acknowledgment
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
name: 'step-04-generate-validate'
|
||||
description: 'Generate Figma-compatible HTML with OBJECT IDs and validate before export'
|
||||
nextStepFile: './step-05-execute-export.md'
|
||||
---
|
||||
|
||||
# Step 4: Generate and Validate
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate clean, Figma-compatible HTML with proper OBJECT IDs from specifications and validate all aspects — specification coverage, ID naming, structure, styling, and content — before the export is executed.
|
||||
|
||||
## 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 a technical HTML generation specialist for Figma export
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring HTML/CSS-to-Figma expertise, user brings design intent
|
||||
- ✅ Maintain a precise, quality-focused tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on generating validated HTML with correct OBJECT IDs
|
||||
- 🚫 FORBIDDEN to execute the export in this step — validation only
|
||||
- 💬 Present validation report and resolve errors before proceeding
|
||||
- 📋 All five validation checks must pass before export
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Generate HTML structure with proper IDs and styling
|
||||
- 📖 Convert all CSS variables to hex, rem/em to px, use Google Fonts only
|
||||
- 🚫 FORBIDDEN to proceed with validation errors unresolved
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Specification OBJECT IDs, scenario type, ID naming pattern
|
||||
- Focus: Generating HTML and validating it for Figma compatibility
|
||||
- Limits: Do not execute the MCP export — just generate and validate
|
||||
- Dependencies: Complete OBJECT ID mapping from Step 3
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Generate HTML Structure
|
||||
|
||||
Create root container, state/variant containers, apply OBJECT IDs from specification mapping, include state labels, use semantic HTML tags.
|
||||
|
||||
### 2. Apply Styling Requirements
|
||||
|
||||
Convert all styles to Figma-compatible CSS:
|
||||
- Fonts: Google Fonts only, imported in style block
|
||||
- Colors: Convert CSS variables to hex values
|
||||
- Spacing: Convert rem/em to pixels
|
||||
- Layout: Inline styles or style block, simple flexbox/grid only
|
||||
|
||||
### 3. Run Validation Checks
|
||||
|
||||
Execute five validation checks:
|
||||
1. **Specification Coverage:** All components have OBJECT IDs, IDs match exactly, no duplicates
|
||||
2. **ID Naming Convention:** IDs follow project pattern, consistent naming, correct state suffixes
|
||||
3. **HTML Structure:** Semantic tags, proper hierarchy, container elements
|
||||
4. **Styling Compatibility:** Google Fonts, hex colors, pixel values, clean markup
|
||||
5. **Content Completeness:** Text matches specifications, no placeholder content
|
||||
|
||||
### 4. Present Validation Report
|
||||
|
||||
Display pass/fail for each check, list any warnings and errors.
|
||||
|
||||
### 5. Handle Validation Failures
|
||||
|
||||
If errors found: offer auto-fix (CSS variables to hex, rem to px, missing IDs), guide manual fixes (structure issues, missing content), or allow skipping problematic components.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Confirm validation passes, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all validation checks pass will you load {nextStepFile} to execute the export.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- HTML generated with correct OBJECT IDs
|
||||
- All five validation checks pass
|
||||
- Figma-compatible styling applied
|
||||
- Validation report presented to user
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Executing export before validation passes
|
||||
- Using CSS variables instead of hex colors
|
||||
- Using rem/em instead of pixels
|
||||
- Proceeding with duplicate IDs
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: 'step-05-execute-export'
|
||||
description: 'Send validated HTML to Figma via MCP and verify the export succeeded'
|
||||
workflowFile: '../workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Send to Figma
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Execute the final export by sending validated HTML to Figma via MCP, verify the layers appear with proper OBJECT ID naming, and complete the Figma export workflow.
|
||||
|
||||
## 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 a technical export specialist executing and verifying the Figma delivery
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring MCP export expertise, user brings their Figma verification
|
||||
- ✅ Maintain a confident, delivery-focused tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on executing the export and verifying success in Figma
|
||||
- 🚫 FORBIDDEN to skip user verification of export in Figma
|
||||
- 💬 Provide troubleshooting guidance if export is not visible
|
||||
- 📋 Document complete export summary with details
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Record export details (node ID, component count, OBJECT IDs)
|
||||
- 📖 Wait for MCP response before asking user to verify
|
||||
- 🚫 FORBIDDEN to mark workflow complete without user confirming export visible
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Validated HTML, OBJECT IDs, scenario type
|
||||
- Focus: Executing the MCP export and verifying results
|
||||
- Limits: This is the final step — focus on delivery and verification
|
||||
- Dependencies: Validated HTML from Step 4
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Prepare Export Parameters
|
||||
|
||||
Set up MCP tool call: descriptive name for Figma layer (format: "{Component/Page Name} - {Purpose}"), complete validated HTML, optional intoNodeId for updating existing layer.
|
||||
|
||||
### 2. Execute Export
|
||||
|
||||
Call the MCP tool with prepared parameters. Wait for response.
|
||||
|
||||
### 3. Verify Export Response
|
||||
|
||||
Check response for success indicators: node ID returned, no error message, response contains node object.
|
||||
|
||||
### 4. User Verification
|
||||
|
||||
Ask: **"Please check your Figma file — can you see the export with proper layer names?"**
|
||||
|
||||
- If Yes: Proceed to success report
|
||||
- If No: Execute troubleshooting (check Figma is open, correct file active, layers panel, all pages, MCP connection)
|
||||
|
||||
### 5. Present Success Report
|
||||
|
||||
Display complete export details: name, node ID, component count, OBJECT IDs used, layer names in Figma.
|
||||
|
||||
### 6. Document Completion
|
||||
|
||||
Record: scenario type, components exported, OBJECT IDs used, specification files referenced, Figma output location.
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF M: Save export record, update design log, return to Activity Menu in {workflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- User can chat or ask questions — always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step of the Figma Export workflow. When M is selected and the export is verified, return to the Activity Menu.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Export executed via MCP without errors
|
||||
- User confirms export visible in Figma
|
||||
- Layer names match OBJECT IDs
|
||||
- Complete export summary documented
|
||||
- Design log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not verifying export with user
|
||||
- Marking complete when export failed
|
||||
- Not providing troubleshooting for invisible exports
|
||||
- Skipping export summary documentation
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: 'step-01-load-context'
|
||||
description: 'Load icon requirements from page specifications, design system, and existing icon references'
|
||||
nextStepFile: './step-02-inventory.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Context
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load all icon requirements from page specifications, design system icon tokens, and any existing icon assets — establishing the complete context needed for icon generation.
|
||||
|
||||
## 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 a creative production partner loading icon generation context
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring systematic asset context loading, user brings project specifics
|
||||
- ✅ Maintain a thorough, organized tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on loading and summarizing icon context
|
||||
- 🚫 FORBIDDEN to generate icons or select styles in this step
|
||||
- 💬 Identify every icon reference across all page specs
|
||||
- 📋 Present a clear context summary before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document context summary with counts and categories
|
||||
- 📖 Check `{output_folder}/E-Assets/icons/` for existing assets
|
||||
- 🚫 FORBIDDEN to skip any context source
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Project configuration, page specifications, design system
|
||||
- Focus: Loading all inputs needed for icon generation
|
||||
- Limits: Do not start generating or styling — just load context
|
||||
- Dependencies: Page specifications and design system must exist
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Icon Requirements
|
||||
|
||||
From page specs, identify every icon reference: navigation icons (menu, close, search, user, cart), action icons (edit, delete, save, share, download), status icons (success, warning, error, info), category/feature icons, social media icons, decorative icons.
|
||||
|
||||
### 2. Load Design System Icon Tokens
|
||||
|
||||
Read icon-related tokens: sizes (sm 16px, md 24px, lg 32px, xl 48px), stroke width (for outline style), color mode (monochrome or multicolor), container type (none, circle, rounded square).
|
||||
|
||||
### 3. Check Existing Icons
|
||||
|
||||
Scan `{output_folder}/E-Assets/icons/` for previously generated icons and check for external icon library references in the design system.
|
||||
|
||||
### 4. Present Context Summary
|
||||
|
||||
```
|
||||
Icon Context:
|
||||
- Total icons identified: [count]
|
||||
- Categories: [navigation, action, status, feature, social, decorative]
|
||||
- Existing icons: [count]
|
||||
- Icon size standard: [primary size]
|
||||
- Style direction: [outline/filled/duotone from design system]
|
||||
```
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save context summary, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and context is summarized will you load {nextStepFile} to begin building the icon inventory.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All icon references identified from page specs
|
||||
- Design system icon tokens loaded
|
||||
- Existing icons checked
|
||||
- Context summary presented with clear counts
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting icon generation without full context
|
||||
- Missing icon categories from page specs
|
||||
- Not checking for existing assets
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: 'step-02-inventory'
|
||||
description: 'Build a complete icon inventory organized by category, usage, and batch opportunity'
|
||||
nextStepFile: './step-03-select-style.md'
|
||||
---
|
||||
|
||||
# Step 2: Asset Inventory
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Build a complete, deduplicated icon inventory organized by category and usage, identifying batch opportunities and letting the user select the generation scope.
|
||||
|
||||
## 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 a creative production partner organizing icon inventory
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring systematic inventory methodology, user brings scope decisions
|
||||
- ✅ Maintain an organized, catalog-focused tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on cataloging and organizing icons for generation
|
||||
- 🚫 FORBIDDEN to generate icons or select styles in this step
|
||||
- 💬 Deduplicate icons used across multiple pages
|
||||
- 📋 Present generation scope options and wait for user selection
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document complete icon catalog with batch groups
|
||||
- 📖 Merge cross-page duplicates and note size variants
|
||||
- 🚫 FORBIDDEN to proceed without user scope selection
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Icon context from Step 1
|
||||
- Focus: Organizing icons into a generation-ready inventory
|
||||
- Limits: Do not generate or style — just catalog and organize
|
||||
- Dependencies: Context summary from Step 1
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Build Icon Catalog
|
||||
|
||||
Create a table: icon name, category, used on (pages), sizes needed.
|
||||
|
||||
### 2. Deduplicate
|
||||
|
||||
Merge icons used across multiple pages, note all size variations needed, identify similar icons that could share a base (arrow variants, etc.).
|
||||
|
||||
### 3. Estimate Batch Size
|
||||
|
||||
Count unique icons, size variants, total assets. Identify similar icon groups for batch generation (arrows, social, CRUD actions).
|
||||
|
||||
### 4. Present Inventory with Scope Options
|
||||
|
||||
```
|
||||
[A] All icons — Generate complete icon set
|
||||
[C] Category — Select specific categories
|
||||
[S] Select individual — Pick specific icons
|
||||
[P] Priority only — Navigation + action icons first
|
||||
```
|
||||
|
||||
Wait for user selection.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save inventory and scope selection, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and scope is confirmed will you load {nextStepFile} to begin selecting icon style.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Complete icon catalog built with all categories
|
||||
- Duplicates merged, size variants noted
|
||||
- Batch groups identified
|
||||
- User selected generation scope
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without inventory
|
||||
- Missing icons from page specs
|
||||
- Not deduplicating cross-page icons
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: 'step-03-select-style'
|
||||
description: 'Define the icon style including outline weight, fill treatment, grid, and color mode'
|
||||
nextStepFile: './step-04-generate.md'
|
||||
---
|
||||
|
||||
# Step 3: Select Style
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define the complete icon style — outline weight, fill treatment, grid alignment, and color mode — ensuring visual consistency rules are established before generation begins.
|
||||
|
||||
## 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 a creative production partner defining icon visual standards
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring icon design system expertise, user brings aesthetic preferences
|
||||
- ✅ Maintain a design-focused, precise tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on defining icon style parameters
|
||||
- 🚫 FORBIDDEN to generate any icons in this step
|
||||
- 💬 Present clear options for each style dimension
|
||||
- 📋 Confirm complete style configuration before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document complete icon style configuration
|
||||
- 📖 Align style choices with design system tokens
|
||||
- 🚫 FORBIDDEN to proceed without confirmed style
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Icon inventory (Step 2), design system tokens
|
||||
- Focus: Defining visual style rules for icon generation
|
||||
- Limits: Do not generate — just define the style
|
||||
- Dependencies: Icon inventory and scope from Step 2
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Select Icon Style
|
||||
|
||||
Present options: [O] Outline, [F] Filled, [D] Duotone, [G] Glyph. Wait for selection.
|
||||
|
||||
### 2. Configure Style Parameters
|
||||
|
||||
Based on selection, configure detailed parameters:
|
||||
- Outline: stroke width, line cap, line join, corner radius
|
||||
- Filled: fill style, corner radius
|
||||
- Duotone: primary color, secondary opacity
|
||||
|
||||
### 3. Define Grid and Alignment
|
||||
|
||||
Canvas size (e.g., 24x24 with 2px padding = 20x20 live area), pixel grid alignment, optical sizing rules.
|
||||
|
||||
### 4. Select Color Treatment
|
||||
|
||||
Present options: [M] Monochrome (currentColor), [B] Brand colors (category distinction), [F] Fixed color (specific hex per icon).
|
||||
|
||||
### 5. Confirm Style
|
||||
|
||||
Present complete configuration summary: style, parameters, grid, color, output format (SVG primary, PNG fallback).
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save style configuration, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and the style is confirmed will you load {nextStepFile} to begin generating icons.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Icon style selected and parameters configured
|
||||
- Grid and alignment rules defined
|
||||
- Color treatment selected
|
||||
- Complete style summary confirmed by user
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating icons without defined style
|
||||
- Not configuring detailed parameters for selected style
|
||||
- Skipping grid alignment definition
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: 'step-04-generate'
|
||||
description: 'Batch-generate icons with consistent style across the entire set'
|
||||
nextStepFile: './step-05-review.md'
|
||||
---
|
||||
|
||||
# Step 4: Generate Icons
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Batch-generate icons with consistent style across the entire set, processing related icons in groups for maximum visual consistency and using approved results as references for subsequent icons.
|
||||
|
||||
## 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 a creative production partner executing icon generation
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring prompt crafting and batch generation expertise, user brings approval decisions
|
||||
- ✅ Maintain an efficient, production-focused tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Generate icons in groups for consistency (navigation, action, status, feature, social)
|
||||
- 🚫 FORBIDDEN to skip group-by-group approval
|
||||
- 💬 Get approval on first icon of each group before batch-generating the rest
|
||||
- 📋 Track progress and display completion status
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Track generation progress per group
|
||||
- 📖 Use approved icons as references for subsequent generations
|
||||
- 🚫 FORBIDDEN to batch-generate without approval of first icon in group
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Icon inventory (Step 2), style configuration (Step 3)
|
||||
- Focus: Crafting prompts and executing icon generation
|
||||
- Limits: Generate only — review as a complete set happens in next step
|
||||
- Dependencies: Confirmed style and scoped inventory
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Build Icon Prompt Template
|
||||
|
||||
Construct base prompt using style configuration: style type, stroke/fill details, canvas size, padding, color mode, background transparency.
|
||||
|
||||
### 2. Generate by Group
|
||||
|
||||
Process related icons together for consistency:
|
||||
1. Navigation set (menu, close, search, arrows, chevrons)
|
||||
2. Action set (edit, delete, save, share, copy, download, upload)
|
||||
3. Status set (success/check, warning, error/x, info)
|
||||
4. Feature set (page-specific icons)
|
||||
5. Social set (platform icons)
|
||||
|
||||
For each group: generate first icon, get approval, use as reference for rest of group.
|
||||
|
||||
### 3. Select Service
|
||||
|
||||
Present options: [G] Generate via MCP (best for custom icons), [E] Export prompts (for external generation), [L] Library match (search open-source icon libraries).
|
||||
|
||||
### 4. Optimize SVG Output
|
||||
|
||||
For each generated icon: clean SVG markup, ensure viewBox is correct, set stroke/fill to currentColor for monochrome, validate pixel alignment.
|
||||
|
||||
### 5. Track Progress
|
||||
|
||||
Display generation progress per group with completion counts.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save generated icons, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all scoped icons are generated will you load {nextStepFile} to begin reviewing the complete set.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Icons generated in consistent groups
|
||||
- First icon of each group approved before batch generation
|
||||
- SVG optimization applied to all icons
|
||||
- Progress tracked and displayed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Batch-generating without first-icon approval
|
||||
- Not using approved icons as references
|
||||
- Skipping SVG optimization
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
124
_bmad/wds/workflows/6-asset-generation/steps-i/step-05-review.md
Normal file
124
_bmad/wds/workflows/6-asset-generation/steps-i/step-05-review.md
Normal file
@@ -0,0 +1,124 @@
|
||||
---
|
||||
name: 'step-05-review'
|
||||
description: 'Review the complete icon set for visual consistency, clarity, and completeness'
|
||||
workflowFile: '../workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Review and Iterate
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Review the complete icon set for visual consistency, metaphor clarity, and completeness — iterating on any icons that need adjustment and saving the final approved set with size variants.
|
||||
|
||||
## 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 a creative production partner conducting quality review
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring visual consistency expertise, user brings final approval
|
||||
- ✅ Maintain a quality-focused, thorough tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Review as a complete set, not individual icons in isolation
|
||||
- 🚫 FORBIDDEN to skip consistency or metaphor clarity checks
|
||||
- 💬 Present icons in grid format at multiple sizes and backgrounds
|
||||
- 📋 Generate size variants only after approval
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Save approved set to `{output_folder}/E-Assets/icons/`
|
||||
- 📖 Check consistency across: stroke weight, visual weight, corner radius, detail level, padding
|
||||
- 🚫 FORBIDDEN to save without user approval
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All generated icons from Step 4, style configuration
|
||||
- Focus: Reviewing the complete set for quality and consistency
|
||||
- Limits: This is the final step — focus on quality assurance and delivery
|
||||
- Dependencies: Generated icons from Step 4
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Present Full Icon Set
|
||||
|
||||
Display all icons in a grid: organized by category, shown at multiple sizes (sm, md, lg), on dark and light backgrounds.
|
||||
|
||||
### 2. Consistency Check
|
||||
|
||||
Verify across the full set: uniform stroke weight, balanced visual weight, consistent corner radius, consistent detail level, uniform padding/live area, recognizable at smallest size.
|
||||
|
||||
### 3. Metaphor Clarity Check
|
||||
|
||||
For each icon: clearly communicates intended meaning, no ambiguity with similar icons, culturally appropriate metaphors.
|
||||
|
||||
### 4. User Review
|
||||
|
||||
Present options: [A] Approve all, [R] Regenerate specific icons, [W] Weight adjust globally, [S] Size test at minimum size, [C] Context preview in UI mockup.
|
||||
|
||||
### 5. Iterate on Flagged Icons
|
||||
|
||||
For icons marked for regeneration: capture feedback, adjust prompt, use closest approved match as reference, re-review in set context.
|
||||
|
||||
### 6. Generate Size Variants
|
||||
|
||||
For approved icons: SVG (scalable, primary format), PNG at 1x, 2x, 3x for each defined size.
|
||||
|
||||
### 7. Save Approved Set
|
||||
|
||||
Save to `{output_folder}/E-Assets/icons/`: `svg/` folder, `png/` folder organized by size, `icon-set-summary.md` catalog.
|
||||
|
||||
### 8. Update Design Log
|
||||
|
||||
Record: icons generated count, style used, categories covered, consistency pass/issues.
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF M: Save final set, update design log, return to Activity Menu in {workflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#9-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- User can chat or ask questions — always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step of the Icons workflow. When M is selected and the icon set is saved, return to the Activity Menu.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Full icon set presented for review
|
||||
- Consistency and metaphor clarity checks completed
|
||||
- User approved the final set
|
||||
- Size variants generated
|
||||
- Set saved to correct output location
|
||||
- Design log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Saving icons without user approval
|
||||
- Skipping consistency or clarity checks
|
||||
- Not generating size variants
|
||||
- Not updating design log
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
name: 'step-01-load-context'
|
||||
description: 'Load all inputs for image generation including page specs, visual direction, and existing imagery'
|
||||
nextStepFile: './step-02-inventory.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Context
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load all inputs needed for image generation — page specifications, visual direction, brand assets, design system image tokens, and any existing imagery.
|
||||
|
||||
## 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 a creative production partner loading image generation context
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring visual asset methodology, user brings project specifics
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on loading and summarizing image context
|
||||
- 🚫 FORBIDDEN to generate images or select styles in this step
|
||||
- 💬 Load five context sources: page specs, visual direction, design system, brand assets, existing images
|
||||
- 📋 Present clear context summary before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document context summary with counts and categories
|
||||
- 📖 Check `{output_folder}/E-Assets/images/` for existing assets
|
||||
- 🚫 FORBIDDEN to skip any context source
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Project configuration, page specs, design system, brand assets
|
||||
- Focus: Loading all inputs for image generation
|
||||
- Limits: Do not start generating — just load context
|
||||
- Dependencies: Page specifications and visual direction must exist
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Page Specifications
|
||||
|
||||
From `{output_folder}/C-Scenarios/`: image placement requirements, content context (what story each image tells), dimensional requirements (hero 16:9, product 1:1, etc.), alt text requirements.
|
||||
|
||||
### 2. Load Visual Direction
|
||||
|
||||
Brand photography guidelines, color palette for harmony, mood/tone, subject matter preferences, what to avoid.
|
||||
|
||||
### 3. Load Design System
|
||||
|
||||
Image-related tokens: aspect ratios, border radius, overlay treatments, container sizes at breakpoints.
|
||||
|
||||
### 4. Check Existing Images
|
||||
|
||||
Scan `{output_folder}/E-Assets/images/` and brand assets: approved images, brand photography, licensed stock, previously generated.
|
||||
|
||||
### 5. Present Context Summary
|
||||
|
||||
```
|
||||
Image Context:
|
||||
- Images needed: [count] across [count] pages
|
||||
- Categories: hero, product, team, background, illustration, decorative
|
||||
- Visual direction: [mood summary]
|
||||
- Existing assets: [count] reusable
|
||||
- Generation needed: [count]
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save context, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and context is summarized will you load {nextStepFile} to begin building the image inventory.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All five context sources loaded
|
||||
- Image requirements identified per page
|
||||
- Existing assets checked
|
||||
- Context summary presented with counts
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without context
|
||||
- Missing visual direction
|
||||
- Not checking existing assets
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: 'step-02-inventory'
|
||||
description: 'Build a complete image inventory organized by type, page, and batch opportunity'
|
||||
nextStepFile: './step-03-select-style.md'
|
||||
---
|
||||
|
||||
# Step 2: Asset Inventory
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Build a complete inventory of all images needed, organized by type and page, identifying batch opportunities for consistent generation.
|
||||
|
||||
## 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 a creative production partner organizing image inventory
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring batch production methodology, user brings scope decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on cataloging and organizing images
|
||||
- 🚫 FORBIDDEN to generate images in this step
|
||||
- 💬 Group by type for batch consistency (heroes, products, team, backgrounds, etc.)
|
||||
- 📋 Wait for user scope selection
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document inventory with batch groups
|
||||
- 🚫 FORBIDDEN to proceed without user scope selection
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Image context from Step 1
|
||||
- Focus: Organizing images for generation
|
||||
- Limits: Do not generate — just catalog
|
||||
- Dependencies: Context from Step 1
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Catalog All Image Placements
|
||||
|
||||
Table: image, page, type (hero/product/team/background/illustration/decorative), dimensions, content description.
|
||||
|
||||
### 2. Group by Type
|
||||
|
||||
Organize for batch generation: hero images, product images, people/team, backgrounds, illustrations, decorative.
|
||||
|
||||
### 3. Identify Batch Opportunities
|
||||
|
||||
Images that should share visual consistency: "All 17 vehicle images" = one batch, "All team photos" = one lighting, "All heroes" = one mood.
|
||||
|
||||
### 4. Present Inventory
|
||||
|
||||
Show: total needed, batch groups, reusable existing, need generation. Present scope: [A] All, [B] By batch, [S] Select specific, [P] Priority (hero + above-fold).
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save inventory and scope, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and scope is confirmed will you load {nextStepFile} to begin selecting image style.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All image placements cataloged
|
||||
- Batch groups identified
|
||||
- Reusable assets noted
|
||||
- User selected scope
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without inventory
|
||||
- Not identifying batch opportunities
|
||||
- Not waiting for user scope selection
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
name: 'step-03-select-style'
|
||||
description: 'Choose content style and visual parameters for image generation per batch'
|
||||
nextStepFile: './step-04-references.md'
|
||||
---
|
||||
|
||||
# Step 3: Select Style
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Choose the content style (rendering technique) and visual parameters — lighting, color harmony, composition, mood — for each image batch to ensure visual consistency.
|
||||
|
||||
## 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 a creative production partner defining image visual standards
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring visual style expertise, user brings brand aesthetic
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on defining image style parameters
|
||||
- 🚫 FORBIDDEN to generate images in this step
|
||||
- 💬 Allow different styles per batch (heroes vs. backgrounds vs. products)
|
||||
- 📋 Confirm complete style configuration before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document style per batch
|
||||
- 📖 Load content styles from `data/styles/content-styles/`
|
||||
- 🚫 FORBIDDEN to proceed without confirmed style
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Image inventory (Step 2), design system, style libraries
|
||||
- Focus: Selecting visual style for image generation
|
||||
- Limits: Do not generate — just define style
|
||||
- Dependencies: Inventory and scope from Step 2
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Content Styles
|
||||
|
||||
Present from `data/styles/content-styles/`: Photorealistic, Illustration, Watercolor, Flat Design, Isometric, 3D Render, Hyper-realistic, Line Art, Pencil Sketch, Comic Book.
|
||||
|
||||
### 2. Assign Style Per Batch
|
||||
|
||||
Different image types may use different styles. Create a table: batch vs. content style.
|
||||
|
||||
### 3. Configure Visual Parameters
|
||||
|
||||
Per batch: lighting (natural, studio, dramatic, soft, golden hour), color harmony (warm, cool, brand-matched), composition (rule of thirds, centered, dynamic), mood (professional, energetic, calm, luxurious).
|
||||
|
||||
### 4. Confirm Style
|
||||
|
||||
Present: primary style, style per batch, color direction, mood, prompt keywords from style library.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save style, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and style is confirmed will you load {nextStepFile} to begin gathering reference images.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Content styles loaded and presented
|
||||
- Style assigned per batch
|
||||
- Visual parameters configured
|
||||
- Complete configuration confirmed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating without defined style
|
||||
- Not allowing per-batch style selection
|
||||
- Skipping visual parameter configuration
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: 'step-04-references'
|
||||
description: 'Attach reference images that guide visual consistency across batch generation'
|
||||
nextStepFile: './step-05-generate.md'
|
||||
---
|
||||
|
||||
# Step 4: Reference Images
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Gather and assign reference images per batch to guide visual consistency, establishing the reference chaining strategy for batch generation.
|
||||
|
||||
## 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 a creative production partner establishing visual reference strategy
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring reference strategy expertise, user brings brand imagery
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on gathering and assigning reference images
|
||||
- 🚫 FORBIDDEN to generate images in this step
|
||||
- 💬 Establish the reference chaining strategy for batch consistency
|
||||
- 📋 Confirm reference assignment before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document reference assignments per batch
|
||||
- 📖 Source from brand photography, mood boards, previously approved images, style examples
|
||||
- 🚫 FORBIDDEN to proceed without reference strategy defined
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Image inventory (Step 2), style configuration (Step 3)
|
||||
- Focus: Establishing references for consistent batch generation
|
||||
- Limits: Do not generate — just establish references
|
||||
- Dependencies: Confirmed style from Step 3
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Gather Reference Images
|
||||
|
||||
Sources: brand photography from client, mood board images, previously approved generated images, style examples from content style library.
|
||||
|
||||
### 2. Categorize References
|
||||
|
||||
Document: brand references (count, descriptions), style references (count, descriptions), previous generations (count, approved images from session).
|
||||
|
||||
### 3. Assign Per Batch
|
||||
|
||||
For each batch, assign 1-3 reference images with purpose (mood direction, framing, texture treatment).
|
||||
|
||||
### 4. Define Reference Chaining Strategy
|
||||
|
||||
Within a batch: generate first without reference (or with external reference only), once approved use it as reference for image 2, continue chaining. If an image diverges, regenerate using closest approved match.
|
||||
|
||||
### 5. Confirm References
|
||||
|
||||
Present: external references loaded, batch chaining enabled, fallback strategy.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save reference assignments, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and references are assigned will you load {nextStepFile} to begin generating images.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Reference images gathered from all sources
|
||||
- References assigned per batch
|
||||
- Chaining strategy defined
|
||||
- Fallback strategy documented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating without reference strategy
|
||||
- Not assigning references per batch
|
||||
- Missing chaining strategy
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
name: 'step-05-generate'
|
||||
description: 'Execute image generation for all batches with reference chaining for consistency'
|
||||
nextStepFile: './step-06-review.md'
|
||||
---
|
||||
|
||||
# Step 5: Generate Images
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Execute image generation for all batches, maintaining visual consistency through reference chaining — starting with hero/anchor images, getting approval, then using approved results as references for subsequent images.
|
||||
|
||||
## 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 a creative production partner executing image generation
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring prompt crafting and batch production expertise, user brings approval decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Start each batch with hero/anchor image, get approval before continuing
|
||||
- 🚫 FORBIDDEN to batch-generate without anchor approval
|
||||
- 💬 Offer variations for key images (heroes, features)
|
||||
- 📋 Track progress per batch with completion counts
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Track progress per batch
|
||||
- 📖 Chain approved results as references for subsequent images
|
||||
- 🚫 FORBIDDEN to skip anchor approval per batch
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Inventory (Step 2), style (Step 3), references (Step 4)
|
||||
- Focus: Prompt crafting and image generation execution
|
||||
- Limits: Generate only — full set review in Step 6
|
||||
- Dependencies: References and chaining strategy from Step 4
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Build Image Prompt
|
||||
|
||||
Per image: content style, subject, mood, lighting, color palette (hex from brand), composition, dimensions, style keywords, reference attachment, negative prompts.
|
||||
|
||||
### 2. Process Batches
|
||||
|
||||
Per batch: start with hero/anchor, present for approval, chain approved result for next, continue through batch.
|
||||
|
||||
### 3. Select Service
|
||||
|
||||
[G] Generate via MCP, [E] Export prompts (save to `{output_folder}/E-Assets/images/prompts/`), [U] Upload existing (user provides, skip generation).
|
||||
|
||||
### 4. Handle Variations
|
||||
|
||||
For key images: [1] Single best, [3] Three options (pick best), [5] Five options (slower).
|
||||
|
||||
### 5. Track Progress
|
||||
|
||||
Display per-batch progress with completion counts.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save generated images, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all scoped images are generated will you load {nextStepFile} to begin reviewing the set.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Prompts crafted with all context
|
||||
- Anchor image approved per batch before continuing
|
||||
- Reference chaining applied
|
||||
- Variations offered for key images
|
||||
- Progress tracked per batch
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Batch-generating without anchor approval
|
||||
- Not using reference chaining
|
||||
- Skipping variation options for key images
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
123
_bmad/wds/workflows/6-asset-generation/steps-m/step-06-review.md
Normal file
123
_bmad/wds/workflows/6-asset-generation/steps-m/step-06-review.md
Normal file
@@ -0,0 +1,123 @@
|
||||
---
|
||||
name: 'step-06-review'
|
||||
description: 'Review all generated images as a cohesive set for brand consistency and quality'
|
||||
workflowFile: '../workflow.md'
|
||||
---
|
||||
|
||||
# Step 6: Review and Iterate
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Review all generated images as a cohesive set, verify batch consistency, brand alignment, and technical quality — iterating on outliers and saving the final approved image set.
|
||||
|
||||
## 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 a creative production partner conducting image quality review
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring visual quality and brand consistency expertise, user brings final approval
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Check four dimensions: batch consistency, brand alignment, technical quality, overall cohesion
|
||||
- 🚫 FORBIDDEN to save without user approval
|
||||
- 💬 Show at intended display size and in page context
|
||||
- 📋 Check for AI artifacts, cultural sensitivity, compression quality
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Save to `{output_folder}/E-Assets/images/`
|
||||
- 📖 Check: color temperature, lighting direction, detail level, no artifacts
|
||||
- 🚫 FORBIDDEN to skip batch consistency or technical quality checks
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All generated images, style configuration, brand direction
|
||||
- Focus: Quality review, brand alignment, and final approval
|
||||
- Limits: This is the final step — focus on quality and delivery
|
||||
- Dependencies: Generated images from Step 5
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Present Image Gallery
|
||||
|
||||
Display all images: grouped by batch/type, at intended display size, with intended page context.
|
||||
|
||||
### 2. Batch Consistency Review
|
||||
|
||||
Per batch: color temperature consistent, lighting direction consistent, detail/sharpness consistent, style reflected, no image feels from different set.
|
||||
|
||||
### 3. Brand Alignment
|
||||
|
||||
Across full set: color harmonizes with brand, mood matches visual direction, subject matter appropriate, no unintended text/artifacts, cultural sensitivity check.
|
||||
|
||||
### 4. Technical Quality
|
||||
|
||||
Per image: resolution sufficient, no visible AI artifacts, clean edges, compression-friendly.
|
||||
|
||||
### 5. User Review
|
||||
|
||||
Present: [A] Approve all, [R] Regenerate specific, [V] Variations for specific image, [E] Edit specific (describe changes), [T] Tone shift (adjust color/mood across batch), [C] Context preview (in page designs).
|
||||
|
||||
### 6. Iterate Outliers
|
||||
|
||||
For flagged images: capture specific feedback, adjust prompt, use closest approved batch-mate as reference, re-review in set context.
|
||||
|
||||
### 7. Save Approved Set
|
||||
|
||||
Save to `{output_folder}/E-Assets/images/`: organized by type (`heroes/`, `products/`, `backgrounds/`, etc.), include original prompts as metadata, `image-set-summary.md`.
|
||||
|
||||
### 8. Update Design Log
|
||||
|
||||
Record: images generated count, batches, styles per batch, reference chaining details, iteration count.
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF M: Save set, update design log, return to Activity Menu in {workflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#9-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step of the Images workflow. When M is selected and image set is saved, return to the Activity Menu.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Full image gallery reviewed
|
||||
- Batch consistency verified
|
||||
- Brand alignment verified
|
||||
- Technical quality checked
|
||||
- User approved final set
|
||||
- Saved organized by type
|
||||
- Design log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Saving without user approval
|
||||
- Skipping batch consistency or technical quality
|
||||
- Not checking for AI artifacts
|
||||
- Not updating design log
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: 'step-01-load-context'
|
||||
description: 'Load everything needed for full page design compositions from specs, design system, and wireframes'
|
||||
nextStepFile: './step-02-inventory.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Context
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load everything needed for full page design compositions — page specifications, complete design system, visual direction, and any approved wireframes to build upon.
|
||||
|
||||
## 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 a creative production partner loading page design context
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring systematic context loading, user brings project specifics
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on loading and summarizing page design context
|
||||
- 🚫 FORBIDDEN to generate designs or select styles in this step
|
||||
- 💬 Load all four context sources: specs, design system, visual direction, wireframes
|
||||
- 📋 Present clear context summary before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document context summary
|
||||
- 📖 Check `{output_folder}/E-Assets/wireframes/` for approved wireframes
|
||||
- 🚫 FORBIDDEN to skip any context source
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Project configuration, page specifications, design system, visual direction
|
||||
- Focus: Loading all inputs needed for page design generation
|
||||
- Limits: Do not start generating — just load context
|
||||
- Dependencies: Page specifications and design system must exist
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Page Specifications
|
||||
|
||||
Read from `{output_folder}/C-Scenarios/`: complete page structure, user journeys, content copy, image placement.
|
||||
|
||||
### 2. Load Design System
|
||||
|
||||
Read full design system: color palette, typography scale, component patterns, spacing tokens, border/shadow/elevation tokens.
|
||||
|
||||
### 3. Load Visual Direction
|
||||
|
||||
Read brand and visual direction: brand guidelines, mood board, photography direction, illustration style.
|
||||
|
||||
### 4. Load Wireframes
|
||||
|
||||
Check `{output_folder}/E-Assets/wireframes/` for approved wireframes as structural reference.
|
||||
|
||||
### 5. Present Context Summary
|
||||
|
||||
```
|
||||
Page Design Context:
|
||||
- Pages to design: [list]
|
||||
- Design system: [name] — [token count] tokens
|
||||
- Wireframes available: [count] pages
|
||||
- Visual direction: [summary]
|
||||
- Content ready: [yes/no per page]
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save context, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and context is summarized will you load {nextStepFile} to begin building the page design inventory.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Page specs loaded
|
||||
- Full design system loaded
|
||||
- Visual direction loaded
|
||||
- Wireframes checked
|
||||
- Context summary presented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without full context
|
||||
- Not checking for wireframes
|
||||
- Skipping visual direction
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
name: 'step-02-inventory'
|
||||
description: 'Identify all pages needing full design compositions and assess readiness'
|
||||
nextStepFile: './step-03-select-style.md'
|
||||
---
|
||||
|
||||
# Step 2: Asset Inventory
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Identify all pages needing full design compositions, assess readiness (wireframe, content, images, components), flag dependencies, and let the user select the generation scope.
|
||||
|
||||
## 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 a creative production partner organizing page design inventory
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring readiness assessment expertise, user brings scope decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on cataloging and assessing readiness
|
||||
- 🚫 FORBIDDEN to generate designs in this step
|
||||
- 💬 Flag pages blocked by missing assets (suggest other activities first)
|
||||
- 📋 Wait for user scope selection
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document inventory with readiness assessment
|
||||
- 🚫 FORBIDDEN to proceed without user scope selection
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Page design context from Step 1
|
||||
- Focus: Cataloging pages and assessing readiness
|
||||
- Limits: Do not generate — just catalog
|
||||
- Dependencies: Context from Step 1
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. List All Pages
|
||||
|
||||
With columns: page name, has wireframe, has content, priority.
|
||||
|
||||
### 2. Assess Readiness
|
||||
|
||||
For each page: wireframe approved? Real copy available? Source images available? All needed components defined?
|
||||
|
||||
### 3. Flag Dependencies
|
||||
|
||||
Pages needing other assets first (e.g., hero images, icon set). Suggest relevant activity (Images, Icons) first.
|
||||
|
||||
### 4. Present Inventory
|
||||
|
||||
Show ready count, blocked count, already designed count. Present scope options.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save inventory and scope, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and scope is confirmed will you load {nextStepFile} to begin selecting design style.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All pages cataloged with readiness assessment
|
||||
- Dependencies flagged with suggestions
|
||||
- User selected generation scope
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without readiness check
|
||||
- Not flagging blocked pages
|
||||
- Not waiting for user scope selection
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
name: 'step-03-select-style'
|
||||
description: 'Choose design style and content style that define the visual character of page designs'
|
||||
nextStepFile: './step-04-generate.md'
|
||||
---
|
||||
|
||||
# Step 3: Select Style
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Choose the design style and content style that define the visual character of page designs, merging selected styles with design system 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 a creative production partner defining page design visual standards
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring design style expertise, user brings aesthetic preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on selecting and configuring design and content styles
|
||||
- 🚫 FORBIDDEN to generate designs in this step
|
||||
- 💬 Merge style selection with design system tokens
|
||||
- 📋 Confirm complete style selection before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document style selection with design system merge
|
||||
- 📖 Load styles from `data/styles/design-styles/` and `data/styles/content-styles/`
|
||||
- 🚫 FORBIDDEN to proceed without confirmed style
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Inventory (Step 2), design system, style libraries
|
||||
- Focus: Selecting visual style for page design generation
|
||||
- Limits: Do not generate — just define style
|
||||
- Dependencies: Inventory and scope from Step 2
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Design Styles
|
||||
|
||||
Present available design styles from `data/styles/design-styles/`: Minimal, Corporate, Brutalist, Organic, Playful, Editorial. Highlight matches with project brand direction.
|
||||
|
||||
### 2. Load Content Styles
|
||||
|
||||
For generated visual elements within pages: select content style if the page uses illustrations or decorative elements. Skip if photography only.
|
||||
|
||||
### 3. Combine with Design System
|
||||
|
||||
Merge: style mood + design system colors, style spacing feel + design system spacing tokens, style typography approach + design system fonts.
|
||||
|
||||
### 4. Confirm Style Selection
|
||||
|
||||
Present: design style, content style (or photography only), applied to design system, output dimensions (desktop x auto, mobile x auto).
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save style, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and style is confirmed will you load {nextStepFile} to begin generating page designs.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Design style selected
|
||||
- Content style selected (or skipped for photography)
|
||||
- Style merged with design system tokens
|
||||
- Complete configuration confirmed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating without defined style
|
||||
- Not merging with design system
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: 'step-04-generate'
|
||||
description: 'Craft detailed prompts and generate full page design compositions'
|
||||
nextStepFile: './step-05-review.md'
|
||||
---
|
||||
|
||||
# Step 4: Generate Page Designs
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Craft comprehensive prompts and generate full page design compositions, generating desktop first then mobile, using approved results as references for batch consistency.
|
||||
|
||||
## 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 a creative production partner executing page design generation
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring comprehensive prompt crafting expertise, user brings approval decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Generate desktop first, then mobile using desktop as reference
|
||||
- 🚫 FORBIDDEN to batch-generate without per-page approval
|
||||
- 💬 Include wireframe reference when available
|
||||
- 📋 Track progress per page and view
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Track progress per page/view
|
||||
- 📖 Use approved pages as reference for subsequent generations
|
||||
- 🚫 FORBIDDEN to skip per-page approval
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Inventory (Step 2), style (Step 3), wireframes, specs
|
||||
- Focus: Prompt crafting and page design generation
|
||||
- Limits: Generate only — full set review in Step 5
|
||||
- Dependencies: Confirmed style and scoped inventory
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Build Page Design Prompt
|
||||
|
||||
For each page: layout (from wireframe or spec), color palette (hex from design system), typography (font families, sizes), style keywords, content (real headlines and body text), components, image areas, dimensions.
|
||||
|
||||
### 2. Include Wireframe Reference
|
||||
|
||||
Attach wireframe as structural reference when available. Note: "Follow layout structure, add full visual design."
|
||||
|
||||
### 3. Select Service
|
||||
|
||||
[G] Generate via MCP or [E] Export prompts.
|
||||
|
||||
### 4. Generate Sequentially
|
||||
|
||||
For each page: desktop first, present for approval, use approved desktop as mobile reference, chain approved pages for batch consistency.
|
||||
|
||||
### 5. Track Progress
|
||||
|
||||
Display progress per page and view (desktop/mobile).
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save generated designs, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all scoped pages are generated will you load {nextStepFile} to begin reviewing the design set.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Prompts crafted with all context
|
||||
- Desktop generated before mobile
|
||||
- Reference chaining for consistency
|
||||
- Progress tracked per page/view
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Batch-generating without approval
|
||||
- Not using wireframe references
|
||||
- Generating mobile before desktop
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
117
_bmad/wds/workflows/6-asset-generation/steps-p/step-05-review.md
Normal file
117
_bmad/wds/workflows/6-asset-generation/steps-p/step-05-review.md
Normal file
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: 'step-05-review'
|
||||
description: 'Review page designs as a cohesive set for design system compliance and consistency'
|
||||
workflowFile: '../workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Review and Iterate
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Review all page designs as a cohesive set, verify design system compliance and cross-page consistency, iterate on flagged designs, and save the final approved set.
|
||||
|
||||
## 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 a creative production partner conducting design quality review
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring design system compliance expertise, user brings final approval
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Review as a complete set — design system compliance AND cross-page consistency
|
||||
- 🚫 FORBIDDEN to save without user approval
|
||||
- 💬 Group by page with desktop + mobile pairs
|
||||
- 📋 Check both design system tokens and cross-page visual rhythm
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Save to `{output_folder}/E-Assets/page-designs/`
|
||||
- 📖 Check: colors, typography, spacing, components, responsive layout
|
||||
- 🚫 FORBIDDEN to skip compliance or consistency checks
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All generated designs, design system, style configuration
|
||||
- Focus: Quality review, compliance, and final approval
|
||||
- Limits: This is the final step — focus on quality and delivery
|
||||
- Dependencies: Generated designs from Step 4
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Present Design Set
|
||||
|
||||
Show all designs grouped by page (desktop + mobile pairs), full-page scrollable views.
|
||||
|
||||
### 2. Design System Compliance
|
||||
|
||||
Check each design: colors match palette tokens, typography follows type scale, spacing follows spacing scale, components match patterns, responsive layout follows breakpoint rules.
|
||||
|
||||
### 3. Cross-Page Consistency
|
||||
|
||||
Verify: navigation identical across pages, footer consistent, color usage consistent (primary for CTAs), typography hierarchy consistent, visual rhythm unified.
|
||||
|
||||
### 4. User Review
|
||||
|
||||
Present: [A] Approve all, [R] Regenerate specific, [S] Style adjust, [D] Detail edit specific element, [C] Compare side-by-side.
|
||||
|
||||
### 5. Iterate
|
||||
|
||||
For flagged designs: capture feedback, adjust prompt, regenerate with approved pages as reference.
|
||||
|
||||
### 6. Save Approved Set
|
||||
|
||||
Save to `{output_folder}/E-Assets/page-designs/`: `{page-name}-desktop.png`, `{page-name}-mobile.png`, `page-design-set-summary.md`.
|
||||
|
||||
### 7. Update Design Log
|
||||
|
||||
Record: pages designed count, styles used, compliance status.
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF M: Save set, update design log, return to Activity Menu in {workflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step of the Page Designs workflow. When M is selected and set is saved, return to the Activity Menu.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Full design set reviewed
|
||||
- Design system compliance verified
|
||||
- Cross-page consistency verified
|
||||
- User approved final set
|
||||
- Saved to correct location
|
||||
- Design log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Saving without user approval
|
||||
- Skipping compliance or consistency checks
|
||||
- Not updating design log
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
name: 'step-01-load-context'
|
||||
description: 'Load design system components, tokens, and page context for UI element asset generation'
|
||||
nextStepFile: './step-02-inventory.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Context
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load the design system components, design tokens, and page context needed to generate UI element assets — establishing the complete component library generation context.
|
||||
|
||||
## 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 a creative production partner loading UI component context
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring component system expertise, user brings project specifics
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on loading and summarizing UI element context
|
||||
- 🚫 FORBIDDEN to generate UI elements or select styles in this step
|
||||
- 💬 Load both component definitions and design tokens
|
||||
- 📋 Present clear context summary before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document context summary
|
||||
- 🚫 FORBIDDEN to skip any context source
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Design system components and tokens, page specifications
|
||||
- Focus: Loading all inputs for UI element generation
|
||||
- Limits: Do not start generating — just load context
|
||||
- Dependencies: Design system must exist
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Design System Components
|
||||
|
||||
Read component definitions: button variants, card patterns, form elements, navigation components, feedback components.
|
||||
|
||||
### 2. Load Design Tokens
|
||||
|
||||
Read tokens affecting rendering: color tokens (per state), typography tokens, spacing tokens, border tokens, shadow tokens, transition tokens.
|
||||
|
||||
### 3. Load Page Context
|
||||
|
||||
From page specs, identify which components are used where: which button variants, form patterns, card layouts per page.
|
||||
|
||||
### 4. Present Context Summary
|
||||
|
||||
```
|
||||
UI Element Context:
|
||||
- Component types defined: [count]
|
||||
- Design tokens loaded: [count]
|
||||
- States to generate: default, hover, focus, active, disabled
|
||||
- Pages referencing components: [count]
|
||||
```
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save context, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and context is summarized will you load {nextStepFile} to begin building the UI element inventory.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Component definitions loaded
|
||||
- Design tokens loaded
|
||||
- Page context loaded
|
||||
- Context summary presented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without context
|
||||
- Missing component categories
|
||||
- Not loading design tokens
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
name: 'step-02-inventory'
|
||||
description: 'Create a complete inventory of UI elements organized by component type, variant, and state'
|
||||
nextStepFile: './step-03-select-style.md'
|
||||
---
|
||||
|
||||
# Step 2: Asset Inventory
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Create a complete inventory of UI elements to generate, organized by component type, variant, and state — with priority levels and scope selection.
|
||||
|
||||
## 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 a creative production partner organizing component inventory
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring component library organization expertise, user brings scope decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on cataloging UI elements for generation
|
||||
- 🚫 FORBIDDEN to generate elements in this step
|
||||
- 💬 Calculate total assets (variants x states)
|
||||
- 📋 Wait for user scope selection
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document inventory with total asset count
|
||||
- 📖 Check `{output_folder}/E-Assets/ui-elements/` for existing assets
|
||||
- 🚫 FORBIDDEN to proceed without user scope selection
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: UI element context from Step 1
|
||||
- Focus: Organizing elements into a generation-ready inventory
|
||||
- Limits: Do not generate — just catalog
|
||||
- Dependencies: Context from Step 1
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. List Component Types
|
||||
|
||||
Table: component, variants, states, total assets (variants x states).
|
||||
|
||||
### 2. Prioritize
|
||||
|
||||
[H] High (used every page: buttons, inputs, navigation), [M] Medium (multiple pages: cards, alerts), [L] Low (specific pages: specialized components).
|
||||
|
||||
### 3. Check Existing Assets
|
||||
|
||||
Scan `{output_folder}/E-Assets/ui-elements/` for already-generated components.
|
||||
|
||||
### 4. Present Inventory
|
||||
|
||||
Show: component types count, total variants x states, already generated, need generation. Present scope: [A] All, [H] High priority only, [S] Select specific.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save inventory and scope, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and scope is confirmed will you load {nextStepFile} to begin selecting rendering style.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All component types cataloged with variants and states
|
||||
- Priority levels assigned
|
||||
- Existing assets checked
|
||||
- User selected scope
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without inventory
|
||||
- Not calculating total assets
|
||||
- Not checking existing assets
|
||||
- Not waiting for user scope selection
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: 'step-03-select-style'
|
||||
description: 'Confirm rendering approach, state visualization, and design system token mapping for UI elements'
|
||||
nextStepFile: './step-04-generate.md'
|
||||
---
|
||||
|
||||
# Step 3: Select Style
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Confirm the visual style for UI element generation — rendering approach, state visualization method, design system token mapping, and output parameters.
|
||||
|
||||
## 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 a creative production partner defining UI element rendering standards
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring component rendering expertise, user brings visual preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on defining rendering style
|
||||
- 🚫 FORBIDDEN to generate elements in this step
|
||||
- 💬 Map design tokens to visual properties
|
||||
- 📋 Confirm complete configuration before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document style configuration
|
||||
- 🚫 FORBIDDEN to proceed without confirmed style
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: UI inventory (Step 2), design system tokens
|
||||
- Focus: Defining rendering parameters
|
||||
- Limits: Do not generate — just define style
|
||||
- Dependencies: Inventory and scope from Step 2
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Select Rendering Approach
|
||||
|
||||
[V] Vector/CSS (clean, scalable, code-ready), [R] Realistic (shadows, depth, presentation-quality), [F] Flat (minimal, no shadows, pure color blocks).
|
||||
|
||||
### 2. Select State Visualization
|
||||
|
||||
[G] Grid (all states in a grid, design system doc style), [I] Individual (each state as separate asset), [A] Animated (state transitions as sequence).
|
||||
|
||||
### 3. Apply Design System Tokens
|
||||
|
||||
Map tokens to visual properties: primary button colors, hover states, focus rings, shadows, etc.
|
||||
|
||||
### 4. Confirm Style
|
||||
|
||||
Present: rendering approach, state display, design system applied, background, scale.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save style, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and style is confirmed will you load {nextStepFile} to begin generating UI elements.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Rendering approach selected
|
||||
- State visualization method selected
|
||||
- Design tokens mapped to properties
|
||||
- Complete configuration confirmed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating without defined style
|
||||
- Not mapping design tokens
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: 'step-04-generate'
|
||||
description: 'Generate UI element assets for all components in priority order'
|
||||
nextStepFile: './step-05-review.md'
|
||||
---
|
||||
|
||||
# Step 4: Generate UI Elements
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate UI element assets for all components in the inventory, processing in priority order (buttons, inputs, cards, navigation, feedback) and using appropriate batch strategies per visualization mode.
|
||||
|
||||
## 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 a creative production partner executing component generation
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring component generation expertise, user brings approval decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Generate in priority order: buttons, inputs, cards, navigation, feedback
|
||||
- 🚫 FORBIDDEN to skip approval between component groups
|
||||
- 💬 Use grid prompts for grid-style state display, individual prompts otherwise
|
||||
- 📋 Track progress per component group
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Track progress per component group
|
||||
- 📖 Use approved results as reference for consistency
|
||||
- 🚫 FORBIDDEN to batch-generate without group-level approval
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Inventory (Step 2), style configuration (Step 3)
|
||||
- Focus: Prompt crafting and component generation
|
||||
- Limits: Generate only — full review in Step 5
|
||||
- Dependencies: Confirmed style and scoped inventory
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Build Component Prompt Template
|
||||
|
||||
Include: rendering approach, state, colors (hex), typography, dimensions, border radius, shadow, padding, style quality note.
|
||||
|
||||
### 2. Generate by Component Group
|
||||
|
||||
Process in priority order: Buttons (all variants and states), Form inputs (all types and states), Cards (all patterns), Navigation (all types), Feedback (alerts, toasts, modals).
|
||||
|
||||
### 3. Apply Batch Strategy
|
||||
|
||||
Grid style: generate all states of one variant in a single prompt. Individual style: generate one asset per prompt with reference chaining.
|
||||
|
||||
### 4. Select Service
|
||||
|
||||
[G] Generate via MCP or [E] Export prompts.
|
||||
|
||||
### 5. Track Progress
|
||||
|
||||
Display per-group completion counts.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save generated elements, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all scoped elements are generated will you load {nextStepFile} to begin reviewing the component library.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Components generated in priority order
|
||||
- Appropriate batch strategy per visualization mode
|
||||
- Progress tracked per group
|
||||
- Approval between groups
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Batch-generating without approval
|
||||
- Wrong batch strategy for visualization mode
|
||||
- Not tracking progress
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
119
_bmad/wds/workflows/6-asset-generation/steps-u/step-05-review.md
Normal file
119
_bmad/wds/workflows/6-asset-generation/steps-u/step-05-review.md
Normal file
@@ -0,0 +1,119 @@
|
||||
---
|
||||
name: 'step-05-review'
|
||||
description: 'Review all UI elements for design system compliance, consistency, and accessibility'
|
||||
workflowFile: '../workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Review and Iterate
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Review all generated UI elements for design system compliance, cross-component consistency, accessibility, and completeness — then save the approved component library.
|
||||
|
||||
## 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 a creative production partner conducting component quality review
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring design system compliance expertise, user brings final approval
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Check three dimensions: design system compliance, cross-component consistency, accessibility
|
||||
- 🚫 FORBIDDEN to save without user approval
|
||||
- 💬 Show all variants side by side, all states for each
|
||||
- 📋 Verify WCAG AA contrast compliance
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Save to `{output_folder}/E-Assets/ui-elements/`
|
||||
- 📖 Check: exact token values, visual weight balance, color contrast
|
||||
- 🚫 FORBIDDEN to skip accessibility check
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All generated elements, design system, style configuration
|
||||
- Focus: Quality review, compliance, and accessibility
|
||||
- Limits: This is the final step — focus on quality and delivery
|
||||
- Dependencies: Generated elements from Step 4
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Present Component Library
|
||||
|
||||
Display grouped by type: all variants side by side, all states for each variant, compare hover/focus/active transitions.
|
||||
|
||||
### 2. Design System Compliance
|
||||
|
||||
For each component: colors match tokens, typography matches scale, border radius matches, shadows match elevation tokens, spacing matches padding/margin tokens, focus ring follows standard.
|
||||
|
||||
### 3. Cross-Component Consistency
|
||||
|
||||
Across full set: visual weight balanced, color usage consistent, radius values uniform, shadow levels distinguishable, disabled states follow same pattern.
|
||||
|
||||
### 4. Accessibility Check
|
||||
|
||||
Color contrast meets WCAG AA (4.5:1 text, 3:1 large text), focus states clearly visible, disabled states distinguishable but clearly inactive.
|
||||
|
||||
### 5. User Review
|
||||
|
||||
Present: [A] Approve all, [R] Regenerate specific, [T] Token adjust and regenerate affected, [C] Compare view.
|
||||
|
||||
### 6. Save Approved Set
|
||||
|
||||
Save to `{output_folder}/E-Assets/ui-elements/`: organized by type (`buttons/`, `inputs/`, `cards/`, etc.), `component-library-summary.md`.
|
||||
|
||||
### 7. Update Design Log
|
||||
|
||||
Record: components generated (types x variants x states), compliance status, accessibility status.
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF M: Save library, update design log, return to Activity Menu in {workflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step of the UI Elements workflow. When M is selected and library is saved, return to the Activity Menu.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Full library reviewed
|
||||
- Design system compliance verified
|
||||
- Cross-component consistency verified
|
||||
- Accessibility checked
|
||||
- User approved
|
||||
- Saved to correct location
|
||||
- Design log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Saving without user approval
|
||||
- Skipping accessibility check
|
||||
- Not verifying design system compliance
|
||||
- Not updating design log
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: 'step-01-load-context'
|
||||
description: 'Load motion content requirements including what needs to move, where, and why'
|
||||
nextStepFile: './step-02-inventory.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Context
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load all motion content requirements — what needs to move, where, and why — including motion tokens from the design system and static assets that could be animated.
|
||||
|
||||
## 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 a creative production partner loading motion content context
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring motion design expertise, user brings project specifics
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on loading and summarizing motion content context
|
||||
- 🚫 FORBIDDEN to generate motion content or select styles in this step
|
||||
- 💬 Identify all motion content types: hero animations, product demos, micro-interactions, background video, explainers
|
||||
- 📋 Present clear context summary before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document context summary
|
||||
- 🚫 FORBIDDEN to skip any context source
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Page specifications, design system motion tokens, existing visual assets
|
||||
- Focus: Loading all motion content requirements
|
||||
- Limits: Do not start generating — just load context
|
||||
- Dependencies: Page specifications must exist
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Motion Requirements
|
||||
|
||||
From page specs: hero animations, product demonstrations, micro-interactions, background video, explainer sequences.
|
||||
|
||||
### 2. Load Motion Tokens
|
||||
|
||||
From design system: duration scale, easing curves, transition types.
|
||||
|
||||
### 3. Load Visual Assets
|
||||
|
||||
Check for static assets that motion builds upon: images needing animation, UI components needing state transitions, illustrations that could be animated.
|
||||
|
||||
### 4. Present Context Summary
|
||||
|
||||
```
|
||||
Video/Motion Context:
|
||||
- Motion assets needed: [count]
|
||||
- Types: [hero, product demo, micro-interaction, background, explainer]
|
||||
- Duration range: [shortest] to [longest]
|
||||
- Existing static assets to animate: [count]
|
||||
- Full video productions: [count]
|
||||
```
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save context, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and context is summarized will you load {nextStepFile} to begin building the motion content inventory.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All motion requirements identified from specs
|
||||
- Motion tokens loaded
|
||||
- Visual assets checked for animation potential
|
||||
- Context summary presented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without context
|
||||
- Missing motion content types
|
||||
- Not checking existing visual assets
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
name: 'step-02-inventory'
|
||||
description: 'Catalog all motion content needed with type, duration, complexity, and format requirements'
|
||||
nextStepFile: './step-03-select-style.md'
|
||||
---
|
||||
|
||||
# Step 2: Asset Inventory
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Catalog all motion content needed with type, duration, complexity level, format requirements, and file size targets — letting the user select generation scope.
|
||||
|
||||
## 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 a creative production partner organizing motion content inventory
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring motion production expertise, user brings scope decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on cataloging motion content with technical requirements
|
||||
- 🚫 FORBIDDEN to generate motion content in this step
|
||||
- 💬 Categorize by complexity: Simple (CSS/SVG), Medium (Lottie), Complex (video), Generated (AI)
|
||||
- 📋 Include format and file size targets
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document inventory with technical requirements
|
||||
- 🚫 FORBIDDEN to proceed without user scope selection
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Motion context from Step 1
|
||||
- Focus: Organizing motion content into generation-ready inventory
|
||||
- Limits: Do not generate — just catalog
|
||||
- Dependencies: Context from Step 1
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Build Motion Asset Catalog
|
||||
|
||||
Table: asset name, page, type, duration, format (MP4/WebM, CSS/Lottie, SVG anim).
|
||||
|
||||
### 2. Categorize by Complexity
|
||||
|
||||
[S] Simple (CSS/SVG, <10KB), [M] Medium (Lottie, <50KB), [C] Complex (video, <10MB), [G] Generated (AI video, <2MB).
|
||||
|
||||
### 3. Document Technical Requirements
|
||||
|
||||
Format, use case, and file size target per complexity level.
|
||||
|
||||
### 4. Present Inventory with Scope Options
|
||||
|
||||
Show counts per complexity level, total motion assets. Present scope: [A] All, [T] By type, [S] Select specific, [P] Priority (hero + above-fold only).
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save inventory and scope, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and scope is confirmed will you load {nextStepFile} to begin selecting motion style.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All motion assets cataloged with technical requirements
|
||||
- Complexity levels assigned
|
||||
- File size targets documented
|
||||
- User selected scope
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without inventory
|
||||
- Missing complexity categorization
|
||||
- Not including file size targets
|
||||
- Not waiting for user scope selection
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: 'step-03-select-style'
|
||||
description: 'Define motion personality, timing parameters, and video visual treatment'
|
||||
nextStepFile: './step-04-generate.md'
|
||||
---
|
||||
|
||||
# Step 3: Select Style
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define the motion style — personality (subtle/fluid/energetic/precise), timing parameters, video visual treatment, and color direction — so all motion content feels cohesive.
|
||||
|
||||
## 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 a creative production partner defining motion visual standards
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring motion design expertise, user brings brand preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on defining motion style parameters
|
||||
- 🚫 FORBIDDEN to generate motion content in this step
|
||||
- 💬 Set timing parameters based on personality selection
|
||||
- 📋 Confirm complete style configuration before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document complete motion style configuration
|
||||
- 🚫 FORBIDDEN to proceed without confirmed style
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Motion inventory (Step 2), design system motion tokens
|
||||
- Focus: Defining motion style parameters
|
||||
- Limits: Do not generate — just define style
|
||||
- Dependencies: Inventory and scope from Step 2
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Select Motion Personality
|
||||
|
||||
[S] Subtle (corporate, medical), [F] Fluid (wellness, lifestyle), [E] Energetic (startup, gaming), [P] Precise (engineering, SaaS).
|
||||
|
||||
### 2. Configure Timing Parameters
|
||||
|
||||
Based on personality: base duration, easing curve, stagger delay, loop delay.
|
||||
|
||||
### 3. Select Video Treatment (for produced/generated video)
|
||||
|
||||
[C] Cinematic (shallow DOF, color graded), [D] Documentary (natural, handheld), [M] Motion design (graphics-driven), [A] Abstract (textures, ambient).
|
||||
|
||||
### 4. Define Color and Lighting
|
||||
|
||||
Match brand palette, dark/light preference, contrast level for overlaid text.
|
||||
|
||||
### 5. Confirm Style
|
||||
|
||||
Present: personality, timing parameters, video treatment, color direction.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save style, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and style is confirmed will you load {nextStepFile} to begin generating motion content.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Motion personality selected
|
||||
- Timing parameters configured
|
||||
- Video treatment selected
|
||||
- Color direction defined
|
||||
- Complete style confirmed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating without defined style
|
||||
- Not configuring timing parameters
|
||||
- Skipping video treatment selection
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
name: 'step-04-generate'
|
||||
description: 'Generate video and motion assets using appropriate tools per complexity level'
|
||||
nextStepFile: './step-05-review.md'
|
||||
---
|
||||
|
||||
# Step 4: Generate Motion Content
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate video and motion assets, routing each to the appropriate tool based on complexity level — CSS/SVG for simple, Lottie for medium, video production for complex, AI generation for generated.
|
||||
|
||||
## 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 a creative production partner executing motion content generation
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring multi-format motion production expertise, user brings approval decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Route each asset to the correct tool based on complexity
|
||||
- 🚫 FORBIDDEN to use wrong tool for complexity level
|
||||
- 💬 Preview each in context (how it looks on the page)
|
||||
- 📋 Track progress across all complexity levels
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Track progress per complexity group
|
||||
- 📖 Use reference frames from approved static images for AI video
|
||||
- 🚫 FORBIDDEN to skip preview and timing check per asset
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Inventory (Step 2), style (Step 3)
|
||||
- Focus: Generating motion content with correct tools
|
||||
- Limits: Generate only — full review in Step 5
|
||||
- Dependencies: Confirmed style and scoped inventory
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Route by Complexity
|
||||
|
||||
- Simple (CSS/SVG): Generate keyframe animations, SVG with SMIL/CSS animation
|
||||
- Medium (Lottie): Describe animation for After Effects/Lottie, generate Lottie JSON if MCP supports
|
||||
- Complex (video): Storyboard, shot list, guide to production
|
||||
- AI Generated: Craft video generation prompts with reference frames
|
||||
|
||||
### 2. Build Prompts (AI Generated)
|
||||
|
||||
Include: duration, subject, movement, mood, style keywords, color palette, dimensions, FPS, loop preference, reference frame.
|
||||
|
||||
### 3. Select Service
|
||||
|
||||
For AI video: [G] Generate via MCP, [E] Export prompts. For CSS/SVG: [C] Generate code, [S] Spec document.
|
||||
|
||||
### 4. Generate and Preview
|
||||
|
||||
For each: generate/create, preview in page context, check timing and feel, iterate if needed.
|
||||
|
||||
### 5. Track Progress
|
||||
|
||||
Display progress per complexity group with counts.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save generated motion content, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all scoped motion content is generated will you load {nextStepFile} to begin reviewing the set.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Each asset routed to correct tool
|
||||
- Prompts crafted with motion style parameters
|
||||
- Preview and timing verified per asset
|
||||
- Progress tracked per complexity group
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Using wrong tool for complexity level
|
||||
- Not previewing in context
|
||||
- Skipping timing verification
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
121
_bmad/wds/workflows/6-asset-generation/steps-v/step-05-review.md
Normal file
121
_bmad/wds/workflows/6-asset-generation/steps-v/step-05-review.md
Normal file
@@ -0,0 +1,121 @@
|
||||
---
|
||||
name: 'step-05-review'
|
||||
description: 'Review all motion content for consistency, performance, and accessibility compliance'
|
||||
workflowFile: '../workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Review and Iterate
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Review all motion content for consistency, performance, accessibility compliance, and user experience quality — then save the approved motion set.
|
||||
|
||||
## 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 a creative production partner conducting motion quality review
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring motion UX and performance expertise, user brings final approval
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Check four dimensions: consistency, performance, accessibility, UX quality
|
||||
- 🚫 FORBIDDEN to save without user approval
|
||||
- 💬 Preview in page context alongside static versions
|
||||
- 📋 Verify `prefers-reduced-motion` coverage
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Save to `{output_folder}/E-Assets/motion/`
|
||||
- 📖 Check: timing consistency, file sizes, flash rate, reduced-motion support
|
||||
- 🚫 FORBIDDEN to skip performance or accessibility checks
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All generated motion content, style configuration
|
||||
- Focus: Quality review, performance, and accessibility
|
||||
- Limits: This is the final step — focus on quality and delivery
|
||||
- Dependencies: Generated motion content from Step 4
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Preview All Motion
|
||||
|
||||
Show each: in isolation, in page context, before/after (static vs. animated).
|
||||
|
||||
### 2. Motion Consistency
|
||||
|
||||
Verify: timing consistent, easing curves match, motion direction logical, no competing animations, loops seamless.
|
||||
|
||||
### 3. Performance Check
|
||||
|
||||
Per asset: file size within target, no excessive complexity, CSS uses GPU-accelerated properties, videos compressed, lazy loading for below-fold.
|
||||
|
||||
### 4. Accessibility Check
|
||||
|
||||
Respects `prefers-reduced-motion`, no flashing (<3 per second), does not interfere with readability, video has pause/stop, alternative static content provided.
|
||||
|
||||
### 5. User Review
|
||||
|
||||
Present: [A] Approve all, [R] Regenerate specific, [T] Timing adjust, [E] Easing adjust, [C] Full page context preview, [P] Performance report.
|
||||
|
||||
### 6. Iterate
|
||||
|
||||
For flagged assets: adjust timing/easing/content, regenerate or re-code, re-preview in context.
|
||||
|
||||
### 7. Save Approved Set
|
||||
|
||||
Save to `{output_folder}/E-Assets/motion/`: `css/`, `svg/`, `lottie/`, `video/`, `motion-set-summary.md`.
|
||||
|
||||
### 8. Update Design Log
|
||||
|
||||
Record: assets created count, type breakdown, motion personality, total added weight, reduced-motion coverage.
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF M: Save set, update design log, return to Activity Menu in {workflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#9-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step of the Videos/Motion workflow. When M is selected and set is saved, return to the Activity Menu.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All motion content reviewed
|
||||
- Consistency, performance, accessibility verified
|
||||
- User approved final set
|
||||
- Saved to correct locations by type
|
||||
- Design log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Saving without user approval
|
||||
- Skipping performance or accessibility checks
|
||||
- Not verifying reduced-motion support
|
||||
- Not updating design log
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
name: 'step-01-load-context'
|
||||
description: 'Load all inputs needed for wireframe generation from page specifications and design system'
|
||||
nextStepFile: './step-02-inventory.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Context
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load all inputs needed to generate wireframes — page specifications, design system layout rules, and any existing wireframe references — establishing the complete context for wireframe generation.
|
||||
|
||||
## 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 a creative production partner loading wireframe generation context
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring systematic context loading, user brings project specifics
|
||||
- ✅ Maintain a thorough, organized tone
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on loading and summarizing wireframe context
|
||||
- 🚫 FORBIDDEN to generate wireframes or select styles in this step
|
||||
- 💬 Load page specs, design system layout tokens, and existing wireframes
|
||||
- 📋 Present a clear context summary before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document context summary
|
||||
- 📖 Check `{output_folder}/E-Assets/wireframes/` for existing assets
|
||||
- 🚫 FORBIDDEN to skip any context source
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Project configuration, page specifications, design system
|
||||
- Focus: Loading all inputs needed for wireframe generation
|
||||
- Limits: Do not start generating — just load context
|
||||
- Dependencies: Page specifications and design system must exist
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Page Specifications
|
||||
|
||||
Read page specs from `{output_folder}/C-Scenarios/`: page structure and layout requirements, content zones and hierarchy, responsive breakpoints, navigation patterns.
|
||||
|
||||
### 2. Load Design System
|
||||
|
||||
Read layout tokens: grid system (columns, gutters, margins), spacing scale, breakpoint definitions, container widths.
|
||||
|
||||
### 3. Check Existing Wireframes
|
||||
|
||||
Scan `{output_folder}/E-Assets/wireframes/` for previously generated wireframes and approved reference wireframes.
|
||||
|
||||
### 4. Present Context Summary
|
||||
|
||||
```
|
||||
Wireframe Context:
|
||||
- Pages to wireframe: [list from specs]
|
||||
- Grid: [columns] / [gutter] / [margins]
|
||||
- Breakpoints: [list]
|
||||
- Existing wireframes: [count] found
|
||||
```
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save context summary, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-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 end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and context is summarized will you load {nextStepFile} to begin building the wireframe inventory.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Page specifications loaded
|
||||
- Design system layout tokens loaded
|
||||
- Existing wireframes checked
|
||||
- Context summary presented
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting wireframe generation without context
|
||||
- Not checking for existing wireframes
|
||||
- Skipping design system tokens
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
name: 'step-02-inventory'
|
||||
description: 'Identify all pages needing wireframes and organize for batch generation'
|
||||
nextStepFile: './step-03-select-style.md'
|
||||
---
|
||||
|
||||
# Step 2: Asset Inventory
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Identify all pages and views that need wireframes, check what already exists, and let the user select the generation scope.
|
||||
|
||||
## 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 a creative production partner organizing wireframe inventory
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring systematic inventory methodology, user brings scope decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on cataloging pages for wireframe generation
|
||||
- 🚫 FORBIDDEN to generate wireframes in this step
|
||||
- 💬 Cross-reference with existing wireframes to avoid duplicates
|
||||
- 📋 Wait for user scope selection before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document inventory with existing/needed counts
|
||||
- 🚫 FORBIDDEN to proceed without user scope selection
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Wireframe context from Step 1
|
||||
- Focus: Building the generation-ready inventory
|
||||
- Limits: Do not generate — just catalog
|
||||
- Dependencies: Context from Step 1
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. List All Pages
|
||||
|
||||
From loaded page specs, create a list with page name, views (Desktop, Mobile), and priority.
|
||||
|
||||
### 2. Check What Exists
|
||||
|
||||
Cross-reference with `{output_folder}/E-Assets/wireframes/`: mark existing, identify outdated (spec changed after generation).
|
||||
|
||||
### 3. Present Inventory
|
||||
|
||||
Show total pages, already wireframed count, need wireframes count, need update count. Ask user to confirm scope: All, Select specific, or Missing only.
|
||||
|
||||
### 4. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save inventory and scope, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and scope is confirmed will you load {nextStepFile} to begin selecting wireframe style.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All pages cataloged with views and priority
|
||||
- Existing wireframes identified
|
||||
- User selected generation scope
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Starting generation without inventory
|
||||
- Not cross-referencing existing wireframes
|
||||
- Not waiting for user scope selection
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
name: 'step-03-select-style'
|
||||
description: 'Choose wireframe fidelity level, design style influence, and annotation options'
|
||||
nextStepFile: './step-04-generate.md'
|
||||
---
|
||||
|
||||
# Step 3: Select Style
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Choose the visual approach for wireframe generation — fidelity level, design style influence, annotation preferences, and output dimensions.
|
||||
|
||||
## 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 a creative production partner defining wireframe visual standards
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring wireframe design expertise, user brings aesthetic preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on defining wireframe style parameters
|
||||
- 🚫 FORBIDDEN to generate wireframes in this step
|
||||
- 💬 Present clear fidelity options with descriptions
|
||||
- 📋 Confirm complete style configuration before proceeding
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Document complete wireframe style configuration
|
||||
- 📖 Load design style from `data/styles/design-styles/` for layout influence
|
||||
- 🚫 FORBIDDEN to proceed without confirmed style
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Wireframe inventory (Step 2), design system
|
||||
- Focus: Defining wireframe style parameters
|
||||
- Limits: Do not generate — just define style
|
||||
- Dependencies: Inventory and scope from Step 2
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Select Fidelity Level
|
||||
|
||||
Present: [L] Low-Fi (boxes and labels), [M] Mid-Fi (recognizable components, basic typography), [H] High-Fi (near-realistic with placeholder content).
|
||||
|
||||
### 2. Load Design Style Influence
|
||||
|
||||
Load selected design style from `data/styles/design-styles/` to extract layout principles and spacing feel.
|
||||
|
||||
### 3. Select Annotation Options
|
||||
|
||||
[Y] Yes (label content zones, note responsive behavior, mark interactions) or [N] No (clean wireframes only).
|
||||
|
||||
### 4. Confirm Style
|
||||
|
||||
Present: fidelity, design influence, annotations, dimensions (Desktop width, Mobile width).
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save style, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and style is confirmed will you load {nextStepFile} to begin generating wireframes.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Fidelity level selected
|
||||
- Design style influence loaded
|
||||
- Annotation preference set
|
||||
- Complete style confirmed
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating without defined style
|
||||
- Not offering fidelity options
|
||||
- Skipping design style influence
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: 'step-04-generate'
|
||||
description: 'Craft optimized prompts and generate wireframes through MCP service or prompt export'
|
||||
nextStepFile: './step-05-review.md'
|
||||
---
|
||||
|
||||
# Step 4: Generate Wireframes
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Craft optimized prompts from context and style, generate wireframes through MCP service or export prompts for external tools, using approved results as references for batch consistency.
|
||||
|
||||
## 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 a creative production partner executing wireframe generation
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring prompt crafting and generation expertise, user brings approval decisions
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Generate one wireframe at a time, getting approval before continuing
|
||||
- 🚫 FORBIDDEN to batch-generate without approval on first result
|
||||
- 💬 Use approved wireframes as reference for consistency
|
||||
- 📋 Track and display batch progress
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Track progress per page/view
|
||||
- 📖 Chain approved results as references for subsequent generations
|
||||
- 🚫 FORBIDDEN to skip per-page approval
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Inventory (Step 2), style configuration (Step 3)
|
||||
- Focus: Crafting prompts and executing generation
|
||||
- Limits: Generate only — full set review happens in Step 5
|
||||
- Dependencies: Confirmed style and scoped inventory
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Craft Prompt Template
|
||||
|
||||
Build base prompt from context + style: fidelity, grid description, content zones, style influence keywords, dimensions, grayscale palette, annotation preference.
|
||||
|
||||
### 2. Customize Per Page
|
||||
|
||||
Insert page-specific content zones, navigation state, and unique layout requirements.
|
||||
|
||||
### 3. Select Service
|
||||
|
||||
[G] Generate via MCP or [E] Export prompts for external tool.
|
||||
|
||||
### 4. Execute Generation
|
||||
|
||||
MCP path: send prompts sequentially, attach approved results as reference for consistency. Export path: save formatted prompts to `{output_folder}/E-Assets/wireframes/prompts/`.
|
||||
|
||||
### 5. Track Progress
|
||||
|
||||
Display completion status per page/view.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save generated wireframes, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all scoped wireframes are generated will you load {nextStepFile} to begin reviewing the set.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Prompts crafted from context and style
|
||||
- Wireframes generated with reference chaining
|
||||
- Progress tracked per page/view
|
||||
- Service selection respected
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Batch-generating without first-result approval
|
||||
- Not using references for consistency
|
||||
- Skipping progress tracking
|
||||
- Not waiting for user input at menu
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
112
_bmad/wds/workflows/6-asset-generation/steps-w/step-05-review.md
Normal file
112
_bmad/wds/workflows/6-asset-generation/steps-w/step-05-review.md
Normal file
@@ -0,0 +1,112 @@
|
||||
---
|
||||
name: 'step-05-review'
|
||||
description: 'Review generated wireframes as a set for consistency and iterate on flagged items'
|
||||
workflowFile: '../workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Review and Iterate
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Review all generated wireframes as a cohesive set, verify consistency across pages, iterate on any that need work, and save the final approved set.
|
||||
|
||||
## 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 a creative production partner conducting quality review
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring visual consistency expertise, user brings final approval
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Review as a complete set, not individual wireframes in isolation
|
||||
- 🚫 FORBIDDEN to save without user approval
|
||||
- 💬 Present desktop and mobile side by side
|
||||
- 📋 Check grid alignment, navigation placement, typography hierarchy, spacing
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the Sequence of Instructions exactly
|
||||
- 💾 Save to `{output_folder}/E-Assets/wireframes/`
|
||||
- 📖 Check consistency: grid, navigation, typography, spacing, labels
|
||||
- 🚫 FORBIDDEN to skip consistency checks
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All generated wireframes, style configuration
|
||||
- Focus: Quality review and final approval
|
||||
- Limits: This is the final step — focus on quality and delivery
|
||||
- Dependencies: Generated wireframes from Step 4
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Present Full Set
|
||||
|
||||
Display all wireframes grouped by page, desktop and mobile side by side.
|
||||
|
||||
### 2. Consistency Check
|
||||
|
||||
Verify: grid alignment consistent, navigation placement consistent, typography hierarchy consistent, spacing uniform, content zones properly labeled (if annotations on).
|
||||
|
||||
### 3. User Review
|
||||
|
||||
Present: [A] Approve all, [R] Regenerate specific, [S] Style adjust and regenerate all, [E] Edit annotations.
|
||||
|
||||
### 4. Iterate
|
||||
|
||||
For flagged wireframes: gather feedback, adjust prompt, regenerate with approved wireframes as reference, re-review in context.
|
||||
|
||||
### 5. Save Approved Set
|
||||
|
||||
Save to `{output_folder}/E-Assets/wireframes/`: `{page-name}-desktop.png`, `{page-name}-mobile.png`, `wireframe-set-summary.md`.
|
||||
|
||||
### 6. Update Design Log
|
||||
|
||||
Record: wireframes generated count, style used (fidelity + design style), pages covered.
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **"Select an Option:** [M] Return to Activity Menu"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF M: Save set, update design log, return to Activity Menu in {workflowFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step of the Wireframes workflow. When M is selected and set is saved, return to the Activity Menu.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Full set presented for review
|
||||
- Consistency checks completed
|
||||
- User approved final set
|
||||
- Saved to correct output location
|
||||
- Design log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Saving without user approval
|
||||
- Skipping consistency checks
|
||||
- Not updating design log
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,349 @@
|
||||
# Content Creation Workshop - Output
|
||||
|
||||
**Strategically Grounded Content with Full Traceability**
|
||||
|
||||
**Content Section:** {content-section-name}
|
||||
**Page/Context:** {page-or-scenario-name}
|
||||
**Created:** {date}
|
||||
**Method:** WDS Content Creation Workshop (5-Model Framework)
|
||||
|
||||
---
|
||||
|
||||
## Strategic Foundation
|
||||
|
||||
### Step 1: Trigger Map Context
|
||||
|
||||
```yaml
|
||||
trigger_map_reference:
|
||||
business_goal: "{goal text}"
|
||||
solution: "{solution name/description}"
|
||||
user:
|
||||
name: "{persona name}"
|
||||
description: "{brief persona description}"
|
||||
driving_forces:
|
||||
positive: "{wish/aspiration}"
|
||||
negative: "{fear/frustration}"
|
||||
customer_awareness:
|
||||
start: "{awareness level where user begins}"
|
||||
end: "{awareness level we want them to reach}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Content Strategy
|
||||
|
||||
### Step 2: Customer Awareness Strategy
|
||||
|
||||
```yaml
|
||||
awareness_strategy:
|
||||
start_level: "{awareness level}"
|
||||
start_characteristics:
|
||||
- "{what they know}"
|
||||
- "{what they don't know}"
|
||||
- "{how they feel}"
|
||||
|
||||
end_level: "{awareness level}"
|
||||
end_characteristics:
|
||||
- "{what they'll know}"
|
||||
- "{what they'll understand}"
|
||||
- "{how they'll feel}"
|
||||
|
||||
language_guidelines:
|
||||
use: ["{appropriate terms}"]
|
||||
avoid: ["{confusing jargon}"]
|
||||
tone: "{conversational, authoritative, empathetic, etc.}"
|
||||
|
||||
information_priorities:
|
||||
essential: ["{must include}"]
|
||||
helpful: ["{nice to include if space}"]
|
||||
avoid: ["{too advanced, confusing, or premature}"]
|
||||
|
||||
credibility_required:
|
||||
type: "{personal story, expert credentials, data, social proof}"
|
||||
examples: ["{specific proof elements}"]
|
||||
|
||||
emotional_journey:
|
||||
starting_emotion: "{frustrated, confused, etc.}"
|
||||
bridge: "{how we facilitate the shift}"
|
||||
ending_emotion: "{hopeful, confident, etc.}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Content Filtering
|
||||
|
||||
### Step 3: Action Filter
|
||||
|
||||
```yaml
|
||||
action_filter:
|
||||
required_action:
|
||||
description: "{Specific action user must be able to take}"
|
||||
success_criteria: "{How we know they can do it}"
|
||||
|
||||
business_impact:
|
||||
connection: "{How this action drives the business goal}"
|
||||
logic: "{Action → Outcome → Goal}"
|
||||
|
||||
user_motivation:
|
||||
positive_driver: "{How action satisfies their wish}"
|
||||
negative_driver: "{How action addresses their fear}"
|
||||
|
||||
essential_information:
|
||||
- "{Information element 1 - WHY needed for action}"
|
||||
- "{Information element 2 - WHY needed for action}"
|
||||
- "{Information element 3 - WHY needed for action}"
|
||||
|
||||
cut_list:
|
||||
- "{Nice-to-know info that doesn't enable action}"
|
||||
- "{Impressive but irrelevant content}"
|
||||
|
||||
action_barriers:
|
||||
- barrier: "{e.g., confusion about next steps}"
|
||||
solution: "{Content that removes this barrier}"
|
||||
- barrier: "{e.g., fear of commitment}"
|
||||
solution: "{Content that addresses this fear}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Content Framing
|
||||
|
||||
### Step 4: Empowerment Frame
|
||||
|
||||
```yaml
|
||||
empowerment_frame:
|
||||
transformation:
|
||||
current_state:
|
||||
description: "{Where user is now}"
|
||||
feelings: ["{frustrated}", "{uncertain}", "{behind}"]
|
||||
capabilities: "{What they can't do yet}"
|
||||
|
||||
badass_state:
|
||||
description: "{Where they're going}"
|
||||
feelings: ["{confident}", "{capable}", "{ahead}"]
|
||||
capabilities: "{What they'll be able to do}"
|
||||
|
||||
visibility: "{How we make the transformation visible and achievable}"
|
||||
|
||||
aha_moment:
|
||||
insight: "{Key realization that shifts perspective}"
|
||||
why_powerful: "{Why this unlocks confidence}"
|
||||
|
||||
capability_framing:
|
||||
- feature: "{Product feature}"
|
||||
reframed: "{What USER can do because of it}"
|
||||
- feature: "{Product feature}"
|
||||
reframed: "{What USER can do because of it}"
|
||||
|
||||
cognitive_load:
|
||||
potential_issues:
|
||||
- issue: "{Where content might overwhelm}"
|
||||
solution: "{How we reduce load}"
|
||||
|
||||
simplifications:
|
||||
- "{What we simplified or cut}"
|
||||
|
||||
skill_focus:
|
||||
primary_skill: "{Main capability user develops}"
|
||||
supporting_skills: ["{Related capabilities}"]
|
||||
tools_secondary: "{Tools are means to skill, not the focus}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Content Structure
|
||||
|
||||
### Step 5: Structural Order (Golden Circle)
|
||||
|
||||
```yaml
|
||||
structural_order:
|
||||
section_why:
|
||||
purpose: "Emotional truth / Why user should care"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "{Opening hook}"
|
||||
rationale: "{Why this opens}"
|
||||
- order: 2
|
||||
element: "{Validation or aspiration}"
|
||||
rationale: "{Why this comes second}"
|
||||
|
||||
section_how:
|
||||
purpose: "Method / Bridge from emotion to specifics"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "{Solution approach}"
|
||||
rationale: "{Why this bridges first}"
|
||||
- order: 2
|
||||
element: "{Key differentiator}"
|
||||
rationale: "{Why this matters here}"
|
||||
- order: 3
|
||||
element: "{Transformation path}"
|
||||
rationale: "{Why this comes last in HOW}"
|
||||
|
||||
section_what:
|
||||
purpose: "Specifics / Proof / Action"
|
||||
content_elements:
|
||||
- order: 1
|
||||
element: "{Product/offer name}"
|
||||
rationale: "{Why we can name it now}"
|
||||
- order: 2
|
||||
element: "{Social proof}"
|
||||
rationale: "{Why proof comes here}"
|
||||
- order: 3
|
||||
element: "{CTA}"
|
||||
rationale: "{Why action comes last}"
|
||||
|
||||
flow_validation:
|
||||
feels_natural: "{yes/no + notes}"
|
||||
persuasive_arc: "{Does WHY → HOW → WHAT create emotional → logical → action flow?}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Final Content
|
||||
|
||||
### Step 6: Generated Content
|
||||
|
||||
#### Variations Presented
|
||||
|
||||
**Variation A: {Name - e.g., "Wish-Focused"}**
|
||||
|
||||
*Rationale:* {Why this approach, what driving force it emphasizes}
|
||||
|
||||
```
|
||||
WHY Section:
|
||||
{Content for WHY}
|
||||
|
||||
HOW Section:
|
||||
{Content for HOW}
|
||||
|
||||
WHAT Section:
|
||||
{Content for WHAT}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Variation B: {Name}**
|
||||
|
||||
*Rationale:* {Why this approach}
|
||||
|
||||
```
|
||||
WHY Section:
|
||||
{Content for WHY}
|
||||
|
||||
HOW Section:
|
||||
{Content for HOW}
|
||||
|
||||
WHAT Section:
|
||||
{Content for WHAT}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Variation C: {Name}** *(if applicable)*
|
||||
|
||||
*Rationale:* {Why this approach}
|
||||
|
||||
```
|
||||
WHY Section:
|
||||
{Content for WHY}
|
||||
|
||||
HOW Section:
|
||||
{Content for HOW}
|
||||
|
||||
WHAT Section:
|
||||
{Content for WHAT}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### Selection & Refinement
|
||||
|
||||
**Chosen Approach:** {Which variation or combination}
|
||||
|
||||
**Reasoning:** {Why user selected this}
|
||||
|
||||
**Adjustments Made:** {Any refinements}
|
||||
|
||||
---
|
||||
|
||||
#### FINAL CONTENT (Implementation-Ready)
|
||||
|
||||
**WHY Section:**
|
||||
|
||||
```
|
||||
{Final WHY content}
|
||||
```
|
||||
|
||||
**HOW Section:**
|
||||
|
||||
```
|
||||
{Final HOW content}
|
||||
```
|
||||
|
||||
**WHAT Section:**
|
||||
|
||||
```
|
||||
{Final WHAT content}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Strategic Traceability
|
||||
|
||||
**This content serves:**
|
||||
|
||||
- **Business Goal:** {How this drives the goal}
|
||||
- **User Driving Forces:**
|
||||
- Positive: {How it satisfies wish}
|
||||
- Negative: {How it addresses fear}
|
||||
- **Customer Awareness Journey:** {START → END validated}
|
||||
- **Required Action:** {What user can now do}
|
||||
- **User Empowerment:** {How they feel capable}
|
||||
- **Persuasive Structure:** {WHY → HOW → WHAT confirmed}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Technical/Design Requirements:**
|
||||
- {Any technical constraints or requirements}
|
||||
- {Design system components needed}
|
||||
- {Responsive behavior notes}
|
||||
|
||||
**Multi-Language Support:**
|
||||
- English: {Status}
|
||||
- {Language 2}: {Status}
|
||||
- {Language 3}: {Status}
|
||||
|
||||
**Assets Needed:**
|
||||
- Images: {List image requirements}
|
||||
- Videos: {List video requirements}
|
||||
- Icons/Graphics: {List graphic requirements}
|
||||
|
||||
**Testing Considerations:**
|
||||
- {A/B test recommendations}
|
||||
- {User testing focus areas}
|
||||
- {Success metrics to track}
|
||||
|
||||
---
|
||||
|
||||
## Workshop Metadata
|
||||
|
||||
**Duration:** {Actual time spent}
|
||||
|
||||
**Participants:**
|
||||
- Designer: {name}
|
||||
- Agent: {agent name}
|
||||
|
||||
**Alpha Feedback:**
|
||||
- {What worked well}
|
||||
- {What felt clunky}
|
||||
- {What's missing}
|
||||
- {How to improve}
|
||||
|
||||
---
|
||||
|
||||
_Created using WDS Content Creation Workshop (5-Model Framework)_
|
||||
_Models: Trigger Map, Customer Awareness Cycle, Action Mapping, Badass Users, Golden Circle_
|
||||
|
||||
@@ -0,0 +1,174 @@
|
||||
# Stitch Prompt Template
|
||||
|
||||
Use this template to prepare an effective Stitch prompt from a WDS specification.
|
||||
|
||||
---
|
||||
|
||||
## How to Use
|
||||
|
||||
1. **Copy this template** into your Stitch dialog
|
||||
2. **Fill in each section** using your spec and design system
|
||||
3. **Remove Object IDs, translations, technical details** - Stitch doesn't need them
|
||||
4. **Keep one language only** - typically the primary language (English or Swedish)
|
||||
5. **Paste the filled template** as your Stitch prompt
|
||||
|
||||
---
|
||||
|
||||
## Template Structure
|
||||
|
||||
```
|
||||
=== PROJECT CONTEXT ===
|
||||
|
||||
App: {App name} - {One-line description}
|
||||
Target: {Target audience}
|
||||
Brand feel: {2-3 adjectives describing the feel}
|
||||
Market: {Market focus if relevant}
|
||||
|
||||
=== DESIGN SYSTEM ===
|
||||
|
||||
Colors:
|
||||
- Background: {color name} ({hex})
|
||||
- Primary/CTA: {color name} ({hex})
|
||||
- Text: {color name} ({hex})
|
||||
- Secondary text: {color name} ({hex})
|
||||
- Success: {hex}
|
||||
- Error: {hex}
|
||||
|
||||
Typography:
|
||||
- Font: {font family}
|
||||
- Headlines: {weight}, {characteristics}
|
||||
- Body: {weight}, {size}
|
||||
|
||||
Component styles:
|
||||
- Buttons: {style description - rounded, gradient, shadow, etc.}
|
||||
- Inputs: {style description - border, focus state, etc.}
|
||||
- Cards: {style description if relevant}
|
||||
|
||||
=== SCREEN DETAILS ===
|
||||
|
||||
Screen: {Screen name}
|
||||
Purpose: {What this screen does, one sentence}
|
||||
User context: {Where user is coming from, what they need}
|
||||
|
||||
Layout structure:
|
||||
1. {Section 1}: {elements}
|
||||
2. {Section 2}: {elements}
|
||||
3. {Section 3}: {elements}
|
||||
|
||||
Key elements:
|
||||
- {Element 1}: "{Actual content/text}"
|
||||
- {Element 2}: "{Actual content/text}"
|
||||
- {Element 3}: "{Actual content/text}"
|
||||
|
||||
Key interactions:
|
||||
- Primary action: {what happens}
|
||||
- Secondary action: {what happens}
|
||||
|
||||
=== CURRENT STATE NOTES ===
|
||||
|
||||
{Note any elements currently using default/unstyled components}
|
||||
- {Component}: Currently ShadCN default, should match brand style
|
||||
- {Component}: Uses custom gradient button
|
||||
|
||||
=== GENERATION INSTRUCTIONS ===
|
||||
|
||||
Generate this screen matching:
|
||||
- Visual style of the attached reference image
|
||||
- Layout structure of the attached sketch
|
||||
- All content and elements listed above
|
||||
|
||||
Viewport: {Mobile 390px / Desktop 1440px}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example: Dog Week Sign-In
|
||||
|
||||
```
|
||||
=== PROJECT CONTEXT ===
|
||||
|
||||
App: Dog Week - Family dog walk coordination app
|
||||
Target: Swedish families (all ages from teens to grandparents)
|
||||
Brand feel: Warm, friendly, trustworthy
|
||||
Market: Sweden
|
||||
|
||||
=== DESIGN SYSTEM ===
|
||||
|
||||
Colors:
|
||||
- Background: Cream (#FEF3CF), gradient to #FFFBED
|
||||
- Primary/CTA: Orange (#FD6408), gradient #FD8002 to #FF2714
|
||||
- Text: Brown (#2F1A0C)
|
||||
- Secondary text: Gray (#686868)
|
||||
- Success: Green (#28C54A)
|
||||
- Error: Red (#DB0000)
|
||||
|
||||
Typography:
|
||||
- Font: Inter
|
||||
- Headlines: Bold/Extra Bold, tight letter spacing
|
||||
- Body: Regular weight, 16px base
|
||||
|
||||
Component styles:
|
||||
- Buttons: Rounded (8px), orange gradient for primary, subtle shadow
|
||||
- Inputs: Light background, rounded corners, brown text
|
||||
- Cards: Cream background, subtle shadow
|
||||
|
||||
=== SCREEN DETAILS ===
|
||||
|
||||
Screen: Sign In
|
||||
Purpose: Authenticate users with email magic link or Google SSO
|
||||
User context: Coming from Start Page, ready to access the app
|
||||
|
||||
Layout structure:
|
||||
1. Header: Logo (left), Back button (right)
|
||||
2. Main form: Email input, magic link button, divider, Google SSO
|
||||
3. Trust section: Privacy and security messages
|
||||
4. Help links: Support links at bottom
|
||||
|
||||
Key elements:
|
||||
- Email input label: "Email address"
|
||||
- Email placeholder: "your@email.com"
|
||||
- Helper text: "We'll send you a magic link to sign in"
|
||||
- Primary button: "Send magic link"
|
||||
- Divider text: "Or sign in with"
|
||||
- Google button: "Continue with Google"
|
||||
- Trust message 1: "Your information is secure and private"
|
||||
- Trust message 2: "We'll never spam you or share your details"
|
||||
- Trust message 3: "Safe for all family members to use"
|
||||
|
||||
Key interactions:
|
||||
- Primary: Enter email → Send magic link → Check email
|
||||
- Secondary: Click Google → OAuth flow → Signed in
|
||||
|
||||
=== CURRENT STATE NOTES ===
|
||||
|
||||
- Input fields: Currently ShadCN default styling, should use cream background
|
||||
- Google button: Should match brand's rounded style with Google colors
|
||||
- Trust icons: Need checkmark or shield icons in success green
|
||||
|
||||
=== GENERATION INSTRUCTIONS ===
|
||||
|
||||
Generate this sign-in screen matching:
|
||||
- Visual style of the attached Start Page screenshot (warm, cream, orange CTAs)
|
||||
- Layout structure of the attached sketch
|
||||
- All content and elements listed above
|
||||
|
||||
Viewport: Mobile 390px
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Checklist Before Pasting to Stitch
|
||||
|
||||
- [ ] Project context filled (app name, target, brand feel)
|
||||
- [ ] Design system colors accurate (from Color-Palette.md)
|
||||
- [ ] Typography correct (from Typography-System.md)
|
||||
- [ ] Component styles described (buttons, inputs)
|
||||
- [ ] Screen content in ONE language only (no translations)
|
||||
- [ ] No Object IDs included
|
||||
- [ ] No technical implementation details
|
||||
- [ ] Current state notes added (what's ShadCN default)
|
||||
- [ ] Viewport specified
|
||||
|
||||
---
|
||||
|
||||
_Stitch Prompt Template — Freya WDS Designer_
|
||||
49
_bmad/wds/workflows/6-asset-generation/workflow-content.md
Normal file
49
_bmad/wds/workflows/6-asset-generation/workflow-content.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: content-creation
|
||||
description: Strategic text content generation using the 5-model framework
|
||||
---
|
||||
|
||||
# Content Creation
|
||||
|
||||
**Goal:** Generate strategically grounded text content using the Five-Model Framework.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## The Five-Model Framework
|
||||
|
||||
1. **Content Purpose** — The job to do
|
||||
2. **Trigger Map** — Strategic foundation
|
||||
3. **Customer Awareness Cycle** — Content strategy
|
||||
4. **Action Mapping** — Content filter
|
||||
5. **Badass Users** — Tone & frame
|
||||
6. **Golden Circle** — Structural order (WHY > HOW > WHAT)
|
||||
|
||||
---
|
||||
|
||||
## Steps
|
||||
|
||||
Execute steps in `./steps-c/`:
|
||||
|
||||
| Step | File | Purpose |
|
||||
|------|------|---------|
|
||||
| 00 | step-00-define-purpose.md | Define content purpose |
|
||||
| 01 | step-01-load-trigger-map-context.md | Load Trigger Map context |
|
||||
| 02 | step-02-awareness-strategy.md | Awareness strategy |
|
||||
| 03 | step-03-action-filter.md | Action mapping filter |
|
||||
| 04 | step-04-empowerment-frame.md | Empowerment framing |
|
||||
| 05 | step-05-structural-order.md | Golden Circle structure |
|
||||
| 06 | step-06-generate-content.md | Generate content |
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action
|
||||
3. Return to activity menu
|
||||
74
_bmad/wds/workflows/6-asset-generation/workflow-figma.md
Normal file
74
_bmad/wds/workflows/6-asset-generation/workflow-figma.md
Normal file
@@ -0,0 +1,74 @@
|
||||
---
|
||||
name: figma-integration
|
||||
description: Code-to-Figma and Figma-to-code workflows for design review and visual iteration
|
||||
web_bundle: true
|
||||
---
|
||||
|
||||
# Figma Integration
|
||||
|
||||
**Goal:** Send code implementations to Figma for design review, documentation, and visual iteration
|
||||
|
||||
**Your Role:** Guide the agent through specification-driven Figma export using html.to.design MCP Server
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## WHEN TO USE
|
||||
|
||||
Send code to Figma when:
|
||||
- Component states need visual documentation (hover, active, disabled, etc.)
|
||||
- Design system components require Figma library representation
|
||||
- Prototype pages need designer review and feedback
|
||||
- Visual adjustments are easier to iterate in Figma than code
|
||||
- Design-code parity documentation is needed
|
||||
|
||||
---
|
||||
|
||||
## STEP PROCESSING RULES
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before action
|
||||
2. **FOLLOW SEQUENCE**: Execute all sections in order
|
||||
3. **WAIT FOR INPUT**: Halt at menus and wait for user selection
|
||||
|
||||
---
|
||||
|
||||
## STEPS
|
||||
|
||||
Execute steps in `./steps-f/`:
|
||||
|
||||
| Step | File | Purpose | Time |
|
||||
|------|------|---------|------|
|
||||
| 01 | step-01-connection-check.md | Verify MCP connection, guide setup | ~5-10 min |
|
||||
| 02 | step-02-identify-export-type.md | Determine export type | ~2-3 min |
|
||||
| 03 | step-03-prepare-specifications.md | Find/create specs with OBJECT IDs | ~5-15 min |
|
||||
| 04 | step-04-generate-validate.md | Generate Figma-compatible HTML | ~5-10 min |
|
||||
| 05 | step-05-execute-export.md | Execute export and verify | ~2-5 min |
|
||||
|
||||
---
|
||||
|
||||
## REFERENCE CONTENT
|
||||
|
||||
| Location | Purpose |
|
||||
|----------|---------|
|
||||
| `data/figma-plugin-setup.md` | Plugin installation and MCP verification |
|
||||
| `data/figma-spec-preparation.md` | Code analysis and OBJECT ID generation |
|
||||
| `data/figma-integration-guide.md` | Figma-to-code workflow guide |
|
||||
| `data/figma-integration-summary.md` | Integration overview and concepts |
|
||||
| `data/figma-designer-guide.md` | Guide for designers in Figma |
|
||||
| `data/figma-mcp-integration.md` | MCP integration technical docs |
|
||||
| `data/mcp-server-integration.md` | MCP server setup and configuration |
|
||||
| `data/tools-reference.md` | Figma MCP tools and parameters |
|
||||
| `data/when-to-extract-decision-guide.md` | Decision tree for when to use Figma integration |
|
||||
| `data/prototype-to-figma-workflow.md` | Iterative refinement workflow |
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action (visual refinement, design system update, or re-render)
|
||||
38
_bmad/wds/workflows/6-asset-generation/workflow-icons.md
Normal file
38
_bmad/wds/workflows/6-asset-generation/workflow-icons.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: icons
|
||||
description: Generate icon sets and individual icons matching design system
|
||||
---
|
||||
|
||||
# Icons
|
||||
|
||||
**Goal:** Generate consistent icon sets and individual icons that match the project's visual direction.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## Steps
|
||||
|
||||
Execute steps in `./steps-i/`:
|
||||
|
||||
| Step | File | Purpose |
|
||||
|------|------|---------|
|
||||
| 01 | step-01-load-context.md | Load design system and icon requirements |
|
||||
| 02 | step-02-inventory.md | Identify icons needed across all pages |
|
||||
| 03 | step-03-select-style.md | Choose icon style (outline, filled, etc.) |
|
||||
| 04 | step-04-generate.md | Craft prompts and batch-generate icons |
|
||||
| 05 | step-05-review.md | Review set consistency, iterate outliers |
|
||||
|
||||
Content to be defined.
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action
|
||||
3. Return to activity menu
|
||||
39
_bmad/wds/workflows/6-asset-generation/workflow-images.md
Normal file
39
_bmad/wds/workflows/6-asset-generation/workflow-images.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: images
|
||||
description: Generate photos, illustrations, and backgrounds from specifications
|
||||
---
|
||||
|
||||
# Images
|
||||
|
||||
**Goal:** Generate production-quality images (hero shots, product photos, illustrations, backgrounds) consistent with the visual direction.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## Steps
|
||||
|
||||
Execute steps in `./steps-m/`:
|
||||
|
||||
| Step | File | Purpose |
|
||||
|------|------|---------|
|
||||
| 01 | step-01-load-context.md | Load page specs, visual direction, brand assets |
|
||||
| 02 | step-02-inventory.md | Identify all images needed (single or batch) |
|
||||
| 03 | step-03-select-style.md | Choose content style (photorealistic, illustration, etc.) |
|
||||
| 04 | step-04-references.md | Attach reference images for consistency |
|
||||
| 05 | step-05-generate.md | Craft prompts and generate, using earlier results as reference |
|
||||
| 06 | step-06-review.md | Review as set, flag outliers for regeneration |
|
||||
|
||||
Content to be defined.
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action
|
||||
3. Return to activity menu
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: page-designs
|
||||
description: Generate full page design compositions from specifications
|
||||
---
|
||||
|
||||
# Page Designs
|
||||
|
||||
**Goal:** Generate complete page design compositions that bring UX specifications to life.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## Steps
|
||||
|
||||
Execute steps in `./steps-p/`:
|
||||
|
||||
| Step | File | Purpose |
|
||||
|------|------|---------|
|
||||
| 01 | step-01-load-context.md | Load page specs, design system, visual direction |
|
||||
| 02 | step-02-inventory.md | Identify pages needing designs |
|
||||
| 03 | step-03-select-style.md | Choose design style and content style |
|
||||
| 04 | step-04-generate.md | Craft prompts and generate page designs |
|
||||
| 05 | step-05-review.md | Review and iterate |
|
||||
|
||||
Content to be defined.
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action
|
||||
3. Return to activity menu
|
||||
146
_bmad/wds/workflows/6-asset-generation/workflow-stitch.md
Normal file
146
_bmad/wds/workflows/6-asset-generation/workflow-stitch.md
Normal file
@@ -0,0 +1,146 @@
|
||||
---
|
||||
name: stitch-generation
|
||||
description: AI-assisted UI design using Google Stitch from specifications and sketches
|
||||
web_bundle: true
|
||||
---
|
||||
|
||||
# Stitch UI Generation
|
||||
|
||||
**Goal:** Generate production-quality UI designs using Google Stitch AI
|
||||
|
||||
**Your Role:** Guide the user through preparing inputs and creating a Stitch generation dialog
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## OVERVIEW
|
||||
|
||||
Google Stitch transforms text prompts, sketches, and reference images into responsive interfaces.
|
||||
|
||||
**Input Formula:**
|
||||
```
|
||||
Visual Reference + Sketch + Specification = Stitch Generation
|
||||
```
|
||||
|
||||
**Output:** UI designs exportable to Figma or HTML/CSS
|
||||
|
||||
---
|
||||
|
||||
## WHEN TO USE
|
||||
|
||||
**Use Stitch when:**
|
||||
- New page with detailed specification ready
|
||||
- Have a visual reference (existing design or screenshot)
|
||||
- Have a sketch showing layout structure
|
||||
- Want rapid visual design iteration
|
||||
|
||||
**Skip when:**
|
||||
- Building design system components (use tokens instead)
|
||||
- Minor updates to existing designs
|
||||
- No specification exists yet (write spec first)
|
||||
|
||||
---
|
||||
|
||||
## PREREQUISITES
|
||||
|
||||
1. **Specification exists** for the screen(s) to generate
|
||||
2. **Visual reference available** (screenshot or approved design)
|
||||
3. **Sketch available** showing layout structure
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW
|
||||
|
||||
### Step 1: Create Generation Log
|
||||
|
||||
Create a Stitch generation log in the agent experiences folder.
|
||||
|
||||
**Location:** `{output_folder}/_progress/agent-experiences/{YYYY-MM-DD}-stitch-{feature}.md`
|
||||
|
||||
### Step 2: Pre-Generation Questions
|
||||
|
||||
For each potential screen, decide:
|
||||
|
||||
| Question | Columns |
|
||||
|----------|---------|
|
||||
| Generate in Stitch? | Screen, Has Code?, Has Sketch?, Generate?, Why |
|
||||
| What reference? | Screen, Reference, Source |
|
||||
|
||||
### Step 3: Gather Inputs
|
||||
|
||||
| Input | Action |
|
||||
|-------|--------|
|
||||
| **Visual Reference** | Take screenshot OR locate existing design |
|
||||
| **Sketch** | Locate in spec's `Sketches/` folder |
|
||||
| **Prompt** | Prepare using template below |
|
||||
|
||||
### Step 3a: Prepare the Prompt
|
||||
|
||||
**DO NOT paste raw specifications into Stitch.** Use the prompt template instead.
|
||||
|
||||
**Template:** `templates/stitch-prompt.template.md`
|
||||
|
||||
Include: Project Context, Design System, Component Styles, Screen Content (ONE language, no Object IDs), Current State Notes.
|
||||
|
||||
### Step 4: Generate in Stitch
|
||||
|
||||
1. Go to [stitch.withgoogle.com](https://stitch.withgoogle.com)
|
||||
2. Upload visual reference and sketch images
|
||||
3. Paste prepared prompt
|
||||
4. Generate 2-3 variants
|
||||
5. Select best result
|
||||
|
||||
**Settings:** Standard Mode (quick) or Pro Mode (higher fidelity). Viewport: Mobile 390px or Desktop 1440px.
|
||||
|
||||
### Step 5: Review Against Spec
|
||||
|
||||
| Check | Pass? |
|
||||
|-------|-------|
|
||||
| Content/copy matches spec | |
|
||||
| Layout follows sketch | |
|
||||
| Visual style matches reference | |
|
||||
| All key elements present | |
|
||||
|
||||
If issues: Re-prompt with specific corrections or edit in Stitch.
|
||||
|
||||
### Step 6: Export & Store
|
||||
|
||||
| Format | When | Destination |
|
||||
|--------|------|-------------|
|
||||
| **Figma** | Team collaboration | Figma project |
|
||||
| **HTML/CSS** | Code reference | `{spec-folder}/Visual-Design/` |
|
||||
| **Screenshot** | Documentation | `{spec-folder}/Visual-Design/` |
|
||||
|
||||
**Naming:** `{screen-name}-stitch-v{#}.{ext}`
|
||||
|
||||
### Step 7: Update Specification
|
||||
|
||||
Add Visual Design section to specification referencing the Stitch output.
|
||||
|
||||
---
|
||||
|
||||
## STITCH CAPABILITIES & LIMITS
|
||||
|
||||
**Does well:** Single screen generation, style matching, responsive layouts, clean HTML/CSS export, Figma-compatible output.
|
||||
|
||||
**Limitations:** Best with 2-3 screens at a time, layouts can be generic, no built-in design system awareness, free tier limits (350 standard + 200 pro/month).
|
||||
|
||||
---
|
||||
|
||||
## PROMPT TIPS
|
||||
|
||||
Effective prompts include: App type, Context, Visual direction, Key elements, Actual content/text, Mood/tone, Viewport.
|
||||
|
||||
**Template:** See `templates/stitch-prompt.template.md` for complete structure and example.
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action (implementation or further iteration)
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: ui-elements
|
||||
description: Generate UI components — buttons, cards, forms, navigation elements
|
||||
---
|
||||
|
||||
# UI Elements
|
||||
|
||||
**Goal:** Generate UI component assets (buttons, cards, forms, navigation) consistent with the design system.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## Steps
|
||||
|
||||
Execute steps in `./steps-u/`:
|
||||
|
||||
| Step | File | Purpose |
|
||||
|------|------|---------|
|
||||
| 01 | step-01-load-context.md | Load design system and component specs |
|
||||
| 02 | step-02-inventory.md | Identify components needing generation |
|
||||
| 03 | step-03-select-style.md | Choose design style |
|
||||
| 04 | step-04-generate.md | Craft prompts and generate components |
|
||||
| 05 | step-05-review.md | Review and iterate |
|
||||
|
||||
Content to be defined.
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action
|
||||
3. Return to activity menu
|
||||
38
_bmad/wds/workflows/6-asset-generation/workflow-videos.md
Normal file
38
_bmad/wds/workflows/6-asset-generation/workflow-videos.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: videos
|
||||
description: Generate motion content and animations from specifications
|
||||
---
|
||||
|
||||
# Videos
|
||||
|
||||
**Goal:** Generate motion content, animations, and video assets for the project.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## Steps
|
||||
|
||||
Execute steps in `./steps-v/`:
|
||||
|
||||
| Step | File | Purpose |
|
||||
|------|------|---------|
|
||||
| 01 | step-01-load-context.md | Load page specs and motion requirements |
|
||||
| 02 | step-02-inventory.md | Identify video/motion assets needed |
|
||||
| 03 | step-03-select-style.md | Choose content style and motion approach |
|
||||
| 04 | step-04-generate.md | Craft prompts and generate |
|
||||
| 05 | step-05-review.md | Review and iterate |
|
||||
|
||||
Content to be defined.
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action
|
||||
3. Return to activity menu
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: wireframes
|
||||
description: Generate outline wireframes from page specifications
|
||||
---
|
||||
|
||||
# Wireframes
|
||||
|
||||
**Goal:** Generate structural wireframes that visualize page layouts from UX specifications.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### Design Log
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
|
||||
## Steps
|
||||
|
||||
Execute steps in `./steps-w/`:
|
||||
|
||||
| Step | File | Purpose |
|
||||
|------|------|---------|
|
||||
| 01 | step-01-load-context.md | Load page specs and design system |
|
||||
| 02 | step-02-inventory.md | Identify pages needing wireframes |
|
||||
| 03 | step-03-select-style.md | Choose design style |
|
||||
| 04 | step-04-generate.md | Craft prompts and generate wireframes |
|
||||
| 05 | step-05-review.md | Review and iterate |
|
||||
|
||||
Content to be defined.
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action
|
||||
3. Return to activity menu
|
||||
156
_bmad/wds/workflows/6-asset-generation/workflow.md
Normal file
156
_bmad/wds/workflows/6-asset-generation/workflow.md
Normal file
@@ -0,0 +1,156 @@
|
||||
---
|
||||
name: asset-generation
|
||||
description: Generate visual and text assets from specifications through AI-powered creative production
|
||||
web_bundle: true
|
||||
---
|
||||
|
||||
# Phase 6: Asset Generation
|
||||
|
||||
**Goal:** Transform UX specifications into production-ready assets — wireframes, page designs, UI elements, icons, images, videos, and strategic content — using AI-powered creative tools.
|
||||
|
||||
**Your Role:** Creative production partner. You read specifications, craft precise prompts using style libraries, and orchestrate batch generation through MCP services. The user brings creative direction; you bring systematic execution.
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
Phase 6 is **menu-driven**, not linear. The user picks what to generate.
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Specification-Driven**: Every asset traces back to an approved page spec or design system
|
||||
- **Style Library**: Design styles and content styles ensure visual consistency
|
||||
- **Prompt Crafting**: WDS translates specs + style into optimized generation prompts
|
||||
- **Batch Automation**: Generate all assets of a type in one session (e.g., "17 vehicle images for Källa")
|
||||
- **Reference Image Support**: Send reference images with prompts for visual consistency across batches
|
||||
- **Service Flexibility**: MCP-powered generation preferred; prompt export as fallback for external services
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before action
|
||||
2. **FOLLOW SEQUENCE**: Execute all sections in order
|
||||
3. **WAIT FOR INPUT**: Halt at menus and wait for user selection
|
||||
4. **SAVE STATE**: Update design log when completing steps
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION
|
||||
|
||||
### 1. Configuration Loading
|
||||
|
||||
Load and read full config from `{project-root}/_bmad/wds/config.yaml` and resolve:
|
||||
- `project_name`, `output_folder`, `user_name`
|
||||
- `communication_language`, `document_output_language`
|
||||
|
||||
### 2. Design Log
|
||||
|
||||
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
||||
|
||||
### 3. Activity Menu
|
||||
|
||||
```
|
||||
What would you like to generate?
|
||||
|
||||
[W] Wireframes — Outline wireframes from page specs
|
||||
[P] Page Designs — Full page design compositions
|
||||
[U] UI Elements — Buttons, cards, forms, components
|
||||
[I] Icons — Icon sets and individual icons
|
||||
[M] Images — Photos, illustrations, backgrounds
|
||||
[V] Videos — Motion content and animations
|
||||
[C] Content — Strategic text content (5-model framework)
|
||||
[E] Export to Figma — Push specs and assets to Figma
|
||||
```
|
||||
|
||||
### Activity Routing
|
||||
|
||||
| Choice | Workflow File | Steps Folder |
|
||||
|--------|--------------|--------------|
|
||||
| [W] | workflow-wireframes.md | steps-w/ |
|
||||
| [P] | workflow-page-designs.md | steps-p/ |
|
||||
| [U] | workflow-ui-elements.md | steps-u/ |
|
||||
| [I] | workflow-icons.md | steps-i/ |
|
||||
| [M] | workflow-images.md | steps-m/ |
|
||||
| [V] | workflow-videos.md | steps-v/ |
|
||||
| [C] | workflow-content.md | steps-c/ |
|
||||
| [E] | workflow-figma.md | steps-f/ |
|
||||
|
||||
---
|
||||
|
||||
## SHARED GENERATION PATTERN
|
||||
|
||||
All visual activities (W, P, U, I, M, V) follow this pattern:
|
||||
|
||||
1. **Load Context** — Read relevant page specs, design system, visual direction
|
||||
2. **Asset Inventory** — Identify all assets needed (single or batch)
|
||||
3. **Select Style** — Choose design style + content style from libraries
|
||||
4. **Reference Images** — Attach reference images for visual consistency (when supported)
|
||||
5. **Craft Prompts** — Translate spec + style + references into generation prompts
|
||||
6. **Select Service** — Route to MCP service or export prompts for external use
|
||||
7. **Generate & Review** — Execute generation, review results, iterate
|
||||
|
||||
### Batch Mode
|
||||
|
||||
For batch generation (e.g., "generate all hero images for the site"):
|
||||
- Inventory all assets of the type from specs
|
||||
- Apply consistent style across the batch
|
||||
- Cycle through generation, using earlier results as reference for consistency
|
||||
- Review as a set, flag outliers for regeneration
|
||||
|
||||
### Prompt Export Fallback
|
||||
|
||||
When MCP service is unavailable or user prefers external tools:
|
||||
- Craft the full prompt with all context
|
||||
- Format for copy-paste into target service
|
||||
- Include style parameters, dimensions, and reference notes
|
||||
|
||||
---
|
||||
|
||||
## STYLE LIBRARIES
|
||||
|
||||
### Design Styles
|
||||
|
||||
Predefined visual approaches loaded from `data/styles/design-styles/`:
|
||||
- Minimal, Brutalist, Organic, Corporate, Playful, etc.
|
||||
- Each defines: color treatment, spacing, typography feel, mood
|
||||
|
||||
### Content Styles
|
||||
|
||||
Visual rendering styles loaded from `data/styles/content-styles/`:
|
||||
- Photorealistic, Illustration, Watercolor, Comic Book, Pencil Sketch
|
||||
- Isometric, Flat Design, 3D Render, Hyper-realistic, Line Art, etc.
|
||||
- Each defines: rendering approach, detail level, texture, lighting
|
||||
|
||||
Style selection happens per activity session and can be mixed within a project.
|
||||
|
||||
---
|
||||
|
||||
## REFERENCE CONTENT
|
||||
|
||||
| Location | Purpose |
|
||||
|----------|---------|
|
||||
| `data/styles/design-styles/` | Design style definitions |
|
||||
| `data/styles/content-styles/` | Content style definitions |
|
||||
| `data/` | Framework guides, examples, service integration docs |
|
||||
| `templates/` | Content output, prompt templates |
|
||||
|
||||
---
|
||||
|
||||
## OUTPUT
|
||||
|
||||
- Wireframe images and annotated layouts
|
||||
- Page design compositions
|
||||
- UI element assets (buttons, cards, forms)
|
||||
- Icon sets (SVG, PNG)
|
||||
- Images (hero, product, background, illustration)
|
||||
- Video/motion assets
|
||||
- Strategic text content
|
||||
- Figma design files
|
||||
|
||||
Output stored in `{output_folder}/E-Assets/` organized by type.
|
||||
|
||||
---
|
||||
|
||||
## AFTER COMPLETION
|
||||
|
||||
1. Update design log
|
||||
2. Suggest next action or return to Activity Menu
|
||||
Reference in New Issue
Block a user