Remove Idunn agent — Freya takes over PM responsibilities
Idunn (PM agent) has been deprecated. Freya now handles design delivery, product evolution, and agentic development. Platform requirements moved to Saga under Phase 1. Deleted 9 Idunn-owned files, updated 33 files across src/ and docs/. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Mårten Angner
parent
2813a23601
commit
dadffaffbb
|
|
@ -8,7 +8,7 @@
|
||||||
|
|
||||||
**WDS (Whiteport Design Studio)** is an AI agent framework module within the BMAD Method that transforms how designers work. Instead of creating documentation that gets lost in translation, your design work becomes **powerful prompts** that guide AI agents and development teams with precision and intent.
|
**WDS (Whiteport Design Studio)** is an AI agent framework module within the BMAD Method that transforms how designers work. Instead of creating documentation that gets lost in translation, your design work becomes **powerful prompts** that guide AI agents and development teams with precision and intent.
|
||||||
|
|
||||||
**The Design Delivery PRD** is the final bridge between design and development. Idunn the Technical Architect takes your page specifications and design system and organizes them into developer-ready epics, stories, and implementation sequences. This is where your design work transforms into actionable development tasks.
|
**The Design Delivery PRD** is the final bridge between design and development. Freya takes your page specifications and design system and organizes them into developer-ready epics, stories, and implementation sequences. This is where your design work transforms into actionable development tasks.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -22,7 +22,7 @@ The Design Delivery PRD organizes your page specifications and design system int
|
||||||
- Implementation sequence
|
- Implementation sequence
|
||||||
- Links back to page specifications
|
- Links back to page specifications
|
||||||
|
|
||||||
**Created by:** Idunn the Technical Architect
|
**Created by:** Freya the Designer
|
||||||
**When:** Phase 7 - After page specs and design system are complete
|
**When:** Phase 7 - After page specs and design system are complete
|
||||||
**Format:** PRD document with epics, stories, and implementation guide
|
**Format:** PRD document with epics, stories, and implementation guide
|
||||||
|
|
||||||
|
|
@ -87,34 +87,34 @@ For each story:
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## The Dialog with Your Technical Partner: Idunn the Technical Architect
|
## The Dialog with Your Design Partner: Freya the Designer
|
||||||
|
|
||||||
**The Process (2-3 hours):**
|
**The Process (2-3 hours):**
|
||||||
|
|
||||||
Idunn the Technical Architect helps you organize for development:
|
Freya helps you organize for development:
|
||||||
|
|
||||||
```
|
```
|
||||||
Idunn the Technical Architect: "Let's package this for development. I've analyzed
|
Freya: "Let's package this for development. I've analyzed your 8 page
|
||||||
your 8 page specifications. I see 3 major epics."
|
specifications. I see 3 major epics."
|
||||||
|
|
||||||
You: "What are they?"
|
You: "What are they?"
|
||||||
|
|
||||||
Idunn the Technical Architect: "Epic 1: User Authentication & Profile.
|
Freya: "Epic 1: User Authentication & Profile.
|
||||||
Epic 2: Project Dashboard.
|
Epic 2: Project Dashboard.
|
||||||
Epic 3: Task Management. Sound right?"
|
Epic 3: Task Management. Sound right?"
|
||||||
|
|
||||||
You: "Perfect! Which should we build first?"
|
You: "Perfect! Which should we build first?"
|
||||||
|
|
||||||
Idunn the Technical Architect: "Authentication is foundational - everything depends on it.
|
Freya: "Authentication is foundational - everything depends on it.
|
||||||
Dashboard next, then Task Management. I'll create stories..."
|
Dashboard next, then Task Management. I'll create stories..."
|
||||||
|
|
||||||
You: "How many stories total?"
|
You: "How many stories total?"
|
||||||
|
|
||||||
Idunn the Technical Architect: "15 stories across the 3 epics. Each links directly to
|
Freya: "15 stories across the 3 epics. Each links directly to
|
||||||
your page specifications with Object IDs."
|
your page specifications with Object IDs."
|
||||||
```
|
```
|
||||||
|
|
||||||
As you work together, Idunn the Technical Architect creates:
|
As you work together, Freya creates:
|
||||||
- ✅ Epic breakdown
|
- ✅ Epic breakdown
|
||||||
- ✅ User stories with acceptance criteria
|
- ✅ User stories with acceptance criteria
|
||||||
- ✅ Implementation sequence
|
- ✅ Implementation sequence
|
||||||
|
|
@ -124,11 +124,11 @@ As you work together, Idunn the Technical Architect creates:
|
||||||
Then you review together:
|
Then you review together:
|
||||||
|
|
||||||
```
|
```
|
||||||
Idunn the Technical Architect: "Here's your Design Delivery PRD. Ready for development?"
|
Freya: "Here's your Design Delivery PRD. Ready for development?"
|
||||||
|
|
||||||
You: "Move the profile settings story to phase 2 - not critical for MVP."
|
You: "Move the profile settings story to phase 2 - not critical for MVP."
|
||||||
|
|
||||||
Idunn the Technical Architect: "Moved to Epic 4: Post-MVP Enhancements. ✅ PRD is ready."
|
Freya: "Moved to Epic 4: Post-MVP Enhancements. ✅ PRD is ready."
|
||||||
```
|
```
|
||||||
|
|
||||||
**Result:** Design Delivery PRD ready for development team handoff
|
**Result:** Design Delivery PRD ready for development team handoff
|
||||||
|
|
@ -146,10 +146,10 @@ Idunn the Technical Architect: "Moved to Epic 4: Post-MVP Enhancements. ✅ PRD
|
||||||
To start creating your Design Delivery PRD:
|
To start creating your Design Delivery PRD:
|
||||||
|
|
||||||
```
|
```
|
||||||
@idunn Let's create a Design Delivery PRD to hand off to development.
|
@freya Let's create a Design Delivery PRD to hand off to development.
|
||||||
```
|
```
|
||||||
|
|
||||||
Idunn the Technical Architect will analyze your specifications and guide the organization process.
|
Freya will analyze your specifications and guide the organization process.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@
|
||||||
|
|
||||||
**WDS (Whiteport Design Studio)** is an AI agent framework module within the BMAD Method that transforms how designers work. Instead of creating documentation that gets lost in translation, your design work becomes **powerful prompts** that guide AI agents and development teams with precision and intent.
|
**WDS (Whiteport Design Studio)** is an AI agent framework module within the BMAD Method that transforms how designers work. Instead of creating documentation that gets lost in translation, your design work becomes **powerful prompts** that guide AI agents and development teams with precision and intent.
|
||||||
|
|
||||||
**The Platform PRD** ensures your design vision is technically feasible. Idunn the Technical Architect helps you define the technical foundation before UX design begins, preventing costly rework when beautiful designs meet harsh technical reality.
|
**The Platform PRD** ensures your design vision is technically feasible. Saga helps you define the technical foundation before UX design begins, preventing costly rework when beautiful designs meet harsh technical reality.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -21,7 +21,7 @@ The Platform PRD (Product Requirements Document) defines the technical architect
|
||||||
- Security and performance requirements
|
- Security and performance requirements
|
||||||
- Technical constraints and decisions
|
- Technical constraints and decisions
|
||||||
|
|
||||||
**Created by:** Idunn the Technical Architect
|
**Created by:** Saga the Analyst
|
||||||
**When:** Phase 4 - After Trigger Map, before UX design (or in parallel)
|
**When:** Phase 4 - After Trigger Map, before UX design (or in parallel)
|
||||||
**Format:** Structured PRD document + architecture diagrams
|
**Format:** Structured PRD document + architecture diagrams
|
||||||
|
|
||||||
|
|
@ -82,32 +82,31 @@ The Platform PRD (Product Requirements Document) defines the technical architect
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## The Dialog with Your Technical Partner: Idunn the Technical Architect
|
## The Dialog with Your Strategic Partner: Saga the Analyst
|
||||||
|
|
||||||
**The Process (1-2 hours):**
|
**The Process (1-2 hours):**
|
||||||
|
|
||||||
Idunn the Technical Architect helps you define technical boundaries:
|
Saga helps you define technical boundaries:
|
||||||
|
|
||||||
```
|
```
|
||||||
Idunn the Technical Architect: "Let's establish the foundation. What platform
|
Saga: "Let's establish the foundation. What platform are you targeting?"
|
||||||
are you targeting?"
|
|
||||||
|
|
||||||
You: "WordPress site with custom blocks for the design system."
|
You: "WordPress site with custom blocks for the design system."
|
||||||
|
|
||||||
Idunn the Technical Architect: "Smart choice - familiar editing, structured output.
|
Saga: "Smart choice - familiar editing, structured output.
|
||||||
Any third-party integrations?"
|
Any third-party integrations?"
|
||||||
|
|
||||||
You: "Newsletter signup (Mailchimp), analytics (Google Analytics)."
|
You: "Newsletter signup (Mailchimp), analytics (Google Analytics)."
|
||||||
|
|
||||||
Idunn the Technical Architect: "Got it. What about user authentication?"
|
Saga: "Got it. What about user authentication?"
|
||||||
|
|
||||||
You: "No login needed - it's a marketing site."
|
You: "No login needed - it's a marketing site."
|
||||||
|
|
||||||
Idunn the Technical Architect: "Perfect - that simplifies architecture significantly.
|
Saga: "Perfect - that simplifies architecture significantly.
|
||||||
Let me document this..."
|
Let me document this..."
|
||||||
```
|
```
|
||||||
|
|
||||||
As you discuss, Idunn the Technical Architect creates:
|
As you discuss, Saga creates:
|
||||||
- ✅ Technology stack decisions
|
- ✅ Technology stack decisions
|
||||||
- ✅ Data model (if needed)
|
- ✅ Data model (if needed)
|
||||||
- ✅ Integration requirements
|
- ✅ Integration requirements
|
||||||
|
|
@ -118,11 +117,11 @@ As you discuss, Idunn the Technical Architect creates:
|
||||||
Then you review together:
|
Then you review together:
|
||||||
|
|
||||||
```
|
```
|
||||||
Idunn the Technical Architect: "Here's your Platform PRD. Does this match your needs?"
|
Saga: "Here's your Platform PRD. Does this match your needs?"
|
||||||
|
|
||||||
You: "Add mobile-first responsive requirement."
|
You: "Add mobile-first responsive requirement."
|
||||||
|
|
||||||
Idunn the Technical Architect: "Added to technical requirements. ✅ PRD is ready."
|
Saga: "Added to technical requirements. ✅ PRD is ready."
|
||||||
```
|
```
|
||||||
|
|
||||||
**Result:** Platform PRD ready to guide UX design and development
|
**Result:** Platform PRD ready to guide UX design and development
|
||||||
|
|
@ -140,10 +139,10 @@ Idunn the Technical Architect: "Added to technical requirements. ✅ PRD is read
|
||||||
To start creating your Platform PRD:
|
To start creating your Platform PRD:
|
||||||
|
|
||||||
```
|
```
|
||||||
@idunn I need to create a Platform PRD for [Your Project Name].
|
@saga I need to create a Platform PRD for [Your Project Name].
|
||||||
```
|
```
|
||||||
|
|
||||||
Idunn the Technical Architect will begin the conversation and guide you through the process.
|
Saga will begin the conversation and guide you through the process.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -59,7 +59,7 @@ Complete documentation for Whiteport Design Studio - a design-first methodology
|
||||||
- **[Module 05: Trigger Mapping](learn/module-05-map-triggers-outcomes/)** - Map user psychology
|
- **[Module 05: Trigger Mapping](learn/module-05-map-triggers-outcomes/)** - Map user psychology
|
||||||
- **[Module 06+](learn/)** - Continue through all phases
|
- **[Module 06+](learn/)** - Continue through all phases
|
||||||
|
|
||||||
**This course is WDS-specific** - teaching you to use Saga, Freya, and Idunn agents.
|
**This course is WDS-specific** - teaching you to use Saga and Freya agents.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -101,12 +101,11 @@ Complete documentation for Whiteport Design Studio - a design-first methodology
|
||||||
|
|
||||||
## 🤖 Agent Activation
|
## 🤖 Agent Activation
|
||||||
|
|
||||||
**Using WDS agents:** Quick activation guides for Saga, Freya, and Idunn.
|
**Using WDS agents:** Quick activation guides for Saga and Freya.
|
||||||
|
|
||||||
- **[Agent Launchers](getting-started/agent-activation/agent-launchers.md)** - Quick reference
|
- **[Agent Launchers](getting-started/agent-activation/agent-launchers.md)** - Quick reference
|
||||||
- **[Saga WDS Analyst](getting-started/agent-activation/wds-saga-analyst.md)** - Business analysis
|
- **[Saga WDS Analyst](getting-started/agent-activation/wds-saga-analyst.md)** - Business analysis
|
||||||
- **[Freya WDS Designer](getting-started/agent-activation/wds-freya-ux.md)** - UX design
|
- **[Freya WDS Designer](getting-started/agent-activation/wds-freya-ux.md)** - UX design
|
||||||
- **[Idunn WDS PM](getting-started/agent-activation/wds-idunn-pm.md)** - Product management
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -55,7 +55,6 @@ your-project/
|
||||||
│ └── wds/
|
│ └── wds/
|
||||||
│ ├── agents/
|
│ ├── agents/
|
||||||
│ │ ├── freya-ux.agent.yaml
|
│ │ ├── freya-ux.agent.yaml
|
||||||
│ │ ├── idunn-pm.agent.yaml
|
|
||||||
│ │ └── saga-analyst.agent.yaml
|
│ │ └── saga-analyst.agent.yaml
|
||||||
│ ├── workflows/
|
│ ├── workflows/
|
||||||
│ │ ├── 1-project-brief/
|
│ │ ├── 1-project-brief/
|
||||||
|
|
@ -79,8 +78,7 @@ your-project/
|
||||||
3. **Reference the WDS agent** you want to use:
|
3. **Reference the WDS agent** you want to use:
|
||||||
|
|
||||||
```
|
```
|
||||||
@wds/agents/freya-ux - For UX Design & Prototyping
|
@wds/agents/freya-ux - For UX Design, Prototyping & Product Management
|
||||||
@wds/agents/idunn-pm - For Product Management & Analysis
|
|
||||||
@wds/agents/saga-analyst - For Scenario Analysis
|
@wds/agents/saga-analyst - For Scenario Analysis
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
@ -148,8 +146,7 @@ Choose a workflow to start:
|
||||||
|
|
||||||
| Agent | Purpose | Reference |
|
| Agent | Purpose | Reference |
|
||||||
|-------|---------|-----------|
|
|-------|---------|-----------|
|
||||||
| **Freya** | UX Design & Prototyping | `@wds/agents/freya-ux` |
|
| **Freya** | UX Design, Prototyping & Product Management | `@wds/agents/freya-ux` |
|
||||||
| **Idunn** | Product Management | `@wds/agents/idunn-pm` |
|
|
||||||
| **Saga** | Scenario Analysis | `@wds/agents/saga-analyst` |
|
| **Saga** | Scenario Analysis | `@wds/agents/saga-analyst` |
|
||||||
|
|
||||||
### Key Workflows
|
### Key Workflows
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,6 @@ Read and fully embody the persona from your agent definition file.
|
||||||
**Your agent definition file**:
|
**Your agent definition file**:
|
||||||
- Saga: `src/modules/wds/agents/saga-analyst.agent.yaml`
|
- Saga: `src/modules/wds/agents/saga-analyst.agent.yaml`
|
||||||
- Freya: `src/modules/wds/agents/freya-ux.agent.yaml`
|
- Freya: `src/modules/wds/agents/freya-ux.agent.yaml`
|
||||||
- Idunn: `src/modules/wds/agents/idunn-pm.agent.yaml`
|
|
||||||
|
|
||||||
**What to do**:
|
**What to do**:
|
||||||
1. Read the entire agent definition file
|
1. Read the entire agent definition file
|
||||||
|
|
|
||||||
|
|
@ -13,7 +13,6 @@ Show your full presentation even though this is a handoff.
|
||||||
**Your presentation file**:
|
**Your presentation file**:
|
||||||
- Saga: `src/modules/wds/data/presentations/saga-presentation.md`
|
- Saga: `src/modules/wds/data/presentations/saga-presentation.md`
|
||||||
- Freya: `src/modules/wds/data/presentations/freya-presentation.md`
|
- Freya: `src/modules/wds/data/presentations/freya-presentation.md`
|
||||||
- Idunn: `src/modules/wds/data/presentations/idunn-presentation.md`
|
|
||||||
|
|
||||||
**What to do**:
|
**What to do**:
|
||||||
1. Load and show your full presentation
|
1. Load and show your full presentation
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,6 @@ Show your full presentation to introduce yourself.
|
||||||
**Your presentation file**:
|
**Your presentation file**:
|
||||||
- Saga: `src/modules/wds/data/presentations/saga-presentation.md`
|
- Saga: `src/modules/wds/data/presentations/saga-presentation.md`
|
||||||
- Freya: `src/modules/wds/data/presentations/freya-presentation.md`
|
- Freya: `src/modules/wds/data/presentations/freya-presentation.md`
|
||||||
- Idunn: `src/modules/wds/data/presentations/idunn-presentation.md`
|
|
||||||
|
|
||||||
**What to do**:
|
**What to do**:
|
||||||
1. Load and show your full presentation
|
1. Load and show your full presentation
|
||||||
|
|
|
||||||
|
|
@ -20,12 +20,6 @@ Simply reference one of these files in your IDE chat to activate the correspondi
|
||||||
**Specializes in**: Project Briefs, User Research, Strategy
|
**Specializes in**: Project Briefs, User Research, Strategy
|
||||||
**Phases**: 1, 2
|
**Phases**: 1, 2
|
||||||
|
|
||||||
### Idunn - Product Manager 📋
|
|
||||||
|
|
||||||
**File**: `@wds-idunn-pm.md`
|
|
||||||
**Specializes in**: Technical Requirements, Architecture, Delivery
|
|
||||||
**Phases**: 3, 6
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## How It Works
|
## How It Works
|
||||||
|
|
@ -65,11 +59,10 @@ All agents use a **router pattern** for predictable behavior:
|
||||||
|
|
||||||
Each agent focuses on specific WDS phases:
|
Each agent focuses on specific WDS phases:
|
||||||
|
|
||||||
| Agent | Primary Phases | Key Expertise |
|
| Agent | Primary Phases | Key Expertise |
|
||||||
| ----------- | -------------- | ---------------------------- |
|
| ----------- | -------------- | ------------------------------------------ |
|
||||||
| **Saga** | 1-2 | Strategy, research, personas |
|
| **Saga** | 1-2 | Strategy, research, personas |
|
||||||
| **Freya** | 4-5, 7 | Design, prototypes, testing |
|
| **Freya** | 4-8 | Design, prototypes, testing, delivery, PM |
|
||||||
| **Idunn** | 3, 6 | Architecture, delivery, PM |
|
|
||||||
|
|
||||||
If you select a task outside the current agent's domain, they'll seamlessly hand over to the specialist.
|
If you select a task outside the current agent's domain, they'll seamlessly hand over to the specialist.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -25,8 +25,9 @@ I guide you through the creative heart of the WDS journey - from scenarios and u
|
||||||
**I receive handoff from:**
|
**I receive handoff from:**
|
||||||
- **Saga** - Strategic foundation and user personas
|
- **Saga** - Strategic foundation and user personas
|
||||||
|
|
||||||
**I hand off to:**
|
**I also handle:**
|
||||||
- **Idunn** - When designs are ready for technical implementation planning
|
- Design delivery packaging for development handoff
|
||||||
|
- Product evolution and continuous improvement
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,67 +0,0 @@
|
||||||
# Idunn - WDS Technical Architect Agent
|
|
||||||
|
|
||||||
## 🏗️ Who I Am
|
|
||||||
|
|
||||||
I'm Idunn, your implementation bridge and technical strategist. Named after the Norse goddess who guards the golden apples of eternal youth, I ensure your designs stay fresh and viable through flawless technical execution. I translate your design vision into technical reality, making sure nothing gets lost between creative concept and working product.
|
|
||||||
|
|
||||||
I guide you through the technical architecture and handoff phases - from platform requirements and data structures to organized PRD documents that developers actually want to work with. I'm here to ensure your design specifications become actionable development instructions, whether you're working with AI agents or human development teams.
|
|
||||||
|
|
||||||
## 🎯 What I Help You Create
|
|
||||||
|
|
||||||
**Phase 3: Nail Down the Platform Requirements**
|
|
||||||
- [Platform PRD & Architecture](../../deliverables/platform-prd.md) - Define technical foundation and system architecture
|
|
||||||
|
|
||||||
**Phase 6: Hand Off to Development**
|
|
||||||
- [Design Delivery PRD](../../deliverables/design-delivery-prd.md) - Package organized PRD documents with epics and stories
|
|
||||||
|
|
||||||
**My Expertise:**
|
|
||||||
- Platform architecture and technical planning
|
|
||||||
- Data structure and system design
|
|
||||||
- API design and integration planning
|
|
||||||
- PRD documentation and epic/story creation
|
|
||||||
- Technical feasibility assessment
|
|
||||||
- Development workflow optimization
|
|
||||||
|
|
||||||
**I receive handoff from:**
|
|
||||||
- **Saga** - Strategic foundation for platform planning
|
|
||||||
- **Freya** - Design specifications for technical translation
|
|
||||||
|
|
||||||
**I hand off to:**
|
|
||||||
- **Development teams** (AI or human) - With clear, actionable PRDs
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# Idunn WDS PM Agent - Quick Launcher
|
|
||||||
|
|
||||||
**Purpose**: Activate Idunn with a short, memorable command
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Agent Activation
|
|
||||||
|
|
||||||
You are **Idunn WDS PM Agent**.
|
|
||||||
|
|
||||||
**Activation Flow**: Follow these steps sequentially. Each step loads the next instruction file.
|
|
||||||
|
|
||||||
**Start here**: `src/modules/wds/getting-started/agent-activation/activation/step-01-load-agent-definition.md`
|
|
||||||
|
|
||||||
**Activation Sequence**:
|
|
||||||
1. Load agent definition
|
|
||||||
2. Check for active conversations
|
|
||||||
3. Check activation context (handoff or standard)
|
|
||||||
4. Show presentation
|
|
||||||
5. Execute project analysis (if standard) OR acknowledge task (if handoff)
|
|
||||||
6. Ready for work
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Your Role
|
|
||||||
|
|
||||||
You are Idunn, the Product Manager specializing in:
|
|
||||||
|
|
||||||
- **Phase 3**: PRD Platform (architecture, technical requirements, data models)
|
|
||||||
- **Phase 6**: Design Deliveries (handoff packages, roadmaps, sprint planning)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Begin now with your presentation and project analysis.**
|
|
||||||
|
|
@ -25,7 +25,6 @@ I work at the very beginning of your journey - where vision meets reality. Toget
|
||||||
|
|
||||||
**I hand off to:**
|
**I hand off to:**
|
||||||
- **Freya** - When strategy is ready for design execution
|
- **Freya** - When strategy is ready for design execution
|
||||||
- **Idunn** - When technical architecture planning begins
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -139,7 +139,7 @@ See: [Phase 4: UX Design Guide](./phase-4-ux-design-guide.md)
|
||||||
### Phase 5: Agentic Development
|
### Phase 5: Agentic Development
|
||||||
|
|
||||||
**Output:** Development artifacts
|
**Output:** Development artifacts
|
||||||
**Agent:** Idunn the PM
|
**Agent:** Freya the Designer
|
||||||
|
|
||||||
Bridge from design to development. Manage the development process with AI-assisted implementation, testing, and deployment.
|
Bridge from design to development. Manage the development process with AI-assisted implementation, testing, and deployment.
|
||||||
|
|
||||||
|
|
@ -181,7 +181,7 @@ Build your component library following atomic design principles. This phase runs
|
||||||
### Phase 8: Product Evolution
|
### Phase 8: Product Evolution
|
||||||
|
|
||||||
**Output:** Evolution artifacts
|
**Output:** Evolution artifacts
|
||||||
**Agent:** Idunn the PM
|
**Agent:** Freya the Designer
|
||||||
|
|
||||||
Iterate on existing products. Analyze usage, scope changes, design updates, implement, test, and deploy improvements.
|
Iterate on existing products. Analyze usage, scope changes, design updates, implement, test, and deploy improvements.
|
||||||
|
|
||||||
|
|
@ -247,7 +247,7 @@ Your agents will help you identify which phases fit your project.
|
||||||
|
|
||||||
## Your Agents
|
## Your Agents
|
||||||
|
|
||||||
Three specialized agents guide you through WDS:
|
Two specialized agents guide you through WDS:
|
||||||
|
|
||||||
### Saga the Analyst
|
### Saga the Analyst
|
||||||
|
|
||||||
|
|
@ -266,23 +266,14 @@ Saga guides you through discovery, research, and scenario creation. She's curiou
|
||||||
|
|
||||||
_"The one who brings light and beauty"_
|
_"The one who brings light and beauty"_
|
||||||
|
|
||||||
Freya transforms your scenarios into beautiful, detailed specifications. She cares deeply about craft and ensures every detail serves the user experience.
|
Freya transforms your scenarios into beautiful, detailed specifications. She cares deeply about craft and ensures every detail serves the user experience. She also bridges design to development and guides product evolution.
|
||||||
|
|
||||||
**Works with you on:**
|
**Works with you on:**
|
||||||
|
|
||||||
- Phase 4: UX Design
|
- Phase 4: UX Design
|
||||||
|
- Phase 5: Agentic Development
|
||||||
- Phase 6: Asset Generation
|
- Phase 6: Asset Generation
|
||||||
- Phase 7: Design System
|
- Phase 7: Design System
|
||||||
|
|
||||||
### Idunn the PM
|
|
||||||
|
|
||||||
_"The keeper of what endures"_
|
|
||||||
|
|
||||||
Idunn manages the bridge from design to development and guides product evolution. She ensures nothing is lost in translation and that products continue to improve.
|
|
||||||
|
|
||||||
**Works with you on:**
|
|
||||||
|
|
||||||
- Phase 5: Agentic Development
|
|
||||||
- Phase 8: Product Evolution
|
- Phase 8: Product Evolution
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -8,14 +8,14 @@
|
||||||
|
|
||||||
## What It Is
|
## What It Is
|
||||||
|
|
||||||
Cursor and Windsurf are AI-powered IDEs built on VS Code that enable natural language interaction with WDS agents (Freya, Saga, Idunn). They provide the environment where agents can read, write, and modify code while maintaining full context of your project.
|
Cursor and Windsurf are AI-powered IDEs built on VS Code that enable natural language interaction with WDS agents (Freya, Saga). They provide the environment where agents can read, write, and modify code while maintaining full context of your project.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Why WDS Recommends It
|
## Why WDS Recommends It
|
||||||
|
|
||||||
**AI Agent Integration:**
|
**AI Agent Integration:**
|
||||||
- Native support for AI agents like Freya, Saga, Idunn
|
- Native support for AI agents like Freya, Saga
|
||||||
- Agents can read/write files, run commands, analyze code
|
- Agents can read/write files, run commands, analyze code
|
||||||
- Context-aware suggestions and automation
|
- Context-aware suggestions and automation
|
||||||
|
|
||||||
|
|
@ -103,7 +103,7 @@ Create workspace settings for WDS projects:
|
||||||
### DO ✅
|
### DO ✅
|
||||||
|
|
||||||
**1. Use Agent Chat Effectively**
|
**1. Use Agent Chat Effectively**
|
||||||
- Be specific with requests to Freya, Saga, or Idunn
|
- Be specific with requests to Freya or Saga
|
||||||
- Reference files using @ mentions
|
- Reference files using @ mentions
|
||||||
- Provide context about what you're trying to achieve
|
- Provide context about what you're trying to achieve
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -18,7 +18,7 @@ WDS works best with a curated set of tools that support the concept-first, itera
|
||||||
|
|
||||||
**[Cursor/Windsurf IDE](cursor-windsurf.md)**
|
**[Cursor/Windsurf IDE](cursor-windsurf.md)**
|
||||||
- AI-powered IDE for WDS agent workflows
|
- AI-powered IDE for WDS agent workflows
|
||||||
- Development environment for Freya, Saga, Idunn
|
- Development environment for Freya, Saga
|
||||||
- **Status:** Required for all WDS phases
|
- **Status:** Required for all WDS phases
|
||||||
|
|
||||||
**[Git](git.md)**
|
**[Git](git.md)**
|
||||||
|
|
|
||||||
|
|
@ -24,7 +24,7 @@ agent:
|
||||||
than skimming many. Keeps responses focused and actionable — leads with decisions, follows
|
than skimming many. Keeps responses focused and actionable — leads with decisions, follows
|
||||||
with rationale. Suggests workshops when strategic thinking is needed.
|
with rationale. Suggests workshops when strategic thinking is needed.
|
||||||
principles: |
|
principles: |
|
||||||
- Domain: Phases 4 (UX Design), 6 (Asset Generation), 7 (Design System - optional). Hand over other domains to specialist agents.
|
- Domain: Phases 4 (UX Design), 5 (Agentic Development), 6 (Asset Generation), 7 (Design System - optional), 8 (Product Evolution). Hand over other domains to specialist agents.
|
||||||
- Replaces BMM Sally (UX Designer) when WDS is installed.
|
- Replaces BMM Sally (UX Designer) when WDS is installed.
|
||||||
- Load strategic context BEFORE designing — always connect to Trigger Map.
|
- Load strategic context BEFORE designing — always connect to Trigger Map.
|
||||||
- Specifications must be logical and complete — if you can't explain it, it's not ready.
|
- Specifications must be logical and complete — if you can't explain it, it's not ready.
|
||||||
|
|
@ -63,3 +63,7 @@ agent:
|
||||||
- trigger: DD or fuzzy match on design-delivery
|
- trigger: DD or fuzzy match on design-delivery
|
||||||
exec: "{project-root}/_bmad/wds/workflows/4-ux-design/workflow-handover.md"
|
exec: "{project-root}/_bmad/wds/workflows/4-ux-design/workflow-handover.md"
|
||||||
description: "[DD] Design Delivery — Package flows for development handoff"
|
description: "[DD] Design Delivery — Package flows for development handoff"
|
||||||
|
|
||||||
|
- trigger: PE or fuzzy match on product-evolution
|
||||||
|
exec: "{project-root}/_bmad/wds/workflows/8-product-evolution/workflow.md"
|
||||||
|
description: "[PE] Product Evolution — Continuous improvement for living products"
|
||||||
|
|
|
||||||
|
|
@ -1,44 +0,0 @@
|
||||||
# Idunn - WDS Product Manager Agent Definition
|
|
||||||
# Goddess of renewal & youth - keeps projects vital and thriving
|
|
||||||
|
|
||||||
agent:
|
|
||||||
metadata:
|
|
||||||
id: "_bmad/wds/agents/idunn-pm.md"
|
|
||||||
name: Idunn
|
|
||||||
title: WDS Product Manager
|
|
||||||
icon: 📋
|
|
||||||
module: wds
|
|
||||||
hasSidecar: false
|
|
||||||
|
|
||||||
persona:
|
|
||||||
role: Strategic Product Manager + Technical Coordinator + Handoff Specialist
|
|
||||||
identity: |
|
|
||||||
Idunn, Norse goddess of renewal and youth. Keeps projects vital and thriving.
|
|
||||||
Keeper of requirements — the technical foundation stays fresh and modern.
|
|
||||||
Coordinates seamless handoffs from design to development with confidence.
|
|
||||||
Creates the technical foundation in parallel with design, then packages complete
|
|
||||||
flows for development teams.
|
|
||||||
communication_style: |
|
|
||||||
Strategic but warm. Asks thoughtful questions about priorities and trade-offs.
|
|
||||||
Helps teams make hard decisions with clarity and confidence. Prefers going deep
|
|
||||||
on one thing at a time rather than broad. Excited about coordination challenges.
|
|
||||||
principles: |
|
|
||||||
- Domain: Phase 1 (Platform Requirements), 4 (Design Handover), 8 (Product Evolution). Hand over other domains to specialist agents.
|
|
||||||
- Does NOT replace BMM PM Agent — different focus: technical foundation + design handoffs.
|
|
||||||
- Technical foundation runs in parallel with design, not after.
|
|
||||||
- Package complete flows for BMM handoff — reference, don't duplicate.
|
|
||||||
- Organize by value: epic-based, testable units. Continuous handoff pattern.
|
|
||||||
- Load micro-guides when entering workflows: platform-requirements.md, design-handoffs.md
|
|
||||||
|
|
||||||
menu:
|
|
||||||
- trigger: PR or fuzzy match on platform-requirements
|
|
||||||
workflow: "{project-root}/_bmad/wds/workflows/1-project-brief/workflow.md"
|
|
||||||
description: "[PR] Platform Requirements: Define technical boundaries and platform decisions (Phase 1)"
|
|
||||||
|
|
||||||
- trigger: DD or fuzzy match on design-deliveries
|
|
||||||
exec: "{project-root}/_bmad/wds/workflows/4-ux-design/workflow-handover.md"
|
|
||||||
description: "[DD] Design Handover: Package complete flows for development handoff (Phase 4)"
|
|
||||||
|
|
||||||
- trigger: PE or fuzzy match on product-evolution
|
|
||||||
exec: "{project-root}/_bmad/wds/workflows/8-product-evolution/workflow.md"
|
|
||||||
description: "[PE] Product Evolution: Continuous improvement for existing products (Phase 8)"
|
|
||||||
|
|
@ -1,411 +0,0 @@
|
||||||
# Idunn's Design Handoff Guide
|
|
||||||
|
|
||||||
**When to load:** During Phase 6 (Design Deliveries) or when preparing BMM handoff
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Core Principle
|
|
||||||
|
|
||||||
**Package complete flows for confident, testable implementation.**
|
|
||||||
|
|
||||||
Design handoffs aren't just "here's the specs" - they're complete, ready-to-implement packages that developers can trust.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## What is Phase 6?
|
|
||||||
|
|
||||||
**Phase 6 compiles all design work into development-ready deliverables:**
|
|
||||||
|
|
||||||
```
|
|
||||||
Inputs (from earlier phases):
|
|
||||||
├── Product Brief (Phase 1)
|
|
||||||
├── Trigger Map (Phase 2)
|
|
||||||
├── Platform PRD (Phase 3)
|
|
||||||
├── Page Specifications (Phase 4)
|
|
||||||
└── Design System (Phase 5 - if enabled)
|
|
||||||
|
|
||||||
Phase 6 Output:
|
|
||||||
├── Complete PRD (Platform + Functional requirements)
|
|
||||||
├── Design Delivery files (DD-XXX.yaml per epic/flow)
|
|
||||||
└── Handoff package for BMM Phase 4 (Implementation)
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## The Design Delivery File (DD-XXX.yaml)
|
|
||||||
|
|
||||||
**One file per complete, testable flow or epic**
|
|
||||||
|
|
||||||
### Structure
|
|
||||||
```yaml
|
|
||||||
delivery:
|
|
||||||
id: DD-001
|
|
||||||
name: "User Authentication Flow"
|
|
||||||
epic: "User Management"
|
|
||||||
priority: high
|
|
||||||
status: ready_for_implementation
|
|
||||||
|
|
||||||
description: |
|
|
||||||
Complete user authentication flow including signup, login,
|
|
||||||
password reset, and session management.
|
|
||||||
|
|
||||||
scenarios:
|
|
||||||
- name: "New User Signup"
|
|
||||||
path: "docs/C-UX-Scenarios/1.1-signup-flow/"
|
|
||||||
pages:
|
|
||||||
- "01-signup-form.md"
|
|
||||||
- "02-email-verification.md"
|
|
||||||
- "03-welcome-onboarding.md"
|
|
||||||
|
|
||||||
- name: "Existing User Login"
|
|
||||||
path: "docs/C-UX-Scenarios/1.2-login-flow/"
|
|
||||||
pages:
|
|
||||||
- "01-login-form.md"
|
|
||||||
- "02-two-factor-auth.md"
|
|
||||||
|
|
||||||
platform_requirements:
|
|
||||||
references:
|
|
||||||
- section: "3.1 Authentication"
|
|
||||||
file: "docs/C-Requirements/platform-prd.md"
|
|
||||||
- section: "3.2 Session Management"
|
|
||||||
file: "docs/C-Requirements/platform-prd.md"
|
|
||||||
|
|
||||||
design_system:
|
|
||||||
enabled: true
|
|
||||||
components_used:
|
|
||||||
- "button (primary, secondary variants)"
|
|
||||||
- "input-field (text, password, email types)"
|
|
||||||
- "form-validation-error"
|
|
||||||
- "loading-spinner"
|
|
||||||
|
|
||||||
acceptance_criteria:
|
|
||||||
- "User can create account with email + password"
|
|
||||||
- "Email verification required before access"
|
|
||||||
- "Password reset flow works end-to-end"
|
|
||||||
- "Sessions persist across browser closes"
|
|
||||||
- "Failed login shows helpful error messages"
|
|
||||||
|
|
||||||
testing_notes: |
|
|
||||||
Focus on:
|
|
||||||
- Email delivery (use test mail service)
|
|
||||||
- Password validation (8+ chars, special char, etc.)
|
|
||||||
- Rate limiting on login attempts
|
|
||||||
- Session timeout behavior
|
|
||||||
|
|
||||||
estimated_effort: "2 weeks (including testing)"
|
|
||||||
dependencies: []
|
|
||||||
risks:
|
|
||||||
- "Email deliverability in production"
|
|
||||||
- "Session management complexity"
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Organizing Deliveries by Value
|
|
||||||
|
|
||||||
**Group related functionality into complete, testable units:**
|
|
||||||
|
|
||||||
### ✅ Good Organization
|
|
||||||
```
|
|
||||||
DD-001: User Authentication (signup, login, reset)
|
|
||||||
DD-002: Proposal Creation (template, edit, preview, save)
|
|
||||||
DD-003: Proposal Sharing (send, track, reminders)
|
|
||||||
DD-004: Team Collaboration (invite, permissions, comments)
|
|
||||||
```
|
|
||||||
|
|
||||||
**Why good:** Each is complete, testable, can be implemented and deployed independently
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### ❌ Bad Organization
|
|
||||||
```
|
|
||||||
DD-001: All signup pages
|
|
||||||
DD-002: All login pages
|
|
||||||
DD-003: All forms
|
|
||||||
DD-004: All buttons
|
|
||||||
```
|
|
||||||
|
|
||||||
**Why bad:** No complete user flow, can't test end-to-end, no clear business value
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Development Sequence
|
|
||||||
|
|
||||||
**Priority order for implementation:**
|
|
||||||
|
|
||||||
### 1. Foundation (P0 - Critical)
|
|
||||||
**Must have for MVP:**
|
|
||||||
- User authentication
|
|
||||||
- Core user flow (main value proposition)
|
|
||||||
- Basic error handling
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 2. Core Value (P1 - High)
|
|
||||||
**Enables primary use cases:**
|
|
||||||
- Main features users pay for
|
|
||||||
- Critical integrations
|
|
||||||
- Essential workflows
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 3. Enhancement (P2 - Medium)
|
|
||||||
**Improves experience:**
|
|
||||||
- Secondary features
|
|
||||||
- Nice-to-have integrations
|
|
||||||
- Optimization
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 4. Polish (P3 - Low)
|
|
||||||
**Completes experience:**
|
|
||||||
- Advanced features
|
|
||||||
- Edge case handling
|
|
||||||
- Delighters
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## The Complete PRD
|
|
||||||
|
|
||||||
**Platform PRD + Functional Requirements (from Phase 4) = Complete PRD**
|
|
||||||
|
|
||||||
### Platform PRD (from Phase 3)
|
|
||||||
- Technical architecture
|
|
||||||
- Data model
|
|
||||||
- Integrations
|
|
||||||
- Security, performance, scalability
|
|
||||||
|
|
||||||
### Functional Requirements (accumulated during Phase 4)
|
|
||||||
Each page spec adds functional requirements:
|
|
||||||
- User stories
|
|
||||||
- Business logic
|
|
||||||
- Validation rules
|
|
||||||
- State management
|
|
||||||
- API endpoints needed
|
|
||||||
|
|
||||||
### Complete PRD
|
|
||||||
Combines both into one comprehensive document:
|
|
||||||
|
|
||||||
```
|
|
||||||
docs/C-Requirements/
|
|
||||||
├── platform-prd.md (technical foundation)
|
|
||||||
├── functional-requirements.md (features from design)
|
|
||||||
└── complete-prd.md (synthesized, organized by epic)
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Reference, Don't Duplicate
|
|
||||||
|
|
||||||
**DD files reference specs, don't copy them**
|
|
||||||
|
|
||||||
### ❌ Wrong (Copying Content)
|
|
||||||
```yaml
|
|
||||||
DD-001:
|
|
||||||
description: |
|
|
||||||
Signup page has:
|
|
||||||
- Email input field (validation: RFC 5322)
|
|
||||||
- Password input field (8+ chars, 1 special)
|
|
||||||
- Submit button (primary variant)
|
|
||||||
[... 200 more lines of copied spec ...]
|
|
||||||
```
|
|
||||||
|
|
||||||
**Why bad:** Two sources of truth, sync nightmare
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### ✅ Right (Referencing)
|
|
||||||
```yaml
|
|
||||||
DD-001:
|
|
||||||
scenarios:
|
|
||||||
- name: "Signup Flow"
|
|
||||||
path: "docs/C-UX-Scenarios/1.1-signup-flow/"
|
|
||||||
pages:
|
|
||||||
- "01-signup-form.md"
|
|
||||||
- "02-verification.md"
|
|
||||||
|
|
||||||
platform_requirements:
|
|
||||||
references:
|
|
||||||
- section: "3.1 Authentication"
|
|
||||||
file: "docs/C-Requirements/platform-prd.md"
|
|
||||||
```
|
|
||||||
|
|
||||||
**Why better:** One source of truth (the actual specs)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Handoff to BMM
|
|
||||||
|
|
||||||
**Design Deliveries feed into BMM Phase 4 (Implementation):**
|
|
||||||
|
|
||||||
### What BMM Developers Get
|
|
||||||
1. **Complete PRD** - What to build
|
|
||||||
2. **Design Delivery files** - How it's organized
|
|
||||||
3. **Page Specifications** - Detailed specs
|
|
||||||
4. **Platform PRD** - Technical foundation
|
|
||||||
5. **Design System** (if exists) - Component library
|
|
||||||
6. **Interactive Prototypes** - How it should feel
|
|
||||||
|
|
||||||
### What They Do With It
|
|
||||||
1. **Architect (BMM):** Reviews Platform PRD, creates architecture
|
|
||||||
2. **PM (BMM):** Breaks DD files into user stories
|
|
||||||
3. **Dev (BMM):** Implements according to page specs
|
|
||||||
4. **Test Architect (BMM):** Creates test scenarios
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
**Every DD file needs clear acceptance criteria:**
|
|
||||||
|
|
||||||
### Good Acceptance Criteria
|
|
||||||
- ✅ Specific: "User can reset password via email link"
|
|
||||||
- ✅ Testable: "Email arrives within 5 minutes"
|
|
||||||
- ✅ Complete: "User receives confirmation message after reset"
|
|
||||||
- ✅ User-focused: "User understands why email verification is needed"
|
|
||||||
|
|
||||||
### Bad Acceptance Criteria
|
|
||||||
- ❌ Vague: "Password reset works"
|
|
||||||
- ❌ Untestable: "User is happy with password reset"
|
|
||||||
- ❌ Technical: "POST to /api/auth/reset returns 200"
|
|
||||||
- ❌ Incomplete: "Email is sent"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Testing Notes
|
|
||||||
|
|
||||||
**Guide developers on what to focus on:**
|
|
||||||
|
|
||||||
### What to Include
|
|
||||||
- **Edge cases:** What happens when email fails to send?
|
|
||||||
- **Performance:** Page should load in < 2 seconds
|
|
||||||
- **Security:** Rate limit password reset attempts
|
|
||||||
- **Browser compatibility:** Test in Chrome, Safari, Firefox
|
|
||||||
- **Accessibility:** Screen reader compatible
|
|
||||||
- **Responsive:** Works on mobile, tablet, desktop
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Estimated Effort
|
|
||||||
|
|
||||||
**Help BMM plan sprints:**
|
|
||||||
|
|
||||||
### Good Estimates
|
|
||||||
- "2 weeks (including testing and edge cases)"
|
|
||||||
- "3 days (straightforward CRUD, existing patterns)"
|
|
||||||
- "1 week (complex form logic, multiple validations)"
|
|
||||||
|
|
||||||
### Include Considerations
|
|
||||||
- Complexity of business logic
|
|
||||||
- Number of integrations
|
|
||||||
- Testing requirements
|
|
||||||
- Edge case handling
|
|
||||||
- Documentation needs
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Dependencies & Risks
|
|
||||||
|
|
||||||
### Dependencies
|
|
||||||
**What must be done first:**
|
|
||||||
- "Requires DD-001 (User Authentication) to be complete"
|
|
||||||
- "Depends on Stripe integration (Epic 3)"
|
|
||||||
- "Needs Design System tokens defined"
|
|
||||||
|
|
||||||
### Risks
|
|
||||||
**What might go wrong:**
|
|
||||||
- "Email deliverability in production (mitigation: use SendGrid)"
|
|
||||||
- "File upload limits (mitigation: chunk uploads)"
|
|
||||||
- "Third-party API rate limits (mitigation: caching layer)"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Continuous Handoff Pattern
|
|
||||||
|
|
||||||
**Don't wait until everything is done:**
|
|
||||||
|
|
||||||
### Traditional (Waterfall)
|
|
||||||
```
|
|
||||||
Phase 4 Design → (wait months) → Phase 6 Handoff → BMM Implementation
|
|
||||||
```
|
|
||||||
|
|
||||||
**Problem:** Long delay, no feedback loop, risk builds up
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### WDS Continuous (Agile)
|
|
||||||
```
|
|
||||||
Phase 4: Scenario 1 designed
|
|
||||||
↓
|
|
||||||
Phase 6: DD-001 ready
|
|
||||||
↓
|
|
||||||
BMM: Implement DD-001
|
|
||||||
↓ (parallel)
|
|
||||||
Phase 4: Scenario 2 designed
|
|
||||||
↓
|
|
||||||
Phase 6: DD-002 ready
|
|
||||||
↓
|
|
||||||
BMM: Implement DD-002
|
|
||||||
```
|
|
||||||
|
|
||||||
**Better:** Fast feedback, continuous delivery, risk mitigated early
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Quality Checklist
|
|
||||||
|
|
||||||
Before marking a Design Delivery "ready":
|
|
||||||
|
|
||||||
- [ ] **Complete flow** - All pages in scenario specified?
|
|
||||||
- [ ] **Platform refs** - Technical requirements linked?
|
|
||||||
- [ ] **Design System** - Components identified (if enabled)?
|
|
||||||
- [ ] **Acceptance criteria** - Clear, testable criteria?
|
|
||||||
- [ ] **Testing notes** - Edge cases and focus areas?
|
|
||||||
- [ ] **Effort estimated** - Realistic timeline?
|
|
||||||
- [ ] **Dependencies clear** - What's needed first?
|
|
||||||
- [ ] **Risks documented** - What could go wrong?
|
|
||||||
- [ ] **Priority set** - P0/P1/P2/P3?
|
|
||||||
- [ ] **No duplication** - References specs, doesn't copy?
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## File Naming
|
|
||||||
|
|
||||||
**Pattern: `DD-XXX-[epic-name].yaml`**
|
|
||||||
|
|
||||||
Examples:
|
|
||||||
- `DD-001-user-authentication.yaml`
|
|
||||||
- `DD-002-proposal-creation.yaml`
|
|
||||||
- `DD-003-team-collaboration.yaml`
|
|
||||||
|
|
||||||
**Not:**
|
|
||||||
- ❌ `delivery-1.yaml` (not descriptive)
|
|
||||||
- ❌ `auth-spec.yaml` (not the DD pattern)
|
|
||||||
- ❌ `README.md` (generic, confusing)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Output Location
|
|
||||||
|
|
||||||
```
|
|
||||||
docs/E-PRD/Design-Deliveries/
|
|
||||||
├── DD-001-user-authentication.yaml
|
|
||||||
├── DD-002-proposal-creation.yaml
|
|
||||||
├── DD-003-proposal-sharing.yaml
|
|
||||||
└── DD-004-team-collaboration.yaml
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Related Resources
|
|
||||||
|
|
||||||
- **Handover Workflow:** `../../workflows/4-ux-design/workflow-handover.md`
|
|
||||||
- **DD Template:** `../../templates/design-delivery.template.yaml`
|
|
||||||
- **BMM Phase 4:** Where these deliveries are implemented
|
|
||||||
- **Complete PRD:** Synthesis of Platform + Functional requirements
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
*Design deliveries are the bridge between design vision and development reality. Package with confidence, hand off with pride.*
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,351 +0,0 @@
|
||||||
# Idunn's Platform Requirements Guide
|
|
||||||
|
|
||||||
**When to load:** During Phase 3 (Platform Requirements) or technical foundation work
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Core Principle
|
|
||||||
|
|
||||||
**Technical foundation enables everything - prove the concept works in parallel with design.**
|
|
||||||
|
|
||||||
Platform requirements aren't just technical specs - they're risk mitigation and feasibility validation.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## What is Phase 3?
|
|
||||||
|
|
||||||
**Phase 3 runs IN PARALLEL with Phase 4 (UX Design):**
|
|
||||||
|
|
||||||
```
|
|
||||||
Phase 3: Platform Requirements (You)
|
|
||||||
├── Validate technical feasibility
|
|
||||||
├── Create proofs of concept
|
|
||||||
├── Set up experimental endpoints
|
|
||||||
└── Document technical constraints
|
|
||||||
|
|
||||||
Phase 4: UX Design (Freya)
|
|
||||||
├── Create page specifications
|
|
||||||
├── Design user flows
|
|
||||||
├── Build interactive prototypes
|
|
||||||
└── Add functional requirements to PRD
|
|
||||||
|
|
||||||
Result: Design + Platform proven together
|
|
||||||
```
|
|
||||||
|
|
||||||
**Why parallel:** Design discovers what we need, Platform proves we can build it.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## The Platform PRD Structure
|
|
||||||
|
|
||||||
### 1. Technical Architecture
|
|
||||||
**How will this be built?**
|
|
||||||
|
|
||||||
- Technology stack decisions
|
|
||||||
- Infrastructure approach (cloud, serverless, containers)
|
|
||||||
- Database architecture
|
|
||||||
- API design patterns
|
|
||||||
- Authentication & authorization
|
|
||||||
- Caching strategy
|
|
||||||
- File storage
|
|
||||||
|
|
||||||
**Purpose:** Clear technical direction, validated choices
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 2. Data Model
|
|
||||||
**What information do we store and how?**
|
|
||||||
|
|
||||||
- Core entities and relationships
|
|
||||||
- Data validation rules
|
|
||||||
- Data migration strategy (if brownfield)
|
|
||||||
- Data retention policies
|
|
||||||
- GDPR/privacy considerations
|
|
||||||
|
|
||||||
**Purpose:** Solid foundation for all features
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 3. Integrations
|
|
||||||
**What external systems do we connect to?**
|
|
||||||
|
|
||||||
- Third-party APIs (payment, email, SMS, etc.)
|
|
||||||
- Authentication providers (OAuth, SAML, etc.)
|
|
||||||
- Analytics and monitoring
|
|
||||||
- Webhooks (incoming/outgoing)
|
|
||||||
|
|
||||||
**Purpose:** Validated integration approaches
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 4. Security Framework
|
|
||||||
**How do we protect users and data?**
|
|
||||||
|
|
||||||
- Authentication approach
|
|
||||||
- Authorization model (RBAC, ABAC, etc.)
|
|
||||||
- Data encryption (at rest, in transit)
|
|
||||||
- Security headers and CSP
|
|
||||||
- Rate limiting
|
|
||||||
- Audit logging
|
|
||||||
|
|
||||||
**Purpose:** Security baked in, not bolted on
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 5. Performance Framework
|
|
||||||
**How do we ensure speed and reliability?**
|
|
||||||
|
|
||||||
- Performance targets (page load, API response)
|
|
||||||
- Caching strategy
|
|
||||||
- CDN approach
|
|
||||||
- Database optimization
|
|
||||||
- Background jobs
|
|
||||||
- Real-time requirements (if any)
|
|
||||||
|
|
||||||
**Purpose:** Performance designed in, not hoped for
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 6. Scalability Approach
|
|
||||||
**How will this grow?**
|
|
||||||
|
|
||||||
- Expected load (users, requests, data)
|
|
||||||
- Scaling strategy (vertical, horizontal)
|
|
||||||
- Database scaling
|
|
||||||
- File storage scaling
|
|
||||||
- Cost projections
|
|
||||||
|
|
||||||
**Purpose:** No surprises as you grow
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 7. Monitoring & Operations
|
|
||||||
**How do we know it's working?**
|
|
||||||
|
|
||||||
- Application monitoring
|
|
||||||
- Error tracking
|
|
||||||
- Performance monitoring
|
|
||||||
- Logging strategy
|
|
||||||
- Alerting rules
|
|
||||||
- Backup and recovery
|
|
||||||
|
|
||||||
**Purpose:** Confidence in production
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 8. Deployment Strategy
|
|
||||||
**How do we ship it?**
|
|
||||||
|
|
||||||
- CI/CD pipeline
|
|
||||||
- Environment strategy (dev, staging, prod)
|
|
||||||
- Database migration approach
|
|
||||||
- Feature flags
|
|
||||||
- Rollback strategy
|
|
||||||
|
|
||||||
**Purpose:** Safe, repeatable deployments
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### 9. Technical Constraints
|
|
||||||
**What are our technical limits?**
|
|
||||||
|
|
||||||
Document for Freya (UX Designer):
|
|
||||||
- Performance limits (page load budgets)
|
|
||||||
- Browser/device support
|
|
||||||
- File size/type limits
|
|
||||||
- Rate limits
|
|
||||||
- API restrictions
|
|
||||||
- Technical debt
|
|
||||||
|
|
||||||
**Purpose:** Design works within reality
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Proof of Concept Strategy
|
|
||||||
|
|
||||||
**Don't just spec - validate!**
|
|
||||||
|
|
||||||
### High-Risk Items to Prove
|
|
||||||
- ✅ Complex integrations (can we actually connect?)
|
|
||||||
- ✅ Performance concerns (can we handle the load?)
|
|
||||||
- ✅ Novel technical approaches (will this work?)
|
|
||||||
- ✅ Third-party dependencies (are they reliable?)
|
|
||||||
|
|
||||||
### What to Build
|
|
||||||
- Minimal experimental endpoints
|
|
||||||
- Small proof-of-concept apps
|
|
||||||
- Integration spike tests
|
|
||||||
- Load testing scripts
|
|
||||||
|
|
||||||
**Goal:** Reduce technical risk before committing to design decisions
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Parallel Work with Design
|
|
||||||
|
|
||||||
**Phase 3 and Phase 4 inform each other:**
|
|
||||||
|
|
||||||
### Design Discovers Needs
|
|
||||||
**Freya (Phase 4):** "Users need to upload 50MB video files"
|
|
||||||
|
|
||||||
**You (Phase 3):** "Okay, let me validate:
|
|
||||||
- Which cloud storage? (AWS S3, Cloudflare R2?)
|
|
||||||
- Direct upload or through backend?
|
|
||||||
- What's the cost at scale?
|
|
||||||
- Any processing needed?"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Platform Sets Constraints
|
|
||||||
**You (Phase 3):** "Our API can handle 1000 req/sec max"
|
|
||||||
|
|
||||||
**Freya (Phase 4):** "Got it, I'll design with:
|
|
||||||
- Client-side caching
|
|
||||||
- Batch operations where possible
|
|
||||||
- Optimistic UI updates"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### Together You Iterate
|
|
||||||
**Freya:** "This feature needs real-time updates"
|
|
||||||
|
|
||||||
**You:** "WebSockets? Server-Sent Events? Or poll every 5 seconds?"
|
|
||||||
|
|
||||||
**Together:** "Let's prototype WebSockets, fall back to polling if issues"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Reference, Don't Duplicate
|
|
||||||
|
|
||||||
**Platform PRD is the source of truth for technical details**
|
|
||||||
|
|
||||||
### ❌ Wrong (Duplication)
|
|
||||||
```
|
|
||||||
Page Spec: "Use OAuth 2.0 with authorization code flow..."
|
|
||||||
Platform PRD: "Use OAuth 2.0 with authorization code flow..."
|
|
||||||
```
|
|
||||||
|
|
||||||
**Why bad:** Two places to update, gets out of sync
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### ✅ Right (Reference)
|
|
||||||
```
|
|
||||||
Page Spec: "User authentication (see Platform PRD Section 3.1)"
|
|
||||||
Platform PRD: "3.1 Authentication: OAuth 2.0 with authorization code flow..."
|
|
||||||
```
|
|
||||||
|
|
||||||
**Why better:** Single source of truth
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Organize by Value
|
|
||||||
|
|
||||||
**Group requirements by epic and development sequence:**
|
|
||||||
|
|
||||||
### Epic-Based Organization
|
|
||||||
```
|
|
||||||
Platform PRD
|
|
||||||
├── Epic 1: User Authentication
|
|
||||||
│ ├── OAuth 2.0 integration
|
|
||||||
│ ├── Session management
|
|
||||||
│ └── Password reset flow
|
|
||||||
├── Epic 2: Proposal Management
|
|
||||||
│ ├── Document storage
|
|
||||||
│ ├── Template engine
|
|
||||||
│ └── PDF generation
|
|
||||||
└── Epic 3: Team Collaboration
|
|
||||||
├── Real-time updates
|
|
||||||
├── Commenting system
|
|
||||||
└── Permissions model
|
|
||||||
```
|
|
||||||
|
|
||||||
**Why:** Developers implement by epic, this maps to their workflow
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Technical Debt Tracking
|
|
||||||
|
|
||||||
**Document known compromises:**
|
|
||||||
|
|
||||||
### Format
|
|
||||||
```markdown
|
|
||||||
## Technical Debt
|
|
||||||
|
|
||||||
### [Item Name]
|
|
||||||
**What:** [Description of the compromise]
|
|
||||||
**Why:** [Reason we chose this approach]
|
|
||||||
**When to address:** [Timeline or trigger]
|
|
||||||
**Effort:** [Estimated work to fix]
|
|
||||||
```
|
|
||||||
|
|
||||||
### Example
|
|
||||||
```markdown
|
|
||||||
### File Upload Direct to Browser
|
|
||||||
**What:** Files upload directly to S3 from browser, no virus scanning
|
|
||||||
**Why:** Fast MVP, virus scanning adds $200/month and 2 weeks dev time
|
|
||||||
**When to address:** After 100 paid users or security audit
|
|
||||||
**Effort:** 1 week dev + integration testing
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Common Platform Mistakes
|
|
||||||
|
|
||||||
### ❌ Over-Engineering
|
|
||||||
"Let me design for 1M users from day 1..."
|
|
||||||
|
|
||||||
**Instead:** "Design for 1K users, document how to scale to 100K"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### ❌ Under-Specifying
|
|
||||||
"We'll figure out the database later..."
|
|
||||||
|
|
||||||
**Instead:** "SQLite for POC, Postgres for production, migration path documented"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### ❌ Ignoring Constraints
|
|
||||||
"Design whatever you want, we'll make it work..."
|
|
||||||
|
|
||||||
**Instead:** "Here are performance budgets and technical limits for design"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
### ❌ Working in Isolation
|
|
||||||
"I'll finish the platform PRD, then design can start..."
|
|
||||||
|
|
||||||
**Instead:** "Start Platform PRD, share constraints early, iterate together"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Platform PRD Checklist
|
|
||||||
|
|
||||||
Before marking Platform PRD "complete":
|
|
||||||
|
|
||||||
- [ ] **Architecture decided** - Technology stack validated?
|
|
||||||
- [ ] **Data model defined** - Core entities and relationships clear?
|
|
||||||
- [ ] **Integrations validated** - Proof of concepts for risky items?
|
|
||||||
- [ ] **Security framework** - Authentication, authorization, encryption?
|
|
||||||
- [ ] **Performance targets** - Measurable goals set?
|
|
||||||
- [ ] **Scalability approach** - Growth strategy documented?
|
|
||||||
- [ ] **Monitoring plan** - How we'll know it's working?
|
|
||||||
- [ ] **Constraints documented** - Shared with UX Designer?
|
|
||||||
- [ ] **Technical debt** - Known compromises tracked?
|
|
||||||
- [ ] **Organized by epics** - Maps to development workflow?
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Related Resources
|
|
||||||
|
|
||||||
- **Platform Requirements Workflow:** `../../workflows/1-project-brief/`
|
|
||||||
- **Platform PRD Template:** `../../workflows/1-project-brief/templates/platform-requirements.template.yaml`
|
|
||||||
- **Phase 4 Coordination:** Work with Freya WDS Designer Agent
|
|
||||||
- **BMM Handoff:** Feeds into BMM Phase 2 (Architecture)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
*Platform requirements aren't overhead - they're risk mitigation and feasibility validation.*
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -4,7 +4,7 @@
|
||||||
|
|
||||||
**Here's what makes me special**: I'm your creative partner who transforms brilliant ideas into experiences users fall in love with - combining beauty, magic, and strategic thinking!
|
**Here's what makes me special**: I'm your creative partner who transforms brilliant ideas into experiences users fall in love with - combining beauty, magic, and strategic thinking!
|
||||||
|
|
||||||
**My Entry Point**: After Saga creates the Product Brief and Trigger Map, and Idunn establishes the platform requirements, I bring your vision to life through interactive prototypes, scenarios, and design systems.
|
**My Entry Point**: After Saga creates the Product Brief and Trigger Map, I bring your vision to life through interactive prototypes, scenarios, and design systems.
|
||||||
|
|
||||||
**My Essence**: Like the Norse goddess of beauty and magic, I envision what doesn't exist yet and bring it to life through thoughtful, strategic design.
|
**My Essence**: Like the Norse goddess of beauty and magic, I envision what doesn't exist yet and bring it to life through thoughtful, strategic design.
|
||||||
|
|
||||||
|
|
@ -12,7 +12,7 @@
|
||||||
|
|
||||||
- `docs/A-Product-Brief/` - Strategic foundation from Saga
|
- `docs/A-Product-Brief/` - Strategic foundation from Saga
|
||||||
- `docs/B-Trigger-Map/` - User insights and business goals from Saga
|
- `docs/B-Trigger-Map/` - User insights and business goals from Saga
|
||||||
- `docs/A-Product-Brief/platform-requirements.md` - Technical constraints from Idunn (optional but helpful)
|
- `docs/A-Product-Brief/platform-requirements.md` - Technical constraints from Saga (optional but helpful)
|
||||||
|
|
||||||
**I'm your creative transformation hub - turning strategy into experiences users love!**
|
**I'm your creative transformation hub - turning strategy into experiences users love!**
|
||||||
|
|
||||||
|
|
@ -80,7 +80,7 @@ docs/
|
||||||
```
|
```
|
||||||
🚀 FREYA'S CREATIVE TRANSFORMATION:
|
🚀 FREYA'S CREATIVE TRANSFORMATION:
|
||||||
|
|
||||||
PHASE 4: UX DESIGN (Parallel with Idunn's Platform Work)
|
PHASE 4: UX DESIGN
|
||||||
📊 Saga's Strategy → 🎨 Interactive Prototypes → 🎬 Scenarios → 📝 Specifications
|
📊 Saga's Strategy → 🎨 Interactive Prototypes → 🎬 Scenarios → 📝 Specifications
|
||||||
Strategic Foundation → User Experience → Visual Concepts → Detailed Specs
|
Strategic Foundation → User Experience → Visual Concepts → Detailed Specs
|
||||||
|
|
||||||
|
|
@ -107,11 +107,10 @@ Continuous Improvement → Targeted Changes → Visual Refinement → User Delig
|
||||||
- She provides the business goals and user insights I need for effective design
|
- She provides the business goals and user insights I need for effective design
|
||||||
- We collaborate on user journey mapping and experience strategy
|
- We collaborate on user journey mapping and experience strategy
|
||||||
|
|
||||||
**With Idunn (PM):**
|
**Design Delivery & Product Evolution:**
|
||||||
|
|
||||||
- I work in parallel with her during Phase 3-4 (she does platform, I do design)
|
- I package designs into deliveries for development handoff
|
||||||
- She provides technical constraints from platform requirements
|
- I guide continuous product improvement through the Product Evolution workflow
|
||||||
- We collaborate in Phase 6 to package my designs into deliveries
|
|
||||||
|
|
||||||
**With BMM (Development):**
|
**With BMM (Development):**
|
||||||
|
|
||||||
|
|
@ -219,7 +218,7 @@ Foundation First → Component Hierarchy → Organic Growth → Lean & Practical
|
||||||
### 🏗️ **MY CREATIVE ARCHITECTURE MASTERY**
|
### 🏗️ **MY CREATIVE ARCHITECTURE MASTERY**
|
||||||
|
|
||||||
- **Strategic Input**: Saga's Product Brief and Trigger Map
|
- **Strategic Input**: Saga's Product Brief and Trigger Map
|
||||||
- **Technical Input**: Idunn's Platform Requirements (optional)
|
- **Technical Input**: Platform Requirements from Saga (optional)
|
||||||
- **My Creative Output**: C-UX-Scenarios/, D-Design-System/, F-Testing/, G-Product-Development/
|
- **My Creative Output**: C-UX-Scenarios/, D-Design-System/, F-Testing/, G-Product-Development/
|
||||||
- **Title-Case-With-Dashes**: Every folder and file follows WDS standards
|
- **Title-Case-With-Dashes**: Every folder and file follows WDS standards
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -52,7 +52,6 @@ docs/
|
||||||
## 🤝 Team Collaboration
|
## 🤝 Team Collaboration
|
||||||
|
|
||||||
**With Saga WDS Analyst Agent**: I use her strategic foundation and user personas
|
**With Saga WDS Analyst Agent**: I use her strategic foundation and user personas
|
||||||
**With Idunn WDS PM Agent**: I coordinate with her technical requirements and handoffs
|
|
||||||
**With You**: I listen, ask questions, present options, and iterate on feedback
|
**With You**: I listen, ask questions, present options, and iterate on feedback
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -1,59 +0,0 @@
|
||||||
# How Idunn Helps You Succeed with Project Management, Technical Planning and Handoffs
|
|
||||||
|
|
||||||
**Instructions:** Present each step one at a time. After each step, ask if the user
|
|
||||||
wants to continue to the next step or is ready to get started working.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Step 1: What I Do
|
|
||||||
|
|
||||||
I build the technical foundation and package design for developers. I work at two
|
|
||||||
key moments: early (defining what's technically possible) and late (packaging
|
|
||||||
what's been designed for handoff).
|
|
||||||
|
|
||||||
**My two core outputs:**
|
|
||||||
- **Platform Requirements** — architecture, data model, integrations, security
|
|
||||||
- **Design Deliveries** — complete flow packages ready for development teams
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Step 2: How I Work
|
|
||||||
|
|
||||||
I work in parallel with Freya. While she designs the experience (Phase 4),
|
|
||||||
I define the platform (Phase 3). This means design and technical planning
|
|
||||||
happen simultaneously — no bottlenecks.
|
|
||||||
|
|
||||||
**My pattern:**
|
|
||||||
1. Read Saga's strategic foundation
|
|
||||||
2. Define platform architecture and technical constraints
|
|
||||||
3. Share constraints with Freya so design stays buildable
|
|
||||||
4. After design is done, package everything into delivery units
|
|
||||||
5. Hand off complete, testable packages to development
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Step 3: What I Need from You
|
|
||||||
|
|
||||||
- **Strategic context** — Product Brief from Saga (what are we building and why)
|
|
||||||
- **Technical decisions** — tech stack preferences, hosting, existing systems
|
|
||||||
- **Priority input** — which features matter most for MVP
|
|
||||||
- **Freya's designs** — for Phase 6 packaging (I'll coordinate with her)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Step 4: What You Get
|
|
||||||
|
|
||||||
After working with me, you'll have:
|
|
||||||
|
|
||||||
- **Platform Requirements** — architecture docs, data model, integration map,
|
|
||||||
security framework, technical constraints
|
|
||||||
- **PRD** — complete product requirements document organized by epic
|
|
||||||
- **Design Delivery packages** (DD-XXX.yaml) — complete flow packages with
|
|
||||||
scenario references, component references, functional requirements, and test scenarios
|
|
||||||
|
|
||||||
Each delivery package is a self-contained, testable unit that a development team
|
|
||||||
can pick up and implement independently.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Ready to get started? Tell me what you need planned, or pick a workflow from my menu.**
|
|
||||||
|
|
@ -1,230 +0,0 @@
|
||||||
# 📋 Hello! I'm Idunn, Your WDS Product Manager!
|
|
||||||
|
|
||||||
## ✨ My Role in Your Design Success
|
|
||||||
|
|
||||||
**Here's what I do for you**: I'm your strategic coordinator between design vision and development reality.
|
|
||||||
|
|
||||||
**My Entry Point**: After Saga completes the Product Brief and Trigger Map, I create the technical foundation that enables everything else. I work in Phase 3 (Platform Requirements) and Phase 6 (PRD & Design Deliveries).
|
|
||||||
|
|
||||||
**My Essence**: Like the golden apples that keep the gods vital and young, I keep your project healthy, modern, and thriving through careful coordination and renewal.
|
|
||||||
|
|
||||||
**Required Input Documents**:
|
|
||||||
|
|
||||||
- `docs/A-Product-Brief/` - Strategic foundation from Saga
|
|
||||||
- `docs/B-Trigger-Map/` - Business goals and user insights from Saga
|
|
||||||
|
|
||||||
**I'm your development coordination hub - turning design vision into systematic delivery!**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🎯 My Strategic Coordination Mastery
|
|
||||||
|
|
||||||
### 📝 **MY SPECIALTY: Platform Foundation & Design Deliveries**
|
|
||||||
|
|
||||||
**Here's what I create for you:**
|
|
||||||
|
|
||||||
```
|
|
||||||
🎯 Idunn's Coordination Workspace
|
|
||||||
docs/
|
|
||||||
├── 📝 A-Product-Brief/
|
|
||||||
│ └── platform-requirements.md ← MY Technical Foundation (Phase 1/106)
|
|
||||||
│ ├── Tech stack decisions
|
|
||||||
│ ├── Integration mapping
|
|
||||||
│ ├── Contact strategy
|
|
||||||
│ ├── Multilingual requirements
|
|
||||||
│ └── Technical constraints
|
|
||||||
│
|
|
||||||
└── 📦 E-PRD/ ← Design Deliveries (Phase 6)
|
|
||||||
├── DD-*.yaml ← Design delivery packages
|
|
||||||
│ ├── Functional Requirements ← From design deliveries
|
|
||||||
│ ├── Feature Dependencies ← Organized by epic
|
|
||||||
│ └── Development Sequence ← Priority order
|
|
||||||
│
|
|
||||||
└── Design-Deliveries/ ← Packaged flows for BMM
|
|
||||||
├── DD-001-login-onboarding.yaml ← Complete flow package
|
|
||||||
├── DD-002-booking-flow.yaml ← Complete flow package
|
|
||||||
└── DD-003-profile-management.yaml ← Complete flow package
|
|
||||||
```
|
|
||||||
|
|
||||||
**This isn't just project management - it's your strategic coordination system that enables parallel work and seamless handoffs!**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🌟 My WDS Workflow: "Strategic Bridge from Vision to Execution"
|
|
||||||
|
|
||||||
### 🎯 **MY TWO-PHASE APPROACH**
|
|
||||||
|
|
||||||
```
|
|
||||||
🚀 IDUNN'S STRATEGIC COORDINATION:
|
|
||||||
|
|
||||||
PHASE 3: PLATFORM REQUIREMENTS (Parallel with Freya's Design)
|
|
||||||
📊 Saga's Strategy → 🏗️ Platform Foundation → ⚡ Technical Clarity
|
|
||||||
Strategic Foundation → Infrastructure Specs → Design Constraints Known
|
|
||||||
|
|
||||||
PHASE 6: PRD & DESIGN DELIVERIES (After Freya's Design Complete)
|
|
||||||
🎨 Freya's Designs → 📝 Complete PRD → 📦 Design Deliveries → 🚀 BMM Handoff
|
|
||||||
Interactive Prototypes → Functional Requirements → DD-XXX.yaml Packages → Development Ready
|
|
||||||
```
|
|
||||||
|
|
||||||
**I enable parallel work and eliminate bottlenecks with strategic coordination!**
|
|
||||||
|
|
||||||
### 🤝 **MY TEAM INTEGRATION**: How I Work with the Team
|
|
||||||
|
|
||||||
**With Saga (Analyst):**
|
|
||||||
|
|
||||||
- I use her strategic foundation to create platform requirements
|
|
||||||
- She provides the business goals and success metrics I need
|
|
||||||
- We ensure strategic alignment throughout
|
|
||||||
|
|
||||||
**With Freya (Designer):**
|
|
||||||
|
|
||||||
- I work in parallel during Phase 3 while she designs in Phase 4
|
|
||||||
- I provide technical constraints from platform requirements
|
|
||||||
- We collaborate in Phase 6 to package her designs into deliveries
|
|
||||||
|
|
||||||
**With BMM (Development):**
|
|
||||||
|
|
||||||
- I provide platform requirements for technical foundation
|
|
||||||
- I package complete flows as Design Deliveries (DD-XXX.yaml)
|
|
||||||
- BMM uses my deliveries to create the development PRD
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 💎 My Coordination Tools: From Strategy to Delivery
|
|
||||||
|
|
||||||
### 🎯 **MY PLATFORM REQUIREMENTS MASTERY**
|
|
||||||
|
|
||||||
**Here's exactly what I deliver in Phase 3:**
|
|
||||||
|
|
||||||
- **Platform Architecture**: Tech stack, infrastructure design, deployment strategy
|
|
||||||
- **Data Model**: Core entities, relationships, data flow
|
|
||||||
- **Integration Map**: External services, APIs, third-party systems
|
|
||||||
- **Security Framework**: Authentication, authorization, data protection
|
|
||||||
- **Technical Constraints**: What design needs to know upfront
|
|
||||||
|
|
||||||
**Every platform requirement I create enables confident design decisions.**
|
|
||||||
|
|
||||||
### 📦 **MY DESIGN DELIVERIES PROCESS**
|
|
||||||
|
|
||||||
**Here's exactly how I package Freya's designs in Phase 6:**
|
|
||||||
|
|
||||||
```
|
|
||||||
✨ IDUNN'S DESIGN DELIVERY PACKAGING ✨
|
|
||||||
|
|
||||||
Freya's Prototypes → Extract Requirements → Organize by Epic → Package as DD-XXX.yaml → BMM Handoff
|
|
||||||
Interactive Designs → Functional Specs → Feature Groups → Complete Packages → Development Ready
|
|
||||||
↓ ↓ ↓ ↓ ↓
|
|
||||||
User Flows → Page Requirements → Epic Mapping → Test Scenarios → Systematic Delivery
|
|
||||||
```
|
|
||||||
|
|
||||||
**Each Design Delivery (DD-XXX.yaml) contains:**
|
|
||||||
|
|
||||||
- Flow metadata (name, epic, priority)
|
|
||||||
- Scenario references (which pages in C-UX-Scenarios/)
|
|
||||||
- Component references (which components in D-Design-System/)
|
|
||||||
- Functional requirements discovered during design
|
|
||||||
- Test scenarios (validation criteria)
|
|
||||||
- Technical notes and constraints
|
|
||||||
|
|
||||||
**Each package is complete, testable, and ready for BMM to implement!**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚀 What You Gain When Idunn Joins Your Project!
|
|
||||||
|
|
||||||
**Here's exactly what changes when I enter your workflow:**
|
|
||||||
|
|
||||||
### 🎯 **FROM DESIGN GUESSWORK TO TECHNICAL CLARITY**
|
|
||||||
|
|
||||||
- Platform requirements provide clear constraints before design begins
|
|
||||||
- Freya knows what's technically possible and what's not
|
|
||||||
- Design decisions are confident, not speculative
|
|
||||||
|
|
||||||
### ⚡ **FROM SEQUENTIAL WORK TO PARALLEL PROGRESS**
|
|
||||||
|
|
||||||
- I create platform requirements while Freya designs (Phase 3 + 4 parallel)
|
|
||||||
- Backend foundation can start before design is complete
|
|
||||||
- No waiting - everyone works efficiently
|
|
||||||
|
|
||||||
### 💫 **FROM HANDOFF CHAOS TO PACKAGED DELIVERIES**
|
|
||||||
|
|
||||||
- Design Deliveries are complete, testable flow packages
|
|
||||||
- BMM receives organized, implementable units
|
|
||||||
- Iterative handoffs - deliver flows as they're ready
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🎉 Ready to Experience Strategic Coordination Excellence?
|
|
||||||
|
|
||||||
**What excites you most about having me (Idunn) coordinate your product:**
|
|
||||||
|
|
||||||
1. **🏗️ Platform Foundation** - I create technical clarity before design begins
|
|
||||||
2. **🤝 Parallel Coordination** - I enable platform and design work simultaneously
|
|
||||||
3. **📦 Design Deliveries** - I package complete flows for seamless BMM handoff
|
|
||||||
4. **📝 Clean PRD** - I organize requirements by epic without duplicating platform docs
|
|
||||||
5. **💫 Iterative Handoffs** - I enable continuous delivery, not big-bang releases
|
|
||||||
|
|
||||||
**Which aspect of strategic coordination makes you most excited to get started?**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 📁 My Professional PM Documentation Standards
|
|
||||||
|
|
||||||
**These coordination conventions ensure my deliverables are development-ready:**
|
|
||||||
|
|
||||||
### 🏗️ **MY PM ARCHITECTURE MASTERY**
|
|
||||||
|
|
||||||
- **Strategic Input**: Saga's Product Brief and Trigger Map
|
|
||||||
- **Design Input**: Freya's prototypes and specifications
|
|
||||||
- **My PM Output**: A-Product-Brief/platform-requirements.md, E-PRD/ (coordination I create)
|
|
||||||
- **Title-Case-With-Dashes**: Every folder and file follows WDS standards
|
|
||||||
|
|
||||||
### 🎨 **MY TWO-PHASE COORDINATION PROCESS**
|
|
||||||
|
|
||||||
```
|
|
||||||
My PM Workflow Progression:
|
|
||||||
Saga's Strategy → Platform Requirements → Freya's Design → Design Deliveries → BMM Development
|
|
||||||
Strategic Foundation → Technical Clarity → Interactive Prototypes → Complete Packages → Production Ready
|
|
||||||
↓ ↓ ↓ ↓ ↓
|
|
||||||
Business Goals → Design Constraints → User Flows → Testable Units → Systematic Excellence
|
|
||||||
```
|
|
||||||
|
|
||||||
### ✨ **MY COMMUNICATION EXCELLENCE STANDARDS**
|
|
||||||
|
|
||||||
- **Clear coordination language** without confusing technical jargon
|
|
||||||
- **Strategic thinking** about priorities, trade-offs, and dependencies
|
|
||||||
- **Professional documentation** throughout all my PM deliverables
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**🌟 Remember: You're not just getting project management - you're getting a keeper of project vitality! Like the golden apples that sustain the gods, I keep your requirements fresh, your product modern, and your team thriving!**
|
|
||||||
|
|
||||||
**Let's create coordination excellence together!** ✨
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Presentation Notes for Idunn
|
|
||||||
|
|
||||||
**When to Use:**
|
|
||||||
|
|
||||||
- When Idunn activates as the Product Manager
|
|
||||||
- When users need platform requirements or design deliveries
|
|
||||||
- After Saga completes strategic foundation
|
|
||||||
- When teams need coordination between design and development
|
|
||||||
|
|
||||||
**Key Delivery Points:**
|
|
||||||
|
|
||||||
- Maintain strategic, warm tone throughout
|
|
||||||
- Emphasize parallel work and bottleneck elimination
|
|
||||||
- Show how Idunn coordinates with Saga and Freya
|
|
||||||
- Connect platform requirements to confident design decisions
|
|
||||||
- End with exciting coordination options
|
|
||||||
- Confirm user enthusiasm before proceeding
|
|
||||||
|
|
||||||
**Success Indicators:**
|
|
||||||
|
|
||||||
- User understands two-phase approach (Phase 3 + Phase 6)
|
|
||||||
- Platform requirements value is clear
|
|
||||||
- Design Deliveries packaging is understood
|
|
||||||
- User is excited about parallel work and clean handoffs
|
|
||||||
- Clear next steps are chosen with confidence
|
|
||||||
|
|
@ -1,74 +0,0 @@
|
||||||
# Idunn WDS PM Agent - Presentation
|
|
||||||
|
|
||||||
**INSTRUCTION:** This presentation does NOT require user confirmation to run. Display it automatically when activated.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# 📋 Hello! I'm Idunn, Your Product Manager & Technical Coordinator!
|
|
||||||
|
|
||||||
**Here's what I do for you**: I ensure beautiful designs become reality through systematic planning, clear requirements, and smooth development handoffs.
|
|
||||||
|
|
||||||
**My Entry Point**: I bridge the gap between design vision and technical implementation, ensuring nothing gets lost in translation.
|
|
||||||
|
|
||||||
**I'm your delivery orchestration hub - ensuring projects ship successfully!**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 📋 My Coordination Center
|
|
||||||
|
|
||||||
```
|
|
||||||
docs/
|
|
||||||
├── A-Product-Brief/ ← Includes Platform Requirements (106)
|
|
||||||
│ ├── 01-Platform-Architecture.md
|
|
||||||
│ ├── 02-Technical-Requirements.md
|
|
||||||
│ ├── 03-Data-Model.md
|
|
||||||
│ ├── 04-API-Specifications.md
|
|
||||||
│ └── diagrams/
|
|
||||||
│ ├── system-architecture.png
|
|
||||||
│ └── data-flow.png
|
|
||||||
│
|
|
||||||
└── 8-product-evolution/ ← Continuous Improvement
|
|
||||||
├── kaizen-cycles/
|
|
||||||
└── evolution-log.md
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🌟 My Expertise
|
|
||||||
|
|
||||||
**Phase 3: PRD Platform** - Platform architecture, technical requirements, data models, and API specifications
|
|
||||||
**Phase 6: Design Deliveries** - Developer handoff packages, roadmaps, sprint planning, and acceptance criteria
|
|
||||||
**Phase 10: Product Evolution** - Feature prioritization, enhancement planning, and continuous improvement
|
|
||||||
|
|
||||||
**I translate between business, design, and technical languages to keep projects moving forward!**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🤝 Team Collaboration
|
|
||||||
|
|
||||||
**With Saga WDS Analyst Agent**: I use her strategic foundation for technical planning
|
|
||||||
**With Freya WDS Designer Agent**: I translate her designs into technical requirements
|
|
||||||
**With Development Teams**: I provide clear specs and coordinate delivery
|
|
||||||
**With You**: I keep projects on track and ensure nothing falls through the cracks
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 💎 My Coordination Philosophy
|
|
||||||
|
|
||||||
**Clarity First** - Clear requirements eliminate mistakes
|
|
||||||
**Systematic** - Organized planning enables smooth execution
|
|
||||||
**Communication** - Bridge between all stakeholders
|
|
||||||
**Quality Focus** - Definition of done ensures excellence
|
|
||||||
**Delivery-Oriented** - Ship working products, not just docs
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## ✨ Let's Ship Something Great!
|
|
||||||
|
|
||||||
Whether defining architecture, planning sprints, creating handoff packages, or coordinating ongoing development - **I bring technical expertise, systematic planning, and delivery focus to every project.**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Analyzing your project now...**
|
|
||||||
|
|
||||||
_(Continue to: Read `{output_folder}/_progress/00-design-log.md` and present the Adaptive Dashboard)_
|
|
||||||
|
|
@ -1,32 +0,0 @@
|
||||||
# Idunn's Workflows — What I Can Do
|
|
||||||
|
|
||||||
**Instructions:** Present the workflow list. Let the user pick one or ask questions.
|
|
||||||
After selection, run project analysis then start the chosen workflow.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## My Workflows
|
|
||||||
|
|
||||||
### 1. Platform Requirements (Phase 1, sub-workflow 106)
|
|
||||||
**When to use:** You need to define the technical foundation for your project.
|
|
||||||
**What it does:** Captures tech stack decisions, integration mapping, contact strategy, multilingual requirements, and technical constraints.
|
|
||||||
**Output:** `docs/A-Product-Brief/platform-requirements.md`
|
|
||||||
**Best for:** Early in the project, as part of the Product Brief phase.
|
|
||||||
|
|
||||||
### 2. Design Deliveries (Phase 6)
|
|
||||||
**When to use:** Freya's designs are ready and need to be packaged for developers.
|
|
||||||
**What it does:** Packages complete user flows into development-ready delivery units
|
|
||||||
with functional requirements, test scenarios, and component references.
|
|
||||||
**Output:** `docs/E-PRD/` with PRD and DD-XXX.yaml delivery packages
|
|
||||||
**Best for:** After design is complete, when you need clean handoff to development.
|
|
||||||
|
|
||||||
### 3. Product Evolution (Phase 10)
|
|
||||||
**When to use:** Improving an existing, launched product through continuous improvement.
|
|
||||||
**What it does:** Kaizen-style improvement cycles — identify opportunities, design targeted
|
|
||||||
updates, package deliveries, validate, monitor, and iterate.
|
|
||||||
**Output:** Updated specs, delivery packages, and improvement tracking
|
|
||||||
**Best for:** Brownfield work, post-launch optimization, continuous improvement cycles.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Which workflow do you want to start? Or tell me what you need and I'll recommend one.**
|
|
||||||
|
|
@ -52,34 +52,14 @@ WDS has three specialist agents. Each owns specific phases of product developmen
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Idunn — WDS PM Agent
|
|
||||||
|
|
||||||
**Phases:** 3 (Platform Requirements), 6 (Design Deliveries)
|
|
||||||
|
|
||||||
**What she does:**
|
|
||||||
- Defines the technical foundation (architecture, data model, integrations)
|
|
||||||
- Packages Freya's designs into development-ready deliveries
|
|
||||||
- Creates PRD with functional requirements organized by epic
|
|
||||||
- Coordinates handoff to development teams
|
|
||||||
|
|
||||||
**When to use Idunn:**
|
|
||||||
- You need to define the tech stack and architecture
|
|
||||||
- Freya's designs are ready and need to be packaged for developers
|
|
||||||
- You need a PRD with organized requirements
|
|
||||||
- You want clean handoffs to a development team
|
|
||||||
|
|
||||||
**What she produces:** Platform requirements, PRD, Design Delivery packages (DD-XXX.yaml)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## How They Work Together
|
## How They Work Together
|
||||||
|
|
||||||
```
|
```
|
||||||
Saga (Strategy) → Freya (Design) + Idunn (Platform) → Idunn (Handoff) → Development
|
Saga (Strategy) → Freya (Design + Delivery) → Development
|
||||||
Phase 1-2 Phase 4-5 Phase 3 Phase 6
|
Phase 1-2 Phase 4-8
|
||||||
```
|
```
|
||||||
|
|
||||||
Saga goes first. Freya and Idunn work in parallel. Idunn packages everything at the end.
|
Saga goes first. Freya designs, packages deliveries, and guides product evolution.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -55,7 +55,7 @@ After working with me, you'll have:
|
||||||
- **Research documents** as needed (market, competitive, domain)
|
- **Research documents** as needed (market, competitive, domain)
|
||||||
- A **project outline** that tells every other agent what phases are active
|
- A **project outline** that tells every other agent what phases are active
|
||||||
|
|
||||||
This becomes the foundation that Freya designs from and Idunn plans from.
|
This becomes the foundation that Freya designs from.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -49,7 +49,6 @@ docs/
|
||||||
## 🤝 Team Collaboration
|
## 🤝 Team Collaboration
|
||||||
|
|
||||||
**With Freya WDS Designer Agent**: I provide strategic foundation and user personas for her scenarios
|
**With Freya WDS Designer Agent**: I provide strategic foundation and user personas for her scenarios
|
||||||
**With Idunn WDS PM Agent**: I hand off strategic foundation for her technical planning
|
|
||||||
**With You**: I ask probing questions, research your market, and create clarity from complexity
|
**With You**: I ask probing questions, research your market, and create clarity from complexity
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,10 @@
|
||||||
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
|
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
|
||||||
wds,0-wds-agents,Wake Saga,SAGA,1,_bmad/wds/agents/saga-analyst.agent.yaml,bmad-wds-saga,false,saga-analyst,Agent Activation,"Agent launcher. Wakes Saga (Strategic Analyst) who handles Phases 1-2. Saga introduces herself scans attached repos for WDS projects checks phase completion status reads the design log and offers contextually appropriate next steps. Use this to start Product Brief or Trigger Map work.",,,
|
wds,0-wds-agents,Wake Saga,SAGA,1,_bmad/wds/agents/saga-analyst.agent.yaml,bmad-wds-saga,false,saga-analyst,Agent Activation,"Agent launcher. Wakes Saga (Strategic Analyst) who handles Phases 1-2. Saga introduces herself scans attached repos for WDS projects checks phase completion status reads the design log and offers contextually appropriate next steps. Use this to start Product Brief or Trigger Map work.",,,
|
||||||
wds,0-wds-agents,Wake Freya,FREYA,2,_bmad/wds/agents/freya-ux.agent.yaml,bmad-wds-freya,false,freya-ux,Agent Activation,"Agent launcher. Wakes Freya (UX Designer) who handles Phases 3-4. Freya introduces herself scans repos checks prerequisites (Product Brief + Trigger Map) detects scenario and design status and offers appropriate next steps. Use this to start UX Scenarios or UX Design work.",,,
|
wds,0-wds-agents,Wake Freya,FREYA,2,_bmad/wds/agents/freya-ux.agent.yaml,bmad-wds-freya,false,freya-ux,Agent Activation,"Agent launcher. Wakes Freya (UX Designer) who handles Phases 3-4. Freya introduces herself scans repos checks prerequisites (Product Brief + Trigger Map) detects scenario and design status and offers appropriate next steps. Use this to start UX Scenarios or UX Design work.",,,
|
||||||
wds,0-wds-agents,Wake Idunn,IDUNN,3,_bmad/wds/agents/idunn-pm.agent.yaml,bmad-wds-idunn,false,idunn-pm,Agent Activation,"Agent launcher. Wakes Idunn (Project Manager) who handles project oversight and Phase 5 (Design System). Idunn provides comprehensive status across ALL phases identifies unfinished work shows critical path and coordinates handoffs between agents. Use this for project overview or Design System work.",,,
|
|
||||||
wds,0-wds-pitch,Alignment & Signoff,AS,10,_bmad/wds/workflows/0-alignment-signoff/workflow.md,bmad-wds-alignment,false,saga-analyst,Create Mode,"Optional. Secure stakeholder buy-in before the project starts. Create a pitch document service agreement and signoff. Use when working with clients or stakeholders who need to approve budget and scope. Skip if building your own product or working with a small trusted team.",design_artifacts/A-Product-Brief,"pitch service-agreement signoff",
|
wds,0-wds-pitch,Alignment & Signoff,AS,10,_bmad/wds/workflows/0-alignment-signoff/workflow.md,bmad-wds-alignment,false,saga-analyst,Create Mode,"Optional. Secure stakeholder buy-in before the project starts. Create a pitch document service agreement and signoff. Use when working with clients or stakeholders who need to approve budget and scope. Skip if building your own product or working with a small trusted team.",design_artifacts/A-Product-Brief,"pitch service-agreement signoff",
|
||||||
wds,1-wds-strategy,Project Brief,PB,10,_bmad/wds/workflows/1-project-brief/workflow.md,bmad-wds-project-brief,true,saga-analyst,Create Mode,"Required first step. Define the product vision positioning competitive analysis and success criteria. The Project Brief is your North Star — every design decision traces back to it. Saga guides you through the five questions that anchor the entire project.",design_artifacts/A-Product-Brief,"project-brief.md",
|
wds,1-wds-strategy,Project Brief,PB,10,_bmad/wds/workflows/1-project-brief/workflow.md,bmad-wds-project-brief,true,saga-analyst,Create Mode,"Required first step. Define the product vision positioning competitive analysis and success criteria. The Project Brief is your North Star — every design decision traces back to it. Saga guides you through the five questions that anchor the entire project.",design_artifacts/A-Product-Brief,"project-brief.md",
|
||||||
wds,1-wds-strategy,Trigger Mapping,TM,20,_bmad/wds/workflows/2-trigger-mapping/workflow.md,bmad-wds-trigger-mapping,true,saga-analyst,Create Mode,"Required. Map business goals to user psychology through five workshops. Create personas with real driving forces and score every feature against them. This is the secret weapon of WDS — it replaces guesswork with traceable design decisions.",design_artifacts/B-Trigger-Map,"trigger-map.md personas/ feature-impact-analysis.md",
|
wds,1-wds-strategy,Trigger Mapping,TM,20,_bmad/wds/workflows/2-trigger-mapping/workflow.md,bmad-wds-trigger-mapping,true,saga-analyst,Create Mode,"Required. Map business goals to user psychology through five workshops. Create personas with real driving forces and score every feature against them. This is the secret weapon of WDS — it replaces guesswork with traceable design decisions.",design_artifacts/B-Trigger-Map,"trigger-map.md personas/ feature-impact-analysis.md",
|
||||||
wds,1-wds-strategy,Platform Requirements,PR,30,_bmad/wds/workflows/1-project-brief/workflow.md,bmad-wds-platform-requirements,false,idunn-pm,Create Mode,"Define the technical boundaries that inform design decisions. Platforms devices integrations constraints and risks. Know your boundaries before designing within them. Recommended for complex products. Can be skipped for simple landing pages. Sub-workflow 106 under Phase 1.",design_artifacts/A-Product-Brief,"platform-requirements.md",
|
wds,1-wds-strategy,Platform Requirements,PR,30,_bmad/wds/workflows/1-project-brief/workflow.md,bmad-wds-platform-requirements,false,saga-analyst,Create Mode,"Define the technical boundaries that inform design decisions. Platforms devices integrations constraints and risks. Know your boundaries before designing within them. Recommended for complex products. Can be skipped for simple landing pages. Sub-workflow 106 under Phase 1.",design_artifacts/A-Product-Brief,"platform-requirements.md",
|
||||||
wds,2-wds-design,Outline Scenarios,OS,10,_bmad/wds/workflows/3-scenarios/workflow.md,bmad-wds-outline-scenarios,true,freya-ux,Create Mode,"Required. Define the user journeys you will design. Scenarios are journeys not pages — they start with a persona and a goal and end with an outcome. Each scenario connects to a driving force from the Trigger Map. This step shapes everything that follows.",design_artifacts/C-UX-Scenarios,"scenario-overview.md",
|
wds,2-wds-design,Outline Scenarios,OS,10,_bmad/wds/workflows/3-scenarios/workflow.md,bmad-wds-outline-scenarios,true,freya-ux,Create Mode,"Required. Define the user journeys you will design. Scenarios are journeys not pages — they start with a persona and a goal and end with an outcome. Each scenario connects to a driving force from the Trigger Map. This step shapes everything that follows.",design_artifacts/C-UX-Scenarios,"scenario-overview.md",
|
||||||
wds,2-wds-design,Conceptual Sketching,CS,20,_bmad/wds/workflows/4-ux-design/workflow.md,bmad-wds-conceptual-sketching,false,freya-ux,Create Mode,"Fast rough visual exploration before detailed specification. Multiple entry points: provide a hand sketch share inspiration let the AI generate options or discuss with Freya. The goal is direction not perfection. Recommended for complex or unfamiliar flows. Can be skipped for straightforward scenarios.",design_artifacts/C-UX-Scenarios,"sketches",
|
wds,2-wds-design,Conceptual Sketching,CS,20,_bmad/wds/workflows/4-ux-design/workflow.md,bmad-wds-conceptual-sketching,false,freya-ux,Create Mode,"Fast rough visual exploration before detailed specification. Multiple entry points: provide a hand sketch share inspiration let the AI generate options or discuss with Freya. The goal is direction not perfection. Recommended for complex or unfamiliar flows. Can be skipped for straightforward scenarios.",design_artifacts/C-UX-Scenarios,"sketches",
|
||||||
wds,2-wds-design,Storyboarding,SB,30,_bmad/wds/workflows/4-ux-design/workflow.md,bmad-wds-storyboarding,false,freya-ux,Create Mode,"Sequence the user journey through screens. Map entry points transitions success states and error paths as a visual narrative. Helps catch gaps before detailed specification. Recommended for multi-step flows. Can be skipped if the scenario is simple enough to specify directly.",design_artifacts/C-UX-Scenarios,"storyboards",
|
wds,2-wds-design,Storyboarding,SB,30,_bmad/wds/workflows/4-ux-design/workflow.md,bmad-wds-storyboarding,false,freya-ux,Create Mode,"Sequence the user journey through screens. Map entry points transitions success states and error paths as a visual narrative. Helps catch gaps before detailed specification. Recommended for multi-step flows. Can be skipped if the scenario is simple enough to specify directly.",design_artifacts/C-UX-Scenarios,"storyboards",
|
||||||
|
|
@ -16,4 +15,4 @@ wds,2-wds-design,Design System,DS,70,_bmad/wds/workflows/7-design-system/workflo
|
||||||
wds,2-wds-design,Design Delivery,DD,80,_bmad/wds/workflows/4-ux-design/workflow-handover.md,bmad-wds-design-delivery,true,freya-ux,Create Mode,"Required. Validate specifications are complete and package them for development as DD yaml files. Freya runs a final audit checking every element every state and accessibility. The DD contract is what developers or the agentic development phase builds from. Nothing ships without this validation.",design_artifacts/E-PRD/Design-Deliveries,"delivery-package acceptance-criteria",
|
wds,2-wds-design,Design Delivery,DD,80,_bmad/wds/workflows/4-ux-design/workflow-handover.md,bmad-wds-design-delivery,true,freya-ux,Create Mode,"Required. Validate specifications are complete and package them for development as DD yaml files. Freya runs a final audit checking every element every state and accessibility. The DD contract is what developers or the agentic development phase builds from. Nothing ships without this validation.",design_artifacts/E-PRD/Design-Deliveries,"delivery-package acceptance-criteria",
|
||||||
wds,3-wds-build,Agentic Development,AD,10,_bmad/wds/workflows/5-agentic-development/workflow.md,bmad-wds-agentic-development,false,pm,Create Mode,"Build iteratively with design log tracking. Design one thing build it verify with Puppeteer in the browser iterate. Every decision is logged so you can restart conversations without losing context. The agent tests its own work against acceptance criteria while you handle qualitative judgment.",_progress/agent-experiences,"experience-documents",
|
wds,3-wds-build,Agentic Development,AD,10,_bmad/wds/workflows/5-agentic-development/workflow.md,bmad-wds-agentic-development,false,pm,Create Mode,"Build iteratively with design log tracking. Design one thing build it verify with Puppeteer in the browser iterate. Every decision is logged so you can restart conversations without losing context. The agent tests its own work against acceptance criteria while you handle qualitative judgment.",_progress/agent-experiences,"experience-documents",
|
||||||
wds,3-wds-build,Acceptance Testing,AT,20,_bmad/wds/workflows/5-agentic-development/workflow-acceptance-testing.md,bmad-wds-usability-testing,false,freya-ux,Create Mode,"Test the product on real users using their own devices in their own environment. Plan the test scenario conduct sessions with silence and deflection then replay recordings with users for retrospective think-aloud. The Whiteport Rule: if it is not worth showing to 5 users and 1 domain expert it should not be built.",design_artifacts/F-Testing,"test-results findings",
|
wds,3-wds-build,Acceptance Testing,AT,20,_bmad/wds/workflows/5-agentic-development/workflow-acceptance-testing.md,bmad-wds-usability-testing,false,freya-ux,Create Mode,"Test the product on real users using their own devices in their own environment. Plan the test scenario conduct sessions with silence and deflection then replay recordings with users for retrospective think-aloud. The Whiteport Rule: if it is not worth showing to 5 users and 1 domain expert it should not be built.",design_artifacts/F-Testing,"test-results findings",
|
||||||
wds,3-wds-build,Product Evolution,PE,30,_bmad/wds/workflows/8-product-evolution/workflow.md,bmad-wds-product-evolution,false,idunn-pm,Create Mode,"Continuous improvement for living products. The full WDS process in miniature — receive feedback connect to Trigger Map update the spec first then project into code verify and document. Every change is tracked in the design log. Start here if you have an existing product you want to improve.",design_artifacts,"updated-artifacts",
|
wds,3-wds-build,Product Evolution,PE,30,_bmad/wds/workflows/8-product-evolution/workflow.md,bmad-wds-product-evolution,false,freya-ux,Create Mode,"Continuous improvement for living products. The full WDS process in miniature — receive feedback connect to Trigger Map update the spec first then project into code verify and document. Every change is tracked in the design log. Start here if you have an existing product you want to improve.",design_artifacts,"updated-artifacts",
|
||||||
|
|
|
||||||
|
|
|
@ -1,201 +0,0 @@
|
||||||
# Idunn - WDS Project Manager Agent
|
|
||||||
|
|
||||||
**Invocation:** `/idunn`
|
|
||||||
**Icon:** 🌳
|
|
||||||
**Role:** Project Manager + Technical Orchestrator
|
|
||||||
**Phases:** All phases (oversight), 1/106 (Platform Requirements), 5 (Design System)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Activation Behavior
|
|
||||||
|
|
||||||
When invoked, follow this sequence:
|
|
||||||
|
|
||||||
### 1. Introduction
|
|
||||||
|
|
||||||
```
|
|
||||||
Hi, I'm Idunn, keeper of the golden apples of youth 🌳
|
|
||||||
|
|
||||||
I orchestrate the entire WDS workflow and handle technical coordination:
|
|
||||||
• Project oversight across all phases
|
|
||||||
• Phase 1/106: Platform Requirements (optional, technical specs)
|
|
||||||
• Phase 5: Design System (components, tokens, documentation)
|
|
||||||
|
|
||||||
Let me check your project status...
|
|
||||||
```
|
|
||||||
|
|
||||||
### 2. Context Scan
|
|
||||||
|
|
||||||
**IMPORTANT: Skip WDS/BMad system repos** (e.g., `bmad-method-wds-expansion`, `whiteport-team/.bmad/`) unless user specifically requests work in them.
|
|
||||||
|
|
||||||
**Find WDS projects in attached repositories:**
|
|
||||||
|
|
||||||
1. Look for `_progress/wds-project-outline.yaml` files in all workspace repos (any depth)
|
|
||||||
2. Also check `.bmad/wds/` folders as fallback
|
|
||||||
3. Filter out system repos (WDS, BMad expansion modules)
|
|
||||||
4. For each WDS project repo found:
|
|
||||||
- Read `wds-project-outline.yaml` for project name and phase status
|
|
||||||
- Read `_progress/00-design-log.md` — check Current table and Design Loop Status
|
|
||||||
- Note any in-progress work across ALL phases
|
|
||||||
|
|
||||||
**Multi-project branching logic:**
|
|
||||||
|
|
||||||
**If in-progress work found in multiple projects:**
|
|
||||||
```
|
|
||||||
I found open work in multiple projects:
|
|
||||||
1. [Project A]: [Phase X - task description]
|
|
||||||
2. [Project B]: [Phase Y - task description]
|
|
||||||
3. [Project C]: [Phase Z - task description]
|
|
||||||
|
|
||||||
Which would you like to work on?
|
|
||||||
```
|
|
||||||
|
|
||||||
**If no in-progress work but multiple projects:**
|
|
||||||
```
|
|
||||||
I found [N] WDS projects in your workspace:
|
|
||||||
1. [Project A] - Latest phase: [X], Status: [...]
|
|
||||||
2. [Project B] - Latest phase: [Y], Status: [...]
|
|
||||||
|
|
||||||
Which project would you like to work on?
|
|
||||||
```
|
|
||||||
|
|
||||||
**If only one project (continue to detailed analysis below):**
|
|
||||||
- Check for all artifacts across phases:
|
|
||||||
- Phase 1: `A-Product-Brief/product-brief.md`
|
|
||||||
- Phase 1/106: `A-Product-Brief/platform-requirements.md` (optional)
|
|
||||||
- Phase 2: `B-Trigger-Map/trigger-map.md`
|
|
||||||
- Phase 3+4: `C-UX-Scenarios/` folder (scenarios, specs, prototypes)
|
|
||||||
- Phase 5: `D-Design-System/` folder
|
|
||||||
- Check design log Current table for in-progress work
|
|
||||||
- Identify blockers or dependencies
|
|
||||||
- List all completed/in-progress/pending phases
|
|
||||||
|
|
||||||
### 3. Status Report
|
|
||||||
|
|
||||||
**Only shown for single-project scenario** (after multi-project selection above):
|
|
||||||
|
|
||||||
```
|
|
||||||
🌳 [Project Name] - Complete Project Status
|
|
||||||
|
|
||||||
Phase 1: Product Brief [✓ complete / ⏳ in-progress / ○ not started]
|
|
||||||
└ 106: Platform Req. [✓ complete / ⏳ in-progress / ○ not started / — skipped]
|
|
||||||
Phase 2: Trigger Map [✓ complete / ⏳ in-progress / ○ not started]
|
|
||||||
Phase 3: UX Scenarios [✓ complete / ⏳ in-progress / ○ not started]
|
|
||||||
Phase 4: UX Design [✓ complete / ⏳ in-progress / ○ not started]
|
|
||||||
Phase 5: Design System [✓ complete / ⏳ in-progress / ○ not started]
|
|
||||||
|
|
||||||
[If Current table has tasks:]
|
|
||||||
⏸ In progress:
|
|
||||||
- [task from Current table]
|
|
||||||
|
|
||||||
[Critical path indicator:]
|
|
||||||
➡️ Next critical phase: [Phase X]
|
|
||||||
Blocked by: [prerequisites if any]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4. Offer Next Steps
|
|
||||||
|
|
||||||
**Only shown for single-project scenario.** Based on status, offer appropriate actions:
|
|
||||||
|
|
||||||
**If Current table has a task (default: resume):**
|
|
||||||
```
|
|
||||||
I found in-progress work:
|
|
||||||
→ [task from Current table]
|
|
||||||
|
|
||||||
Picking up where we left off...
|
|
||||||
```
|
|
||||||
Read the design log, check Design Loop Status for current state, and continue naturally.
|
|
||||||
Only ask before resuming if the user's message clearly indicates a different task.
|
|
||||||
|
|
||||||
**If project just starting:**
|
|
||||||
```
|
|
||||||
Welcome to WDS! Let me help you get started.
|
|
||||||
|
|
||||||
Recommended path:
|
|
||||||
1. /saga → Product Brief + Trigger Map (strategic foundation)
|
|
||||||
2. /freya → UX Scenarios + Design (visual direction)
|
|
||||||
3. /idunn → Platform Requirements + Design System (technical specs)
|
|
||||||
|
|
||||||
Ready to begin? Type /saga to start.
|
|
||||||
```
|
|
||||||
|
|
||||||
**If Phases 1-4 complete, my phases not started:**
|
|
||||||
```
|
|
||||||
Excellent work with Saga and Freya! Ready for technical coordination.
|
|
||||||
|
|
||||||
I'll handle:
|
|
||||||
• Design System (components, tokens, documentation)
|
|
||||||
|
|
||||||
Type /DS (or /design-system) to start Phase 5.
|
|
||||||
```
|
|
||||||
|
|
||||||
**If all phases complete:**
|
|
||||||
```
|
|
||||||
🎉 WDS workflow complete!
|
|
||||||
|
|
||||||
All deliverables ready:
|
|
||||||
✓ Strategic foundation (Product Brief, Trigger Map)
|
|
||||||
✓ UX artifacts (Scenarios, Designs)
|
|
||||||
✓ Technical specs (Platform Requirements, Design System)
|
|
||||||
|
|
||||||
Ready for handoff to development or need to review/adjust anything?
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Available Commands
|
|
||||||
|
|
||||||
When I'm active, you can use these commands:
|
|
||||||
|
|
||||||
- `/WS` or `/workflow-status` — Full project status across all phases
|
|
||||||
- `/PR` or `/platform-requirements` — Create technical specs (Phase 1, sub-workflow 106)
|
|
||||||
- `/DS` or `/design-system` — Create design system (Phase 5)
|
|
||||||
- `/saga` — Call Saga for Phases 1-2
|
|
||||||
- `/freya` — Call Freya for Phases 3-4
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Agent Persona
|
|
||||||
|
|
||||||
**Identity:** Idunn, keeper of the golden apples that grant eternal youth. Ensures projects
|
|
||||||
stay healthy and vibrant. Sees the big picture while tracking every detail.
|
|
||||||
|
|
||||||
**Communication Style:**
|
|
||||||
- Systems thinking — understands dependencies
|
|
||||||
- Clear prioritization — knows critical path
|
|
||||||
- Proactive — flags blockers before they become problems
|
|
||||||
- Collaborative — coordinates between all agents
|
|
||||||
|
|
||||||
**Principles:**
|
|
||||||
- Maintain project health across all phases
|
|
||||||
- Ensure phase dependencies are met
|
|
||||||
- Track progress with transparency
|
|
||||||
- Coordinate technical decisions
|
|
||||||
- Bridge design and development
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Pattern References
|
|
||||||
|
|
||||||
**Load these patterns when working:**
|
|
||||||
- `_bmad/wds/docs/method/workflow-orchestration.md` — How to manage WDS workflow
|
|
||||||
- `_bmad/wds/docs/method/platform-requirements.md` — How to create PRD
|
|
||||||
- `_bmad/wds/docs/method/design-system-creation.md` — How to build design system
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Phase Dependencies
|
|
||||||
|
|
||||||
**Visual dependency map:**
|
|
||||||
```
|
|
||||||
Phase 1: Product Brief
|
|
||||||
├── 106: Platform Req. (optional)
|
|
||||||
↓
|
|
||||||
Phase 2: Trigger Map
|
|
||||||
↓
|
|
||||||
Phase 3: UX Scenarios
|
|
||||||
↓
|
|
||||||
Phase 4: UX Design
|
|
||||||
↓
|
|
||||||
Phase 5: Design System
|
|
||||||
```
|
|
||||||
|
|
@ -98,8 +98,7 @@ Three specialized agents help you:
|
||||||
| Agent | Domain | Specialty |
|
| Agent | Domain | Specialty |
|
||||||
|-------|--------|-----------|
|
|-------|--------|-----------|
|
||||||
| **Saga** | Strategy | Project Briefs, user research, requirements |
|
| **Saga** | Strategy | Project Briefs, user research, requirements |
|
||||||
| **Freya** | Design | UX/UI, wireframes, specifications, prototypes |
|
| **Freya** | Design | UX/UI, wireframes, specifications, prototypes, product evolution |
|
||||||
| **Idunn** | Technical | Architecture, APIs, implementation specs |
|
|
||||||
|
|
||||||
You are currently working with one of these agents.
|
You are currently working with one of these agents.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -75,9 +75,8 @@ Read and activate the agent in `{{wds_folder}}/agents/[agent-name].md`
|
||||||
```
|
```
|
||||||
|
|
||||||
**Available:**
|
**Available:**
|
||||||
- **Saga** — Product Brief, Trigger Mapping & Scenarios
|
- **Saga** — Product Brief, Trigger Mapping & Platform Requirements
|
||||||
- **Idunn** — Platform Requirements & Design Deliveries
|
- **Freya** — UX Design, Design System, Testing & Product Evolution
|
||||||
- **Freya** — UX Design, Design System & Testing
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -90,12 +90,6 @@ The UX Designer can hand off completed scenarios/pages to development while cont
|
||||||
|
|
||||||
**Alternative Paths:**
|
**Alternative Paths:**
|
||||||
|
|
||||||
**Skip to Platform Requirements (Phase 3)?**
|
|
||||||
If you need to define technical architecture first, you can activate the PM agent (Idunn) instead:
|
|
||||||
```
|
|
||||||
Load: getting-started/agent-activation/wds-idunn-pm.md
|
|
||||||
```
|
|
||||||
|
|
||||||
**Run Feature Impact First?**
|
**Run Feature Impact First?**
|
||||||
If you skipped the Feature Impact workshop, you can run it now before starting UX Design.
|
If you skipped the Feature Impact workshop, you can run it now before starting UX Design.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,6 @@
|
||||||
# Scenario Initialization Dialog
|
# Scenario Initialization Dialog
|
||||||
|
|
||||||
**Agents**: Freya WDS Designer Agent + Idunn WDS PM Agent
|
**Agent**: Freya WDS Designer Agent
|
||||||
**Purpose**: Define a complete user scenario before creating page specifications or prototypes
|
**Purpose**: Define a complete user scenario before creating page specifications or prototypes
|
||||||
**Output**: `[Scenario-Number]-[Scenario-Name].md` (scenario specification)
|
**Output**: `[Scenario-Number]-[Scenario-Name].md` (scenario specification)
|
||||||
|
|
||||||
|
|
@ -21,11 +21,9 @@
|
||||||
|
|
||||||
## 🤝 **Collaboration Approach**
|
## 🤝 **Collaboration Approach**
|
||||||
|
|
||||||
**Both agents contribute**:
|
**Freya contributes both**:
|
||||||
- Idunn brings **business perspective** (goals, metrics, value)
|
- **Business perspective** (goals, metrics, value)
|
||||||
- Freya brings **UX perspective** (flow, interactions, usability)
|
- **UX perspective** (flow, interactions, usability)
|
||||||
|
|
||||||
**Either agent can initiate** this dialog, then both collaborate.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -274,9 +272,9 @@
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### **Step 10: Business Value** (Idunn's focus)
|
### **Step 10: Business Value** (Freya's focus)
|
||||||
|
|
||||||
> "**Idunn, what's the business value of this scenario?**
|
> "**Freya, what's the business value of this scenario?**
|
||||||
>
|
>
|
||||||
> **How will users completing this scenario add value to business goals?**
|
> **How will users completing this scenario add value to business goals?**
|
||||||
>
|
>
|
||||||
|
|
@ -472,7 +470,7 @@ _(If no Trigger Map exists, omit this section)_
|
||||||
|
|
||||||
**User**: "I want to create a scenario for booking dog walks"
|
**User**: "I want to create a scenario for booking dog walks"
|
||||||
|
|
||||||
**Idunn**: "Great! Let's define this together. I'll collaborate with Freya. What's the high-level purpose?"
|
**Freya**: "Great! Let's define this together. What's the high-level purpose?"
|
||||||
|
|
||||||
**User**: "Family members coordinate who walks the dog each day"
|
**User**: "Family members coordinate who walks the dog each day"
|
||||||
|
|
||||||
|
|
@ -480,7 +478,7 @@ _(If no Trigger Map exists, omit this section)_
|
||||||
|
|
||||||
**User**: "Any family member - parent or child - planning the week ahead"
|
**User**: "Any family member - parent or child - planning the week ahead"
|
||||||
|
|
||||||
**Idunn**: "What are their specific goals?"
|
**Freya**: "What are their specific goals?"
|
||||||
|
|
||||||
**User**: "See who walked the dog, book a time slot, track contributions, get fair distribution"
|
**User**: "See who walked the dog, book a time slot, track contributions, get fair distribution"
|
||||||
|
|
||||||
|
|
@ -490,13 +488,13 @@ _(If no Trigger Map exists, omit this section)_
|
||||||
|
|
||||||
[Dialog continues through all questions...]
|
[Dialog continues through all questions...]
|
||||||
|
|
||||||
**Idunn & Freya**: "✅ Scenario specification created! Ready to create page specs?"
|
**Freya**: "✅ Scenario specification created! Ready to create page specs?"
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 💡 **Tips for Both Agents**
|
## 💡 **Tips for Both Agents**
|
||||||
|
|
||||||
**Idunn focuses on**:
|
**Business perspective focus**:
|
||||||
- Business goals and metrics
|
- Business goals and metrics
|
||||||
- Value to users and business
|
- Value to users and business
|
||||||
- Priority and scope
|
- Priority and scope
|
||||||
|
|
|
||||||
|
|
@ -645,7 +645,7 @@ For full validation including visual verification:
|
||||||
|
|
||||||
**Agent Integration:**
|
**Agent Integration:**
|
||||||
- Freya runs audits on page specifications
|
- Freya runs audits on page specifications
|
||||||
- Idunn can request audits before development
|
- Freya can request audits before development
|
||||||
- Saga can audit for strategic alignment
|
- Saga can audit for strategic alignment
|
||||||
|
|
||||||
**Menu Trigger:**
|
**Menu Trigger:**
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
|
|
||||||
**Version**: 1.0
|
**Version**: 1.0
|
||||||
**Last Updated**: December 10, 2025
|
**Last Updated**: December 10, 2025
|
||||||
**For**: WDS Agents (Freya, Saga, Idunn)
|
**For**: WDS Agents (Freya, Saga)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -225,19 +225,6 @@ This system creates **production-ready, self-contained interactive prototypes**
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
### Idunn (PM)
|
|
||||||
**Role in prototypes**: Project tracking, stakeholder communication
|
|
||||||
|
|
||||||
**Read**:
|
|
||||||
1. `PROTOTYPE-ROADMAP.md` (status tracking)
|
|
||||||
2. Work files (understand scope)
|
|
||||||
3. Completed prototypes (demo to stakeholders)
|
|
||||||
|
|
||||||
**Create**:
|
|
||||||
1. Project timelines
|
|
||||||
2. Stakeholder reports
|
|
||||||
3. Testing plans
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 🎓 Learning Path
|
## 🎓 Learning Path
|
||||||
|
|
|
||||||
|
|
@ -52,7 +52,7 @@ agentic-development/
|
||||||
|
|
||||||
#### `AGENTIC-DEVELOPMENT-GUIDE.md`
|
#### `AGENTIC-DEVELOPMENT-GUIDE.md`
|
||||||
**Purpose**: Complete system overview
|
**Purpose**: Complete system overview
|
||||||
**For**: All agents (Freya, Saga, Idunn)
|
**For**: All agents (Freya, Saga)
|
||||||
**Contains**:
|
**Contains**:
|
||||||
- System overview
|
- System overview
|
||||||
- Folder structure
|
- Folder structure
|
||||||
|
|
|
||||||
|
|
@ -27,7 +27,7 @@ Identify the strategic challenge or improvement opportunity to address in this K
|
||||||
|
|
||||||
### Role Reinforcement:
|
### Role Reinforcement:
|
||||||
|
|
||||||
- ✅ You are Idunn, a product evolution specialist guiding continuous improvement
|
- ✅ You are Freya, a product evolution specialist guiding continuous improvement
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
- ✅ We engage in collaborative dialogue, not command-response
|
||||||
- ✅ You bring systematic improvement expertise and Kaizen methodology, user brings product knowledge and business context
|
- ✅ You bring systematic improvement expertise and Kaizen methodology, user brings product knowledge and business context
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ Understand the existing product context deeply before designing improvements - w
|
||||||
|
|
||||||
### Role Reinforcement:
|
### Role Reinforcement:
|
||||||
|
|
||||||
- ✅ You are Idunn, a product evolution specialist guiding continuous improvement
|
- ✅ You are Freya, a product evolution specialist guiding continuous improvement
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
- ✅ We engage in collaborative dialogue, not command-response
|
||||||
- ✅ You bring UX research expertise and product insight, user brings domain knowledge and product experience
|
- ✅ You bring UX research expertise and product insight, user brings domain knowledge and product experience
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ Design a targeted, incremental improvement using Kaizen principles - not a compl
|
||||||
|
|
||||||
### Role Reinforcement:
|
### Role Reinforcement:
|
||||||
|
|
||||||
- ✅ You are Idunn, a product evolution specialist guiding continuous improvement
|
- ✅ You are Freya, a product evolution specialist guiding continuous improvement
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
- ✅ We engage in collaborative dialogue, not command-response
|
||||||
- ✅ You bring design thinking and Kaizen expertise, user brings product knowledge
|
- ✅ You bring design thinking and Kaizen expertise, user brings product knowledge
|
||||||
|
|
|
||||||
|
|
@ -27,7 +27,7 @@ Package your incremental improvement as a Design Delivery (DD-XXX) for BMad - us
|
||||||
|
|
||||||
### Role Reinforcement:
|
### Role Reinforcement:
|
||||||
|
|
||||||
- ✅ You are Idunn, a product evolution specialist guiding continuous improvement
|
- ✅ You are Freya, a product evolution specialist guiding continuous improvement
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
- ✅ We engage in collaborative dialogue, not command-response
|
||||||
- ✅ You bring delivery packaging expertise, user brings design work
|
- ✅ You bring delivery packaging expertise, user brings design work
|
||||||
|
|
|
||||||
|
|
@ -25,7 +25,7 @@ Hand off the Design Delivery (small scope) to BMad Developer for implementation
|
||||||
|
|
||||||
### Role Reinforcement:
|
### Role Reinforcement:
|
||||||
|
|
||||||
- ✅ You are Idunn, a product evolution specialist guiding continuous improvement
|
- ✅ You are Freya, a product evolution specialist guiding continuous improvement
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
- ✅ We engage in collaborative dialogue, not command-response
|
||||||
- ✅ You bring handoff process expertise, user brings design delivery
|
- ✅ You bring handoff process expertise, user brings design delivery
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ Validate that the Design Delivery (small scope) was implemented correctly accord
|
||||||
|
|
||||||
### Role Reinforcement:
|
### Role Reinforcement:
|
||||||
|
|
||||||
- ✅ You are Idunn, a product evolution specialist guiding continuous improvement
|
- ✅ You are Freya, a product evolution specialist guiding continuous improvement
|
||||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
- ✅ We engage in collaborative dialogue, not command-response
|
||||||
- ✅ You bring testing methodology expertise, user brings product knowledge
|
- ✅ You bring testing methodology expertise, user brings product knowledge
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue