codex-workflows 0.1.0 → 0.2.1

package/.codex/agents/task-executor-frontend.toml

@@ -191,6 +191,10 @@ Examples: `docs/plans/analysis/component-research.md`, `docs/plans/analysis/api-
 
 ## Structured Response Specification
 
+### Field Specifications
+
+**requiresTestReview**: Set to `true` when the task added or updated integration tests or E2E tests. Set to `false` for unit-test-only tasks or tasks with no tests.
+
 ### 1. Task Completion Response
 Report in the following JSON format upon task completion (**without executing quality checks or commits**, delegating to quality assurance process):
 
@@ -201,6 +205,7 @@ Report in the following JSON format upon task completion (**without executing qu
   "changeSummary": "[Specific summary of React component implementation/changes]",
   "filesModified": ["src/components/Button/Button.tsx", "src/components/Button/index.ts"],
   "testsAdded": ["src/components/Button/Button.test.tsx"],
+  "requiresTestReview": false,
   "newTestsPassed": true,
   "progressUpdated": {
     "taskFile": "5/8 items completed",

package/.codex/agents/task-executor.toml

@@ -192,6 +192,10 @@ Examples: `docs/plans/analysis/research-results.md`, `docs/plans/analysis/api-sp
 
 ## Structured Response Specification
 
+### Field Specifications
+
+**requiresTestReview**: Set to `true` when the task added or updated integration tests or E2E tests. Set to `false` for unit-test-only tasks or tasks with no tests.
+
 ### 1. Task Completion Response
 Report in the following JSON format upon task completion (**without executing quality checks or commits**, delegating to quality assurance process):
 
