RELEASEv0.3.0

WIGTN Plugin v2: Codex

A second plugin, for Codex rather than Claude Code. Nine skills, of which eight open on their own and one has to be named, so an ordinary coding request cannot grow into the full delivery pipeline by accident.

2026.07.28 2 min read WIGTN

WIGTN Plugin v2 is a Codex plugin, and v0.3.0 landed on 28 July 2026. It is not the Claude Code plugin ported across: that one puts a fixed team of agents in front of the model, and this one hands Codex nine skills and stays out of the way until a request matches one of them.

What it does

The rule that shapes it is which skills are allowed to start themselves. Eight are selected automatically when a request matches what they do. The ninth, verified-delivery, runs only when it is named, because it is the one that opens the whole implement-and-verify loop and an ordinary bug fix should not fall into it.

So the day-to-day behaviour is that nothing happens. Ask for a fix and Codex fixes it. The skills open on the work that repeats across products: writing a PRD, turning it into screens, planning the tasks, checking the requirements against executed tests, and getting a branch to the point where it can be pushed.

Get it

Two lines, verbatim from the v0.3.0 README:

  • codex plugin marketplace add wigtn/wigtn-plugins-codex
  • codex plugin add wigtn-plugins-with-codex@wigtn

After that there is nothing to memorise: the skills are chosen from plain requests. Naming one explicitly is $wigtn-plugins-with-codex:<skill>, which is also how verified-delivery is invoked, since it will not start any other way.

What shipped

Nothing here compiles. The plugin is skill definitions, JSON schemas and one Python script that reads and writes a project's WorkGraph state file.

  • Nine skills at v0.3.0, from the repository tree and matching the README's table: product-spec, screen-spec, work-planner, verified-delivery, acceptance-verifier, design-direction, release-readiness, handdrawn-diagram and wigtn-presentation. That is an inventory of what is in the box, not a claim about what comes out of it.
  • The state contract that v0.3.0 is named for: requirement, artifact, task, check and release gate are linked, and a change to a source hash marks everything downstream of it stale. A task cannot reach verified without a passing check behind it.
  • Release authority is separated from the rest. Reviewing, committing, pushing and opening a PR are distinct permissions, and none of them is taken without being asked for.
  • Apache 2.0.
  • Not included: any claim that this makes ordinary coding faster. The README lists that one as contradicted by its own fixtures, and the report is where the evaluation is set out.

Read the report

Why the harness got smaller instead of larger is the second part of the Codex tech report: what the evaluation on two SWE-bench Verified tasks actually showed, what it cost, and what the result does not cover. The release history and every skill definition are in the repository. Both are linked at the top of this page.

Working on something like this? Let's talk.

Talk to us
More from Research