Long AI projects often fail because the goal drifts, agents expand the scope, and review loops multiply—not because the models are weak.
Three-Level Delivery keeps a large Codex project moving through one Owner-approved slice, one Writer, one independent Reviewer, clear evidence, and a hard stop.
From a plain-language idea to a versioned project foundation. Project memory lives in Git and durable files, not in one chat window. New chats, agents, and machines can resume from recorded truth.
Installed skills do not auto-update, and no fork is required. $skill-installer aborts when the destination skill folder already exists, so updating must be an explicit, user-authorized replacement of only the installed three-level-delivery skill folder outside every project repository. It must not mutate a project, silently replace an install, or imply that this update method applies universally to other skills or platforms.
For the Codex-first v0.1.4 update, give Codex this prompt:
Use $skill-installer to update Three-Level Delivery from https://github.com/nguyenduytamgithub/three-level-delivery/tree/main/three-level-delivery. First ask for my explicit authorization to back up and replace only the installed three-level-delivery skill folder outside all project repositories. After authorization, reinstall the canonical tree, verify that the installed metadata version is exactly 0.1.4, and tell me to restart Codex. Do not modify any project repository or perform a silent update.
For an unestablished project, the Owner does not manually assemble setup checklists or files. This includes an empty folder, a new non-Git project, an empty or newly initialized Git repository, and a repository without durable vision and state equivalents. After the Owner confirms the target and explicitly replies Duyệt S000 và tạo Lead task riêng., Three-Level Delivery checks HEAD before creating the visible Lead. Without a valid HEAD, approved S000 uses the user-visible local/no-worktree path bound to the saved project checkout; its sole Writer initializes Git if needed, immediately passes CodeGraph ensure/sync and one focused maxFiles: 2 exploration in that checkout, then creates only the minimal missing foundation files and makes the first foundation commit. A CodeGraph failure stops before foundation edits. The foundation and root-commit evidence are reviewed and reported, then delivery hard-stops. A generic Duyệt S000, ok, or làm đi does not authorize the slice or Lead-task creation.
S000 creates only Owner-level vision and state memory. It does not create app, demo, product, package, or framework code; implementation design, plan, test, or review documents owned by Superpowers; or tracked CodeGraph indexes, MCP configuration, or call-path documentation. The ignored .codegraph/ cache required in the writable checkout is tooling state, not a project artifact. After S000 acceptance, delivery hard-stops. A product slice may be proposed separately only in a later Owner-gated interaction. Later Superpowers specs and plans remain subordinate links from project state, while the same one-Writer/one-Reviewer hierarchy controls delivery.
| Layer | Its boundary |
|---|---|
| Owner and direct project constraints | Authoritative intent and project constraints |
| Three-Level Delivery — governance/authority only | Owner intent, visible role topology, one active slice and Writer, writable scope, durable state, accepted evidence, and the Owner hard stop |
| Superpowers — sole technical workflow/method layer | Design, plans, implementation, debugging, TDD and test strategy, review, verification, and worktree technique inside the approved slice |
| CodeGraph — context/intelligence/evidence only | What code exists, where it lives, and how it is related; never lifecycle orchestration |
Authority precedence is explicit: Owner and direct project constraints > Three-Level Delivery governance boundary > the relevant Superpowers technical method > CodeGraph context and evidence. This is not execution order: after Three-Level Delivery locks the approved slice, CodeGraph performs discovery first, the relevant Superpowers method runs inside that slice, and Three-Level Delivery records evidence and durable state, then stops at the Owner gate. Three-Level Delivery may require method use and evidence, but it does not redefine technical procedures. A technical method cannot widen the Owner-approved slice, change the visible role topology, bypass gates, or open the next slice.
Git plus durable project documents are the single source of project state. Specifications, architecture documents, ADRs, Reviewer findings, CI, and evals may describe or verify technical work; they are not a competing plan or checkpoint ledger and do not by themselves govern Owner intent, cross-task role authority, scope expansion, continuity, or Owner acceptance.
It strongly reduces the risk of:
- the coordinator quietly becoming another coder;
- agents adding “helpful” work outside the approved slice;
- self-checks, boundary checks, and Owner acceptance becoming duplicate code reviews;
- a second Writer, Reviewer, plan hierarchy, or automatic next slice appearing;
- completion being claimed without fresh evidence.
- Open the correct large-project Codex project or task, invoke
$three-level-delivery, and describe the idea and first visible result. - Confirm the intended folder. The skill checks the binding and prerequisites read-only, then classifies an established project foundation by its mapped durable vision/state equivalents; every unestablished or ambiguous case gets S000 first or stops.
- Approve both the proposed slice and creation of its separate visible Lead task with the exact, unambiguous confirmation requested. Nothing is written and no visible task or internal delivery role is created before that confirmation.
- The current
[Project] — PO Gốctask checksgit rev-parse --verify HEAD, then makes one user-visible Lead-task creation attempt. Approved S000 without HEAD uses the local/no-worktree path; a valid-HEAD slice uses one worktree. A returnedthreadIdbecomes ready only after exact project, title, and sidebar verification. A returnedclientThreadIdmeansQUEUED_NOT_READY, neverFAILand never a usablethreadId; the PO makes no second creation attempt and uses only a bounded compact task-list observation to reconcile the same Lead. If the real Lead does not appear by the declared deadline, status isUNKNOWN/QUEUEDand delivery hard-stops. Exactly the PO and Lead tasks appear in the sidebar. Only the Writer and independent read-only Reviewer run internally to the Lead. You stay in the PO task.
First install and enable the two required prerequisites from their official repositories:
Then give Codex this one prompt for a first installation whose destination does not already exist:
Use $skill-installer to install the skill from https://github.com/nguyenduytamgithub/three-level-delivery/tree/main/three-level-delivery
Installation is user-directed. The skill never auto-installs itself or its prerequisites.
Open the correct large-project Codex project or task and explicitly invoke $three-level-delivery. Once per new PO task/activation, v0.1.4 performs its read-only canonical identity/version check before any target write, Git initialization, visible task, or internal role. Then describe the project idea and first visible result and confirm the intended folder. The skill reuses an established foundation's mapped durable documents or proposes S000 for an unestablished project. Its approval request asks you to authorize both the slice and one separate visible Lead task; generic approval is insufficient. After exact confirmation, it checks HEAD and makes one creation attempt: approved S000 without a valid HEAD uses the user-visible local/no-worktree path in the saved checkout, while S001 and every valid-HEAD slice use one worktree. A real threadId is usable only after exact project/title/sidebar verification. Queued clientThreadId is reconciled through bounded compact task-list observation; a deadline produces UNKNOWN/QUEUED, a hard stop, and no duplicate creation. Before the Writer starts, the actual writable checkout must pass CodeGraph ensure/sync and one focused maxFiles: 2 exploration or document its no-code/doc-only result. Writer and Reviewer stay internal to the Lead. The S000 Writer alone creates the first foundation commit, review includes its evidence, and delivery hard-stops before product work. If the harness cannot satisfy a required gate, the skill fails closed or reports the defined queued unknown without internal substitution or manual PO bootstrap.
Three-Level Delivery v0.1.4 is Codex-first and instruction-only: no hook, MCP server, daemon, background process, or auto-install. Its activation freshness check is a read-only fetch of the canonical raw SKILL.md; it sends no credentials and adds no tracking or telemetry. Installation and behavior on other agent platforms remain unverified. Installs older than v0.1.4 cannot be retroactively forced to perform this check.
Created by NGUYỄN DUY TÂM (NDT) — GitHub: nguyenduytamgithub.
Canonical repository: https://github.com/nguyenduytamgithub/three-level-delivery
Citation metadata is in CITATION.cff.
Copyright © 2026 Nguyễn Duy Tâm (NDT). The content and instructions are licensed under Creative Commons Attribution 4.0 International.