--- name: Ultra ADLC slug: ultra-adlc category: Automation description: Ultra ADLC turns one large natural-language goal into a complete, audited delivery with independent verification. Use it for explicitly requested full deliveries that need end-to-end implementation and proof, not small fixes or ad hoc work. github: "https://github.com/KonghaYao/peri/tree/main/peri-middlewares/src/skills/builtin/skills/ultra-adlc" language: Rust stars: 163 forks: 30 install: "npx degit https://github.com/KonghaYao/peri/tree/main/peri-middlewares/src/skills/builtin/skills/ultra-adlc ~/.claude/skills/ultra-adlc" installs_to: ~/.claude/skills/ultra-adlc source_path: peri-middlewares/src/skills/builtin/skills/ultra-adlc/SKILL.md collection_size: 20 category_size: 2226 collection_url: "https://dirskills.com/collections/KonghaYao/peri" added: 2026-09-08T05:35:46.911Z last_synced: 2026-09-08T05:35:46.911Z canonical_url: "https://dirskills.com/skills/ultra-adlc" --- # Ultra ADLC Ultra ADLC turns one large natural-language goal into a complete, audited delivery with independent verification. Use it for explicitly requested full deliveries that need end-to-end implementation and proof, not small fixes or ad hoc work. **Install:** ```bash npx degit https://github.com/KonghaYao/peri/tree/main/peri-middlewares/src/skills/builtin/skills/ultra-adlc ~/.claude/skills/ultra-adlc ``` ## README # Ultra-ADLC Turn one natural-language goal into a complete, audited delivery. The Main Agent preserves the user's stated intent and authority boundaries, delegates ordinary design adjudication to an independent `opus` or `fable` arbiter, and coordinates all execution without making the user supervise implementation choices. This skill is self-contained. Use the existing deferred `Workflow` tool and its existing `agent`, `parallel`, `pipeline`, `phase`, and ordinary JavaScript control flow only. Do not add a DAG/runtime/RPC/event/TUI primitive or a third logical workflow. ## Admission and completion invariants - This mode is for a very large end-to-end task. If it was selected implicitly for ordinary work, do the work normally instead. An explicit `/ultra-adlc` invocation always selects this mode. - There are exactly two **logical** workflows: `discovery-design` and `delivery-convergence`. A resumed physical run remains part of its original logical workflow. - The Main Agent is the only user-interaction seam. Workflow Agents cannot and must not call `AskUserQuestion`. User adjudication is not the default: ordinary reversible product, scope, risk, and design choices go to an independent `opus` or `fable` Decision Arbiter. Ask the user only for missing product intent, new authority, secret or external state, legally or financially consequential acceptance, irreversible action, or two outcomes that materially affect the user and cannot be resolved from the stated goal. - There are exactly three contracts: `intent.md`, `execution.md`, and `evidence.md`. Manifests, decisions, handoffs, artifacts, and learning records are audit records, not extra contracts. - Legal terminal states are `complete`, `blocked`, and `cancelled`. There is no `partially_complete`. "Core complete", "mostly complete", an exhausted context, or a normally exited Workflow are never completion evidence. - Assessor verdicts are only `complete | incomplete | blocked`. Do not invent a fourth verdict such as `complete_with_known_gaps`. Every required check in the accepted Verification Plan must have current, attributable evidence. Unrun or missing required tests, missing required coverage evidence, and unevidenced acceptance scenarios are coverage gaps: return `incomplete` when fixable inside Workflow 2, or `blocked` when an external dependency or authorization prevents obtaining the evidence. Keep fixable incomplete items inside the Workflow 2 loop. `Remaining Risks` may contain only non-required checks outside the accepted Verification Plan (including an out-of-plan E2E or preexisting flake); it cannot excuse missing required evidence or reduce any completion percentage. - A task is `complete` only after one independent Completion Assessor in the current assessment round proves 100% coverage. Fixable gaps remain inside logical Workflow 2 and loop until they are fixed and reassessed. - Never commit, push, publish, deploy, delete material data, or mutate an external system unless the user separately and explicitly authorizes that action. ## Engine and orchestration hard rules `phase(name) only marks a stage`. The engine drops any second callback argument. Never write `phase(name, async () => { ... })`. Correct shape: ```javascript phase('ADLC/W1/Discover') await parallel([() => agent(...)]) ``` After every Workflow completion notification, read `.claude/workflow-runs//state.json` before the decision seam or any delivery claim. If the run has `0 agents`, or it finishes in a few seconds with an empty handoff directory, the script failed: fix the script and relaunch. Do not enter the decision seam or claim discovery finished. Engine four-layer status is not product completion. Read `execution_status`, `acceptance_status`, `post_processing_status`, and `delivery_status` separately. Do not treat engine `completed`, a worker `status: complete`, or a completion notification as product done. Product completion requires an independent Completion Assessor verdict of `complete` and a finalized `evidence.md`. `writeIntent.path_allowlist` is enforced against the Git baseline captured when the Workflow starts. The existing Git postcondition omits ignored paths, so the Ultra-ADLC orchestrator must also capture a filesystem write-boundary snapshot at preflight and compare it during post-processing. That check must report both created files and files whose content or type changed, including under ignored paths such as `.peri/adlc/`; merge those paths with Git `changed_paths` and validate every repo-relative path against the same allowlist. The Git postcondition checks only paths whose status changed during the run by comparing before/after porcelain records. A pre-existing unrelated dirty or ignored path is therefore allowed when its status and filesystem snapshot remain unchanged; record it once as an out-of-scope baseline, preserve it, and do not treat it as a blocker or ask the user to clean it. Before launching a write Workflow, run `git status --porcelain` and capture the filesystem write-boundary snapshot to establish that context. The allowlist lists only authorized write paths (product crates plus `{cwd}/.peri/adlc/tasks//**` and the designated evolution record); never add unrelated dirty paths merely to widen write authority. Interpret the four engine statuses independently. `delivery_status: blocked` alone does not prove a Git failure: an explicit Git postcondition error requires `post_processing_status: failed` and an error mentioning `path_allowlist` (or another Git invariant). `acceptance_status: unknown` with successful execution and post-processing means delivery is `unknown`, not blocked. If a path-allowlist error occurs, it proves that some out-of-allowlist path changed after baseline; unless the engine names that path or a before/after comparison proves it, do not infer the culprit from the final dirty set. Treat the event as a Git close-out failure rather than a product failure, and do not stash, commit, reset, clean, or ask the user to alter unrelated changes. Keep `head_may_change: false` unless the user explicitly authorizes a commit. The Main Agent authors every Workflow script from engine primitives. `parallel` must receive `() => agent(` factories, never already-started promises. ## Preflight before fan-out Before creating an expensive run: 1. Confirm the natural-language goal is non-empty and large enough for this mode. 2. Detect whether `AskUserQuestion` is available in the Main Agent's current tool view, but do not block normal fan-out when it is absent. It is needed only if a valid Decision Arbiter result is `needs_user`; at that point, absence is a real `blocked` condition. 3. Discover the deferred Workflow capability with `SearchExtraTools("workflow")`, and execute it only through `ExecuteExtraTool("Workflow", ...)`. If it is unavailable, stop before fan-out. 4. Resolve `{cwd}/.peri/adlc/`, canonicalizing existing ancestors. Refuse symlink or `..` traversal that escapes cwd. Never resolve to `~/.peri/` or outside cwd. Verify the task directory is writable. 5. Confirm the required Peri profile aliases are usable: `haiku`, `sonnet`, and `opus`; confirm `fable` when arbitration or convergence escalation requires it. 6. Inspect the working tree with `git status --porcelain` and preserve unrelated user changes. Load the repository and relevant module instructions before assigning work. Workflow startup may still fail quickly when Node/the runner is unavailable. Record that failure and stop; do not substitute an untracked inline process. ## Project record The project-level root is always: ```text ./.peri/adlc/ ``` ADLC records are a local audit under `{cwd}/.peri/adlc/`. They are ignored by `.peri/*` and are not committed unless the user separately authorizes it. Never write `{cwd}/peri/adlc/`. Create a safe task id outside Workflow scripts and inject it, the cwd, and all timestamps through Workflow `args`. A task id may be `YYYY-MM-DD-[-NN]`; inspect the filesystem to choose a collision suffix. Never use `Date.now()`, `new Date()`, `Math.random()`, random APIs, or ambient time inside a Workflow script. ```text .peri/adlc/ ├── tasks// │ ├── manifest.json │ ├── contracts/ │ │ ├── intent.md │ │ ├── execution.md │ │ └── evidence.md │ ├── decisions/ │ ├── handoffs/ │ │ ├── workflow-1/ │ │ └── workflow-2/ │ ├── artifacts/ │ │ ├── designs/ │ │ ├── reviews/ │ │ ├── test-results/ │ │ ├── progress/ │ │ └── workflow-provenance/ │ └── learning/ │ └── agent-performance.md └── evolution/records/.json ``` Raw Workflow state remains in `.claude/workflow-runs//`. Do not move or copy its full journal into `.peri/adlc/`; record the run ids in `manifest.json` and, at the end, retain only a compact provenance summary. The Main Agent is the single writer for `manifest.json`, user decisions, and accepted `intent.md`/`execution.md` revisions. The Completion Assessor exclusively owns the completion verdict and all substantive `evidence.md` sections. After the physical Workflow run reaches a terminal state, the Main Agent may only append the compact Workflow provenance; it must not change the assessor's verdict or coverage. Initialize all three contract paths before Workflow 1; `evidence.md` remains a draft until the final assessor passes. Use this minimal manifest shape and append physical runs rather than replacing history: ```json { "schema": "peri.adlc/task-v1", "adlcId": "", "status": "discovering", "contracts": { "intent": { "path": "contracts/intent.md", "revision": 0 }, "execution": { "path": "contracts/execution.md", "revision": 0 }, "evidence": { "path": "contracts/evidence.md", "revision": 0 } }, "workflowRuns": { "discoveryDesign": [], "deliveryConvergence": [] }, "decision": { "status": "pending", "packet": null, "record": null, "source": null, "attempts": [], "arbiterAgentId": null, "arbiterProfile": null }, "progress": { "snapshotRevision": 0, "denominatorRevision": "bootstrap-0" }, "completion": { "round": 0, "verdict": null } } ``` Allowed manifest states are: ```text discovering -> planning_delivery -> delivering ^ discovering -> awaiting_user_decision awaiting_user_decision -> planning_delivery delivering -> verifying -> converging -> delivering verifying -> complete any active state -> blocked | cancelled blocked -> delivering (after the required authority or external state exists) ``` The direct `discovering -> planning_delivery` path is normal after a valid arbiter decision. `awaiting_user_decision` is exceptional and legal only after a valid `needs_user` result. `workflowRuns` has only `discoveryDesign` and `deliveryConvergence` logical slots; each slot is an append-only list of physical run ids. ## The three contracts `contracts/intent.md` is the user-facing truth and contains: ```markdown # Intent ## User Goal ## Environment Facts Relevant to the Goal ## Desired Behavior ## Acceptance Scenarios ## Non-goals ## User Decisions ## Constraints ## Authorized Actions ## Stop and Escalation Conditions ``` A user choice may revise user-visible behavior, scope, non-goals, or authority. A valid arbiter Decision Record may select only among outcomes already permitted by the original goal and current authority; it cannot expand them. Increment `intent_revision` when accepted intent semantics change and invalidate affected downstream work. `contracts/execution.md` is the Main-Agent-to-Workflow contract and contains: ```markdown # Execution ## Intent Revision ## Repository Facts ## Selected Design ## Rejected Alternatives ## Impacted Areas ## Work Packages ## Completion Ledger ## Decision Arbitration ## Progress Reporting ## Model Routing ## Concurrency and Write Ownership ## Verification Plan ## Handoff Plan ## Retry, Resume, and Escalation ``` Every Work Package records `id`, a concise semantic title, `goal`, `dependencies`, `profile`, allowed tools, read scope, exclusive write scope, inputs, outputs, acceptance evidence, retry limit, escalation profile/condition, and immutable handoff path. Exhausting one Worker's retry limit escalates or replans the package; it does not defer or remove the requirement. Every intent requirement must map to one or more packages, actual implementation, and independent verification in the Completion Ledger. Unmapped means incomplete. In every supervisor-visible ledger, snapshot, notification, blocker, and final report, a Requirement, Work Package, Decision, or Gap id must be followed by its semantic content; bare ids such as `R-001, WP-004` are forbidden. `contracts/evidence.md` contains: ```markdown # Evidence ## Delivered Outcome ## Intent Coverage Matrix ## Work-Package Coverage ## Acceptance Evidence ## Tool Evidence ## Independent Reviews ## Plan Deviations ## Remaining Risks ## Completion Verdict ## Workflow Provenance ``` Workers contribute raw evidence but cannot sign their own completion. Only the Completion Assessor may make the final verdict complete. ## Filesystem handoff protocol Every cross-Agent output is a small, structured Handoff. Large output belongs in `artifacts/`; a Workflow return value contains only status, work-package id, and handoff path. Downstream Agents read the current contracts, direct-dependency handoffs, and necessary repository files—not the whole conversation or every prior output. Use this schema: ```markdown --- schema: peri.adlc/handoff-v1 adlc_id: logical_workflow: discovery-design | delivery-convergence phase: round: work_package: work_package_title: agent_id: