codex-workflows 0.3.0 → 0.4.0

package/.codex/agents/technical-designer.toml

@@ -113,6 +113,8 @@ Must be performed before Design Doc creation:
    - Clearly document similar functionality search results (found implementations or "none")
    - Include dependency existence verification results (verified existing / requires new creation / external dependency)
    - Record adopted decision (use existing/improvement proposal/new implementation) and rationale
+   - When Codebase Analysis input is provided, use it as the baseline evidence set and extend it only where gaps remain
+   - When persistence, repositories, queries, migrations, or schema-bound behavior are part of scope, complete the `Test Boundaries` section with a concrete data layer verification strategy. When they are not part of scope, mark the section explicitly as not applicable.
 
 6. **Code Inspection Evidence**
    - Record all inspected files and key functions in "Code Inspection Evidence" section of Design Doc
@@ -233,6 +235,13 @@ Confirm and document conflicts with existing systems at each integration point t
   - `reverse-engineer`: Document existing architecture as-is
 
 - **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
+- **Codebase Analysis** (optional, from codebase-analyzer):
+  - Use as the primary source for Existing Codebase Analysis when provided
+  - `existingElements` informs implementation path mapping and inspection evidence
+  - `dataModel` informs schema references, data contracts, and persistence design
+  - `focusAreas` indicate areas requiring deeper design attention
+  - `constraints` inform design constraints, assumptions, and risk handling
+  - Additional investigation should focus on gaps or limitations that the analysis calls out
 - **PRD**: PRD document (if exists)
 - **Documents to Create**: ADR, Design Doc, or both
 - **Existing Architecture Information**:

package/.codex/agents/work-planner.toml

@@ -156,7 +156,26 @@ Read test skeleton files (integration tests, E2E tests) and extract meta informa
    - `// @complexity: high` → Subdivide tasks or estimate higher effort
    - `// @complexity: low` → Consider combining multiple tests into one task
 
-#### Step 3: Classify and Place Tests
+#### Step 3: Extract Environment Prerequisites from E2E Skeletons
+
+When E2E test skeletons are provided, first identify the E2E skeleton subset using file naming conventions such as `*.e2e.test.*` and then scan only those files for environment prerequisites in two stages:
+
+**Stage 1: Detect precondition patterns**
+- `Preconditions:` annotations mentioning seed data, test users, subscriptions, or required DB state
+- `@dependency: full-system` combined with auth/login setup
+- Environment variable references such as `E2E_*` or `TEST_*`
+- External service dependencies that require mock/intercept or a running local dependency
+
+**Stage 2: Generate Phase 0 setup tasks**
+- Seed data → Add a Phase 0 task for fixture or seed preparation
+- Auth fixture/login state → Add a Phase 0 task for auth setup
+- External service mocks → Add a Phase 0 task for mock/intercept setup
+- Environment configuration → Add a Phase 0 task for env var or local service configuration
+- Other prerequisites → Add a matching setup task with clear traceability to the E2E skeleton
+
+Place these setup tasks before implementation and annotate them as E2E setup work.
+
+#### Step 4: Classify and Place Tests
 
 **Test Classification**:
 - Setup items (Mock preparation, measurement tools, Helpers, etc.) → Prioritize in Phase 1
@@ -208,7 +227,7 @@ Compose phases based on technical dependencies and implementation approach from
 Always include quality assurance (all tests passing, acceptance criteria achieved) in final phase.
 
 ### Test Skeleton Integration
-Follow the test skeleton placement rules defined in Step 4 of the Planning Process.
+Follow the test skeleton placement rules defined in the Planning Process.
 
 ## Diagram Creation (using mermaid notation)
 
@@ -221,6 +240,7 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
 - [ ] All requirements converted to tasks
 - [ ] Quality assurance exists in final phase
 - [ ] Test skeleton file paths listed in corresponding phases (when provided)
+- [ ] E2E environment prerequisites addressed when E2E skeletons are provided
 - [ ] Test design information reflected (only when provided)
   - [ ] Setup tasks placed in first phase
   - [ ] Risk level-based prioritization applied

package/README.md

@@ -48,10 +48,11 @@ The framework runs a structured workflow — requirements → design → task de
 A single request becomes a structured development process:
 
 1. **Understand** the problem (scale, constraints, affected files)
-2. **Design** the solution (ADR, Design Doc with acceptance criteria)
-3. **Break it into tasks** (atomic, 1 commit each)
-4. **Implement with tests** (TDD per task)
-5. **Run quality checks** (lint, test, build — no failing checks)
+2. **Analyze the existing codebase** (dependencies, data layer, risk areas)
+3. **Design** the solution (ADR, Design Doc with acceptance criteria)
+4. **Break it into tasks** (atomic, 1 commit each)
+5. **Implement with tests** (TDD per task)
+6. **Run quality checks** (lint, test, build — no failing checks)
 
 Each step is handled by a specialized subagent in its own context, preventing context pollution and reducing error accumulation in long-running tasks:
 
@@ -62,9 +63,13 @@ requirement-analyzer  →  Scale determination (Small / Medium / Large)
     ↓
 prd-creator           →  Product requirements (Large scale)
     ↓
+codebase-analyzer     →  Existing codebase facts + focus areas
+    ↓
 technical-designer    →  ADR + Design Doc with acceptance criteria
     ↓
-document-reviewer     →  Quality gate
+code-verifier         →  Design Doc vs existing code verification
+    ↓
+document-reviewer     →  Quality gate with verification evidence
     ↓
 acceptance-test-gen   →  Test skeletons from ACs
     ↓
@@ -222,6 +227,7 @@ Codex spawns these as needed during recipe execution. Each agent runs in its own
 | `technical-designer` | ADR and Design Doc creation (backend) |
 | `technical-designer-frontend` | Frontend ADR and Design Doc creation (React) |
 | `ui-spec-designer` | UI Specification from PRD and optional prototype code |
+| `codebase-analyzer` | Existing codebase analysis before Design Doc creation |
 | `work-planner` | Work plan creation from Design Docs |
 | `document-reviewer` | Document consistency and approval |
 | `design-sync` | Cross-document consistency verification |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codex-workflows",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Task-oriented agentic coding framework for OpenAI Codex CLI — skills, recipes, and subagents for structured development workflows",
   "license": "MIT",
   "author": "Shinsuke Kagawa",