codex-workflows 0.1.0 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/skills/coding-rules/SKILL.md +22 -4
- package/.agents/skills/coding-rules/references/security-checks.md +62 -0
- package/.agents/skills/documentation-criteria/references/design-template.md +7 -1
- package/.agents/skills/documentation-criteria/references/plan-template.md +1 -0
- package/.agents/skills/recipe-build/SKILL.md +10 -1
- package/.agents/skills/recipe-front-build/SKILL.md +11 -2
- package/.agents/skills/recipe-front-review/SKILL.md +54 -21
- package/.agents/skills/recipe-front-review/agents/openai.yaml +1 -1
- package/.agents/skills/recipe-fullstack-build/SKILL.md +10 -1
- package/.agents/skills/recipe-fullstack-implement/SKILL.md +9 -0
- package/.agents/skills/recipe-implement/SKILL.md +10 -1
- package/.agents/skills/recipe-review/SKILL.md +60 -26
- package/.agents/skills/recipe-review/agents/openai.yaml +1 -1
- package/.agents/skills/subagents-orchestration-guide/SKILL.md +40 -21
- package/.agents/skills/subagents-orchestration-guide/references/monorepo-flow.md +1 -1
- package/.agents/skills/task-analyzer/references/skills-index.yaml +1 -1
- package/.codex/agents/code-reviewer.toml +63 -125
- package/.codex/agents/requirement-analyzer.toml +27 -19
- package/.codex/agents/security-reviewer.toml +170 -0
- package/.codex/agents/task-executor-frontend.toml +5 -0
- package/.codex/agents/task-executor.toml +5 -0
- package/.codex/agents/work-planner.toml +36 -26
- package/LICENSE +21 -0
- package/README.md +6 -5
- package/package.json +1 -1
|
@@ -84,10 +84,28 @@ For language-specific rules, also read:
|
|
|
84
84
|
|
|
85
85
|
## Security
|
|
86
86
|
|
|
87
|
-
|
|
88
|
-
-
|
|
89
|
-
- Use parameterized queries for
|
|
90
|
-
-
|
|
87
|
+
### Secure Defaults
|
|
88
|
+
- Store credentials and secrets through environment variables or dedicated secret managers
|
|
89
|
+
- Use parameterized queries (prepared statements) for all database access
|
|
90
|
+
- Use established cryptographic libraries provided by the language or framework
|
|
91
|
+
- Generate security-critical values (tokens, IDs, nonces) with cryptographically secure random generators
|
|
92
|
+
- Encrypt sensitive data at rest and in transit using standard protocols
|
|
93
|
+
|
|
94
|
+
### Input and Output Boundaries
|
|
95
|
+
- Validate all external input at system entry points for expected format, type, and length
|
|
96
|
+
- Encode output appropriately for its rendering context (HTML, SQL, shell, URL)
|
|
97
|
+
- Return only information necessary for the caller in error responses; log detailed diagnostics server-side
|
|
98
|
+
|
|
99
|
+
### Access Control
|
|
100
|
+
- Apply authentication to all entry points that handle user data or trigger state changes
|
|
101
|
+
- Verify authorization for each resource access, not only at the entry point
|
|
102
|
+
- Grant only the permissions required for the operation (files, database connections, API scopes)
|
|
103
|
+
|
|
104
|
+
### Knowledge Cutoff Supplement (2026-03)
|
|
105
|
+
- OWASP Top 10:2025 shifted from symptoms to root causes; added "Software Supply Chain Failures" (A03) and "Mishandling of Exceptional Conditions" (A10)
|
|
106
|
+
- Recent research indicates AI-generated code shows elevated rates of access control gaps — treat authentication and authorization as high-priority review targets
|
|
107
|
+
- OpenSSF published "Security-Focused Guide for AI Code Assistant Instructions" — recommends language-specific, actionable constraints over generic advice
|
|
108
|
+
- For detailed detection patterns, see `references/security-checks.md`
|
|
91
109
|
|
|
92
110
|
## Version Control [MANDATORY]
|
|
93
111
|
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# Security Check Patterns
|
|
2
|
+
|
|
3
|
+
Last reviewed: 2026-03-21
|
|
4
|
+
|
|
5
|
+
## Stable Patterns
|
|
6
|
+
|
|
7
|
+
These patterns have low false-positive rates and are detectable through grep or static analysis.
|
|
8
|
+
|
|
9
|
+
### Hardcoded Secrets
|
|
10
|
+
- Credentials, API keys, or tokens assigned as string literals in source code
|
|
11
|
+
- Connection strings containing embedded passwords
|
|
12
|
+
- Private keys or certificates stored in source files
|
|
13
|
+
- Detection approach: search for high-entropy strings near assignment operators, common key names (`password`, `secret`, `api_key`, `token`, `private_key`), and platform-specific token formats
|
|
14
|
+
|
|
15
|
+
### SQL String Concatenation
|
|
16
|
+
- SQL statements constructed through string concatenation or interpolation with variables
|
|
17
|
+
- Detection approach: search for SQL keywords (`SELECT`, `INSERT`, `UPDATE`, `DELETE`) combined with string concatenation operators or template literals containing variable references
|
|
18
|
+
|
|
19
|
+
### Dynamic Code Execution
|
|
20
|
+
- Use of `eval()`, `Function()`, `exec()`, `compile()` with dynamic input
|
|
21
|
+
- Dynamic import or require with variable paths
|
|
22
|
+
- Detection approach: search for these function calls where the argument is not a static literal
|
|
23
|
+
|
|
24
|
+
### Insecure Deserialization
|
|
25
|
+
- `pickle.loads()`, `yaml.load()` without SafeLoader, `marshal.loads()` with untrusted input
|
|
26
|
+
- `JSON.parse()` followed by direct use in `eval()` or `Function()`
|
|
27
|
+
- Detection approach: search for deserialization calls that accept external input without safe loader configuration
|
|
28
|
+
|
|
29
|
+
### Path Traversal
|
|
30
|
+
- File system paths constructed from user-supplied input without sanitization
|
|
31
|
+
- Patterns where request parameters flow into file read/write operations
|
|
32
|
+
- Detection approach: search for file operations where path arguments include request parameters, query strings, or user input variables
|
|
33
|
+
|
|
34
|
+
### CORS Wildcard
|
|
35
|
+
- `Access-Control-Allow-Origin` set to `*` in production configuration
|
|
36
|
+
- CORS middleware configured with wildcard origin
|
|
37
|
+
- Detection approach: search for CORS configuration with wildcard values
|
|
38
|
+
|
|
39
|
+
### Non-TLS URLs
|
|
40
|
+
- HTTP (non-TLS) URLs embedded in source code for production endpoints (outside configuration files, tests, and documentation)
|
|
41
|
+
- Detection approach: search for `http://` patterns in source files, excluding localhost, configuration files, tests, and documentation
|
|
42
|
+
|
|
43
|
+
## Trend-Sensitive Patterns
|
|
44
|
+
|
|
45
|
+
Updated: 2026-03-21
|
|
46
|
+
Sources: OWASP Top 10:2025, DryRun Agentic Coding Security Report (2026-03)
|
|
47
|
+
|
|
48
|
+
### Access Control Gaps in AI-Generated Code
|
|
49
|
+
- Endpoints or route handlers defined without authentication middleware
|
|
50
|
+
- Resource access operations (read, update, delete) without authorization verification
|
|
51
|
+
- Administrative or destructive operations accessible without elevated permissions
|
|
52
|
+
- Recent research indicates this pattern appears at elevated rates in AI-generated code — treat as high-priority review target
|
|
53
|
+
|
|
54
|
+
### Mishandling of Exceptional Conditions (OWASP A10:2025)
|
|
55
|
+
- Error handlers that expose internal system details (stack traces, database errors, file paths) in responses
|
|
56
|
+
- Error handlers that fail open (grant access or skip validation on error)
|
|
57
|
+
- Missing error handling on security-critical operations (authentication, authorization, cryptographic operations)
|
|
58
|
+
|
|
59
|
+
### Software Supply Chain Patterns (OWASP A03:2025)
|
|
60
|
+
- Dependencies imported without version pinning
|
|
61
|
+
- Use of deprecated or unmaintained packages for security-critical functions
|
|
62
|
+
- Detection approach: check dependency manifests for unpinned versions and known deprecated packages
|
|
@@ -295,7 +295,13 @@ Automatically derive test cases from acceptance criteria:
|
|
|
295
295
|
|
|
296
296
|
## Security Considerations
|
|
297
297
|
|
|
298
|
-
|
|
298
|
+
Evaluate the following for this feature's trust boundaries and data flow:
|
|
299
|
+
|
|
300
|
+
- **Authentication & Authorization**: What authentication is required for new entry points? What authorization checks protect resource access?
|
|
301
|
+
- **Input Validation**: Where does external input enter the system? How is it validated before processing?
|
|
302
|
+
- **Sensitive Data Handling**: What data requires protection (encryption, masking, access control)? What data is safe to include in logs and error responses?
|
|
303
|
+
|
|
304
|
+
Mark items as N/A with brief rationale when the feature has no relevant trust boundary.
|
|
299
305
|
|
|
300
306
|
## Future Extensibility
|
|
301
307
|
|
|
@@ -92,6 +92,7 @@ Related Issue/PR: #XXX (if any)
|
|
|
92
92
|
|
|
93
93
|
#### Tasks
|
|
94
94
|
- [ ] Verify all Design Doc acceptance criteria achieved
|
|
95
|
+
- [ ] Security review: Verify security considerations from Design Doc are implemented
|
|
95
96
|
- [ ] Quality checks (types, lint, format)
|
|
96
97
|
- [ ] Execute all tests
|
|
97
98
|
- [ ] Coverage 70%+
|
|
@@ -75,7 +75,7 @@ For EACH task, YOU MUST:
|
|
|
75
75
|
2. **Spawn task-executor agent**: "Execute the task implementation for [task-file-path]"
|
|
76
76
|
3. **CHECK task-executor response**:
|
|
77
77
|
- `status: "escalation_needed"` or `"blocked"` -> STOP and escalate to user
|
|
78
|
-
- `
|
|
78
|
+
- `requiresTestReview` is `true` -> Spawn integration-test-reviewer agent: "Review integration tests in [test-files]"
|
|
79
79
|
- `needs_revision` -> Return to step 2 with `requiredFixes`
|
|
80
80
|
- `approved` -> Proceed to step 4
|
|
81
81
|
- `readyForQualityCheck: true` -> Proceed to step 4
|
|
@@ -98,6 +98,15 @@ ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued w
|
|
|
98
98
|
|
|
99
99
|
VERIFY approval status before proceeding. Once confirmed, INITIATE autonomous execution mode.
|
|
100
100
|
|
|
101
|
+
## Security Review (After All Tasks Complete)
|
|
102
|
+
|
|
103
|
+
After all task cycles finish, collect all `filesModified` from every task-executor response (deduplicated), then invoke security-reviewer before the completion report:
|
|
104
|
+
1. Spawn security-reviewer agent: "Design Doc: [path]. Implementation files: [collected filesModified list]. Review security compliance."
|
|
105
|
+
2. Check response:
|
|
106
|
+
- `approved` or `approved_with_notes` -> Proceed to completion report (include notes if present)
|
|
107
|
+
- `needs_revision` -> Spawn task-executor with `requiredFixes`, then quality-fixer, then re-invoke security-reviewer
|
|
108
|
+
- `blocked` -> Escalate to user
|
|
109
|
+
|
|
101
110
|
**[STOP — BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
|
|
102
111
|
**CANNOT proceed until user explicitly confirms the change scope.**
|
|
103
112
|
|
|
@@ -72,7 +72,7 @@ Verify generated task files exist in docs/plans/tasks/.
|
|
|
72
72
|
|
|
73
73
|
### Structured Response Specification
|
|
74
74
|
Each sub-agent responds in JSON format:
|
|
75
|
-
- **task-executor-frontend**: status, filesModified, testsAdded, readyForQualityCheck
|
|
75
|
+
- **task-executor-frontend**: status, filesModified, testsAdded, requiresTestReview, readyForQualityCheck
|
|
76
76
|
- **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
|
|
77
77
|
- **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
|
|
78
78
|
|
|
@@ -83,7 +83,7 @@ For EACH task, YOU MUST:
|
|
|
83
83
|
2. **Spawn task-executor-frontend agent**: "Task file: docs/plans/tasks/[filename].md Execute frontend implementation"
|
|
84
84
|
3. **CHECK task-executor-frontend response**:
|
|
85
85
|
- `status: "escalation_needed"` or `"blocked"` -> STOP and escalate to user
|
|
86
|
-
- `
|
|
86
|
+
- `requiresTestReview` is `true` -> Spawn integration-test-reviewer agent: "Review integration tests in [test-files]"
|
|
87
87
|
- `needs_revision` -> Return to step 2 with `requiredFixes`
|
|
88
88
|
- `approved` -> Proceed to step 4
|
|
89
89
|
- `readyForQualityCheck: true` -> Proceed to step 4
|
|
@@ -106,6 +106,15 @@ ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued w
|
|
|
106
106
|
|
|
107
107
|
VERIFY approval status before proceeding. Once confirmed, INITIATE autonomous execution mode.
|
|
108
108
|
|
|
109
|
+
## Security Review (After All Tasks Complete)
|
|
110
|
+
|
|
111
|
+
After all task cycles finish, collect all `filesModified` from every task-executor-frontend response (deduplicated), then invoke security-reviewer before the completion report:
|
|
112
|
+
1. Spawn security-reviewer agent: "Design Doc: [path]. Implementation files: [collected filesModified list]. Review security compliance."
|
|
113
|
+
2. Check response:
|
|
114
|
+
- `approved` or `approved_with_notes` -> Proceed to completion report (include notes if present)
|
|
115
|
+
- `needs_revision` -> Spawn task-executor-frontend with `requiredFixes`, then quality-fixer-frontend, then re-invoke security-reviewer
|
|
116
|
+
- `blocked` -> Escalate to user
|
|
117
|
+
|
|
109
118
|
**[STOP -- BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
|
|
110
119
|
**CANNOT proceed until user explicitly confirms the change scope.**
|
|
111
120
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: recipe-front-review
|
|
3
|
-
description: "Frontend Design Doc compliance validation with optional auto-fixes using React-specific quality checks."
|
|
3
|
+
description: "Frontend Design Doc compliance and security validation with optional auto-fixes using React-specific quality checks."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
**Context**: Post-implementation quality assurance for React/TypeScript frontend
|
|
@@ -14,10 +14,11 @@ description: "Frontend Design Doc compliance validation with optional auto-fixes
|
|
|
14
14
|
## Execution Method
|
|
15
15
|
|
|
16
16
|
- Compliance validation -> performed by code-reviewer
|
|
17
|
+
- Security validation -> performed by security-reviewer
|
|
17
18
|
- Rule analysis -> performed by rule-advisor
|
|
18
19
|
- Fix implementation -> performed by task-executor-frontend
|
|
19
20
|
- Quality checks -> performed by quality-fixer-frontend
|
|
20
|
-
- Re-validation -> performed by code-reviewer
|
|
21
|
+
- Re-validation -> performed by code-reviewer / security-reviewer
|
|
21
22
|
|
|
22
23
|
Orchestrator spawns agents and passes structured data between them.
|
|
23
24
|
|
|
@@ -32,22 +33,44 @@ Identify the Design Doc in docs/design/ and check implementation files changed f
|
|
|
32
33
|
**CANNOT proceed without both a Design Doc and implementation files.**
|
|
33
34
|
|
|
34
35
|
### 2. Execute code-reviewer
|
|
35
|
-
Spawn code-reviewer agent: "Validate Design Doc compliance for [design-doc-path].
|
|
36
|
+
Spawn code-reviewer agent: "Validate Design Doc compliance for [design-doc-path]. Implementation files: [git diff file list]. Review mode: full. Return structured JSON report with complianceRate, verdict, acceptanceCriteria, and qualityIssues."
|
|
36
37
|
|
|
37
|
-
|
|
38
|
+
**Store output as**: `$STEP_2_OUTPUT`
|
|
38
39
|
|
|
39
|
-
|
|
40
|
+
### 3. Execute security-reviewer
|
|
41
|
+
Spawn security-reviewer agent: "Design Doc: [path]. Implementation files: [file list from git diff in Step 1]. Review security compliance."
|
|
42
|
+
|
|
43
|
+
**Store output as**: `$STEP_3_OUTPUT` and `$STEP_1_FILES` (the initial file list)
|
|
44
|
+
|
|
45
|
+
### 4. Verdict and Response
|
|
46
|
+
|
|
47
|
+
**If security-reviewer returned `blocked`**: Stop immediately. Report the blocked finding and escalate to user. Do not proceed to fix steps.
|
|
48
|
+
|
|
49
|
+
**Code compliance criteria (considering project stage)**:
|
|
40
50
|
- Prototype: Pass at 70%+
|
|
41
51
|
- Production: 90%+ recommended
|
|
42
|
-
- Critical items (security, etc.): Required regardless of rate
|
|
43
52
|
|
|
44
|
-
**
|
|
53
|
+
**Security criteria**:
|
|
54
|
+
- `approved` or `approved_with_notes` -> Pass
|
|
55
|
+
- `needs_revision` -> Fail
|
|
56
|
+
|
|
57
|
+
**Report both results independently using subagent output fields only** (do not add fields that are not in the subagent response):
|
|
45
58
|
|
|
46
|
-
For low compliance (production <90%):
|
|
47
59
|
```
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
60
|
+
Code Compliance: [complianceRate from code-reviewer]
|
|
61
|
+
Verdict: [verdict from code-reviewer]
|
|
62
|
+
Acceptance Criteria:
|
|
63
|
+
- [fulfilled] [item]
|
|
64
|
+
- [partially_fulfilled] [item]: [gap] — [suggestion]
|
|
65
|
+
- [unfulfilled] [item]: [gap] — [suggestion]
|
|
66
|
+
|
|
67
|
+
Security Review: [status from security-reviewer]
|
|
68
|
+
Findings by category:
|
|
69
|
+
- [confirmed_risk] [location]: [description] — [rationale]
|
|
70
|
+
- [defense_gap] [location]: [description] — [rationale]
|
|
71
|
+
- [hardening] [location]: [description] — [rationale]
|
|
72
|
+
- [policy] [location]: [description] — [rationale]
|
|
73
|
+
Notes: [notes from security-reviewer, if present]
|
|
51
74
|
|
|
52
75
|
Execute fixes? (y/n):
|
|
53
76
|
```
|
|
@@ -55,24 +78,31 @@ Execute fixes? (y/n):
|
|
|
55
78
|
**[STOP -- BLOCKING]** Wait for user response on whether to execute fixes.
|
|
56
79
|
**CANNOT proceed with auto-fixes without user approval.**
|
|
57
80
|
|
|
81
|
+
If both pass and user selects `n`: Skip fix steps, proceed to Final Report.
|
|
82
|
+
|
|
58
83
|
If user selects `y`:
|
|
59
84
|
|
|
60
85
|
## Pre-fix Metacognition
|
|
61
|
-
**Required flow**: rule-advisor -> task registration -> task-executor-frontend -> quality-fixer-frontend
|
|
62
86
|
|
|
63
|
-
1. **Spawn rule-advisor agent**: "Analyze fixes needed
|
|
64
|
-
2. **Register tasks**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file -> `docs/plans/tasks/review-fixes-YYYYMMDD.md
|
|
87
|
+
1. **Spawn rule-advisor agent**: "Analyze fixes needed. Code issues: $STEP_2_OUTPUT. Security findings: $STEP_3_OUTPUT. Determine root solutions vs symptomatic treatments."
|
|
88
|
+
2. **Register tasks**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`. Include both code compliance issues and security requiredFixes.
|
|
65
89
|
3. **Spawn task-executor-frontend agent**: "Execute staged auto-fixes for [task-file-path]. Stop at 5 files."
|
|
66
90
|
4. **Spawn quality-fixer-frontend agent**: "Execute all frontend quality checks and confirm quality gate passage"
|
|
67
|
-
5. **Re-validate**: Spawn code-reviewer agent: "Re-validate compliance for [design-doc-path]. Measure improvement."
|
|
91
|
+
5. **Re-validate code-reviewer**: Spawn code-reviewer agent: "Re-validate compliance for [design-doc-path]. Prior issues: $STEP_2_OUTPUT. Measure improvement."
|
|
92
|
+
6. **Re-validate security-reviewer** (only if security fixes were applied): Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings: $STEP_3_OUTPUT. Design Doc: [path]. Implementation files: [union of $STEP_1_FILES and task-executor-frontend filesModified from step 3, deduplicated]."
|
|
68
93
|
|
|
69
94
|
ENFORCEMENT: Auto-fixes MUST go through quality-fixer-frontend before re-validation. Skipping quality checks invalidates fixes.
|
|
70
95
|
|
|
71
|
-
###
|
|
96
|
+
### Final Report
|
|
72
97
|
```
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
98
|
+
Code Compliance:
|
|
99
|
+
Initial: [X]%
|
|
100
|
+
Final: [Y]% (if fixes executed)
|
|
101
|
+
|
|
102
|
+
Security Review:
|
|
103
|
+
Initial: [status]
|
|
104
|
+
Final: [status] (if fixes executed)
|
|
105
|
+
Notes: [notes from approved_with_notes, if any]
|
|
76
106
|
|
|
77
107
|
Remaining issues:
|
|
78
108
|
- [items requiring manual intervention]
|
|
@@ -83,19 +113,22 @@ Remaining issues:
|
|
|
83
113
|
- Error handling additions
|
|
84
114
|
- Contract definition fixes
|
|
85
115
|
- Function splitting (length/complexity improvements)
|
|
116
|
+
- Security confirmed_risk and defense_gap fixes (input validation, auth checks, output encoding)
|
|
86
117
|
|
|
87
118
|
## Non-fixable Items
|
|
88
119
|
- Fundamental business logic changes
|
|
89
120
|
- Architecture-level modifications
|
|
90
121
|
- Design Doc deficiencies
|
|
122
|
+
- Committed secrets (blocked -> human intervention)
|
|
91
123
|
|
|
92
124
|
## Completion Criteria
|
|
93
125
|
|
|
94
126
|
- [ ] Design Doc compliance validated
|
|
127
|
+
- [ ] Security review completed
|
|
95
128
|
- [ ] Compliance percentage calculated
|
|
96
129
|
- [ ] User informed of results
|
|
97
130
|
- [ ] Fixes executed if requested and approved
|
|
98
131
|
- [ ] Quality gates passed for all fixes
|
|
99
|
-
- [ ] Final compliance re-measured
|
|
132
|
+
- [ ] Final compliance and security re-measured
|
|
100
133
|
|
|
101
|
-
**Scope**: Design Doc compliance validation and auto-fixes.
|
|
134
|
+
**Scope**: Design Doc compliance validation, security review, and auto-fixes.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
interface:
|
|
2
2
|
display_name: "recipe-front-review"
|
|
3
|
-
short_description: "Frontend Design Doc compliance with React-specific checks"
|
|
3
|
+
short_description: "Frontend Design Doc compliance and security validation with React-specific checks"
|
|
4
4
|
default_prompt: "Use $recipe-front-review to validate frontend: "
|
|
5
5
|
|
|
6
6
|
policy:
|
|
@@ -93,7 +93,7 @@ For EACH task, YOU MUST:
|
|
|
93
93
|
2. **Spawn task-executor or task-executor-frontend agent** (per routing table): "Execute the task implementation for [task-file-path]"
|
|
94
94
|
3. **CHECK executor response**:
|
|
95
95
|
- `status: "escalation_needed"` or `"blocked"` -> STOP and escalate to user
|
|
96
|
-
- `
|
|
96
|
+
- `requiresTestReview` is `true` -> Spawn integration-test-reviewer agent: "Review integration tests in [test-files]"
|
|
97
97
|
- `needs_revision` -> Return to step 2 with `requiredFixes`
|
|
98
98
|
- `approved` -> Proceed to step 4
|
|
99
99
|
- `readyForQualityCheck: true` -> Proceed to step 4
|
|
@@ -116,6 +116,15 @@ ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued w
|
|
|
116
116
|
|
|
117
117
|
VERIFY approval status before proceeding. Once confirmed, INITIATE autonomous execution mode.
|
|
118
118
|
|
|
119
|
+
## Security Review (After All Tasks Complete)
|
|
120
|
+
|
|
121
|
+
After all task cycles finish, collect all `filesModified` from every task-executor/task-executor-frontend response (deduplicated), then invoke security-reviewer before the completion report:
|
|
122
|
+
1. Spawn security-reviewer agent: "Design Doc: [path(s)]. Implementation files: [collected filesModified list]. Review security compliance."
|
|
123
|
+
2. Check response:
|
|
124
|
+
- `approved` or `approved_with_notes` -> Proceed to completion report (include notes if present)
|
|
125
|
+
- `needs_revision` -> Spawn layer-appropriate task-executor with `requiredFixes`, then quality-fixer, then re-invoke security-reviewer
|
|
126
|
+
- `blocked` -> Escalate to user
|
|
127
|
+
|
|
119
128
|
**[STOP -- BLOCKING]** Upon detecting ANY requirement changes, halt execution immediately.
|
|
120
129
|
**CANNOT proceed until user explicitly confirms the change scope.**
|
|
121
130
|
|
|
@@ -125,6 +125,15 @@ ENFORCEMENT: Sub-agent prompts missing the constraint suffix MUST be re-issued w
|
|
|
125
125
|
3. Quality-fixer MUST run after each executor (no skipping)
|
|
126
126
|
4. Commit MUST execute when quality-fixer returns `approved: true` (do not defer to end)
|
|
127
127
|
|
|
128
|
+
### Security Review (After All Tasks Complete)
|
|
129
|
+
|
|
130
|
+
After all task cycles finish, collect all `filesModified` from every task-executor/task-executor-frontend response (deduplicated), then invoke security-reviewer before the completion report:
|
|
131
|
+
1. Spawn security-reviewer agent: "Design Doc: [path(s)]. Implementation files: [collected filesModified list]. Review security compliance."
|
|
132
|
+
2. Check response:
|
|
133
|
+
- `approved` or `approved_with_notes` -> Proceed to completion report (include notes if present)
|
|
134
|
+
- `needs_revision` -> Spawn layer-appropriate task-executor with `requiredFixes`, then quality-fixer, then re-invoke security-reviewer
|
|
135
|
+
- `blocked` -> Escalate to user
|
|
136
|
+
|
|
128
137
|
### Test Information Communication
|
|
129
138
|
After acceptance-test-generator execution, when calling work-planner, communicate:
|
|
130
139
|
- Generated integration test file path
|
|
@@ -101,13 +101,22 @@ After user grants "batch approval for entire implementation phase", enter autono
|
|
|
101
101
|
1. Spawn task-executor (or task-executor-frontend) agent: "Implement task [task-file-path]"
|
|
102
102
|
2. Check task-executor response:
|
|
103
103
|
- `status: escalation_needed` or `blocked` -> Escalate to user
|
|
104
|
-
- `
|
|
104
|
+
- `requiresTestReview` is `true` -> Spawn integration-test-reviewer agent
|
|
105
105
|
- `needs_revision` -> Return to step 1 with `requiredFixes`
|
|
106
106
|
- `approved` -> Proceed to step 3
|
|
107
107
|
- Otherwise -> Proceed to step 3
|
|
108
108
|
3. Spawn quality-fixer (or quality-fixer-frontend) agent: "Quality check and fixes"
|
|
109
109
|
4. git commit -> Execute on `approved: true`
|
|
110
110
|
|
|
111
|
+
### Security Review (After All Tasks Complete)
|
|
112
|
+
|
|
113
|
+
After all task cycles finish, collect all `filesModified` from every executor response (task-executor and task-executor-frontend, deduplicated), then invoke security-reviewer before the completion report:
|
|
114
|
+
1. Spawn security-reviewer agent: "Design Doc: [path]. Implementation files: [collected filesModified list]. Review security compliance."
|
|
115
|
+
2. Check response:
|
|
116
|
+
- `approved` or `approved_with_notes` -> Proceed to completion report (include notes if present)
|
|
117
|
+
- `needs_revision` -> Spawn layer-appropriate executor (task-executor or task-executor-frontend per task filename routing) with `requiredFixes`, then layer-appropriate quality-fixer, then re-invoke security-reviewer
|
|
118
|
+
- `blocked` -> Escalate to user
|
|
119
|
+
|
|
111
120
|
### Test Information Communication
|
|
112
121
|
After acceptance-test-generator execution, when spawning work-planner, communicate:
|
|
113
122
|
- Generated integration test file path
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: recipe-review
|
|
3
|
-
description: "Design Doc compliance validation with optional auto-fixes."
|
|
3
|
+
description: "Design Doc compliance and security validation with optional auto-fixes."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
## Required Skills [LOAD BEFORE EXECUTION]
|
|
@@ -15,14 +15,15 @@ description: "Design Doc compliance validation with optional auto-fixes."
|
|
|
15
15
|
|
|
16
16
|
**Core Identity**: "I am not a worker. I am an orchestrator."
|
|
17
17
|
|
|
18
|
-
**First Action**: Register Steps 1-
|
|
18
|
+
**First Action**: Register Steps 1-11 before any execution.
|
|
19
19
|
|
|
20
20
|
## Execution Method
|
|
21
21
|
|
|
22
22
|
- Compliance validation -> Spawn code-reviewer agent
|
|
23
|
+
- Security validation -> Spawn security-reviewer agent
|
|
23
24
|
- Fix implementation -> Spawn task-executor agent
|
|
24
25
|
- Quality checks -> Spawn quality-fixer agent
|
|
25
|
-
- Re-validation -> Spawn code-reviewer
|
|
26
|
+
- Re-validation -> Spawn code-reviewer / security-reviewer agents
|
|
26
27
|
|
|
27
28
|
Orchestrator spawns sub-agents and passes structured data between them.
|
|
28
29
|
|
|
@@ -34,59 +35,89 @@ Design Doc (uses most recent if omitted): $ARGUMENTS
|
|
|
34
35
|
Identify Design Doc in docs/design/ and check implementation files via git diff.
|
|
35
36
|
|
|
36
37
|
### Step 2: Execute code-reviewer
|
|
37
|
-
Spawn code-reviewer agent: "Validate Design Doc compliance for the implementation.
|
|
38
|
+
Spawn code-reviewer agent: "Validate Design Doc compliance for the implementation. Design Doc path: [path]. Implementation files: [git diff file list]. Review mode: full. Return structured JSON report with complianceRate, verdict, acceptanceCriteria, and qualityIssues."
|
|
38
39
|
|
|
39
40
|
**Store output as**: `$STEP_2_OUTPUT`
|
|
40
41
|
|
|
41
|
-
### Step 3:
|
|
42
|
+
### Step 3: Execute security-reviewer
|
|
43
|
+
Spawn security-reviewer agent: "Design Doc: [path]. Implementation files: [file list from git diff in Step 1]. Review security compliance."
|
|
42
44
|
|
|
43
|
-
**
|
|
45
|
+
**Store output as**: `$STEP_3_OUTPUT` and `$STEP_1_FILES` (the initial file list)
|
|
46
|
+
|
|
47
|
+
### Step 4: Verdict and Response
|
|
48
|
+
|
|
49
|
+
**If security-reviewer returned `blocked`**: Stop immediately. Report the blocked finding and escalate to user. Do not proceed to fix steps.
|
|
50
|
+
|
|
51
|
+
**Code compliance criteria (considering project stage)**:
|
|
44
52
|
- Prototype: Pass at 70%+
|
|
45
53
|
- Production: 90%+ REQUIRED
|
|
46
|
-
- Critical items (security, etc.): REQUIRED regardless of rate
|
|
47
54
|
|
|
48
|
-
**
|
|
55
|
+
**Security criteria**:
|
|
56
|
+
- `approved` or `approved_with_notes` -> Pass
|
|
57
|
+
- `needs_revision` -> Fail
|
|
58
|
+
|
|
59
|
+
**Report both results independently using subagent output fields only** (do not add fields that are not in the subagent response):
|
|
49
60
|
|
|
50
|
-
For low compliance (production <90%):
|
|
51
61
|
```
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
62
|
+
Code Compliance: [complianceRate from code-reviewer]
|
|
63
|
+
Verdict: [verdict from code-reviewer]
|
|
64
|
+
Acceptance Criteria:
|
|
65
|
+
- [fulfilled] [item]
|
|
66
|
+
- [partially_fulfilled] [item]: [gap] — [suggestion]
|
|
67
|
+
- [unfulfilled] [item]: [gap] — [suggestion]
|
|
68
|
+
|
|
69
|
+
Security Review: [status from security-reviewer]
|
|
70
|
+
Findings by category:
|
|
71
|
+
- [confirmed_risk] [location]: [description] — [rationale]
|
|
72
|
+
- [defense_gap] [location]: [description] — [rationale]
|
|
73
|
+
- [hardening] [location]: [description] — [rationale]
|
|
74
|
+
- [policy] [location]: [description] — [rationale]
|
|
75
|
+
Notes: [notes from security-reviewer, if present]
|
|
55
76
|
|
|
56
77
|
Execute fixes? (y/n):
|
|
57
78
|
```
|
|
58
79
|
|
|
59
|
-
**[STOP — BLOCKING]** Present
|
|
80
|
+
**[STOP — BLOCKING]** Present results to user for confirmation.
|
|
60
81
|
**CANNOT proceed until user explicitly confirms.**
|
|
61
82
|
|
|
62
|
-
|
|
83
|
+
If both pass and user selects `n`: Skip Steps 5-10, proceed to Step 11.
|
|
63
84
|
|
|
64
|
-
|
|
85
|
+
### Step 5: Prepare Fix Context
|
|
65
86
|
|
|
66
87
|
Reference documentation-criteria skill for task file template.
|
|
67
88
|
|
|
68
|
-
### Step
|
|
89
|
+
### Step 6: Create Task File
|
|
69
90
|
|
|
70
91
|
Create task file at `docs/plans/tasks/review-fixes-YYYYMMDD.md`
|
|
92
|
+
Include both code compliance issues and security requiredFixes.
|
|
71
93
|
|
|
72
|
-
### Step
|
|
94
|
+
### Step 7: Execute Fixes
|
|
73
95
|
|
|
74
96
|
Spawn task-executor agent: "Execute review fixes. Task file: docs/plans/tasks/review-fixes-YYYYMMDD.md. Apply staged fixes (stops at 5 files)."
|
|
75
97
|
|
|
76
|
-
### Step
|
|
98
|
+
### Step 8: Quality Check
|
|
77
99
|
|
|
78
100
|
Spawn quality-fixer agent: "Confirm quality gate passage for fixed files."
|
|
79
101
|
|
|
80
|
-
### Step
|
|
102
|
+
### Step 9: Re-validate code-reviewer
|
|
81
103
|
|
|
82
104
|
Spawn code-reviewer agent: "Re-validate Design Doc compliance after fixes. Prior compliance issues: $STEP_2_OUTPUT. Verify each prior issue is resolved."
|
|
83
105
|
|
|
84
|
-
### Step
|
|
106
|
+
### Step 10: Re-validate security-reviewer (only if security fixes were applied)
|
|
107
|
+
|
|
108
|
+
Spawn security-reviewer agent: "Re-validate security after fixes. Prior findings: $STEP_3_OUTPUT. Design Doc: [path]. Implementation files: [union of $STEP_1_FILES and task-executor filesModified from Step 7, deduplicated]."
|
|
109
|
+
|
|
110
|
+
### Step 11: Final Report
|
|
85
111
|
|
|
86
112
|
```
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
113
|
+
Code Compliance:
|
|
114
|
+
Initial: [X]%
|
|
115
|
+
Final: [Y]% (if fixes executed)
|
|
116
|
+
|
|
117
|
+
Security Review:
|
|
118
|
+
Initial: [status]
|
|
119
|
+
Final: [status] (if fixes executed)
|
|
120
|
+
Notes: [notes from approved_with_notes, if any]
|
|
90
121
|
|
|
91
122
|
Remaining issues:
|
|
92
123
|
- [items requiring manual intervention]
|
|
@@ -97,19 +128,22 @@ Remaining issues:
|
|
|
97
128
|
- Error handling additions
|
|
98
129
|
- Contract definition fixes
|
|
99
130
|
- Function splitting (length/complexity improvements)
|
|
131
|
+
- Security confirmed_risk and defense_gap fixes (input validation, auth checks, output encoding)
|
|
100
132
|
|
|
101
133
|
## Non-fixable Items
|
|
102
134
|
- Fundamental business logic changes
|
|
103
135
|
- Architecture-level modifications
|
|
104
136
|
- Design Doc deficiencies
|
|
137
|
+
- Committed secrets (blocked -> human intervention)
|
|
105
138
|
|
|
106
139
|
## Completion Criteria
|
|
107
140
|
|
|
108
141
|
- [ ] Design Doc identified and implementation files checked
|
|
109
142
|
- [ ] code-reviewer spawned and compliance validated
|
|
110
|
-
- [ ]
|
|
143
|
+
- [ ] security-reviewer spawned and security reviewed
|
|
144
|
+
- [ ] Results presented to user
|
|
111
145
|
- [ ] Fixes executed if user approved (with quality-fixer gate)
|
|
112
|
-
- [ ] Re-validation completed after fixes
|
|
146
|
+
- [ ] Re-validation completed after fixes (both code and security)
|
|
113
147
|
- [ ] Final report presented to user
|
|
114
148
|
|
|
115
|
-
**Scope**: Design Doc compliance validation and auto-fixes.
|
|
149
|
+
**Scope**: Design Doc compliance validation, security review, and auto-fixes.
|