@@ -202,6 +206,7 @@ Report in the following JSON format upon task completion (**without executing qu
   "changeSummary": "[Specific summary of implementation content/changes]",
   "filesModified": ["specific/file/path1", "specific/file/path2"],
   "testsAdded": ["created/test/file/path"],
+  "requiresTestReview": true,
   "newTestsPassed": true,
   "progressUpdated": {
     "taskFile": "5/8 items completed",

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

@@ -40,35 +40,45 @@ Skill Status:
 2. Clarify task dependencies
 3. Phase division and prioritization
 4. Define completion criteria for each task (derived from Design Doc acceptance criteria)
-5. **Define operational verification procedures for each phase**
+5. Define operational verification procedures for each phase
 6. Concretize risks and countermeasures
 7. Document in progress-trackable format
 
-## Required Information
-
-Required input (in natural language):
-
-- **Operation Mode**:
-  - `create`: New creation (default)
-  - `update`: Update existing plan
-
-- **Requirements Analysis Results**: Requirements analysis results (scale determination, technical requirements, etc.)
-- **PRD**: PRD document (if created)
-- **ADR**: ADR document (if created)
-- **Design Doc(s)**: Design Doc document(s) (if created, may be multiple for cross-layer features)
-- **Test Design Information** (reflect in plan if provided from previous process):
-  - Test definition file path
-  - Test case descriptions (it.todo format, etc.)
-  - Meta information (@category, @dependency, @complexity, etc.)
-- **Current Codebase Information**:
-  - List of affected files
-  - Current test coverage
-  - Dependencies
-
-- **Update Context** (update mode only):
-  - Path to existing plan
-  - Reason for changes
-  - Tasks needing addition/modification
+## Input Parameters
+
+- **mode**: `create` (default) | `update`
+- **designDoc**: Path to Design Doc(s) (may be multiple for cross-layer features)
+- **uiSpec** (optional): Path to UI Specification (frontend/fullstack features)
+- **prd** (optional): Path to PRD document
+- **adr** (optional): Path to ADR document
+- **testSkeletons** (optional): Paths to integration/E2E test skeleton files from acceptance-test-generator
+- **updateContext** (update mode only): Path to existing plan, reason for changes
+
+## Workflow
+
+### 1. Load Input Documents
+Read the Design Doc(s), UI Spec, PRD, and ADR (if provided). Extract:
+- Acceptance criteria and implementation approach
+- Technical dependencies and implementation order
+- Integration points requiring E2E verification
+
+### 2. Process Test Design Information (when provided)
+Read test skeleton files and extract meta information (see Test Design Information Processing section).
+
+### 3. Select Implementation Strategy
+Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementation-first) otherwise. See Implementation Strategy Selection section.
+
+### 4. Compose Phases
+Structure phases based on technical dependencies from Design Doc:
+- Place tasks with lowest dependencies in earlier phases
+- Include operational verification at integration points
+- Include quality assurance in final phase
+
+### 5. Define Tasks with Completion Criteria
+For each task, derive completion criteria from Design Doc acceptance criteria. Apply the 3-element completion definition (Implementation Complete, Quality Complete, Integration Complete).
+
+### 6. Produce Work Plan Document
+Write the work plan following the plan template from documentation-criteria skill. Include Phase Structure Diagram and Task Dependency Diagram (mermaid).
 
 ## Work Plan Output Format
 

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Shinsuke Kagawa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -6,7 +6,7 @@
 
 **End-to-end AI coding workflows for [Codex CLI](https://developers.openai.com/codex/cli)** — specialized subagents handle requirements, design, implementation, and quality checks so you get code with explicit design docs, test coverage, and commit-level traceability — not just raw generations.
 
-Built on the [Agent Skills specification](https://developers.openai.com/codex/skills/) and [Codex subagents](https://developers.openai.com/codex/subagents). Works with GPT-5.4 and GPT-5.3-Codex-Spark.
+Built on the [Agent Skills specification](https://developers.openai.com/codex/skills/) and [Codex subagents](https://developers.openai.com/codex/subagents). Works with the latest GPT models.
 
 ---
 
@@ -144,7 +144,7 @@ Invoke recipes with `$recipe-name` in Codex. Type `$recipe-` and use tab complet
 | `$recipe-design` | Requirements → ADR/Design Doc | Architecture planning |
 | `$recipe-plan` | Design Doc → test skeletons → work plan | Planning phase |
 | `$recipe-build` | Execute backend tasks autonomously | Resume backend implementation |
-| `$recipe-review` | Design Doc compliance validation with auto-fixes | Post-implementation check |
+| `$recipe-review` | Design Doc compliance and security validation with auto-fixes | Post-implementation check |
 | `$recipe-diagnose` | Problem investigation → verification → solution | Bug investigation |
 | `$recipe-reverse-engineer` | Generate PRD + Design Docs from existing code | Legacy system documentation |
 | `$recipe-add-integration-tests` | Add integration/E2E tests from Design Doc | Test coverage for existing code |
@@ -157,7 +157,7 @@ Invoke recipes with `$recipe-name` in Codex. Type `$recipe-` and use tab complet
 | `$recipe-front-design` | Requirements → UI Spec → frontend Design Doc | Frontend architecture planning |
 | `$recipe-front-plan` | Frontend Design Doc → test skeletons → work plan | Frontend planning phase |
 | `$recipe-front-build` | Execute frontend tasks with RTL + quality checks | Resume frontend implementation |
-| `$recipe-front-review` | Frontend compliance validation with React-specific fixes | Frontend post-implementation check |
+| `$recipe-front-review` | Frontend compliance and security validation with React-specific fixes | Frontend post-implementation check |
 
 ### Fullstack (Cross-Layer)
 
@@ -244,6 +244,7 @@ Codex spawns these as needed during recipe execution. Each agent runs in its own
 |-------|------|
 | `code-reviewer` | Design Doc compliance validation |
 | `code-verifier` | Document-code consistency verification |
+| `security-reviewer` | Security compliance review after implementation |
 | `rule-advisor` | Skill selection via metacognitive analysis |
 | `scope-discoverer` | Codebase scope discovery for reverse docs |
 
@@ -316,7 +317,7 @@ your-project/
 │   ├── requirement-analyzer.toml
 │   ├── technical-designer.toml
 │   ├── task-executor.toml
-│   └── ... (22 agents total)
+│   └── ... (23 agents total)
 └── docs/                     # Created as you use the recipes
     ├── prd/
     ├── design/
@@ -332,7 +333,7 @@ your-project/
 
 **Q: What models does this work with?**
 
-A: Designed for GPT-5.4 (default). Subagents like rule-advisor use GPT-5.3-Codex-Spark for faster lightweight analysis. Models are configurable per agent in the TOML files.
+A: Designed for the latest GPT models. Lightweight subagents (e.g. rule-advisor) can use smaller models for faster analysis. Models are configurable per agent in the TOML files.
 
 **Q: Can I customize the agents?**
 

package/package.json

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