Samaschke Codex Implementation Skills

Codex-compatible port of the implementation-skills workflow plugin. The plugin provides skills for shaping work, planning implementation slices, implementing tracker items, committing, opening PRs, reviewing, merging, delegating to local PI/Codex/Claude lanes, and applying long-horizon Codex work discipline.

Skill Families

• Workflow pipeline: prepare-work, plan-slices, implement-issues, requirements-checker, commit-and-push, pr-and-merge.
• Delegation lanes: dispatcher, codex-worker, use-pi, pi-delegate, use-claude.
• Codex discipline: codex-mindset, codex-long-horizon, codex-coding, codex-debugging, codex-research, codex-orchestration.
• Environment setup: configure-codex-roles installs and updates the workload-specific native Codex subagent roles in the user's Codex home.

Delivery lanes

implement-issues keeps tracker work items as the units of acceptance, claims, and closure, but forms compatible items into delivery lanes before launching workers. A lane owns one branch/worktree, implementation context, combined requirements check, adversarial review, and PR/merge. This lets a coherent slice be reviewed once as a whole while unrelated items remain isolated and can run in parallel. The shared grouping and review contract is plugins/implementation-skills/skills/implement-issues/references/delivery-lanes.md.

Use parallel_lanes: auto|N|off in project config to control concurrent lanes; the older parallel_issues key remains a compatibility alias. Review budgets and runtime verification apply per lane, while acceptance evidence remains per work item.

OpenAI Model Routing

The delegation skills route only to models the selected engine actually offers. Current defaults follow the GPT-5.6 family:

Model	Use it for	Typical effort
GPT-5.6 Luna	Bounded, cost-sensitive, high-volume work, focused audits, and localized one-component implementation	low/medium
GPT-5.6 Terra	Routine or multi-component implementation, repo analysis, contained debugging, and ordinary review	medium/high
GPT-5.6 Sol	Complex coding, architecture, adversarial review, ambiguity, security/concurrency/data work, and broad changes	high/xhigh
GPT-5.6 Sol at max	The hardest quality-first work or repeated failed attempts	max

gpt-5.5 remains a compatibility fallback when the appropriate GPT-5.6 tier is not offered. The skills re-dispatch and report the fallback instead of silently changing model or provider.

GPT-5.6 in Codex requires Codex CLI 0.144.0 or newer and account/workspace access. PI routes GPT models only through its openai-codex provider; check the exact local offer with pi --list-models.

Claude Model Routing

The strongest Claude CLI tier is pinned to claude-fable-5, Anthropic's fifth-generation successor to Opus 4.8. The plugin does not use the floating opus alias for that tier.

Install

Install directly from the Git repository:

codex plugin marketplace add https://git.samaschke.de/ksamaschke/implementation-skills-codex.git --ref main
codex plugin add implementation-skills@samaschke-codex-skills

From an existing local checkout, add the checkout root as a marketplace instead:

codex plugin marketplace add .
codex plugin add implementation-skills@samaschke-codex-skills

Configure Native Codex Roles

The plugin includes an optional configure-codex-roles skill. Ask Codex to "configure the recommended Codex subagent roles" after installation, or invoke the skill again after an update to reconcile the latest assignments. It manages only the six implementation-skills role names and their files under $CODEX_HOME/agents/ (~/.codex/agents/ by default), preserving unrelated Codex configuration.

The bundled script also supports deterministic provisioning:

python3 <skill-directory>/scripts/configure_roles.py apply \
  --codex-home "${CODEX_HOME:-$HOME/.codex}"

python3 <skill-directory>/scripts/configure_roles.py apply \
  --project /path/to/repo

Use status instead of apply for a read-only drift check, or remove to remove the managed role definitions. Without --project, the script manages user-level roles in ~/.codex; project mode writes the overriding role layer to <repo>/.codex/, which Codex loads for trusted projects. Start a new Codex session after applying or removing roles.

After Updating

Codex loads skills when a session or process starts. Existing chat sessions, codex exec resume, T3 dedicated harnesses, and long-lived worker pools can keep using an older cached skill after codex plugin add. After updating this plugin, start a fresh Codex session/process or restart the harness pool before expecting changed skill behavior such as implement-issues parallel N.

Quick probe:

codex exec --ephemeral -C . 'Do not edit files or run commands. Report the path for implementation-skills:implement-issues and whether it mentions parallel N.'

Validation

This repo does not vendor Codex's plugin and skill validator helpers. They are provided by the local Codex system skills under $CODEX_HOME/skills/.system (~/.codex/skills/.system by default). Use the repo wrapper so release checks do not depend on remembering those absolute paths:

scripts/validate-plugin.sh

Optional Session Backends

The skills work without extra terminal tooling, but long-running subagent workers are easier to supervise with a session backend.

• Recommended: herdr for API/CLI-driven agent sessions, panes, waits, reads, sends, and worktree-aware workflows.
• Unix fallback: tmux on macOS/Linux when Herdr is unavailable.
• Portable fallback: raw background process supervision with .out/.exit sentinel files.

On macOS or Linux with Homebrew:

brew install herdr
brew install tmux

The plugin does not install system packages during plugin installation. On the first relevant skill use, an agent should run the session backend doctor and ask before installing Herdr or tmux. Noninteractive runs fall back to raw sentinel supervision unless the project config requires a specific backend.

Configuration

Project configuration is read from:

• .codex/implementation-skills.md
• .codex/git-ops.md

The same configuration settings can also live in these shared paths for repos that are used by both Codex and Claude workflows:

• .claude/implement-issues.md
• .claude/git-ops.md

When both exist, .codex/* wins. Newly learned Codex settings are written to .codex/*.

Delegated model defaults can also be defined globally in ~/.codex/implementation-skills.md, with ~/.claude/implement-issues.md as the shared fallback when the Codex global file is absent. Only the lane map is inherited globally; repository settings such as gates, branches, and credentials remain project-local.

Delegated lane settings resolve leaf-by-leaf: an explicit prompt model wins, then the project config, then the global config, then built-in defaults. Persistent named-role settings resolve project > global > bundled defaults. This lets a project override one model without copying the entire global profile:

# $CODEX_HOME/models.yaml  (default ~/.codex)
implementer_moderate: gpt-5.6-terra
reviewer_default: opus            # cross-family from Codex's own main model
engine.pi.fast: gpt-5.6-luna
engine.pi.ordinary: gpt-5.6-terra
engine.pi.strong: gpt-5.6-sol
engine.codex.ordinary: gpt-5.6-terra
engine.claude.fast: haiku
engine.claude.ordinary: sonnet
engine.claude.strong: claude-fable-5
role.scout: gpt-5.6-luna
role.implementer: gpt-5.6-terra
role.architect: gpt-5.6-sol

# <repo>/.codex/models.yaml
engine.pi.ordinary: gpt-5.6-sol
engine.claude.ordinary: claude-fable-5
role.implementer: gpt-5.6-sol

The lane map is models.yaml — the same schema the Claude Code and Cursor variants read, so a lane means the same thing wherever you run it. Resolution, per key: <repo>/.codex/models.yaml > <repo>/models.yaml > $CODEX_HOME/models.yaml

built-in default, and harness.codex.<key> beats a bare <key> inside any file. The legacy markdown form (- model.role.<name>: <id> lines — note the model. prefix, which the legacy parser requires — in ~/.codex/implementation-skills.md or <repo>/.codex/implementation-skills.md, with .claude/implement-issues.md as fallback) is still read, one step weaker than the yaml in the same scope, so a migrating repo keeps working. Full contract: plugins/implementation-skills/skills/implement-issues/references/model-config.md.

Each engine lane supports fast, ordinary, strong, review, and fallback leaves. Configured identifiers are still checked against the lane's actual offer; unavailable choices and fallbacks are reported rather than silently substituted. local-codex is controlled by the active host session and cannot be changed by this plugin.

bin/isc

isc (implementation-skills config) resolves and validates the lane map, and materializes the native role profiles from it:

bin/isc show      # the resolved lane map, and which file each value came from
bin/isc doctor    # unknown keys, ids the CLI refuses, and the two invariants
bin/isc init      # write a starter .codex/models.yaml (--global for ~/.codex)
bin/isc models    # the model ids this harness accepts
bin/isc sync      # run configure-codex-roles to render config.toml + agents/

doctor enforces cross-family review — on this harness the implementer lanes are GPT, so an independent reviewer belongs on a Claude lane; the Claude Code variant has it the other way up, which is why the file is per-harness — and cheap lanes stay cheap. It rejects gpt-5.6 and gpt-5.6-codex outright, since ChatGPT-account auth refuses both.

sync is required because Codex resolves a native subagent's model from static config. Start a new session afterwards: an open one does not reload it.

Managed native roles add role.<name> leaves for scout, simple_coder, implementer, complex_worker, architect, and adversarial_reviewer. Run configure_roles.py apply to materialize global role profiles, or configure_roles.py apply --project <repo> to materialize a trusted project's leaf overrides while inheriting every unspecified global role model.

Project rules may live in AGENTS.md, CODEX.md, CLAUDE.md, or CONTRIBUTING.md.