# Engifoundry Orch > Materialize direct or Package execution contracts and orchestrate Phase, PAK, and Job records without executing them. Use after classification, for package creation or revision, roadmap planning, Job decomposition, and rework after package review. - Skill: `caoyuan-fire/engifoundry-orch` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add caoyuan-fire/engifoundry-orch` - Raw SKILL.md: https://api.skillmd.com/api/skills/caoyuan-fire/engifoundry-orch/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: caoyuan-fire (https://skillmd.com/u/caoyuan-fire) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/caoyuan-fire/engifoundry-orch --- # EngiFoundry Orch `` is the root of the target project. It normally contains `engifoundry.config.json`; the Router-authorized unconfigured fallback direct path is the only exception. `` is the directory containing this `SKILL.md`. These are independent locations: never infer the project root from the Skill installation path, and never look for bundled Orch resources under the project root. For configured work, read `/engifoundry.config.json`, the project-owned workspace guide, the Workflow config, and `/references/contracts.md` before writing records. For `package`, also read the complete Executor/Reviewer config and schema. Every Planning Review uses the configured Reviewer under `engifoundry-review`. For the Router-authorized unconfigured fallback direct path, read only `/references/contracts.md`. Use `.engifoundry/packages/`, create or reuse `PHASE-001`, and create only a `direct` PAK with one concise Job. Do not run Audit or create project configuration, workspace, Workflow, Executor, Reviewer, Package, or delivery records. These sparse paths are compatible with later Init adoption. Inline fallback never reads Orch. ## Boundary The Agent applies this contract to turn a classified task goal into execution input. While doing so, it does not select an Executor, edit implementation, perform delivery verification, or close delivery. For configured new work, Router reads `engifoundry-audit` before selecting Orch: - `direct`: create the minimal PAK and one Job requirement contract, then the controlling Agent implements it under Router Group Rules and closes it through Verify. - `package`: the Agent applies this contract to create execution input. `inline` and `blocked` do not read Orch. Do not re-audit a supplied classification or explicit continuation of an existing PAK or Job. `executionMode` is authoritative and is never inferred from files or field count. `migration`, or a missing mode with confirmed migration provenance, is preserved without Review, challenge, or runtime activation. ## Direct Record For `direct`, allocate one PAK and `JOB-001`, write the authorized requirement and overall acceptance boundary in `job.md`, and record only current status, evidence references, and `execution.verificationRef` in `package.config.json`. The narrative may contain the ordered actions, approvals, checkpoints, and controls needed for one atomic goal; these do not become separate Jobs without independent outcomes. The controlling Agent performs the work without Executor delegation, selects task-appropriate evidence, and may arrange bounded Review when it has concrete value. After implementation, set the Job to `completed` and execution to `verifying`; Verify is mandatory. Only a direct Verify result of `verified` permits execution status `completed`. The sparse structure is complete for its mode and does not trigger Planning Review, Exec delegation, Package verification extensions, or Deliver. ## Package Orchestration Before allocation, confirm the classification facts identify independent outcomes or a responsibility, acceptance, delegation, or handoff boundary that direct cannot represent. State that orchestration value in the existing `summary.md`; do not add a control field for it. Steps, files, risk, or publication activity alone are insufficient. 1. Resolve the relevant Phase from `phase.index.json`, Phase status, and Roadmaps. Use `PHASE-001` when the project has no meaningful period model. 2. Allocate Phase, PAK, and Job identifiers monotonically. Never reuse or renumber identifiers. 3. Write human narrative in Markdown and machine control in JSON using the reference contract. 4. Keep `planning.status: draft` while content is incomplete. 5. Before Review, simulate the Job sequence against its dependencies, outputs, shared areas, interfaces, versions, compatibility duties, and acceptance evidence. Set `reviewRequired` true only where scope or impact gives independent Review concrete value; keep it false for bounded work sufficiently controlled by required evidence. Record these facts in existing narrative and contract fields rather than inventing implementation detail. 6. When the PAK and every Job are internally consistent, record `planning.status: pending-review`. The configured Reviewer Worker reads `engifoundry-review`, examines the complete planning subject including dependency simulation and each Review decision, and returns its identity-locked handback. The first Review establishes the clean PAK Review chain; later Planning, Job, and rework Reviews default to the same Reviewer session unless the Review contract requires a reset. The controlling Agent validates the handback and records the conclusion. 7. Planning is `ready` only while a current valid PAK-chain Review pass exists and no newer blocking fact invalidates the contract. 8. Planning is `rework-required` only for an unresolved blocking Review finding whose facts can still be reconciled with the user's authorized goal, design, scope, and authority through permitted planning work. Continue correction or investigation until the contract passes or objective evidence establishes `blocked`; non-blocking findings do not delay readiness. 9. Planning is `blocked` while an objective fact prevents a usable Review conclusion or safe planning requires a user decision that changes the authorized goal, design, scope, or authority. `draft`, `pending-review`, and `rework-required` do not describe executable planning. Correction requires an actual relevant change and fresh evidence, continues independently of Review count, and ends only with `ready` or factual `blocked`. Quality refinement remains welcome within planning, but only blocking facts defined by Review delay `ready`. ## Blocked Contract Revision When Exec or Planning Review proves that safe continuation requires a contract, design, scope, or authority change, preserve the blocker evidence and prepare the complete minimum revision proposal without changing the current contracts. Pause for the user's decision. After authorization, revise only the affected contracts, reset to a new clean PAK Review chain when the change is material under the Review contract, obtain Planning Review, and resume Exec from the resulting recorded facts. ## Verification Extension For one current `extension-required` record, convert its complete extension specification into exactly one appended Job with `extensionRef`. Preserve every completed Job and its evidence. A PAK that already records an extension Job cannot append another. Review only the appended contract and its dependency effect, not the unchanged original planning. ## Output Write execution input only under the configured package root. The controlling Agent writes validated Reviewer evidence under the configured artifact review directory. Never store raw model output, credentials, cache state, or transient sessions in either location. ## Commands - macOS/Linux: `sh /scripts/orch.sh create-phase|create-direct|create-package|append-job|check --project-root [options]` - Windows: `powershell -ExecutionPolicy Bypass -File /scripts/orch.ps1 -Action create-phase|create-direct|create-package|append-job|check -ProjectRoot [options]` - Unconfigured direct fallback adds `--unconfigured-direct` or `-UnconfiguredDirect` to `create-phase`, `create-direct`, and `check`. The flag never authorizes `create-package` or `append-job`. Resolve the bundled script from `/scripts/` and always pass `` explicitly. Use the action matching the recorded mode or extension fact. Only when the correctly resolved script remains unavailable may the Agent use the complete reference contract manually. The helpers handle only allocation and skeleton creation. Fill every semantic field and require `check` before recording `pending-review`; when the helper itself is non-runnable, perform the equivalent contract checks manually. The Agent writes Review evidence, `reviewRef`, and conclusion state directly from the applicable contracts. ## Continuation For `direct`, the recorded minimal PAK lets the controlling Agent act, and completed implementation evidence lets it read Verify for mandatory closure. For a `package` endpoint that includes implementation or delivery, a `ready` PAK is the fact that lets the Agent read Exec. A recorded appended Job also lets Exec continue. A bounded orchestration request ends with its recorded fact. Mode-selection and dependency-simulation examples are in [examples.md](references/examples.md).