ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

Sync learn section with v0.3.0: remove Idunn, Agent Dialog, _wds/ references 

- Remove all Idunn references (54 occurrences) — only Saga + Freya remain
- Replace Agent Dialog with Design Log (64 occurrences)
- Update _wds/ paths to _bmad/wds/ in installation module
- Update F-Agent-Dialogs folder refs to _progress/agent-experiences

24 files updated across modules 01, 02, 05, 07, 14, 15, 16, 18.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Mårten Angner 2026-03-01 14:50:30 +01:00
parent ff4d370442
commit 6729d32630
24 changed files with 133 additions and 140 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
docs/learn/00-course-overview/00-course-overview.md
View File

@ -105,20 +105,20 @@ Each module contains:
| 12 | [Functional Components](../module-12-functional-components/module-12-functional-components-overview.md) | Freya | UX | 45 min |
| 13 | [Design System](../module-13-design-system/module-13-design-system-overview.md) | Freya | Systems | 30 min |
### Build & Deliver Phase (Modules 14-16) — Agents: Freya + Idunn
### Build & Deliver Phase (Modules 14-16) — Agent: Freya
| Module | Title | Agent | Focus | Time |
|--------|-------|-------|-------|------|
| 14 | [Agentic Development](../module-14-agentic-development/module-14-agentic-development-overview.md) | Idunn | 7-activity menu | 60 min |
| 14 | [Agentic Development](../module-14-agentic-development/module-14-agentic-development-overview.md) | Freya | 7-activity menu | 60 min |
| 15 | [Visual Design & Assets](../module-15-visual-design/module-15-visual-design-overview.md) | Freya | Asset pipeline | 60 min |
| 16 | [Design Delivery](../module-16-design-delivery/module-16-design-delivery-overview.md) | Freya | Handover | 45 min |
### Validate & Evolve (Modules 17-18) — Agents: Freya + Idunn
### Validate & Evolve (Modules 17-18) — Agent: Freya
| Module | Title | Agent | Time |
|--------|-------|-------|------|
| 17 | [Usability Testing](../module-17-usability-testing/module-17-usability-testing-overview.md) | Freya | 45 min |
| 18 | [Product Evolution](../module-18-product-evolution/module-18-product-evolution-overview.md) | Idunn | 30 min |
| 18 | [Product Evolution](../module-18-product-evolution/module-18-product-evolution-overview.md) | Freya | 30 min |
---
@ -138,19 +138,18 @@ Each module contains:
---
## The Three Agents
## The Two Agents
WDS uses three AI agents, each with a specific domain:
WDS uses two AI agents, each with a specific domain:
| Agent | Domain | Phase | Modules |
|-------|--------|-------|---------|
| **Saga** | Strategy | Strategy | 3-6 |
| **Freya** | UX, Visual Design & Assets | Design & Deliver | 7-13, 15-17 |
| **Idunn** | Development & Evolution | Build & Evolve | 14, 18 |
| **Freya** | UX, Visual Design, Development & Evolution | Design, Build & Evolve | 7-18 |
Each agent maintains focus on their domain while coordinating with the others.
Each agent maintains focus on their domain while coordinating with the other.
**Idunn's 7 activities** (Module 14): Prototyping, Development, Bugfixing, Evolution, Analysis, Reverse Engineering, and Acceptance Testing — all menu-driven from a single entry point.
**Freya's 7 activities** (Module 14): Prototyping, Development, Bugfixing, Evolution, Analysis, Reverse Engineering, and Acceptance Testing — all menu-driven from a single entry point.
---

2
docs/learn/module-01-why-wds-matters/lesson-02-designer-as-strategic-thinker.md
View File

@ -408,7 +408,7 @@ Amateur designers make AI code faster.
**The methodology empowers you:**
- Saga helps you think strategically about business and users
- Freya helps you forge complete UX specifications
- Idunn helps you generate implementations
- Freya helps you generate implementations
**The guard rails keep you strategic:**
- Every decision traces to business goals

14
docs/learn/module-02-installation-setup/lesson-04-wds-initialization.md
View File

