frontier-simplify

Frontier-simplify for Fable and Astra

Built for frontier coding agents including Fable and Astra (gpt-6-astra). Coding agents do not only over-engineer code. They build bureaucracy around their own work — gates, registries, traceability matrices, validators for the validators — and then spend the project maintaining it. Frontier-simplify cuts that invented process and bounds automatic review attempts. The skills are model-independent; targeting Fable and Astra does not claim measured results for both.

The core frontier-simplify skill is one Markdown file; no plugin or hook is required. The optional review skill adds an explicitly invoked local runner, described below.

Install

Pick whichever fits your agent. Then just work — the agent loads the skill on its own when a task calls for it. Nothing to invoke.

Codex — as a plugin, versioned and updatable:

codex plugin marketplace add MongLong0214/frontier-simplify
codex plugin add frontier-simplify@frontier-simplify

Claude Code:

/plugin marketplace add MongLong0214/frontier-simplify
/plugin install frontier-simplify@frontier-simplify

Or just copy the file — into its own folder under ~/.codex/skills/, ~/.claude/skills/, or any tool's rules directory (Cursor, Windsurf, Cline, Copilot). It is plain markdown with standard frontmatter. Keep the folder: a loose SKILL.md sitting directly in skills/ still loads, but it will shadow a plugin install and quietly serve the older copy.

mkdir -p ~/.codex/skills/frontier-simplify
curl -sL https://raw.githubusercontent.com/MongLong0214/frontier-simplify/main/skills/frontier-simplify/SKILL.md \
  -o ~/.codex/skills/frontier-simplify/SKILL.md

To uninstall, delete the file.

Upgrading from sol-simplify

Version 2.0.0 renames the repository, marketplace, plugin and three skill directories to frontier-simplify, frontier-simplify-audit and frontier-simplify-review. Remove the old plugin or standalone skill copies through the same installation method, then install using the commands above; do not leave both identities active. Update saved script paths and reinstall a local review hook or poller from the renamed checkout if you use one. Existing review history stays in place: the old ~/.sol-simplify-review root is automatically reused so the PR budget cannot reset. Historical benchmark transcripts and the original review-design/reassessment documents keep their original names and model identities; they are evidence, not current installation instructions.

What it does

Asked to design a development process for a project with no code yet and one maintainer:

The example below is the historical gpt-5.6-sol measurement, not an Astra or Fable result.

Without — 437 lines, 35 sections: risk-based quality gates, six test tiers, a CI operating model, a release-candidate checklist, a defect taxonomy, project health metrics, and a section on maintaining the document itself.

With frontier-simplify — 58 lines, 6 sections. And it says why:

No ceremonial self-approval PRs when working alone.

No new documents or global rules because of a single mistake.

When a check fails for reasons unrelated to product behavior, fix or delete the check instead of building an exception procedure around it.

The skill was never mentioned in the prompt. Codex found it and applied it on its own.

Process it decides to keep, it marks with a removal condition — so it can be audited later instead of becoming permanent:

frontier-simplify: <why this exists>, remove when <condition>

What it never cuts

Correctness. Tests that exercise real behavior. Input validation at trust boundaries. Error handling that prevents data loss. Security. Accessibility. Data migrations. Anything you explicitly asked for.

Restraint applies to process the agent invented, never to the product's real obligations. On the scenario where a payments team facing a PCI-DSS audit explicitly asks for a checklist, approval flow, rollback procedure, and audit records, the skill kept all four — every run, mapped to real PCI DSS v4.0.1 controls.

Audit a repo that already has the disease

A second skill diagnoses an existing repository instead of preventing a new one. Install it the same way, then say "audit this repo for ceremony".

mkdir -p ~/.codex/skills/frontier-simplify-audit
curl -sL https://raw.githubusercontent.com/MongLong0214/frontier-simplify/main/skills/frontier-simplify-audit/SKILL.md \
  -o ~/.codex/skills/frontier-simplify-audit/SKILL.md

It measures the machinery-to-product ratio, finds maintenance commits that shipped nothing, ranks what to delete, and reports only — it changes no files.

Stop repeating the same code review

The optional frontier-simplify-review skill preserves concrete findings and checks repairs against them. Its runner is for one maintainer on a trusted local host, not a merge gate or hosted service. Use a separate installation of this repository, outside the checkout being reviewed:

export REVIEW_CODEX_MODEL=gpt-6-astra  # Astra when using the Codex executor
skills/frontier-simplify-review/scripts/review-pr.sh "$CONSUMER_REPO" "$PR_NUMBER" auto codex
skills/frontier-simplify-review/scripts/review-pr.sh "$CONSUMER_REPO" "$PR_NUMBER" status codex

• Identical inputs reuse the latest attempt. Code, target, supplied context, lessons, response, model settings or protocol changes invalidate that reuse. Unchanged failures do not auto-retry.
• Repairs use the original findings and latest review. Rewritten history or a changed base gets a fresh scope review within the same three-attempt PR budget, never a reset.
• status reads state without launching a model or fetching Git objects. Completion rechecks the requested commits; a moved or unavailable target leaves a preserved but stale result.
• report reads local evidence without GitHub or fetches, showing the starting protocol fingerprint and freshness at finish. It announces evidence checks; historical freshness is not current PR state.
• Executors time out after 1,800 seconds by default (REVIEW_TIMEOUT changes it). Timeout and SIGINT/SIGTERM stop their process group and preserve the failed attempt.
• Contract defects are reported as an invariant with a producer/sink table, enumerated once; follow-ups verify that table instead of finding one more path per round. A defect that also exists at the base is classified, and one inside the change's new contract comes with the option of shrinking the contract.
• Reviewer reproductions saved in review_evidence/ are kept outside the checkout and rerun on the next head before any model starts. A failing witness returns the repair without using an attempt.
• A contract invariant still open in two consecutive reviews stops the next review and asks for a redesign instead; the template is rendered from the skill.
• After the three automatic attempts, more review needs --supplementary --granted-by WHO --budget N. Every round prints the PR's cumulative count and time, and a spent budget writes HANDOFF.md asking for one decision.

Exit 10 means evidence recorded, 11 means the budget ended in a human handoff, and 5 means failed or stale evidence. 12 (redesign required) and 13 (a preserved witness fails) return before any reservation or model launch. None means approval. Three attempts bound automatic repetition; they do not guarantee correct review, closed defects or a safe merge. Provider-side model revisions and unexposed executor defaults cannot be fingerprinted and remain unknown.

Help and read-only commands return 0; invalid command syntax returns 2. A valid target reserves an attempt before preparing inputs, so a later failure consumes it. Legacy histories remain readable even when they exceed three attempts, but cannot launch another review. Prompt values are rendered once, then the frozen prompt is sent through finite stdin; this removes argv limits without promising unlimited input or hiding a CLI rejection. See the runner guide for v3 history, Git scope and rollback limits.

The runner needs Bash, Git and Python 3.9+; PR discovery also needs authenticated gh, and live reviews need Codex or Claude Code. Full offline tests and optional Node witness replay need Node 22+.

bash skills/frontier-simplify-review/scripts/selftest.sh
python3 dogfood/run.py --status  # inspect configured consumers; no model calls
python3 dogfood/run.py           # one discovery/review pass, not a daemon

Edit the maintainer-local paths in dogfood/consumers.json, or set REVIEW_CONSUMERS_CONFIG to your own file. Plugin installation starts no scheduled work. The optional macOS poller, separate responses, and measured regression leads are covered in the consumer guide and runner guide. Consumer reviews never push, post or merge.

Why this exists

Measured across the full git history of one repository an agent built over 20 days: 20,280 lines of verification machinery against 17,964 lines of product, 33% of commits maintaining the machinery, and on day 17 the agent's own rule blocked all work — in its own words:

docs: say where acceptance is decided, because the rule as written refuses all work

Every individual file there is defensible. Code-level advice — use the stdlib, keep the diff small — would not have prevented any of it, because the failure is not in the code.

1  Pre-emptive governance   gates, ADRs, traceability, registries — before any product exists
2  Check proliferation      every artifact gets a validator; every validator a contract test
3  Self-amplification       pins break on every merge → re-sync commits → repeat
4  Self-refusal             the process the agent authored refuses to let the agent work

Stages 3 and 4 are what nothing else addresses, and the reason a one-line prompt is not enough.

Does it work?

Astra (gpt-6-astra), 2026-09-09: a fresh four-arm 02-process spot check produced 246 lines plain, 81 with the Korean one-line instruction, 152 with the English one-line instruction, and 33 with Frontier-simplify. The transcript confirms the skill was read in the treatment arm. This is one run per arm, not a correctness score or proof of review convergence. Raw outputs, setup and limits.

The five-scenario table below is the historical gpt-5.6-sol result, not a Fable or Astra score.

Five ordinary requests, each sent three ways — plain, with a "keep it simple" sentence added, and with the skill installed. Same model, same prompt every time.

The number counts things the model added that were never requested: a made-up latency target, a staged rollout, an approval step for a team of one. 0 is best.

Nothing was dropped to get the second row to 0: what left that document was the release-candidate checklist, the defect taxonomy, and the six test tiers, none of which had been asked for.

Row three is the one to check if you worry this makes an agent cut corners: when the process is genuinely required, it keeps all of it.

Every run without the skill invented between one and six of these. With the skill, one run added a canary deployment step on the audit scenario; the rest added nothing at all. Every number traces to a line in the committed output; full detail and limits are in benchmarks/.

FAQ

How is this different from code-minimalism skills like Ponytail? Different layer. Those ask "can this be one line?" about code; frontier-simplify asks "should this check exist at all?" about process. They compose — run both if you want both.

Will this make the agent skip tests? Measured: no. Every skill run on the incident scenario fixed the root cause and added the regression test. Tests that exercise behavior are in the never-cut list; if you see it cut a real one, that is a bug worth an issue.

Does it work on other models? Fable and Astra (gpt-6-astra) are the intended frontier-model use cases. The instructions are portable, but effectiveness must be measured per model. The historical five-scenario results retain their original gpt-5.6-sol attribution; they are not Fable or Astra scores. No Fable benchmark result has been recorded yet. See benchmark evidence and limits.

Why is the core skill just Markdown? The core frontier-simplify skill is one Markdown file. The optional review skill also ships an explicitly invoked runner, regression replay and a local test hook; plugin installation alone starts no poller.

Releases or Packages? Use GitHub Releases for tagged versions and source archives. This plugin does not need a separate registry package or container image.

License

MIT