# Engifoundry Audit > Classify new EngiFoundry work for inline action, a minimal direct PAK, a fully planned Package PAK, or a factual block. Use when deciding whether durable task identity and heavyweight orchestration add material value. - Skill: `caoyuan-fire/engifoundry-audit` (Agent Skill) - Install (CLI): `npx skillmds@latest add caoyuan-fire/engifoundry-audit` - Raw SKILL.md: https://api.skillmd.com/api/skills/caoyuan-fire/engifoundry-audit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: caoyuan-fire (https://skillmd.com/u/caoyuan-fire) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/caoyuan-fire/engifoundry-audit --- # EngiFoundry Audit Use this classification only after complete Initialization. Read the configured Workflow file and inspect only the new task facts needed for classification. Unconfigured fallback uses the equivalent Router boundary without project preferences or heavyweight execution authority. ## Boundary The Agent applies these rules only to classify new work as `inline`, `direct`, `package`, or `blocked`. Classification does not execute, plan, split Jobs, edit files, ask for approval, or write durable records. Continue work already bound to a PAK or Job under that identity instead of allocating another one. Keep only concise observed facts sufficient to support the classification. Do not introduce recommendations or proposed implementation. ## Project Relevance Current-project relevance is the applicability boundary for every classification in this contract. A request is relevant when the user's intent materially concerns the current project, its contents, interfaces, engineering operations, or delivery, or continues work already bound to one of its PAKs or Jobs. The current working directory, an available EngiFoundry configuration, use of engineering tools, and task complexity, risk, or duration do not establish relevance by themselves. A request that targets another project or has no material relationship to the current project is outside this classification domain. `inline`, `direct`, `package`, and `blocked` are all inapplicable, and no current-project PAK or other EngiFoundry record is justified. An explicit user request to manage that work through the current project's EngiFoundry runtime overrides this boundary. Project relevance has precedence over persistence value, execution topology, and configured preferences. Router treats out-of-domain work as an ordinary request rather than as an Audit classification or runtime state. ## Decision Prefer the lightest path that preserves sufficient control. First decide whether a PAK has material persistence value, then whether heavyweight orchestration has material execution value. Risk strengthens safeguards and evidence on the selected path; it changes topology only when those controls require an independent responsibility, acceptance, delegation, or handoff boundary. Classify as `inline` when a bounded operation can be completed and confirmed in the current context and a durable requirement, recovery, coordination, or acceptance record would add no material value. Existing PAK, commit, issue, or release identity may already supply sufficient traceability. Inline is a judgment, not a checklist or synonym for low effort; do not use it when the user requests a PAK or when safe control requires durable task evidence. Otherwise classify one goal, one controlling execution unit, and one overall acceptance boundary as `direct`. A direct goal may contain many ordered steps, files, checks, approvals, external systems, checkpoints, or repository and publication operations. Their number, risk, or sequencing does not make them independent Jobs. The controlling Agent executes direct work without Executor delegation and may arrange bounded Review when it has concrete value. Classify as `package` regardless of preference when the user explicitly requests full Package or Job orchestration, Executor delegation is required, or reliable execution requires independently acceptable outcomes, separate responsibility or approval, or durable cross-session or human handoff between work units. Meaningful decomposition normally gives most proposed Jobs an independent outcome, acceptance, and Review value plus a dependency or handoff worth recording. A possible Review, stronger evidence, or recovery checkpoint inside one execution unit is not enough. Security, data, release, migration, destructive, and delivery risk require proportionate authorization, safeguards, evidence, and verification. They require `package` only when a single direct execution unit cannot reliably contain them without one of the independent boundaries above. Do not select `package` solely because work has many operations or files, invokes external systems, or includes commit, push, tag, publish, release, migration, rollback, or destructive commands. Apply `actionPreference` only after these boundaries: - `package-first`: prefer `package` when useful independent units genuinely exist; keep atomic work `direct`. - `balanced`: use `package` for independently acceptable units, material dependency coordination, delegation, or handoff; otherwise use `direct`. - `direct-first`: use `direct` unless full orchestration has demonstrable independent execution or coordination value. Ordinary uncertainty, difficulty, duration, or failed attempts inside one atomic goal does not produce `package`. Use `blocked` only when an inaccessible objective or invalid required input prevents any safe actionable classification; state that fact and the observed failure. `inline` proceeds under Router Inline Rules without Orch or durable EngiFoundry records. `direct` reads Orch to create one minimal PAK and Job before controlling-Agent action; `package` reads Orch to create the complete planned contracts. Classification itself writes nothing.