@ -36,7 +36,7 @@ The installer will guide you through:
- **Experience level** — Beginner, Intermediate, or Expert
- **IDE configuration** — Sets up your AI IDE automatically
**✅ Checkpoint:** Installer completes, `_wds/` folder appears in your project
**✅ Checkpoint:** Installer completes, `_bmad/wds/` folder appears in your project
---
@ -46,11 +46,10 @@ After installation, your project has:
```
your-project/
├── _wds/ ← WDS system files
├── _bmad/wds/ ← WDS system files
│ ├── agents/ ← Agent files (.md)
│ │ ├── saga-analyst.md
│ │ ├── freya-ux.md
│ │ └── idunn-pm.md
│ ├── workflows/ ← Phase workflows
│ ├── data/ ← Standards, frameworks
│ ├── gems/ ← Reusable prompt components
@ -63,11 +62,11 @@ your-project/
│ ├── C-UX-Scenarios/
│ ├── D-Design-System/
│ ├── E-PRD/
│ └── F-Agent-Dialogs/
│ └── _progress/
└── .claude/instructions.md ← IDE configuration
```
**Key insight:** `_wds/` contains the methodology. `docs/` is where your design work lives.
**Key insight:** `_bmad/wds/` contains the methodology. `docs/` is where your design work lives.
---
@ -79,7 +78,6 @@ WDS has three specialized agents:
|-------|-------------|-------------|
| **Saga** | Business & Product Analyst | Product Brief, Trigger Mapping |
| **Freya** | UX/UI Designer | Scenarios, UX Design, Visual Design |
| **Idunn** | Project Manager | Platform Requirements, Design System |
### Start with Saga
@ -88,7 +86,7 @@ For a new project, start with Saga to create your Product Brief:
Tell your AI IDE:
```
Read and activate the agent in _wds/agents/saga-analyst.md
Read and activate the agent in _bmad/wds/agents/saga-analyst.md
```
Saga will:
@ -104,7 +102,7 @@ Saga will:
**Issue:** `npx` command not found → Install Node.js from <https://nodejs.org>
**Issue:** Installer fails → Make sure you're in your project folder
**Issue:** Agent file not found → Check `_wds/agents/` folder exists
**Issue:** Agent file not found → Check `_bmad/wds/agents/` folder exists
---

4
docs/learn/module-02-installation-setup/tutorial-02.md
View File

