Codex Architect

---
name: codex-architect
description: "Codex architecture consulting. Use when: designing features, evaluating architecture, getting second opinion on design. Not for: implementation (use codex-implement), code review (use codex-code-review). Output: architecture advice + design recommendations."
allowed-tools: Read, Grep, Glob, Agent, Bash(node:*), Write
---

# 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

```bash
/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 dispatching per `@skills/codex-code-review/references/codex-transport.md` § Start, the prompt must include the following:

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 the project structure by discovering it: `ls` at the repository root, then list the directories it actually shows — do not assume a `src/` or `test/unit/` layout; many repositories, this one included, have neither
2. Search related modules: `grep -rn "keyword" . -l | head -10` — rooted at the repository, or at a directory the discovery step above actually surfaced; never at an assumed `src/`
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)


## 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
```