Partially Verified by AI Team
The Mob Elaboration approach has been trialed in select projects. Multi-level spec management is integrated into existing workflows.
Feature Development Flow
This document describes the complete feature development flow, explaining how AI-DLC (AI-Driven Development Life Cycle) Mob Elaboration integrates into the multi-level spec management system in the Workflow Framework.
Early Convergence Phase
Before entering spec refinement, the Early Convergence Phase must be completed first. This is where humans contribute the most wisdom and work most intensively throughout the entire workflow.
| Phase | Description | Participants |
|---|---|---|
| Receive Intent | Receive requirement intent from business or product | PM, Business |
| Intensive Discussion | Complete all key decision convergence within 2-3 days | All Stakeholders |
| Form Proposal | Produce a spec-reviewed proposal document | PM, Tech Lead, Design |
| Produce Specs | Generate detailed specs via OpenSpec | Each Role + AI |
Key: Early Convergence
The core of this workflow is the 2-3 days of intensive upfront discussion. All stakeholders who might influence the spec must complete opinion convergence during this phase to avoid late-stage changes causing rework.
Why No AI in Early Convergence?
According to AI-DLC definitions, AI should theoretically be involved in the early convergence phase. However, after actual experimentation, we found that AI produces over-extended specs when context is not sufficiently clear.
Therefore, at this stage we still recommend using human thinking for specifications. This is also where humans contribute the most wisdom and work most intensively throughout the entire workflow.
During this intensive discussion of intent and proposals, everyone becomes a core designer of the product—everyone is closely connected to it.
Relationship with Workflow Framework
AI-DLC Mob Elaboration Flow
| Phase | Description | Output |
|---|---|---|
| Requirement Seed | Through intensive discussion in mob elaboration meeting | Refined preliminary spec |
| AI Expansion | AI expands the preliminary spec | Standardized spec document |
Early Convergence produces the Preliminary Spec (requirement seed), which is then transformed via AI Expansion into a Standardized Spec Document. After spec review, it becomes the High-Level Spec, then enters the multi-level spec management flow of the Workflow Framework.
Practical Timeline Example
Below is a typical day-by-day timeline for feature development, showing each role's participation at different stages:
Timeline Overview
Day-by-Day Breakdown
| Day | Phase | Activity | Participants | Output |
|---|---|---|---|---|
| Day -5~-1 | Pre-Meeting | PM writes requirement seed, each role prepares materials | PM, RD, UX, Architect | Requirement seed, prep materials |
| Day 0-2 | Mob Elaboration | Hold Mob Elaboration meeting, intensive discussion | PM, RD, UX, Architect | Preliminary spec (refined requirements) |
| Day 3 | AI Expansion | AI expands preliminary spec into standardized document | AI, RD | Standardized spec document |
| Day 4 | Spec Archive | Review and archive high-level spec | PM, RD | Versioned high-level spec |
| Day 5-6 | Web UX Branch | Generate Web UX spec and wireframes | UX, AI | Web UX spec, design tokens |
| Day 5-6 | App UX Branch | Generate App UX spec and wireframes | UX, AI | App UX spec, design tokens |
| Day 5-6 | API Branch | Generate API spec and OpenAPI | RD, Architect, AI | OpenAPI document |
| Day 5-6 | Design Branch | Generate technical design document | Architect, AI | Architecture decisions, technical design |
| Day 7-9 | Web Frontend Impl | Develop based on Web UX + API specs | Web Frontend RD, AI | Web frontend code |
| Day 7-9 | App Frontend Impl | Develop based on App UX + API specs | App Frontend RD, AI | App frontend code |
| Day 7-9 | Backend Impl | Develop based on API + Design docs | Backend RD, AI | Backend code |
| Day 10-11 | Testing | QA executes acceptance tests | QA, AI | Test report |
| Day 10 | Code Review | Review code | RD, TL | Review comments, approval |
| Day 12 | Complete | Merge to main branch, deployment prep | RD, Ops | Deployable version |
Role Participation Timeline
Key Milestones
| Milestone | Timing | Verification Items | Owner |
|---|---|---|---|
| Requirement Seed Complete | Day 0 | Business context, scope, constraints documented | PM |
| High-Level Spec Approved | Day 2 | All participants reach consensus, edge cases identified | PM, RD, UX, Architect |
| Spec Branches Complete | Day 4 | Web UX/App UX/API/Design specs archived | Branch owners |
| Development Complete | Day 7 | Code complete, unit tests passing | RD |
| Acceptance Complete | Day 10 | QA acceptance passed, Code Review approved | QA, TL |
Problems with Traditional SDLC
Sequential Knowledge Transfer
Blind Spots by Role
| Role | Blind Spot | Consequence |
|---|---|---|
| PM | Technical constraints, API limits | Unrealistic requirements |
| RD | UX impact, user journey gaps | Poor user experience |
| UX | Technical feasibility, data availability | Unimplementable designs |
| Architect | Business context, priority trade-offs | Over-engineered solutions |
| Everyone | Edge cases, error scenarios | Production bugs |
AI-DLC Solution: Mob Elaboration
Core Insight: Requirement quality improves significantly when multiple perspectives challenge assumptions simultaneously. AI adds a tireless participant that surfaces edge cases, checks consistency, and maintains complete documentation in real-time.
Target State
Phase 1: Pre-Meeting Preparation
Requirement Seed
Before the Mob Elaboration meeting, PM prepares a requirement seed document:
## Requirement Seed: [Feature Name]
### Business Context
- Why now?
- Who requested this?
- What problem does it solve?
### Initial Scope
- Must have: [Core functionality]
- Nice to have: [Bonus features]
- Out of scope: [Explicit exclusions]
### Known Constraints
- Timeline:
- Budget:
- Technical:
### Success Metrics
- [Quantifiable success criteria]Participant Preparation
| Role | Pre-Meeting Prep |
|---|---|
| PM | Prepare requirement seed, business context |
| RD | Familiarize with related code, technical constraints |
| UX | Prepare user journeys, competitor references |
| Architect | Assess system impact, existing architecture |
| AI Agent | Load CLAUDE.md, existing specs, API docs |
Phase 2: Mob Elaboration Meeting
Meeting Flow
Human Roles in Meeting
The Mob Elaboration meeting is where humans contribute the most wisdom and work most intensively. Each role brings unique perspectives:
| Role | Responsibility | Contribution |
|---|---|---|
| PM | Business context guardian | Ensure requirements align with business goals, clarify priorities |
| RD | Technical feasibility gatekeeper | Assess technical constraints, propose alternatives |
| UX | User experience advocate | Ensure complete user journeys, identify experience pain points |
| Architect | System integrity guardian | Assess architecture impact, ensure consistency |
Why Emphasize Human Roles?
During this intensive discussion of intent and proposals, everyone becomes a core designer of the product—everyone is closely connected to it.
AI in this phase only serves as assistance for recording and organizing, not participating in decisions. All key decisions are made by humans.
Phase 3: Spec Branching
After Mob Elaboration produces the high-level spec, it enters the multi-level spec management:
Standard Workflow for Each Branch
Each branch follows the Receive → Combine → Delegate → Review → Refine → Archive pattern:
| Branch | Receive | Combine | Delegate |
|---|---|---|---|
| Web UX | High-level spec | Web design system, brand guide | AI generates Web UX spec draft |
| App UX | High-level spec | App design system, platform guidelines | AI generates App UX spec draft |
| API | High-level spec | API design principles | AI generates OpenAPI draft |
| Design | High-level spec | Architecture principles, tech stack | AI generates design doc draft |
| Backend | API spec + Design doc | Code standards | AI-assisted implementation |
| Web Frontend | Web UX spec + API spec | Web design system components | AI-assisted implementation |
| App Frontend | App UX spec + API spec | App design system components | AI-assisted implementation |
| QA | All specs | Test strategy | AI generates test cases |
Phase 4: AI-Assisted Implementation
Development Loop
AI Agent Development Assistance
| Task | AI Can Help | AI Should Not |
|---|---|---|
| Write code | Generate initial draft from spec | Make architectural decisions |
| Debug | Analyze error messages, suggest fixes | Ignore root causes |
| Refactor | Improve code structure as directed | Significantly change design |
| Test | Generate test cases | Skip tests and mark complete |
Phase 5: Review & Acceptance
Code Review Flow
Review Focus Areas
| Aspect | Check Items |
|---|---|
| Spec Alignment | Does it match the Mob Elaboration spec? |
| Edge Cases | Are edge cases from the spec handled? |
| Correctness | Is the logic correct? |
| Security | Injection risks? Permission checks complete? |
QA Acceptance
Acceptance tests directly derive from Mob Elaboration outputs:
Definition of Done
| Category | Criteria |
|---|---|
| Spec | All acceptance criteria from Mob Elaboration spec met |
| Code | Merged to main branch, CI all green |
| Testing | Unit/Integration/E2E tests pass, edge cases covered |
| Review | Code Review approved |
| Acceptance | QA acceptance passed |
| Documentation | Required docs updated, archived to version control |
Applicability
Full Mob Elaboration for
- New features with multiple stakeholders
- Features spanning multiple systems
- High-risk or high-visibility features
- Features with unclear requirements
Lightweight Process
For well-defined small features, use:
- Mini Elaboration: PM + RD + AI (30 minutes)
- Direct Delegation: PM writes requirement seed, AI generates spec draft, RD reviews
Frequently Asked Questions
Does "2-3 days of intensive discussion" mean everyone is in meetings for 2-3 days straight?
No. "2-3 days" refers to the decision convergence time window, not continuous meeting time. Here's how it actually works:
| Activity | Timing | Format |
|---|---|---|
| Pre-meeting prep | Day -5 ~ -1 | Async, individual preparation |
| Mob Elaboration meeting | Day 0 | Sync, 2-4 hours |
| Async refinement | Day 0-2 | Async, document comments, Slack discussions |
| Final convergence meeting | Day 2 | Sync, 1-2 hours |
Core synchronous time is about 4-6 hours spread across 2-3 days.
What if stakeholders are distributed across different time zones?
Hybrid sync/async mode:
- Identify overlap windows: Find 2-3 hour slots where all key participants can join
- Async-first discussions: Collect opinions and concerns via documents before the meeting
- Recording supplement: Record sync meetings for those who can't attend to watch and provide written feedback
- Split meetings: If no overlap exists, consider two separate meetings with PM as the bridge
Key: Ensure every critical decision-maker has an opportunity to express their views before decisions are finalized.
What if a key role (like Legal or Security) can only attend for 2 hours?
Expert time slot planning:
| Strategy | Approach |
|---|---|
| Pre-written input | Send focused questionnaire before meeting to collect key constraints and considerations |
| Dedicated slot | Reserve 30-60 minutes in the meeting specifically for the key expert |
| Proxy attendance | Designate someone familiar with that domain as meeting proxy, confirm with expert afterward |
| Post-meeting review | Reserve 24-48 hours for expert to review preliminary spec and raise objections |
Practical tips:
- Legal, Security, and other specialized roles typically focus on specific aspects; they don't need full participation
- Prepare a "summary for experts" document focusing on their areas of concern
- Clearly communicate what will be decided in the meeting so experts know where their input is needed
How do we handle roles with veto power who "can't participate but have final say"?
Tiered decision authority mechanism:
Concrete approaches:
- Pre-meeting alignment: PM conducts 30-minute individual pre-alignment with veto-power roles before Mob Elaboration
- Explicit authorization: Obtain "can proceed under X conditions" conditional authorization
- Reserve review window: Allow 24-48 hour objection period after spec is produced
- Escalation mechanism: If objections come after the review period, they must go through change management
Warning: If a veto-power role can't even arrange 30 minutes for pre-alignment, this is usually an organizational problem, not a process problem. Escalate for coordination.
In reality, it's very hard to get everyone free at the same time. What alternatives exist?
Pragmatic alternative strategies:
| Situation | Alternative |
|---|---|
| Only 2-3 people can sync | Use mini-elaboration + async review cycles |
| Core members completely can't sync | Pure async elaboration (extends to 5-7 days) |
| Urgent feature can't wait | Narrow scope, do MVP version Mob Elaboration first |
Async Mob Elaboration flow:
Note: Async mode significantly increases communication costs and convergence time. Recommend using only when necessary, and scheduling a 30-minute sync meeting afterward for final confirmation.
How do we determine which features need full Mob Elaboration vs. simplified processes?
Decision matrix:
| Criteria | Full Mob Elaboration | Mini Elaboration | Direct Delegation |
|---|---|---|---|
| Stakeholders | ≥ 4 people/teams | 2-3 people | 1 person (PM can decide) |
| Cross-system impact | ≥ 3 systems | 1-2 systems | Single system |
| Uncertainty | Unclear requirements, multiple possibilities | Mostly clear, few items to confirm | Completely clear |
| Risk level | High (revenue, security, compliance impact) | Medium | Low |
| Estimated effort | ≥ 2 weeks | 3-10 days | ≤ 3 days |
Rules of thumb:
- If you can't explain to RD what needs to be done in 5 minutes, you need at least a mini-elaboration
- If anyone says "we need to ask XX about this," bring XX in
- If the answer is "it depends" more than "definitely X," you need more thorough elaboration
Does "avoiding late-stage changes" mean features can never be modified?
No. "Avoiding late-stage changes" refers to within a single feature development cycle—decisions from the convergence meeting should be followed. This doesn't mean features can never evolve.
Correct understanding:
| Timing | Recommended Approach |
|---|---|
| Within cycle | Follow convergence decisions, avoid mid-cycle overturning |
| Post-release | Collect feedback, plan for next cycle |
| Emergency | Follow emergency change process (see below) |
Why stay stable within a cycle?
- AI has started executing based on specs; mid-cycle changes cause massive rework
- Team has allocated resources; changes affect other schedules
- Frequent changes destroy the value of "early convergence"
What if market conditions really change (e.g., competitor releases new feature)?
Ask three questions first:
- Urgency: Does this change affect the core value of this release?
- Scope impact: Will the adjustment affect more than 30% of planned work?
- Time buffer: How much time remains until the planned release?
Decision matrix:
| Situation | Recommended Approach |
|---|---|
| Doesn't affect core value | Record it, include in next cycle |
| Affects core but small scope (< 30%) | Hold mini-elaboration to adjust |
| Affects core and large scope (≥ 30%) | Consider pausing current cycle, re-converge |
Practical advice:
Most "market changes" aren't as urgent as they seem. Ask yourself:
"What happens if we respond two weeks later?"
If the answer is "not much impact, really," put it in the next cycle.
What's the process for force majeure like regulatory changes or security vulnerabilities?
Force majeure change process:
Force majeure types and responses:
| Type | Example | Response |
|---|---|---|
| Blocking regulation | Must comply before GDPR effective date | Pause feature development, focus on compliance |
| Security vulnerability | High-severity CVE | Independent emergency fix branch, don't mix with feature development |
| Third-party API change | Vendor deprecates API | Assess impact scope, decide whether to pause or parallel process |
| Hardware/Infrastructure | Cloud provider ends support | Include in tech debt handling, usually doesn't affect feature development |
Key principle: Force majeure changes should be tracked independently—don't mix them into the original feature spec.
Is there a "fast track" for emergency changes?
Yes. But conditions must be met and process followed:
Activation conditions (at least one must apply):
- [ ] Security vulnerability (CVSS ≥ 7.0)
- [ ] Regulatory compliance deadline
- [ ] Core functionality completely unusable
- [ ] Committed customer timeline
Fast track process:
| Step | Time | Description |
|---|---|---|
| 1. Submit emergency request | Immediate | Explain situation to PM Lead or Tech Lead |
| 2. Impact assessment | Within 30 min | Assess impact on current development cycle |
| 3. Authorization decision | Within 1 hour | PM Lead + Tech Lead jointly decide whether to activate |
| 4. Mini-elaboration | 1-2 hours | Minimum necessary personnel for quick convergence |
| 5. Execution | As needed | May require pausing or adjusting original schedule |
| 6. Post-mortem | After completion | Document change reason, impact, learnings |
Costs of fast track:
Warning: If fast track usage exceeds once per month, this usually indicates:
- Early convergence wasn't thorough enough
- Stakeholders weren't sufficiently included
- Or the project itself is too high-risk and needs re-evaluation
How do you distinguish "legitimate requirement evolution" from "inappropriate late-stage interference"?
Judgment criteria:
| Aspect | Legitimate Evolution | Inappropriate Interference |
|---|---|---|
| Information source | New data, user feedback, market changes | "I just thought of this," "Boss said" |
| Timing | Raised in post-release feedback cycle | Suddenly inserted during development |
| Scope | Clear boundaries, can be evaluated independently | Vague, constantly expanding |
| Proposer | Participant from original convergence meeting | Person who didn't participate in convergence |
| Decision process | Willing to follow formal process | Wants to bypass process and change directly |
Handling approach:
Practical phrasing:
"That's a great idea—let's record it. Since the team has already started executing based on our convergence decisions, I suggest we complete this version first, then evaluate it together in the next cycle after collecting feedback. That way we'll have more complete information to make the decision."
Core principle: Respect work already invested, but don't reject good ideas—put them at the right time for handling.
Will multi-level spec maintenance cost become a new bottleneck?
Reframe multi-level specs: This is tree structure, not document burden.
Core insight:
| Traditional View | Correct View |
|---|---|
| 7 spec levels = 7x maintenance cost | Trunk + Branches = Structural investment |
| Specs are "extra documents" | Specs are "skeleton" |
| Maintaining specs vs writing code | Without skeleton, leaves won't grow stable |
Without API specs, AI-generated frontend and backend code won't automatically align. Without UX specs, AI-generated UI won't match design intent. "Multi-level specs" aren't document burden—they're structural investment for stable AI output.
How many spec documents does a medium-sized feature actually need?
Not every feature needs all 7 layers. The 7 layers represent maximum possible scope:
| Feature Type | Specs Actually Needed | Layers |
|---|---|---|
| Pure backend API | High-level → API → Backend | 3 layers |
| Pure frontend adjustment | High-level → UX → Frontend | 3 layers |
| Full-stack feature | High-level → UX → API → Frontend + Backend | 5 layers |
| Complex cross-platform | Full 7 layers | 7 layers |
More importantly: Specs are "generated," not "hand-written"
Traditional: Human writes high-level → Human writes UX → Human writes API → Human writes code
↓ ↓ ↓ ↓
(time-consuming) (time-consuming) (time-consuming) (time-consuming)
AI Mode: Human writes high-level → AI generates UX → AI generates API → AI generates code
↓ ↓ ↓
Human reviews Human reviews Human reviews
(fast) (fast) (fast)Maintenance cost isn't "writing 7 documents"—it's "reviewing AI-generated content."
When requirements change, how many specs need synchronous updates?
Principle: Update from the highest affected level, regenerate downward.
Change frequency by layer:
| Layer | Change Frequency | Notes |
|---|---|---|
| Trunk (High-level spec) | Rarely | Business intent is stable once established |
| Branches (API/UX/Design) | Occasionally | Mainly adjusted during early development |
| Leaves (Implementation/Tests) | Frequently | But regeneration cost is low (AI-generated) |
Practical experience: Most changes only affect the "leaves" layer—no need to touch "trunk" and "branches."
Who ensures consistency between specs? Manual or automated?
Hybrid mode: Automated checks + Human judgment
| Consistency Type | Check Method | Tools |
|---|---|---|
| API spec vs implementation | Automated | OpenAPI validation, CI checks |
| UX spec vs implementation | Semi-automated | Visual regression testing + Design review |
| Terminology consistency across specs | AI-assisted | AI comparison + Human confirmation |
| Business logic consistency | Manual | Spec review meetings |
Responsibility assignment:
Key principles:
- Automate everything that can be automated (API contract validation)
- Use AI to flag suspicious areas for what can't be automated
- Final judgment rests with humans (PM/Tech Lead/UX Lead)
What simplification strategies exist if spec maintenance really becomes a bottleneck?
Diagnosis: First identify where the bottleneck is
| Symptom | Likely Cause | Solution |
|---|---|---|
| "Writing specs takes too long" | Not leveraging AI generation | Let AI generate drafts, humans only review |
| "Too many specs to track" | Over-granular layer division | Merge related specs, reduce document count |
| "Specs are often outdated" | Unclear update process | Define trigger conditions and owners |
| "Specs are inconsistent" | Lack of automated checks | Implement CI validation |
Simplification strategies:
- Merge layers: Small features can merge UX + Frontend specs, API + Backend specs
- Skip non-essential layers: Pure bug fixes can just have high-level description + direct code changes
- Progressive refinement: Start with rough specs for rapid development, add detail after stabilization
- Spec templates: Build team templates to reduce starting-from-scratch cost each time
Final reminder:
If "writing specs" feels like a burden, it usually means:
- Not leveraging AI generation (should be reviewing, not writing)
- Or the feature doesn't need this many layers (over-formalization)
The purpose of specs is to make AI output more stable. If specs themselves become the bottleneck, they've lost their purpose. Pragmatically choose spec layers appropriate for the feature's complexity.
Anti-Patterns
1. AI as Decision Maker
Problem: Pushing decisions to AI instead of human judgment.
Correct Approach: AI provides options and surfaces trade-offs. Humans decide.
2. Skipping Mob Elaboration
Problem: Complex features go straight to implementation without multi-perspective refinement.
Correct Approach: Complex features must go through Mob Elaboration to produce high-level spec.
3. Treating Spec as Final
Problem: Treating Mob Elaboration spec as immutable.
Correct Approach: Specs are living documents. Hold mini-elaboration when issues arise.
4. Skipping Spec Branches
Problem: High-level spec jumps directly to implementation without UX/API/Design branches.
Correct Approach: Follow multi-level spec management, each branch produces its spec.
Related Documents
- Workflow Framework - Multi-level spec management and standard workflow pattern
- AI-DLC Mob Elaboration Proposal - Detailed Mob Elaboration methodology
- API Design Flow - API branch detailed flow
References
- AI-Driven Development Life Cycle (AWS) - AWS approach to AI-enhanced SDLC
- OpenSpec - Specification-driven development framework
- Mob Programming - Foundation practice inspiring Mob Elaboration