@ -132,11 +132,11 @@ npx whiteport-design-studio install
```
- [ ] Follow the installer prompts (project type, experience level, IDE)
- [ ] ✅ `_wds/` folder appears in your project
- [ ] ✅ `_bmad/wds/` folder appears in your project
### Activate an Agent
- [ ] Tell your AI IDE: `Read and activate the agent in _wds/agents/saga-analyst.md`
- [ ] Tell your AI IDE: `Read and activate the agent in _bmad/wds/agents/saga-analyst.md`
- [ ] ✅ Saga responds and welcomes you!
---

4
docs/learn/module-05-platform-requirements/lesson-01-why-boundaries-matter.md
View File

@ -180,9 +180,9 @@ This document travels with your Product Brief because it's strategic context —
Here's a powerful pattern:
Once you document platform requirements, you can **send them to Idunn immediately**.
Once you document platform requirements, you can **hand them off to development immediately**.
While you move into UX design (Freya), Idunn can:
While you move into UX design, Freya can also handle development tasks in parallel:
- Research knowledge gaps
- Spike complex integrations

10
docs/learn/module-05-platform-requirements/lesson-02-defining-platform-requirements.md
View File

@ -309,9 +309,9 @@ Needs Team Decision:
### Why this matters:
**Knowledge gaps become tasks for Idunn.**
**Knowledge gaps become development tasks.**
While you design with Freya, Idunn can:
While you focus on design, the development agent can:
- Research the unknowns
- Spike the complex integrations
- Test the assumptions
@ -383,11 +383,11 @@ Just like the Product Brief, this document gets referenced throughout the projec
Once this document exists:
1. **Send to Idunn** — Technical investigation begins
1. **Hand off to development** — Technical investigation begins
2. **Reference in design** — Every decision respects these boundaries
3. **Update as you learn** — New discoveries get documented
**This is a living document.** As Idunn investigates knowledge gaps, the document gets updated. As the project evolves, constraints may change. Keep it current.
**This is a living document.** As knowledge gaps get investigated, the document gets updated. As the project evolves, constraints may change. Keep it current.
---
@ -396,7 +396,7 @@ Once this document exists:
- The five sections of platform requirements
- How to document each section effectively
- Why constraints inform rather than limit design
- How knowledge gaps become parallel work for Idunn
- How knowledge gaps become parallel development work
- Where the document lives and how it's used
---

8
docs/learn/module-05-platform-requirements/module-05-platform-requirements-overview.md
View File

@ -81,7 +81,7 @@ What do we **not** know yet?
- No team expertise?
- Needs a spike or proof-of-concept?
**Surface these gaps explicitly.** They become tasks for Idunn to investigate in parallel.
**Surface these gaps explicitly.** They become development tasks to investigate in parallel.
---
@ -106,11 +106,11 @@ This document lives with your Product Brief because it's part of the strategic f
---
## Handoff to Idunn
## Handoff to Development
Once platform requirements are documented, you can **send them to Idunn** immediately.
Once platform requirements are documented, you can **hand them off to development** immediately.
While you continue with UX design (Freya), Idunn can:
While you continue with UX design, Freya can also handle development tasks:
- Research knowledge gaps
- Spike complex integrations

16
docs/learn/module-05-platform-requirements/tutorial-05.md
View File

@ -28,7 +28,7 @@ This tutorial walks you through creating a platform requirements document that c
- Ask the right questions
- Identify gaps you might miss
- Document clearly and consistently
- Prepare handoff to Idunn
- Prepare handoff to development
---
@ -168,7 +168,7 @@ This gives Saga the context to ask relevant questions.
### Saga summarizes:
> "So we have medium complexity on push notifications and offline sync, with lower complexity on core features. I'll flag the iOS push notification limitations as something Idunn should research."
> "So we have medium complexity on push notifications and offline sync, with lower complexity on core features. I'll flag the iOS push notification limitations as something that needs research."
---
@ -237,15 +237,15 @@ If anything is missing or wrong, tell Saga:
---
## Step 9: Handoff to Idunn (Optional)
## Step 9: Handoff to Development (Optional)
### If you want parallel development:
> "Please prepare a handoff for Idunn with the knowledge gaps that need investigation."
> "Please prepare a handoff for development with the knowledge gaps that need investigation."
### Saga creates handoff:
> "Handoff prepared for Idunn:
> "Handoff prepared for development:
>
> **Research Tasks:**
> - iOS 17+ PWA push notification behavior
@ -257,7 +257,7 @@ If anything is missing or wrong, tell Saga:
> **Pending Decisions:**
> - React Native vs PWA long-term strategy
>
> Idunn can start investigating while you continue to UX design with Freya."
> Development can start while you continue to UX design with Freya."
---
@ -305,7 +305,7 @@ If anything is missing or wrong, tell Saga:
### Immediate:
- Platform requirements inform all design decisions
- Knowledge gaps become Idunn's research tasks
- Knowledge gaps become development research tasks
- You have a clear picture of what's possible
### Next Phase:
@ -337,7 +337,7 @@ If anything is missing or wrong, tell Saga:
## Common Questions
**Q: What if I don't know the technical details?**
A: That's what knowledge gaps are for. Document what you don't know and let Idunn investigate.
A: That's what knowledge gaps are for. Document what you don't know and let the development agent investigate.
**Q: Should I talk to developers before creating this?**
A: Helpful but not required. Saga will ask questions that surface what you know. Mark unknowns as knowledge gaps.

2
docs/learn/module-07-design-phase/lesson-01-entering-design.md
View File

@ -192,7 +192,7 @@ By the end of this phase:
| **Component definitions** | Reusable patterns identified |
| **Visual designs** | Final look and feel |
| **Design system** | Your component library |
| **Delivery package** | Ready for Idunn to implement |
| **Delivery package** | Ready for implementation |
---

2
docs/learn/module-07-design-phase/lesson-02-why-specifications-matter.md
View File

@ -550,7 +550,7 @@ Spec phase: Define exactly what you want (upfront investment)
Specifications: Document every detail (with Freya)
Code phase: Agent builds it correctly (first time)
Idunn reads specs
Freya reads specs
Generates code matching specifications exactly
Includes tests from specs

7
docs/learn/module-07-design-phase/lesson-03-meet-freya.md
View File

@ -146,18 +146,17 @@ Finally, Freya helps apply visual language to your specifications and packages e
**Don't start with Freya when:**
- You haven't completed the strategic foundation yet (go back to Saga)
- You want to write code (that's Idunn's domain)
- You want to write code (that's handled in a development session)
- You're still figuring out business goals or target groups
### The Three Agents — Quick Reference
### The Two Agents — Quick Reference
| Agent | Domain | When to Use |
|-------|--------|------------|
| **Saga** | Strategy | Product Brief, Trigger Mapping, Platform Requirements |
| **Freya** | Design | Scenarios, Sketching, Specifications, Components, Visual Design |
| **Idunn** | Implementation | Prototyping, Development, Verification |
Saga hands off to Freya. Freya hands off to Idunn. But the handoff isn't one-way — you'll often loop back to earlier stages as you learn from design and implementation.
Saga hands off to Freya. Freya handles both design and development. But the workflow isn't one-way — you'll often loop back to earlier stages as you learn from design and implementation.
---

26
docs/learn/module-14-agentic-development/lesson-01-iterative-building.md
View File

@ -1,6 +1,6 @@
# Module 14: Agentic Development
## Lesson 1: The Development Agent Dialog
## Lesson 1: The Development Design Log
**How the process is organized**
@ -8,7 +8,7 @@
## Every Session Starts with a Plan
When you ask Freya or Idunn to develop something, the first thing the agent does is create an **Agent Dialog**.
When you ask Freya to develop something, the first thing the agent does is create a **Design Log**.
This isn't documentation after the fact. It's the plan *before* anything is built.
@ -23,15 +23,15 @@ Then the agent starts executing. One step at a time.
---
## The Agent Dialog Document
## The Design Log Document
```markdown
# Agent Dialog: Signup Form
# Design Log: Signup Form
## Meta
- Date: 2026-02-10
- Input: P02-signup-form.md (specification)
- Agent: Idunn
- Agent: Freya
- Status: In Progress
## Scope
@ -128,15 +128,15 @@ The plan is not a contract. It's a compass.
## Types of Agentic Sessions
The same Agent Dialog structure works for all types:
The same Design Log structure works for all types:
| Type | Example | Agent |
|------|---------|-------|
| **Concept exploration** | "Dream up a dashboard layout for dog trainers" | Freya |
| **Proof of concept** | "Can we do infinite scroll with this data model?" | Idunn |
| **Prototype** | "Build a working signup form from this spec" | Idunn |
| **Proof of concept** | "Can we do infinite scroll with this data model?" | Freya |
| **Prototype** | "Build a working signup form from this spec" | Freya |
| **Design inspiration** | "Generate 3 visual directions for the landing page" | Freya |
| **Production code** | "Implement the complete registration scenario" | Idunn |
| **Production code** | "Implement the complete registration scenario" | Freya |
The scope and depth change. The process doesn't.
@ -146,11 +146,11 @@ The scope and depth change. The process doesn't.
### Starting a new session
Load the Agent Dialog into your new conversation:
Load the Design Log into your new conversation:
```
"I'm continuing the signup form implementation.
Here's the current Agent Dialog with plan and log:
Here's the current Design Log with plan and log:
[Paste dialog.md content]
@ -161,9 +161,9 @@ The agent picks up from the log, not from memory.
### Handing off between agents
Freya dreamed up a component. Now Idunn needs to build it.
You dreamed up a component in a design session. Now you need to build it.
The Agent Dialog travels with the work. Idunn reads Freya's dialog and continues where she left off.
The Design Log travels with the work. The agent reads the previous design log and continues where it left off.
---

2
docs/learn/module-14-agentic-development/lesson-02-documenting-decisions.md
View File

@ -101,7 +101,7 @@ Not everything is in the spec. Use your design judgment:
## Re-evaluating the Plan
After evaluation, open the Agent Dialog and update the task list.
After evaluation, open the Design Log and update the task list.
**Before step 3:**
```markdown

