Workflow Framework
Development Framework Challenge
All known AI development frameworks currently assume: single product, single team, small workforce.
Without reinventing the wheel, we need to extend these existing specification-driven frameworks to adapt to multi-product, multi-endpoint, multi-role environments. After referencing AWS AI DLC, the following proposal was generated. Some scenarios have been implemented in several feature development processes documented in the appendices. Here we present the complete picture:
Multi-Level Specification Management
Why Multi-Level Architecture
A single specification document cannot satisfy the needs of different roles. PMs care about business value and scope, designers need user flows and visual standards, engineers need technical details and interface contracts. Putting all information into one document means everyone must filter through irrelevant content to find what they need.
Multi-level architecture allows each role to read only the specification levels relevant to them. High-level specs define "what to build," while specialized specs define "how to build." Each level has clear input sources and output deliverables, forming a traceable specification chain. When requirements change, affected levels can be quickly identified rather than searching through a single massive document.
Level Structure
Each level inherits from and extends its predecessors:
| Level | Inputs | Output |
|---|---|---|
| High-Level Spec | Discussed Business Intent | Feature Requirements, Scope, Impact |
| Design Document | High-Level Spec | Architectural Decisions, Trade-offs, Risks |
| UX Spec | High-Level Spec | User Flows, Design Tokens, Wireframes |
| API Spec | High-Level Spec + API Principles | Interface Contracts, Schema Definitions |
| Backend Spec | High-Level + API Spec | Implementation Design, Data Models |
| Frontend Spec | High-Level + API + UX + Design System | Component Architecture, State Management |
| Test Spec | All Above | Test Cases, Acceptance Criteria |
Simplified Spec Levels for Smaller Projects
If your project is relatively simple—such as a backend-only service, frontend-only application, or solo full-stack development—you don't need to adopt all levels. Omit intermediate specs that don't apply to your project:
- Backend-only API service: Skip UX Spec, Frontend Spec
- Frontend-only application: Skip Backend Spec, API Spec (if using third-party APIs)
- Small full-stack project: High-Level Spec maps directly to implementation, skip intermediate specialized specs
The key is to retain levels that are meaningful for your project, not to mechanically apply the full architecture.
Agentic Product Development Flow Architecture
| 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 |
| Review Specs | Each role reviews specs for correctness and feasibility | Each Role |
| Implement from Specs | AI agents generate implementation based on specs, humans review | Engineers + 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.
The Standard Workflow Pattern
Each functional role follows a consistent cycle:
- Receive - Obtain standardized specifications from upstream
- Combine - Merge with domain-specific context (Design System, API Principles, Coding Standards)
- Delegate - Submit to AI Agent for proposal generation
- Review - Evaluate agent output for correctness and quality
- Refine - Iterate with agent until acceptable
- Archive - Commit to version control as single source of truth
Workflow Topics
This section covers specific workflows for different scenarios in spec-driven development:
| Topic | Description |
|---|---|
| Requirement Seed Content | Minimum necessary information to initiate an OpenSpec change proposal |
| Bug Fix Flow | Workflows for handling bugs based on whether they indicate spec or implementation problems |
| API Design Flow | API-First approach with AI agent integration for API specification |
| Change Artifacts | Managing supplementary documents that support OpenSpec change proposals |
References
- OpenSpec - Specification-driven development framework for AI-assisted workflows
- Claude Code Documentation - Official documentation for CLAUDE.md and AI guidance files
- shadcn/ui - Beautifully designed components for design system foundation
- OpenAPI Specification - API description format for RESTful APIs
- Gherkin Syntax - Given/When/Then scenario specification format