Three review outcomes: draft generated, missing input blocked, and a stop-before-deploy rule added to the generated instruction.
Demo overview: nine-field contract, seven-section review output, defined failure states, 14-case evaluation, and judge quick test.

Codex BriefGuard

Project tagline: Turn feature briefs into validated, review-ready Codex instructions—without guessing or auto-running changes.

Short description: Codex BriefGuard is a review-first Codex plugin that checks a feature brief for defined completeness, consistency, and approval risks before producing an implementation instruction for human review.

Track: Developer Tools

Repository: https://github.com/Korea-uni/Codex-BriefGuard

Codex BriefGuard turns explicit feature requirements into structured implementation instructions for human review. It checks the brief before generating the instruction and never executes the generated result automatically.

Inspiration

I originally wanted to build a broad automation tool, but the project changed when I realized that unclear instructions were a bigger problem than slow execution.

An incomplete instruction could make Codex confidently work on the wrong task. A feature request may omit an important mapping, mix included and excluded scope, lack a clear completion condition, or hide a production deployment inside an ordinary-looking request.

That led me to narrow the project to one focused workflow: check whether a feature brief is complete and consistent, then turn it into a structured Codex instruction without guessing missing information or automatically executing the result.

I built Codex BriefGuard to make the handoff between a person and Codex explicit, reviewable, and human-controlled.

What it does

Codex BriefGuard requires nine input fields:

task_name
goal
current_state
context
in_scope
out_of_scope
constraints
done_when
verification

The tool checks the brief for:

missing, empty, unresolved, or unknown information;
goals that ask Codex to generate another prompt instead of implementing the requested feature;
conflicts between included and excluded scope;
explicit required and forbidden conflicts;
requests that try to make the generator execute or modify work directly;
recognizable sensitive-value patterns; and
deployment, production, external-network, or destructive actions that require approval.

A successful brief always produces the same seven-section Markdown review package:

Status
Task Summary
Confirmed Assumptions
Missing Information
Final Codex Instruction
Review Checklist
Risks and Approval-Required Work

Codex BriefGuard uses clear result states:

READY_FOR_REVIEW: a final instruction is generated for human review.
MISSING_INPUT: required information is missing, so no final instruction is generated.
CONFLICT: contradictory requirements are detected and generation is blocked.
OUT_OF_SCOPE: the request attempts to make the workflow execute side effects.
SECRET_BLOCKED: a recognizable sensitive value is detected and is not repeated.
APPROVAL_REQUIRED: a review draft may be generated, but it must stop before the real high-impact operation.

Generated instructions are never automatically executed, queued, deployed, or sent back to Codex.

Demo flow

The demonstration covers three representative cases:

Input	Result	Final instruction
Complete and consistent feature brief	`READY_FOR_REVIEW`	Generated for human review
Required information is missing	`MISSING_INPUT`	Not generated
Production deployment is requested	`APPROVAL_REQUIRED`	Generated with a stop-and-approve gate

The user reads the generated Markdown review and separately decides whether to give the instruction to Codex.

How I built it

I packaged Codex BriefGuard as a local Codex plugin containing one focused skill and a deterministic Python validation layer.

The repository includes:

a SKILL.md that defines the review-only workflow;
a separate input contract defining the nine required fields;
a separate output contract defining statuses and output structure;
a Markdown template for consistent results;
a Python validator that classifies and renders each brief;
a JSON evaluation corpus;
stored acceptance artifacts;
a one-command evaluation runner; and
a three-scenario judge demonstration.

The validator and evaluation pipeline use only the Python 3 standard library. The judge path requires no third-party packages, credentials, API key, or network connection.

JSON is used for structured feature briefs and evaluation fixtures. Markdown is used for the contracts, generated reviews, acceptance records, and judge documentation.

The generated instruction remains a review artifact. Codex BriefGuard does not implement the instruction or control an external deployment system.

How I used Codex and GPT-5.6

I built and refined Codex BriefGuard in OpenAI Codex during the Build Week submission period, using GPT-5.6 Sol for tool-assisted development.

Codex helped accelerate:

repository inspection;
translating the input and output contracts into Python code;
generating synthetic evaluation cases;
running regression checks;
comparing the documented contracts with generated results;
reviewing failure behavior;
packaging the local Codex plugin; and
preparing the reproducible judge path.

I made the main product and engineering decisions:

reduce the project to one focused workflow;
require all nine input fields;
prohibit the invention of missing facts, paths, or technology stacks;
fail closed for defined missing, conflicting, out-of-scope, and sensitive inputs;
separate instruction generation from execution;
require visible approval stops before high-impact actions; and
keep human review mandatory.

The shipped validator does not call the OpenAI API at runtime. Codex and GPT-5.6 contributed to building and refining the project, while the final judge test is local and deterministic.

Challenges I faced

The hardest challenge was defining deterministic boundaries for natural-language requirements without pretending that the validator understands every possible meaning.

The first acceptance review found several problems that the original structural checks had missed:

deployment approval risk was also appearing as missing information;
some examples asked Codex to generate another prompt instead of describing the intended feature;
the generated checklist did not always match its documented contract; and
conflict detection normalized text more broadly than the specification allowed.

I corrected each issue and added a regression check or boundary test to prevent it from returning.

Another challenge was deciding where automation should stop. It would have been easy to connect the generated instruction directly to another execution step, but that would remove the most important human decision. I therefore kept generation and execution separate and made approval-required work stop visibly before the real operation.

The project also documents its limitations. Exact conflict checks and pattern-based sensitive-value detection cannot detect every semantic contradiction or every possible secret. They support human review rather than replacing it.

Accomplishments

Codex BriefGuard v0.1.2 passed its technical acceptance checks.

Evidence	Result
Synthetic workflow evaluations	14/14 PASS
Normal output structures	3/3 identical seven-section structures
Stored acceptance artifacts	4 byte-matched and SHA-256-pinned outputs
Judge demonstration scenarios	3/3 PASS
Clean-package checks	7/7 PASS
Isolated local plugin installation	Enabled at version 0.1.2

The 14 evaluation cases include:

3 normal feature briefs;
5 missing or incomplete briefs;
2 conflicting briefs;
2 out-of-scope requests; and
2 sensitive-input or deployment-approval cases.

The public repository is available under the MIT License. The complete judge path can run locally without rebuilding the project or connecting to an external service.

What I learned

I learned that a prompt generator benefits from the same engineering discipline as any other developer tool: explicit contracts, consistent output structures, deterministic failure states, regression cases, version history, and a documented rollback path.

I also learned that generating an instruction and authorizing its execution are two different decisions. Keeping that boundary visible makes human review meaningful instead of ceremonial.

Most importantly, a passing schema is not enough. The meaning and placement of information must also be tested. One deployment-related issue passed the original structural suite but failed human review, and that discovery directly improved the evaluator.

This project also taught me that reducing scope can make a tool stronger. Instead of trying to automate every possible task, Codex BriefGuard concentrates on one problem that can be tested and explained clearly.

Try it

Requirements:

Python 3.9 or newer
No third-party Python packages
No credentials
No network connection

Run the judge demonstration:

python3 scripts/judge_demo.py

Expected result:

Codex BriefGuard judge demo: PASS (3/3 scenarios)

Run the full evaluation suite:

python3 plugins/codex-briefguard/skills/create-codex-implementation-prompt/scripts/run_evals.py

Expected result:

Prompt workflow evals: PASS (14/14 cases)

Run the clean-package audit:

python3 scripts/check_submission.py

What's next

Codex BriefGuard v0.1.2 is available in a public MIT-licensed repository with a public demonstration video and a no-build judge test.

Possible next steps include:

testing the workflow with feature briefs from different repositories;
expanding conflict detection while keeping every failure reason explainable;
improving sensitive-information detection without exposing detected values; and
evaluating a separately packaged user interface while preserving the deterministic command-line judge path.

Codex BriefGuard is not presented as fully autonomous or capable of detecting every possible conflict or secret. It is a focused developer tool for making Codex implementation handoffs more explicit, reviewable, and human-controlled.