codex-workflows 0.2.4 → 0.2.5

package/.agents/skills/documentation-criteria/references/design-template.md

@@ -110,6 +110,11 @@ Each AC is written in EARS (Easy Approach to Requirements Syntax) format.
 - **Integration Target**: [What to connect with]
 - **Invocation Method**: [How it will be invoked]
 
+### Dependency Verification
+| Dependency | Status | Evidence |
+|------------|--------|----------|
+| [Service / hook / type / table / endpoint] | [verified-existing / requires-new-creation / external-dependency] | [path:line, search evidence, or authoritative external source] |
+
 ### Code Inspection Evidence
 
 | File/Function | Relevance |

package/.codex/agents/document-reviewer.toml

@@ -92,6 +92,7 @@ Verify required elements exist per documentation-criteria skill template. Gate 0
 For DesignDoc, additionally verify:
 - [ ] Code inspection evidence recorded (files and functions listed)
 - [ ] Applicable standards listed with explicit/implicit classification
+- [ ] Dependencies described as existing have verification results or authoritative external source
 - [ ] Field propagation map present (when fields cross boundaries)
 
 #### Gate 1: Quality Assessment (only after Gate 0 passes)
@@ -106,6 +107,7 @@ For DesignDoc, additionally verify:
 - Technical information verification: When sources exist, verify with web search for latest information and validate claim validity
 - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
 - Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
+- Dependency realizability check: For each dependency the Design Doc's Existing Codebase Analysis section describes as "existing", verify its definition exists in the codebase using file pattern search and content search. Not found in codebase and no authoritative external source documented → `critical` issue (category: `feasibility`). Found but the definition signature or named contract materially diverges from the Design Doc description → `important` issue (category: `consistency`)
 - **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
 - **Undetermined items review** [MANDATORY]: Every TBD, unknown, or open item MUST include: (1) **owner** — who resolves it, (2) **due** — when it gets resolved (which phase or milestone), (3) **next-phase handling** — how the next phase treats this gap. Missing any of these three → `important` issue
 
@@ -259,6 +261,7 @@ Include in output when `prior_context_count > 0`:
 - [ ] Gate 0 structural existence checks pass before quality review
 - [ ] Design decision rationales verified against identified standards/patterns
 - [ ] Code inspection evidence covers files relevant to design scope
+- [ ] Dependencies described as existing verified against codebase or authoritative external source
 - [ ] Field propagation map present when fields cross component boundaries
 
 ## Review Criteria (for Comprehensive Mode)

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

@@ -84,9 +84,17 @@ Must be performed before Design Doc creation:
      - Similar component is technical debt → Create ADR improvement proposal before implementation
      - No similar component → Proceed with new implementation
 
-4. **Include in Design Doc**
+4. **Dependency Existence Verification**
+   - For each component the design assumes already exists, search for its definition in the codebase using file pattern search and content search
+   - Typical targets include: components, custom hooks, Context definitions, store/state definitions, API endpoints, type definitions, utility functions
+   - If found in codebase: record file path and definition location
+   - If found outside codebase (external API, separate repository, generated artifact): record the authoritative source and mark as "external dependency"
+   - If not found anywhere: mark as "requires new creation" in the Design Doc and reflect this in implementation order dependencies
+
+5. **Include in Design Doc**
    - Always include investigation results in "## Existing Codebase Analysis" section
    - Clearly document similar component search results (found components 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
 
 ### Integration Points【Important】

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

@@ -101,12 +101,20 @@ Must be performed before Design Doc creation:
      - Similar functionality is technical debt → Create ADR improvement proposal before implementation
      - No similar functionality → Proceed with new implementation
 
-4. **Include in Design Doc**
+4. **Dependency Existence Verification**
+   - For each dependency the design assumes already exists, search for its definition in the codebase using file pattern search and content search
+   - Typical targets include: interfaces, classes, repositories, service methods, API endpoints, DB tables/columns, configuration keys, enum values, type definitions
+   - If found in codebase: record file path and definition location
+   - If found outside codebase (external API, separate repository, generated artifact): record the authoritative source and mark as "external dependency"
+   - If not found anywhere: mark as "requires new creation" in the Design Doc and reflect this in implementation order dependencies
+
+5. **Include in Design Doc**
    - Always include investigation results in "## Existing Codebase Analysis" section
    - 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
 
-5. **Code Inspection Evidence**
+6. **Code Inspection Evidence**
    - Record all inspected files and key functions in "Code Inspection Evidence" section of Design Doc
    - Each entry must state relevance (similar functionality / integration point / pattern reference)
 

package/package.json

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