Refactor config collection to handle both interactive and static fields. Update logic to process new static fields and merge answers accordingly.
Co-authored-by: Brian <bmadcode@gmail.com>
Change "Story is ready for next work!" to "Code review complete!"
The original phrasing was misleading - when a code review finishes
with status "done", it means the review itself is complete and the
story is marked done in tracking. However, the user may choose to
do additional reviews or the story may genuinely be finished.
"Code review complete" more accurately describes what actually
happened without implying next steps.
- Disable high_level_summary to stop PR description modifications
- Disable commit_status to stop GitHub status checks
- Disable issue_enrichment.auto_enrich to stop auto-commenting on issues
These settings complement the existing review_status: false and
auto_review.enabled: false to ensure CodeRabbit only responds
when explicitly tagged with @coderabbitai review.
Deleted the pre-commit hook script from the Husky configuration. This script previously auto-fixed changed files and ran tests before commits. The removal streamlines the commit process.
Completed the content for Module 02, ensuring all lessons are beginner-friendly and comprehensive:
- Enhanced explanations and examples for each lesson
- Included troubleshooting tips and clear instructions
- Maintained logical flow and accessibility throughout
Updated lesson files to reflect the finalized structure and content, ready for deployment and learner engagement.
Complete YouTube show notes for Module 02 video:
- Optimized title and description for YouTube
- Comprehensive timestamps for 30-minute video
- Key concepts explained simply
- All 4 lessons outlined with timing
- Repository structure decision guidance
- 8-phase docs structure overview
- Common questions answered
- Resources and links
- Community connection
- Mimir introduction
- SEO-optimized tags
- Pinned comments for engagement
Focuses on encouragement and accessibility:
- 'You can do this' messaging
- Celebrates small wins
- Normalizes being a beginner
- Clear time expectations
- No coding required emphasis
Ready for video production!
Complete restructure with logical separation:
Lesson 01: Git Setup (15-20 min)
- GitHub account creation
- Repository creation or joining existing
- Single vs separate repo decision at naming
Lesson 02: IDE Installation (10 min)
- Cursor or VS Code choice and installation
- First launch setup
- Terminal verification
Lesson 03: Git Repository Cloning (10 min)
- Create Projects folder
- Clone your repository
- Open in IDE
- Git auto-installation by IDE
Lesson 04: WDS Project Initialization (15-20 min)
- Clone WDS repository
- Add WDS to workspace
- Create 8-phase docs structure
- Activate Mimir
Each lesson:
- 01-quick-checklist.md (checkbox action list)
- 02-full-lesson.md (detailed explanation)
Also organized course explainers:
- Created course-explainers/ folder at course root
- Moved all NotebookLM and YouTube content there
- Cleaner module folders
Benefits:
- Clear logical separation of concerns
- Mimir integrated with WDS init (natural fit)
- Git cloning separate from WDS setup
- Each lesson focused on single topic
- Dual format for all learning styles
Renamed all lesson files with clear numbered prefixes:
Before:
- checklist.md
- lesson.md
After:
- 01-quick-checklist.md
- 02-full-lesson.md
Benefits:
- Clear ordering in file browser
- Easy to see which is quick vs full
- Professional file naming
- Better for navigation
- Consistent across all 4 lessons
Updated module overview with new filenames.
Each lesson now has two files:
- checklist.md: Quick action list with checkboxes
- lesson.md: Full detailed explanation
Overview updated to show both options per lesson.
Updated all Module 02 lesson titles for better scannability:
Before (verb-first):
- Setting Up GitHub
- Install IDE
- Git Setup
- Clone & Add WDS
- Initiate Mimir
After (value-first):
- GitHub Setup
- IDE Installation
- Git Configuration
- Repository Cloning & WDS Integration
- Mimir Activation
Benefits:
- Immediate understanding of what's covered
- Better scannability in overview
- Professional terminology
- Clear value proposition
- Easier to reference specific lessons
Follows principle: Value word should appear as early as possible
in titles for maximum comprehension speed.
Major restructure for better organization and navigation:
New Structure:
- module-02-overview.md (minimal, just links to lessons)
- lesson-01-github-account/tutorial.md
- lesson-02-create-repository/tutorial.md
- lesson-03-install-ide/tutorial.md
- lesson-04-git-setup/tutorial.md
- lesson-05-clone-and-wds/tutorial.md
- lesson-06-initiate-mimir/tutorial.md
Each Lesson Contains:
- Focused tutorial on one specific task
- Clear time estimate
- Step-by-step instructions
- Troubleshooting section
- Navigation to next lesson
Overview Benefits:
- Minimal and scannable
- Easy to navigate between lessons
- See progress through module
- Jump to specific lesson easily
Lesson Benefits:
- Self-contained tutorials
- Focused on single topic
- Can be referenced individually
- Progressive complexity
- Clear completion criteria
Old tutorial-02.md kept for reference until verified working.
Critical UX improvement: Decision happens at the RIGHT moment.
Changes to Step 2.2 (Repository Settings):
- ADDED: Comprehensive 'Single vs Separate Repo' decision framework
- Decision now happens DURING naming (not after)
- Clear naming convention: 'my-project' vs 'my-project-specs'
Single Repository Use Cases:
✅ Close to development team
✅ Simple, direct communication needed
✅ Building the project yourself
✅ Working closely with other designers
✅ Small team with full ownership
✅ Rapid iteration and feedback
Separate Repository Use Cases:
✅ Corporate or enterprise environment
✅ Specifications serve multiple products/platforms
✅ Development team has many developers
✅ Extensive or complex codebase
✅ Clear handoff boundaries needed
✅ Design and dev have separate workflows
Changes to Step 2.3:
- Acknowledge decision was made
- Remind about implications
Changes to Step 4.1:
- SIMPLIFIED: Just recap the decision made in Step 2
- No longer presenting options (already decided!)
- Cleaner flow
Reasoning:
Repository NAME determines structure. The decision must happen when
naming the repository, not later. This is when GitHub asks 'what do
you want to call this?' - that's the natural decision point.
Benefits:
- Decision at natural moment (when naming)
- Clear naming conventions prevent confusion
- Users understand implications before creating
- No 'oops, I named it wrong' moments
- Professional guidance on when to use each approach
Reorganization for better logical flow:
Changes:
- MOVED: 'One Repo or Two?' decision from Step 2.4 to Step 4.1
- Placed BEFORE Git installation discussion
- Added note in Step 2 pointing forward to Step 4
Reasoning:
- Repository structure decision affects how you'll set up Git workflow
- Makes more sense alongside Git/GitHub Desktop discussion
- GitHub Desktop can help visualize the single vs separate decision
- Users make informed choice before cloning
- Better pedagogical flow: Create repo → Understand structure → Clone it
Benefits:
- Decision happens at the right moment (before cloning)
- Connected to tooling discussion (Git/GitHub Desktop)
- Eliminates duplicate content
- Clearer mental model for beginners
Major UX improvement for complete beginners:
Tutorial Changes (Step 4):
- REMOVED: Manual Git installation steps with command line
- ADDED: Explanation that IDE handles Git automatically
- ADDED: GitHub Desktop as visual alternative for non-technical users
- NEW APPROACH: Let Cursor prompt for Git installation when needed
Key improvements:
- Beginners don't need to manually install Git
- Cursor/VS Code will automatically prompt when cloning
- Optional GitHub Desktop path for visual learners
- Reduces friction and confusion for designers
- Eliminates 'why am I doing this?' questions
Overview Changes:
- Updated lesson descriptions to match tutorial flow
- Clarified Git is handled automatically
- Updated completion checklist
- Improved tutorial description
Reasoning:
Complete beginners don't need to understand Git installation.
Modern IDEs handle this transparently. Let the tools do the work.
Designers can focus on design, not developer tooling.
Complete rewrite of Installation & Setup module targeting designers with
zero technical experience:
Overview Changes:
- Expanded from 30min to 45-60min to accommodate beginners
- Added GitHub account creation as first step
- Added repository setup and naming guidance
- Added IDE installation (Cursor vs VS Code comparison)
- Reduced prerequisites to absolute minimum (just computer + internet)
- New lesson structure: GitHub → Repository → IDE → Clone → WDS → Mimir
Tutorial Changes (8 detailed steps):
1. Create GitHub Account - Username tips, verification
2. Create Project Repository - Naming, public/private, one vs two repos
3. Install IDE - Cursor vs VS Code, first launch setup
4. Install Git - Check, install, configure
5. Clone Repository - URL, location, terminal commands
6. Add WDS to Workspace - Inside vs beside decision
7. Create Docs Structure - 8-phase folders with platform-specific commands
8. Initiate with Mimir - Drag file, first interaction
New Features:
- Screenshot-worthy step-by-step instructions
- Platform-specific commands (Windows/Mac/Linux)
- Troubleshooting section for common beginner issues
- Visual file structure diagrams
- Pro tips for ongoing use
- Quick reference for 'what lives where'
- Encouragement and celebration at each checkpoint
Target: Designer who has never used GitHub, Git, or an IDE before.
- Add training course section to orchestrator with module overview
- Update presentation to suggest training for new users
- Expand Patient Trainer role to include course guidance
- Provide @wds-mimir training invocation example
Users can now be guided through comprehensive WDS training with:
@wds-mimir Take me through the WDS training
- Add mimir-presentation.md introducing the WDS guide/coach/trainer persona
- Create MIMIR-WDS-ORCHESTRATOR.md with complete orchestration logic
- Include initialization sequence: presentation → assessment → environment check → routing
- Add adaptive teaching based on skill levels (beginner to experienced)
- Integrate with existing project-analysis-router.md workflow
- Add @wds-mimir chat invocation instructions
- Fix workflow folder names in MANUAL-INIT-GUIDE.md
Mimir serves as the welcoming entry point, assessing user needs and routing to
specialist agents (Freyja, Idunn, Saga) when appropriate.
- Created DRAG-ME-TO-AI-CHAT-TO-GET-STARTED.md for AI agent context
- AI automatically checks if WDS repo exists
- AI offers to clone WDS if not found
- Zero manual setup required - just drag file to chat
- Supports both workspace and copied setups
AGENTS COMPLETE (3 files):
- Created saga-analyst.agent.yaml (Saga - WDS Analyst)
- Created idunn-pm.agent.yaml (Idunn - WDS PM)
- Created freyja-ux.agent.yaml (Freyja - WDS Designer)
- All agents include presentations, personas, and full menu integration
- Norse mythology theme unified across all agents
DOCUMENTATION UPDATES:
- Updated README with complete 8-phase structure
- Updated folder structure to show
Removes references to epic-tech-context, story-context, story-done,
and story-ready workflows that were deleted in the Phase 4 transformation.
Also renames mislabeled excalidraw element IDs from proc-story-done
to proc-code-review to match the actual displayed text.
Fixes#1088
Kevin Heidt
Alex Verkhovsky
murat
Mårten Angner
Murat K Ozcan
Brian Madison