codex-architect
Codex Architect Skill (Third Brain)
Trigger
- Keywords: architecture design, solution evaluation, tech selection, third brain, Codex advice, design consulting, ask Codex, second opinion
When NOT to Use
- Code implementation (use /codex-implement)
- Code review (use /codex-review)
- Deep discussion/exhaustive exploration (use /codex-brainstorm)
Usage
/codex-architect "<question>"
/codex-architect "Evaluate this design" --context src/xxx.ts --mode review
/codex-architect "Redis vs MongoDB?" --mode compare
Modes
| Mode | Purpose | When |
|---|---|---|
| design | Provide design advice | Starting from scratch (default) |
| review | Evaluate existing design | Validate solution, find issues |
| compare | Compare multiple options | Tech selection |
Core Principle
User -> Claude -> Codex -> Integrate
| | |
Initial thinking Third perspective Combined advice
Codex Prompt Template
When using mcp__codex__codex, must include the following:
mcp__codex__codex({
prompt: `You are a senior architect. Please provide architecture advice for the following question.
## Question
${QUESTION}
## Mode
${MODE} (design/review/compare)
## IMPORTANT: You must independently research the project
Before providing architecture advice, you **must** perform the following research:
### Research Steps
1. Understand project structure: \`ls src/\`, \`ls src/service/\`, \`ls src/provider/\`
2. Search related modules: \`grep -r "keyword" src/ --include="*.ts" -l | head -10\`
3. Read existing implementations: \`cat <relevant files> | head -150\`
4. Understand existing architecture patterns and conventions
### Verification Focus
- What does the existing architecture look like?
- What are the existing code style and patterns?
- What similar features can be referenced?
## Output Requirements
1. First describe which files you researched
2. Provide advice based on current project state
3. Consider consistency with existing architecture
...(other review dimensions)`,
sandbox: 'read-only',
'approval-policy': 'never',
});
Workflow Integration
/codex-architect -> /tech-spec -> /review-spec -> /codex-implement -> /codex-review-fast
Design Plan Review Implement Code Review
Verification
- Report includes Codex advice + Claude perspective
- Consensus and divergence points clearly marked
- Final recommendation integrates both perspectives
References
references/project-knowledge.md- Project architecture knowledge + report template
Examples
Input: /codex-architect "How to design a high-concurrency cache?"
Action: Codex analysis -> Claude supplement -> Integrated output
Input: /codex-architect "Any issues with this API design?" --mode review
Action: Codex evaluation -> Claude verification -> Output issues + recommendations
More from sd0xdev/sd0x-dev-flow
statusline-config
Customize Claude Code statusline. Use when: user says 'statusline', 'status line', 'customize statusline', 'modify statusline', 'statusline settings', 'statusline theme', 'change theme', 'color scheme', wants to add/remove/change segments (cost, git, model, context), switch color themes (catppuccin, dracula, nord), or asks what can be shown in the statusline.
52tech-spec
Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.
45codex-brainstorm
Adversarial brainstorming via Claude+Codex debate. Use when: exploring solutions, feasibility analysis, exhaustive enumeration. Not for: implementation (use feature-dev), architecture only (use codex-architect). Output: Nash equilibrium consensus + action items.
7security-review
Security review via Codex MCP. Use when: OWASP Top 10 audit, dependency vulnerability check, security-sensitive changes. Not for: code review (use codex-code-review), test review (use test-review). Output: security findings + audit report.
7test-review
Test coverage review via Codex MCP. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
7post-dev-test
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
6