Implement

Token budget: Keep total trace reads under 5K tokens in dispatch context.

Pre-Flight Challenge

Before beginning work, address these operational feasibility questions:

1. Are all required environment variables configured for this feature?
2. Are external dependencies (APIs, services, databases) available and accessible?
3. Are infrastructure prerequisites (build tools, runtimes, packages) in place?
4. Is the execution environment ready (correct Node version, disk space, permissions)?

If any question cannot be answered from available context, surface it as a finding -- do not skip.

Purpose

Execute implementation from approved atomic specs with full traceability to requirements.

Key Input: Atomic specs from .codex/specs/groups/<spec-group-id>/atomic/

Usage

/implement <spec-group-id>                    # Implement all atomic specs in order
/implement <spec-group-id> <atomic-spec-id>   # Implement specific atomic spec
/implement <spec-group-id> --parallel         # Dispatch parallel implementers per atomic spec

Prerequisites

Before using this skill, verify:

1. Spec group exists at .codex/specs/groups/<spec-group-id>/
2. review_state is APPROVED in manifest.json
3. Atomic specs exist in atomic/ directory
4. Enforcement passed (orchestrator workflows only): When atomic_specs exists in manifest, verify atomic_specs.enforcement_status: "passing". For oneoff-spec workflows (no atomic specs), enforcement is not required — skip this check.
5. Open questions are resolved or explicitly deferred

If prerequisites not met → STOP and resolve before implementing.

Implementation Process

Step 0: Load Session Context

Check for existing session state to enable resuming mid-implementation:

# Check session checkpoint
cat .codex/context/session.json | jq '.phase_checkpoint'

If atomic_specs_pending has values, use those as the implementation queue instead of starting fresh. This enables cross-session recovery if implementation was interrupted.

{
  "phase_checkpoint": {
    "phase": "implementing",
    "atomic_specs_pending": ["as-003", "as-004"],
    "atomic_specs_complete": ["as-001", "as-002"],
    "last_completed": "as-002"
  }
}

If no checkpoint exists or phase is not implementing, proceed with full atomic spec list from Step 2.

Step 1: Load and Verify Spec Group

Read: .codex/specs/groups/<spec-group-id>/manifest.json
Read: .codex/specs/groups/<spec-group-id>/requirements.md
Read: .codex/specs/groups/<spec-group-id>/spec.md
List: .codex/specs/groups/<spec-group-id>/atomic/*.md

Verify in manifest.json:

• review_state is APPROVED
• If atomic_specs exists in manifest (orchestrator workflow): atomic_specs.enforcement_status is passing
• If atomic_specs is absent (oneoff-spec workflow): skip enforcement check
• No blocking open questions

Step 2: List Atomic Specs

.codex/specs/groups/<spec-group-id>/atomic/
├── as-001-logout-button-ui.md
├── as-002-token-clearing.md
├── as-003-post-logout-redirect.md
└── as-004-error-handling.md

Each atomic spec is independently implementable. Execute in order (as-001, as-002, etc.).

Step 3: Understand the Codebase

Before making changes, study existing patterns:

• File structure and naming conventions
• Error handling patterns
• Testing approaches

Step 4: Execute Atomic Specs in Order

For each atomic spec:

4a. Mark Atomic Spec as In Progress

Update atomic spec frontmatter: