Consult Codex for architectural decisions. Use when: (1) introducing patterns not in codebase, (2) 3+ design options exist, (3) performance-critical implementation, (4) major refactoring...
Design-phase Codex consultation: Consult with Codex before making complex design decisions. Get expert validation, alternative approaches, and risk assessment early in the development process.
Claude Code analyzes the design problem:
- Current situation and constraints
- Requirements (functional and non-functional)
- Existing codebase patterns
- Performance/security requirements
- Team expertise and maintenance considerations
Claude Code proposes 2-3 viable approaches:
## Option 1: [Approach Name]
**Pros:**
- [Advantage 1]
- [Advantage 2]
**Cons:**
- [Drawback 1]
- [Drawback 2]
**Implementation Complexity:** Low/Medium/High
**Maintenance Cost:** Low/Medium/High
**Performance Impact:** Low/Medium/High
## Option 2: [Approach Name]
...
## Option 3: [Approach Name]
...
Execute Codex in read-only sandbox for design review.
Invariants — see codex-review/SKILL.md Step 2 for full rationale:
< /dev/null—codex execprobes stdin even when prompt is passed as an argument; inherited open pipes from Claude Code's Bash will hang the call indefinitely.- Portable timeout — macOS has no
timeoutby default; use the TIMEOUT_CMD fallback chain.--ephemeral— avoids session-file contention in parallel runs.
# Portable timeout (gtimeout → timeout → perl alarm → none).
if command -v gtimeout >/dev/null 2>&1; then
TIMEOUT_CMD=(gtimeout 1200)
elif command -v timeout >/dev/null 2>&1; then
TIMEOUT_CMD=(timeout 1200)
elif command -v perl >/dev/null 2>&1; then
TIMEOUT_CMD=(perl -e 'my $t=shift; my $pid=fork; if(!defined $pid){die "fork: $!"} if($pid==0){exec @ARGV; exit 127} $SIG{ALRM}=sub{kill "TERM",$pid; sleep 2; kill "KILL",$pid; exit 124}; alarm $t; waitpid $pid,0; my $st=$?; exit($st & 127 ? 128 + ($st & 127) : $st >> 8)' 1200)
else
TIMEOUT_CMD=()
fi
"${TIMEOUT_CMD[@]}" codex exec --model gpt-5.6-terra --sandbox read-only --ephemeral "$(cat <<'EOF'
# Design Consultation Request
All string fields (reasoning, risks, recommendations, guidance) must be in Japanese.
## Context
[Project overview and current situation]
## Problem Statement
[Detailed description of the problem to solve]
## Constraints
- Performance: [Performance requirements]
- Security: [Security requirements]
- Scalability: [Scalability requirements]
- Maintainability: [Maintainability requirements]
- Team: [Team skillset]
- Timeline: [Schedule constraints]
## Proposed Design Options
### Option 1: [Approach name]
[Detailed description]
**Pros:**
- [Advantage 1]
- [Advantage 2]
**Cons:**
- [Drawback 1]
- [Drawback 2]
### Option 2: [Approach name]
[Detailed description]
...
### Option 3: [Approach name]
[Detailed description]
...
## Existing Codebase Patterns
[Patterns used in existing codebase]
## Questions for Codex
1. Validity assessment for each approach
2. Overlooked potential issues
3. Recommended approach and reasoning
4. Implementation considerations
5. Success/failure cases from similar projects
## Required Output Format (JSON, values in Japanese)
{
"recommended_option": "Option 1|Option 2|Option 3|Alternative",
"reasoning": "Detailed reasoning for recommendation (Japanese)",
"risk_assessment": {
"option_1": {
"technical_risks": ["Risk 1", "Risk 2"],
"mitigation": ["Mitigation 1", "Mitigation 2"]
},
"option_2": { ... },
"option_3": { ... }
},
"additional_considerations": [
{
"category": "performance|security|maintainability|scalability",
"point": "Consideration point (Japanese)",
"importance": "critical|high|medium|low"
}
],
"alternative_approach": {
"description": "Alternative approach description (if better than Options 1-3)",
"why_better": "Why this is better"
},
"implementation_guidance": [
"Implementation guidance 1",
"Implementation guidance 2"
],
"similar_patterns": [
{
"project": "Similar project name",
"approach": "Adopted approach",
"outcome": "Result (success/failure and reasons)"
}
],
"confidence": "high|medium|low",
"caveats": ["Caveat 1", "Caveat 2"]
}
EOF
)" < /dev/null
Claude Code analyzes Codex's response:
All user-facing output must be in Japanese.
Present comprehensive analysis to user for final decision:
## Design Consultation Result: [Problem Title]
### Problem Summary
[Brief description of the problem]
### Proposed Design Options
1. **Option 1**: [Summary]
2. **Option 2**: [Summary]
3. **Option 3**: [Summary]
### Codex Recommendation
- **Recommended approach**: Option 2
- **Confidence**: High
- **Reasoning**:
[Codex reasoning explained]
### Risk Assessment
#### Option 1: [Name]
- **Technical risks**:
- [Risk 1]
- [Risk 2]
- **Mitigations**:
- [Mitigation 1]
- [Mitigation 2]
#### Option 2: [Name] (recommended)
- **Technical risks**:
- [Risk 1]
- **Mitigations**:
- [Mitigation 1]
#### Option 3: [Name]
- **Technical risks**:
- [Risk 1]
- [Risk 2]
- **Mitigations**:
- [Mitigation 1]
### Additional Considerations
#### Critical
- [Critical consideration 1]
#### High
- [High priority consideration 1]
- [High priority consideration 2]
#### Medium
- [Medium priority consideration 1]
### Alternative Approach (Codex proposal)
[Alternative proposed by Codex, if any]
**Why better**: [Reasoning]
### Implementation Guidance
1. [Implementation note 1]
2. [Implementation note 2]
3. [Implementation note 3]
### Similar Project Examples
- **Project**: [Name]
- **Approach**: [Adopted method]
- **Result**: [Success/failure reasons]
### Caveats
- [Caveat 1]
- [Caveat 2]
### Claude Code Observations
[Project-specific insights considering Codex recommendation]
Which approach should we proceed with? Or investigate further?
## Problem
Database design for new multi-tenant feature
## Options
1. Single database with tenant_id column
2. Database per tenant
3. Schema per tenant (PostgreSQL)
[Codex consultation...]
## Codex Recommendation
Option 3 (Schema per tenant) for this scale
- Reasoning: Balance of isolation and management
- Risk: Schema migration complexity
- Mitigation: Use migration tool like Flyway
## Problem
API design for new microservice communication
## Options
1. REST with JSON
2. gRPC
3. GraphQL
[Codex consultation...]
## Codex Recommendation
Option 2 (gRPC) for internal services
- Reasoning: Type safety, performance, streaming support
- Risk: Steeper learning curve
- Mitigation: Start with simple unary calls, add streaming later
## Problem
State management for React application
## Options
1. Redux Toolkit
2. Zustand
3. Jotai
[Codex consultation...]
## Codex Recommendation
Option 2 (Zustand) for this project size
- Reasoning: Simplicity, less boilerplate, sufficient for current needs
- Risk: Might need migration if app grows significantly
- Mitigation: Keep state logic modular for easier migration
| Parameter | Default | Description |
|---|---|---|
| timeout_minutes | 10 | Codex consultation timeout |
| min_options | 2 | Minimum design options to present |
| max_options | 4 | Maximum design options to present |
| require_risk_assessment | true | Require risk analysis for each option |
| include_examples | true | Include similar project examples |
Consultation is successful when: