# Engifoundry Verify > Enforce EngiFoundry's mandatory closure gate by accepting a direct task against its concise requirement contract or synthesizing Package Job conclusions, Review findings, and evidence against the complete PAK contract. - Skill: `caoyuan-fire/engifoundry-verify` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add caoyuan-fire/engifoundry-verify` - Raw SKILL.md: https://api.skillmd.com/api/skills/caoyuan-fire/engifoundry-verify/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: caoyuan-fire (https://skillmd.com/u/caoyuan-fire) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/caoyuan-fire/engifoundry-verify --- # EngiFoundry Verify For configured work, read `./engifoundry.config.json`, the project-owned workspace guide, and [contracts.md](references/contracts.md). For the Router-authorized unconfigured fallback direct path, read only [contracts.md](references/contracts.md), use the default `.engifoundry/packages/` PAK and write verification under `.engifoundry/artifacts/verification/`; do not require configuration or create preference files. Then read the Phase context and PAK. For `direct`, read its concise Job requirement contract, implementation outputs, current evidence, and any actual Review. For `package`, read every Job result and Review, every required artifact, and any prior Verify extension. ## Boundary For `direct`, the Agent reads this contract after the controlling Agent has completed implementation and set `execution.status: verifying`. Verify is the mandatory final requirement-contract acceptance gate. It does not implement corrections or enlarge the requirement; a correctable failure returns bounded work to the controlling Agent. For `package`, the Agent reads this contract only with `planning.status: ready` and `execution.status: jobs-completed`, and verifies the complete PAK goal rather than individual Job steps. It does not implement, revise contracts, repeat Job Review, accept verification, deliver, or reopen or rewrite completed Job states. Automation preferences never weaken verification evidence. Package evidence is an input fact for Deliver; direct verification is itself the final acceptance and does not enter Deliver. ## Direct Closure Keep direct Verify as small as the task permits, but never omit it. Map the authorized requirement and acceptance boundary to the actual output and fresh evidence. Confirm all three closure facts: 1. **Qualified:** the requested result works and no known failure invalidates delivery. 2. **No drift:** changes and conclusions remain inside the authorized requirement and scope. 3. **Acceptable:** evidence is sufficient for a reasonable recipient to accept this specific task. Test is evidence, not a mandatory ritual. The Agent chooses whether a focused unit test, existing suite, static check, real runtime, emulator, device, visual inspection, or another concise method best proves the requirement. UI and interaction work commonly need actual runtime or device evidence; a deterministic path or boundary bug commonly benefits from a focused unit or regression test. TDD is not a direct Verify requirement. Reuse valid current evidence and run only missing checks needed for closure. An optional direct Review is relevant evidence when it occurred, but Review absence is never a gap by itself. Write one immutable concise verification record and attach it as `execution.verificationRef`. Direct Verify records exactly one result: - `verified`: every requirement is satisfied, scope has not drifted, and evidence is sufficient. Set direct execution to `completed`; this is final acceptance. - `rework-required`: a concrete failure or evidence gap is correctable within the concise requirement. Return execution to `in-progress` for bounded controlling-Agent correction, then create a new Verify record. - `blocked`: an objective unavailable input or environment prevents acceptance and no valid alternative evidence exists. Direct Verify never produces a Package extension, invokes Executor, or enters Deliver. Being a light task can reduce the breadth of checks, never the closure threshold. ## Package Verification 1. Record `execution.status: verifying` while evidence is synthesized. 2. Map every PAK criterion to Job conclusions and current valid evidence. 3. Synthesize every Job conclusion, blocking and non-blocking Review finding, accepted risk rationale, dependency obligation, required artifact, and closeout fact. 4. Reuse current valid evidence. Run only the minimum missing PAK-level check when coverage is absent, contradictory, or invalidated, or when integration cannot be shown by Job evidence. 5. Judge prior risk acceptance against the contract, its recorded operating assumptions, required baseline checks, and the material-risk floor. Expanded scale, concurrency, threat, availability, or usage scenarios apply only when evidence invalidates a recorded assumption or makes the risk reachable inside its boundary; a preferred implementation or newly expanded goal does not. 6. Write one immutable verification record and attach it as `execution.verificationRef`. The completed verification record has exactly one result whose meaning matches the evidence: 1. If every criterion and required baseline check is satisfied and remaining risks have sufficient non-blocking rationale under the recorded operating assumptions, write `verified-available`. 2. If one complete, bounded addition can close every remaining contract or evidence gap, and no extension was used, write `extension-required` with one complete extension specification for exactly one appended Job. 3. If a major evidenced contract breach makes the execution chain unacceptable, or the appended Job completed without closing its specified gap, write `rejected`. 4. If a required conclusion cannot be reached because of an objective external condition and no valid alternative evidence exists, write `blocked`. For Package verification, never write `pass` or `rework-required`. `verified-available` means evidence is available; it is not acceptance. Ordinary disagreement with a non-blocking technical choice cannot produce an extension or rejection. An extension specification states all gaps, contract references, dependencies, protected completed Jobs, required outcome, acceptance criteria, verification plan, and why one appended Job is sufficient. Orch materializes it without reopening prior Jobs. Once `extensionUsed` is true, Verify must not return `extension-required` again. A later new user goal belongs to a new PAK. `rejected` rejects the execution chain rather than scheduling rework. It requires a major evidenced contract breach and an explanation of why the single extension cannot or did not close it. Completed Job records remain historical facts. ## Continuation - Direct `verified` is terminal and permits direct execution `completed`. - Direct `rework-required` lets the controlling Agent make the minimum in-scope correction and Verify again. - For an endpoint that includes delivery, `verified-available` lets the Agent read Deliver and continue with the PAK and verification record. - `extension-required` lets the Agent read Orch for the one appended Job. - `rejected` is terminal for the execution chain. - `blocked` is terminal while its objective fact remains. Never continue without the required record or without loading the destination Skill first. Evidence synthesis and one-extension examples are in [examples.md](references/examples.md).