6
docs/learn/module-14-agentic-development/lesson-03-when-you-get-stuck.md
View File

@ -118,9 +118,9 @@ This is the hardest moment for a designer working with AI: admitting the agent c
### How to Ask
Don't come empty-handed. Bring your Agent Dialog:
Don't come empty-handed. Bring your Design Log:
> "I've been building the signup form. Here's my Agent Dialog with everything we tried.
> "I've been building the signup form. Here's my Design Log with everything we tried.
>
> The issue: error messages work on desktop but disappear on mobile. The agent tried 4 different approaches (logged in the dialog). None worked.
>
@ -130,7 +130,7 @@ The dialog shows what you've tried. The developer doesn't start from zero.
### What to Document
When a developer fixes the issue, add it to your Agent Dialog:
When a developer fixes the issue, add it to your Design Log:
```markdown
### Step 4: Error states on mobile (resolved with developer help)

4
docs/learn/module-14-agentic-development/lesson-04-working-with-code.md
View File

@ -108,7 +108,7 @@ Your design tokens (Module 13) define the rules. The component library implement
| Spacing: 8px scale | `spacing: { 1: '8px', 2: '16px', ... }` |
| Button: primary variant | `<Button variant="primary">` uses all the above |
When the agent builds, it should use your component library and respect your design tokens. Include your design system in the Agent Dialog requirements:
When the agent builds, it should use your component library and respect your design tokens. Include your design system in the Design Log requirements:
> "Use our design system tokens. Primary #0066FF, Inter font, 8px spacing scale. Use shadcn/ui components where applicable."
@ -278,7 +278,7 @@ Many projects use both categories: static HTML for exploration, framework code f
- Ask the agent: "Build this as a component in our [framework] project using our design system"
- Make sure your development environment is running before you start
- Deploy to a preview URL (Vercel, Netlify) when you need to share
- Keep the Agent Dialog updated with the branch and commit information
- Keep the Design Log updated with the branch and commit information
### When to ask a developer

20
docs/learn/module-14-agentic-development/lesson-05-git-discipline.md
View File

@ -48,7 +48,7 @@ This isn't optional. It's how teams avoid overwriting each other's work.
## Let the Agent Handle Git
You don't have to type Git commands yourself. The agent can create branches, make commits, and even create pull requests as part of the Agent Dialog flow.
You don't have to type Git commands yourself. The agent can create branches, make commits, and even create pull requests as part of the Design Log flow.
**Tell the agent at the start:**
@ -106,7 +106,7 @@ You've created a new branch and switched to it. All your work happens here.
### Step 4: Work and save as you go
After each completed step in your Agent Dialog, commit:
After each completed step in your Design Log, commit:
```
git add .
@ -140,11 +140,11 @@ Your branch now exists online. Others can see it. After the first push, just typ
### Step 6: Create a pull request
When you're done and the Agent Dialog shows all tests passing:
When you're done and the Design Log shows all tests passing:
**Using the command line:**
```
gh pr create --title "Add signup form prototype" --body "Built from spec P02. See Agent Dialog for details."
gh pr create --title "Add signup form prototype" --body "Built from spec P02. See Design Log for details."
```
**Using GitHub:** Go to your repository, click "Pull requests", click "New pull request", select your branch.
@ -152,7 +152,7 @@ gh pr create --title "Add signup form prototype" --body "Built from spec P02. Se
**What goes in the PR:**
- What you built (reference the spec)
- What to look for in review
- Link to the Agent Dialog
- Link to the Design Log
- Any known limitations
### Step 7: Merge and clean up
@ -225,7 +225,7 @@ Their version
3. Delete the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
4. Save, stage, and commit
**When to ask for help:** If the conflict is in code you don't understand, ask a developer. Show them the Agent Dialog so they have context.
**When to ask for help:** If the conflict is in code you don't understand, ask a developer. Show them the Design Log so they have context.
### Code reviews
@ -239,15 +239,15 @@ Don't take change requests personally. Reviews improve code quality and catch is
---
## Connecting Git to the Agent Dialog
## Connecting Git to the Design Log
Your Agent Dialog meta section should include the branch:
Your Design Log meta section should include the branch:
```markdown
## Meta
- Date: 2026-02-10
- Input: P02-signup-form.md
- Agent: Idunn
- Agent: Freya
- Branch: feature/signup-form-prototype
- Status: In Progress
```
@ -336,7 +336,7 @@ Removes the last commit but keeps all the changes in your files.
## What's Next
In the tutorial, you'll run through a complete agentic development session — from creating the Agent Dialog through evaluation, feedback, and handling a stuck moment.
In the tutorial, you'll run through a complete agentic development session — from creating the Design Log through evaluation, feedback, and handling a stuck moment.
---

32
docs/learn/module-14-agentic-development/module-14-agentic-development-overview.md
View File

@ -1,6 +1,6 @@
# Module 14: Agentic Development
**Time: 60 min | Agents: Freya + Idunn | Phase: Design-Build**
**Time: 60 min | Agent: Freya | Phase: Design-Build**
---
@ -42,9 +42,9 @@ Each activity has its own workflow with dedicated steps. The core agentic loop (
---
## The Agent Dialog
## The Design Log
Every agentic development session starts with an **Agent Dialog** — a structured document that organizes the work.
Every agentic development session starts with a **Design Log** — a structured document that organizes the work.
Before writing a single line of code, the agent creates:
@ -61,7 +61,7 @@ This is your plan. It evolves as you work.
```
┌──────────────┐
│ Create plan │ ← Agent Dialog: scope, tasks, requirements, tests
│ Create plan │ ← Design Log: scope, tasks, requirements, tests
└──────┬───────┘
│
▼
@ -144,31 +144,29 @@ Every step is logged. Every action is noted. Every decision is recorded.
This means you can **restart the conversation at any time**. New session? Load the dialog. The agent picks up where you left off.
```
docs/F-Agent-Dialogs/
└── 2026-02-10-signup-form/
├── dialog.md ← Plan, steps, status
├── decisions.md ← What was decided and why
└── changes.md ← What changed from spec
docs/_progress/
├── 00-design-log.md ← Plan, status, backlog
└── agent-experiences/
└── 2026-02-10-signup-form.md ← Session insights
```
---
## Who Does What?
Both Freya and Idunn can do agentic development:
Freya handles all agentic development activities:
| Agent | Activities | When to use |
|-------|-----------|-------------|
| **Freya** | [P] Prototyping, [A] Analysis | Design exploration — dream up visuals, components, page layouts. Investigate and understand existing products. |
| **Idunn** | [D] Development, [F] Bugfixing, [E] Evolution, [R] Reverse Engineering, [T] Acceptance Testing | Implementation — generate working code from specifications. Fix bugs, add features, test against specs. |
| **Freya** | All 7 activities: [P] Prototyping, [D] Development, [F] Bugfixing, [E] Evolution, [A] Analysis, [R] Reverse Engineering, [T] Acceptance Testing | Design exploration, implementation, bugfixing, evolution, analysis, reverse engineering, and acceptance testing. |
The process is the same. The domain differs.
The process is the same across all activities. The scope and context differ.
---
## What You'll Learn
### Lesson 1: The Development Agent Dialog
### Lesson 1: The Development Design Log
How the process is organized. Creating plans, logging steps, structuring sessions so you can restart at any time.
@ -194,7 +192,7 @@ Keeping your work safe with version control. When to branch, how to commit, work
| Mistake | Fix |
|---------|-----|
| Jumping in without a plan | Start with Agent Dialog every time |
| Jumping in without a plan | Start with Design Log every time |
| Not logging steps | Everything gets logged, no exceptions |
| Keeping a stale plan | Re-evaluate after every step |
| Fighting the AI for too long | Know when to ask for help |
@ -206,7 +204,7 @@ Keeping your work safe with version control. When to branch, how to commit, work
Pick one specification and run the full loop:
1. Create an Agent Dialog with scope, tasks, and test protocol
1. Create a Design Log with scope, tasks, and test protocol
2. Execute one step
3. Evaluate the result
4. Update the plan
@ -216,7 +214,7 @@ Pick one specification and run the full loop:
## Lessons
### [Lesson 1: The Development Agent Dialog](lesson-01-iterative-building.md)
### [Lesson 1: The Development Design Log](lesson-01-iterative-building.md)
How the process is organized
### [Lesson 2: Evaluation and Feedback](lesson-02-documenting-decisions.md)

33
docs/learn/module-14-agentic-development/tutorial-14.md
View File

@ -6,12 +6,12 @@
## Overview
This tutorial walks you through a complete agentic development session — creating an Agent Dialog, building from specification, evaluating results, and handling a stuck moment.
This tutorial walks you through a complete agentic development session — creating a Design Log, building from specification, evaluating results, and handling a stuck moment.
**Time:** 45-60 minutes
**Prerequisites:** Design system completed (Module 13)
**Agent:** Idunn (or Freya for design exploration)
**What you'll create:** Working prototype with documented Agent Dialog
**Agent:** Freya
**What you'll create:** Working prototype with documented Design Log
---
@ -25,29 +25,29 @@ This tutorial walks you through a complete agentic development session — creat
**The agent will help you:**
- Create the Agent Dialog
- Create the Design Log
- Build step by step
- Track decisions
- Handle problems
---
## Step 1: Start the Agent Dialog (5 min)
## Step 1: Start the Design Log (5 min)
### Give the agent your specification:
**You say:**
> "I want to build a working prototype of the signup form from spec P02-signup-form.md. Start by creating an Agent Dialog with scope, tasks, requirements, and test protocol."
> "I want to build a working prototype of the signup form from spec P02-signup-form.md. Start by creating a Design Log with scope, tasks, requirements, and test protocol."
### The agent creates the dialog:
```markdown
# Agent Dialog: Signup Form Prototype
# Design Log: Signup Form Prototype
## Meta
- Date: 2026-02-10
- Input: P02-signup-form.md
- Agent: Idunn
- Agent: Freya
- Status: In Progress
## Scope
@ -233,7 +233,7 @@ New task emerged from building. That's normal.
### Verify everything:
Go through the test protocol from the Agent Dialog:
Go through the test protocol from the Design Log:
```markdown
## Test Protocol
@ -262,13 +262,13 @@ Go through the test protocol from the Agent Dialog:
## Step 8: Finalize the Dialog (5 min)
### Complete the Agent Dialog:
### Complete the Design Log:
```markdown
## Meta
- Date: 2026-02-10
- Input: P02-signup-form.md
- Agent: Idunn
- Agent: Freya
- Status: Complete
## Summary
@ -282,9 +282,8 @@ All tests passing.
### Save the dialog:
```
docs/F-Agent-Dialogs/
└── 2026-02-10-signup-form/
└── dialog.md
docs/_progress/agent-experiences/
└── 2026-02-10-signup-form.md
```
---
@ -292,7 +291,7 @@ docs/F-Agent-Dialogs/
## What You've Created
- **Working prototype** matching your specification
- **Complete Agent Dialog** with plan, log, decisions, and test results
- **Complete Design Log** with plan, log, decisions, and test results
- **Reusable context** for future sessions or handoff
---
@ -301,7 +300,7 @@ docs/F-Agent-Dialogs/
**DO:**
- Always start with an Agent Dialog
- Always start with a Design Log
- Evaluate after every step
- Give specific, numbered feedback
- Update the plan as you learn
@ -320,7 +319,7 @@ docs/F-Agent-Dialogs/
## You've Completed Module 14!
**You can now run agentic development sessions.** You know how to:
- Structure work with Agent Dialogs
- Structure work with Design Logs
- Evaluate and give effective feedback
- Handle stuck moments
- Keep plans alive and updated

2
docs/learn/module-15-visual-design/module-15-visual-design-overview.md
View File

@ -137,7 +137,7 @@ There is no wrong approach. Use whatever gives you confidence in the result.
### AI Code Generation
The agent generates HTML/CSS from your specifications. You review the output in your browser and refine through the Agent Dialog process (Module 14).
The agent generates HTML/CSS from your specifications. You review the output in your browser and refine through the Design Log process (Module 14).
### Figma

6
docs/learn/module-16-design-delivery/tutorial-16.md
View File

@ -289,7 +289,7 @@ E-PRD/Design-Deliveries/
### Sign off:
**Freya:**
> "Delivery package DD01-User-Registration is validated and ready for handoff to Idunn.
> "Delivery package DD01-User-Registration is validated and ready for handoff to development.
>
> Summary:
> - 3 pages specified
@ -301,7 +301,7 @@ E-PRD/Design-Deliveries/
---
## Step 6: Handoff to Idunn (2 min)
## Step 6: Handoff to Development (2 min)
### Prepare handoff message:
@ -309,7 +309,7 @@ E-PRD/Design-Deliveries/
```markdown
# Design Handoff: DD01-User-Registration
## For: Idunn (Implementation)
## For: Development
## From: Freya (Design)
## Date: [Today]

12
docs/learn/module-18-product-evolution/lesson-01-continuous-improvement.md
View File

@ -10,7 +10,7 @@
A product evolution change — whether it's a new feature, a modification, a fix, or an optimization — follows the same WDS process you've learned throughout this course. The difference is scope. Instead of building a whole product, you're improving one part of it.
The Product Evolution Agent Dialog organizes this cycle. It's the same Agent Dialog from Module 14, with one addition: **context** — what exists today and why it needs to change.
The Product Evolution Design Log organizes this cycle. It's the same Design Log from Module 14, with one addition: **context** — what exists today and why it needs to change.
---
@ -44,18 +44,18 @@ Connected. Proceed.
---
## Step 2: Start the Agent Dialog
## Step 2: Start the Design Log
Create the dialog with context about what exists and what needs to change:
```markdown
# Agent Dialog: Password Requirements Clarity
# Design Log: Password Requirements Clarity
## Meta
- Date: 2026-03-15
- Type: Feature modification
- Input: User feedback + usability test findings
- Agent: Idunn
- Agent: Freya
- Branch: fix/password-requirements
- Status: In Progress
@ -118,7 +118,7 @@ Make the change in the spec first. The spec is the source of truth.
The agent implements from the updated spec — exactly as in Module 14.
### Tasks in the Agent Dialog:
### Tasks in the Design Log:
```markdown
## Tasks
@ -164,7 +164,7 @@ For a color fix or typo correction — probably no. Functional verification is e
### Create the delivery
For changes that go through development review, create a DD (Module 16). For small changes you implement yourself, document in the Agent Dialog.
For changes that go through development review, create a DD (Module 16). For small changes you implement yourself, document in the Design Log.
### Close the dialog

8
docs/learn/module-18-product-evolution/lesson-02-update-spec-project-code.md
View File

@ -39,7 +39,7 @@ This happens. Code changes sneak in without spec updates. A developer fixes some
When you find drift:
1. **Note it** — Document the discrepancy in the Agent Dialog
1. **Note it** — Document the discrepancy in the Design Log
2. **Decide** — Does reality match the original intent, or has it drifted in a useful direction?
3. **Update the spec** — Make the spec match what should be true, whether that's the current state or the intended change
4. **Then proceed** — Now you're working from an accurate baseline
@ -130,7 +130,7 @@ The updated spec is the acceptance criteria. The agent checks each element again
## The Scope Boundary
The Agent Dialog defines what changes and what doesn't. The spec update makes this concrete.
The Design Log defines what changes and what doesn't. The spec update makes this concrete.
When the agent is working, it has a clear boundary:
@ -140,7 +140,7 @@ When the agent is working, it has a clear boundary:
This is how you prevent a small change from snowballing. The password field helper text changes. The email field doesn't. The form layout doesn't. The submission flow doesn't.
If the agent discovers something out of scope that needs attention — a bug, a related improvement, an inconsistency — it logs it in the Agent Dialog for a future cycle. It doesn't fix it now.
If the agent discovers something out of scope that needs attention — a bug, a related improvement, an inconsistency — it logs it in the Design Log for a future cycle. It doesn't fix it now.
```markdown
## Notes
@ -216,7 +216,7 @@ The cost of updating a spec is minutes. The cost of spec drift is hours — spen
## What's Next
In the tutorial, you'll run a complete evolution cycle — from receiving feedback to closing the Agent Dialog with a verified change.
In the tutorial, you'll run a complete evolution cycle — from receiving feedback to closing the Design Log with a verified change.
---

14
docs/learn/module-18-product-evolution/module-18-product-evolution-overview.md
View File

@ -1,6 +1,6 @@
# Module 18: Product Evolution
**Time: 30 min | Agent: Freya + Idunn | Phase: Continuous**
**Time: 30 min | Agent: Freya | Phase: Continuous**
---
@ -52,7 +52,7 @@ Here is the full WDS process and how each module maps to an evolution cycle:
### Build (How do we implement it?)
**Agentic Development (Module 14)** — Start an Agent Dialog. The agent builds the change from the specification while verifying with Puppeteer.
**Agentic Development (Module 14)** — Start a Design Log. The agent builds the change from the specification while verifying with Puppeteer.
**Visual Design (Module 15)** — Does the change need visual polish? Apply the same design layer process — code first, Figma when needed.
@ -64,20 +64,20 @@ Here is the full WDS process and how each module maps to an evolution cycle:
---
## The Product Evolution Agent Dialog
## The Product Evolution Design Log
The Agent Dialog is the container for every change. In greenfield, it organizes a build session. In brownfield, it organizes an evolution cycle.
The Design Log is the container for every change. In greenfield, it organizes a build session. In brownfield, it organizes an evolution cycle.
The structure is identical:
```markdown
# Agent Dialog: [Change Name]
# Design Log: [Change Name]
## Meta
- Date: 2026-03-15
- Type: Evolution (feature | modification | fix | optimization)
- Input: User feedback / analytics / business request
- Agent: Idunn
- Agent: Freya
- Branch: fix/password-requirements
- Status: In Progress
@ -180,7 +180,7 @@ The brownfield becomes as well-documented as a greenfield project — one change
### Lesson 1: The Evolution Cycle
How to run a complete evolution cycle using the Product Evolution Agent Dialog — from receiving feedback through implementation and delivery. The same WDS steps, compressed for a single change.
How to run a complete evolution cycle using the Product Evolution Design Log — from receiving feedback through implementation and delivery. The same WDS steps, compressed for a single change.
### Lesson 2: Update the Spec — Project the Code

20
docs/learn/module-18-product-evolution/tutorial-18.md
View File

@ -6,12 +6,12 @@
## Overview
This tutorial walks you through a product evolution cycle — from receiving user feedback to closing the Agent Dialog with a verified change.
This tutorial walks you through a product evolution cycle — from receiving user feedback to closing the Design Log with a verified change.
**Time:** 20-30 minutes
**Prerequisites:** Understanding of WDS workflow (Modules 4-17)
**Agent:** Idunn
**What you'll practice:** The complete evolution cycle using the Product Evolution Agent Dialog
**Agent:** Freya
**What you'll practice:** The complete evolution cycle using the Product Evolution Design Log
---
@ -47,21 +47,21 @@ Is this worth showing to 5 users and 1 domain expert? Yes — the problem was fo
---
## Step 2: Create the Evolution Agent Dialog (5 min)
## Step 2: Create the Evolution Design Log (5 min)
**You say:**
> "Create an Agent Dialog for this evolution. Type: feature modification. Context: password field requirements are hidden until error."
> "Create a Design Log for this evolution. Type: feature modification. Context: password field requirements are hidden until error."
**The agent creates:**
```markdown
# Agent Dialog: Password Requirements Clarity
# Design Log: Password Requirements Clarity
## Meta
- Date: 2026-03-15
- Type: Feature modification
- Input: Usability test findings (Round 1)
- Agent: Idunn
- Agent: Freya
- Branch: fix/password-requirements
- Status: In Progress
@ -206,7 +206,7 @@ One guerrilla test isn't statistically significant — but combined with the ori
**The agent commits:**
> "Show password requirements upfront per spec v1.2"
**Close the Agent Dialog:**
**Close the Design Log:**
```markdown
## Meta
@ -249,12 +249,12 @@ Guerrilla test confirmed improvement.
The complete evolution cycle:
1. **Connected** feedback to Trigger Map and business goal
2. **Created** an Evolution Agent Dialog with context
2. **Created** an Evolution Design Log with context
3. **Updated** the specification before touching code
4. **Built** from the updated spec
5. **Verified** with Puppeteer during development
6. **Tested** with a quick guerrilla session
7. **Documented** everything in the Agent Dialog
7. **Documented** everything in the Design Log
Same WDS process. Smaller scope. Full discipline.