Inspiration
Coding agents can produce changes quickly, but speed does not answer the engineering questions that determine whether a change is trustworthy: Was the task scoped before editing? Did parallel workers add new information? Could a worker write outside its authority? Who integrated the final state? Did the same Agent define both the acceptance criteria and the completion claim?
I built Wide-Lens Engineering to make those decisions explicit without taking autonomy away from the main model. The Skill does not prescribe a fixed team, role roster, or Agent count. It lets the active main model decide whether delegation has positive marginal value while keeping write scope, acceptance, and authority bounded.
What it does
Wide-Lens Engineering is an explicitly invoked Codex Skill for implementation, debugging, refactoring, migrations, architecture work, and review. Installing it does not change ordinary Codex sessions; the workflow loads only after a $wide-lens-engineering request.
Each task separates one intent from three independent axes:
- assurance: practical or assured;
- depth: focused or full;
- coordination: independent or shared.
Execution is then derived from the task and the capabilities the host can actually enforce:
- main-only: the main thread performs the work;
- read-only-proposals: peers inspect the repository and return evidence, plans, or inert patch text;
- isolated-candidates: candidate workers may edit only a host-provided disposable workspace that cannot write the canonical checkout.
The active main model chooses the task DAG, Agent identities, participant count, models, and assignments. Tasks are not Agent slots: one Agent can execute several ready nodes, and a node can remain with the main thread.
Shared analysis uses sealed first-round positions. Only after those positions are sealed can peers challenge one another. The main thread resolves disagreements with discriminating evidence rather than voting or confidence scores.
The main integrator remains the only writer to the canonical checkout. Candidate output is inspected before integration, changed paths are rechecked, and every frozen acceptance command is rerun against the final canonical state. Overlapping candidate writes are serialized or rejected; they are never resolved by last-writer-wins.
Practical and assured delivery
The practical route is for local, reversible, clearly scoped repository work. Before implementation it records the objective, non-goals, allowed paths, exact acceptance commands, observed host capabilities, task DAG, execution policy, and any downgrade reason. Its result is procedural repository evidence, not an attestation.
Assured protocol v5 is for high-risk or audit-required delivery. It defines deterministic packets, orchestration envelopes, task DAGs, controller leases, candidate bundles, execution receipts, verifier receipts, frozen acceptance, and compatibility with the frozen v4 format.
The public v0.1.0 release is deliberately labeled preview-unattested.
The repository ships:
- the opt-in Skill router and practical workflow;
- the protocol v5 specification;
- deterministic packet, receipt, compatibility, and gate validators;
- a neutral read-only Codex peer profile;
- a reproducible Codex Plugin package builder;
- optional result-contract hooks;
- deterministic, structural, platform, distribution, performance, and compatibility tests.
The repository does not ship:
- an external controller or atomic lease service;
- an independent digest or signing service;
- an isolated candidate-workspace runtime;
- an independently deployed verifier;
- an OS process, credential, network, or filesystem sandbox.
The reference gate can validate artifacts produced by that external infrastructure, but it cannot manufacture those trust properties itself. If a required controller, sandbox, digest channel, or independent verifier is missing, the assured claim fails closed.
How I built it with GPT-5.6 and Codex
I used GPT-5.6 Sol as the primary model inside Codex for the core development work.
Codex accelerated repository-wide search, architecture mapping, Python implementation, regression generation, adversarial review, shared-subagent deliberation, documentation, CI configuration, reproducible packaging, and terminal-based GitHub delivery.
GPT-5.6 Sol helped separate task planning from Agent count, distinguish practical evidence from externally anchored assurance, design the capability-gated DAG and candidate-isolation rules, preserve v4 compatibility, and convert counterexamples into deterministic regression cases.
The delivered Skill does not hard-code GPT-5.6 Sol as the model for every worker. Runtime model and reasoning choices remain with the Codex host and the active main model. GPT-5.6 Sol was the primary model used to build and exercise the project.
Primary Codex build thread:
019f67c4-9bd9-7581-8ae9-3cdd4453d9f7
Key engineering decisions
The hardest problem was preventing self-certification. A packet hash is not an external trust anchor if the same Agent creates the packet, digest, report, and completion claim. Protocol v5 therefore treats the external controller, digest channel, verifier, receipts, and sandbox as real prerequisites instead of presenting prompt discipline as a security guarantee.
The second challenge was allowing useful parallel implementation without turning the canonical repository into a shared writable workspace. Analysis peers stay read-only. Candidate workers are allowed only when the host proves a disposable isolated workspace and canonical-write blocking. The main integrator alone mutates canonical state.
The third challenge was preserving model autonomy without encoding a fixed team size. The Skill records capabilities and an acyclic task DAG, but the active main model decides whether to delegate, how many identities to use, and when the marginal value of another lane has fallen to zero.
I also kept the Skill opt-in and used progressive disclosure. The small router loads only the selected practical or assured reference, so normal coding sessions do not pay the context and ceremony cost of the full protocol.
Verification
The public preview is tagged v0.1.0 at commit:
e556a7c2d00e8486a4b943e406cf2696c6a7761e
Seven count-bearing release gates pass 736/736:
- 207/207 core deterministic cases;
- 76/76 forward cases, with zero skips;
- 187/187 protocol v5 cases;
- 56/56 distribution, adapter, and Plugin cases;
- 25/25 local platform-applicability cases;
- 35/35 Codex live-harness structural cases, with no model call;
- 150/150 frozen protocol/controller benchmark tasks.
Windows, Ubuntu, and macOS applicability jobs passed. Performance gates and the reproducible double-build gate also passed.
The 150/150 frozen protocol/controller benchmark has a one-sided exact 95% lower bound of 98.02% for that fixed benchmark and configuration. It is not universal model accuracy, live-coding success, defect recall, an independent security audit, or an externally attested Assured run.
Installation and judge path
Requirements:
- Codex;
- Git;
- Python 3.10 or newer;
- no third-party Python runtime package.
Supported and validated platforms: Windows, Ubuntu, and macOS. Codex, Git, and Python 3.10+ are required.
Install the root Skill with Codex's Skill installer:
Use $skill-installer to install this GitHub skill:
repo: Mai-xiyu/wide-lens-engineering
path: .
name: wide-lens-engineering
Then invoke it explicitly:
Use $wide-lens-engineering to fix this failing behavior.
Choose assurance, depth, and coordination independently.
Let the active main model delegate only where another Agent adds evidence.
Keep one canonical writer and rerun the frozen acceptance checks.
Judges can run a short repository check without rebuilding the Plugin:
python -B tests/run_eval.py --threshold 1.0 --json
python -B tests/run_forward_eval.py --threshold 1.0 --require-no-skips --json
python -B tests/run_v5_eval.py --threshold 1.0 --json
python -B scripts/validate_skill.py .
No sample data is required. These checks require no API key, test account, network call, or third-party Python package. A packaged v0.1.0 preview is also attached to the GitHub Prerelease.
What I learned
More Agents do not automatically produce broader reasoning. Independence, sealed positions, task boundaries, and discriminating evidence matter more than voting.
Repository isolation and security isolation are also different properties. A separate directory or Git worktree can reduce file conflicts without becoming a trustworthy sandbox.
Finally, a useful high-assurance design must state what it does not provide. This preview includes the Skill, protocol, reference gates, packaging, and tests. The trust infrastructure required for a real Assured execution remains external.
What's next
The next step is an independently operated controller reference deployment with authenticated leases, isolated candidate workspaces, signed receipts, and a fresh-context verifier. I also plan to run the external, commit-bound live benchmark across local, security, concurrency, data, API, and distributed tasks before making any externally attested release claim.
Built With
- codex
- gpt-5.6
- openai
- skill
Log in or sign up for Devpost to join the conversation.