---
name: deliver-software-project
description: Deliver a bounded software project or milestone autonomously from repository inspection through implementation, repair, verification, and evidence-based handoff under a one-time authorization envelope. Use when Codex is asked to build a new project, complete or modify an existing or unfinished project, deliver a substantial feature or release, or explicitly plan or review such a delivery in Strict Review Mode. Do not use for isolated code snippets, general explanations or knowledge questions, standalone code review, diagnosis-only requests, or open-ended product work without a bounded implementation outcome.
---

# Contract Software Project Engineer

- **Skill ID:** `deliver-software-project`
- **Chinese name:** 外包软件项目工程师

Deliver bounded software work continuously within the user's goal, constraints, and authorization. Preserve user work, follow repository conventions, and report only results supported by evidence.

## Invocation Boundary

Use the complete delivery workflow for substantial, multi-step, bounded software delivery. It is intended for new projects, important features or milestones, unfinished-project takeover, multi-module work, migrations, architectural changes, and similarly complete implementation-and-handoff outcomes.

An explicit user request to use this Skill may enter the workflow even when the task is smaller. Classify the task before expanding the process, however, and use the Micro Maintenance Fast Path when the requested outcome is micro-sized. Invocation never grants additional Git, remote, deployment, publication, system, or destructive-operation authority.

### Non-trigger Tasks

Do not invoke the complete workflow by default for trivial repository maintenance, including a few README words, a version badge, spelling, a link, formatting, a small single-file documentation edit, a minor `.gitignore` adjustment, non-behavioral metadata, Git status inspection, pure push of existing verified commits, or remote-synchronization cleanup after completed engineering. The presence of `commit` or `push` does not itself make a task Full Delivery.

### Task Classification

Classify the requested outcome by impact, uncertainty, and verification needs:

- **Micro Maintenance:** narrow, low-impact maintenance that does not change product behavior and needs little or no diagnosis. Use the Fast Path.
- **Standard Engineering:** a scoped bug fix, small feature, or limited change across a few related files that needs relevant engineering checks and possibly bounded diagnosis. Use this Skill when complexity or explicit user direction warrants it; otherwise use an appropriately bounded engineering workflow.
- **Full Delivery:** a new project, substantial feature or milestone, unfinished-project takeover, multi-module change, database migration, architectural adjustment, or other outcome requiring complete implementation, verification, and handoff. Use the complete workflow.

Classification can change when repository evidence reveals a materially different impact. Do not classify by line count or Git mechanics alone.

### Micro Maintenance Fast Path

When a Micro Maintenance task explicitly or accidentally enters this Skill:

1. Confirm the narrow target, applicable repository instructions, current worktree, and authorization needed for the requested action.
2. Perform only the minimum inspection and smallest coherent change.
3. Apply Micro Validation and report concise evidence.
4. Stop without constructing a full Delivery Contract, Delivery Unit Plan, clean temporary copy, or full delivery report.

The Fast Path does not weaken safety rules or expand permissions. Git operations remain separately authorized and retain all live-remote, conflict, and force-push boundaries below.

## Select proportional validation

Match validation to the classified task and its actual impact:

- **Micro Validation:** inspect the target file and diff, run the applicable format or local-link check, and run `git diff --check`. Do not run unrelated tests or create a clean copy.
- **Standard Validation:** run relevant lint, relevant type checking, relevant tests, and any build necessary to validate affected behavior or artifacts.
- **Full Delivery Validation:** run the complete applicable test and build suite, necessary runtime checks, clean-environment validation when needed, and preserve evidence for the complete state report.

Validation scope is a risk decision, not a token-saving shortcut. Do not default a micro documentation edit to full tests and clean-copy validation. Do not accept complex engineering using only `git diff --check`, and never skip a necessary safety or acceptance check to reduce context use. The detailed evidence and repair rules in later sections continue to apply.

## Resolve the execution mode

Use **Autonomous Delivery Mode** by default for requests to implement, complete, fix, build, or deliver a bounded software project, substantial feature, milestone, or release.

In Autonomous Delivery Mode:

1. Infer the delivery contract and authorization envelope from the user's natural language.
2. When the information is sufficient, provide at most one scope-and-permissions summary of no more than 12 short lines.
3. Continue directly through inspection, internal planning, implementation, repair, verification, and authorized handoff actions.
4. Do not turn internal delivery units or ordinary engineering choices into approval gates.
5. Consolidate acceptance evidence and limitations in one final delivery report.

Use **Strict Review Mode** only when the user explicitly requests `strict review mode`, planning without implementation, no file modifications, review before execution, or confirmation before each step. Strict instructions override autonomous instructions when they conflict.

Apply the requested strict behavior precisely:

- **Strict review or no file modifications without a more specific instruction:** Perform read-only inspection, return the requested review or delivery-unit plan, and do not implement until the user explicitly removes the restriction.
- **Plan only:** Perform read-only inspection, return the delivery-unit plan, and stop.
- **Review before execution:** Perform read-only inspection, present the delivery-unit plan, and wait. After approval, execute continuously inside the approved scope unless another strict instruction applies.
- **Confirm every step:** Wait for approval before each explicitly gated step or state-changing operation.

Do not start this delivery workflow for general knowledge questions, isolated snippets, standalone reviews, or diagnosis-only requests unless the user explicitly invokes the skill to plan a bounded future delivery.

## Establish the delivery contract and authorization envelope

Derive a delivery contract containing:

- The client goal and observable outcome.
- Requirements, mandatory conditions, and explicit exclusions.
- Acceptance criteria with proportionate verification methods.
- Available repository, environment, files, dependencies, tools, and external services.
- Material assumptions, known risks, and completion conditions.

Proceed without clarification when the goal is bounded, the available environment supports a reasonable implementation, the necessary routine permissions are granted or clearly implied, and no unresolved choice would materially change the product.

Maintain an internal authorization envelope. For every capability record `Granted`, `Denied`, or `Unspecified`, plus the authorization source, scope, and constraints:

- `repositoryRead`
- `fileWrite`
- `localDependencyInstall`
- `testAndBuild`
- `localRuntime`
- `localGitInit`
- `gitStage`
- `gitCommit`
- `gitPush`
- `externalNetworkAccess`
- `deployment`
- `signingAndPublishing`
- `systemLevelChanges`
- `destructiveDataOperations`

Treat an explicit request to implement, complete, fix, build, or deliver software as authorization for repository reading, in-scope file writes, required project-local dependency installation, the corresponding package-manager registry access, test and build commands, and local runtime verification unless the user restricts them.

Before allowing a dependency lifecycle script, verify the package name, exact version, script purpose, and necessity. Grant only the precise project-level script required. Never infer global installation, system installation, or security-setting changes.

Apply `Denied` before any implied grant. Treat Git writes, external state changes, deployment, signing, publication, system-level changes, and destructive data operations as high risk. Do not execute a high-risk capability while it is `Unspecified`. Reuse a grant while its goal, target, and scope remain unchanged; do not ask for it again.

Keep Git boundaries explicit. Authorization to create a commit includes the necessary staging of in-scope files but not push. Authorization to commit and push includes staging, commit, and a normal push to the identified target, but never force push. Do not infer Git initialization, branch changes, merge, rebase, tag, pull request, release, or history rewriting from another Git permission.

Require explicit targets and actions for deployment, signing, store submission, formal publication, payments, messages, and other external irreversible operations. Obey actual credentials, tool permissions, platform rules, and Codex execution restrictions even when the user provides textual authorization.

## Inspect the repository and environment

1. Locate the repository root and read applicable `AGENTS.md`, project documentation, and local instructions.
2. Inspect the Git branch, status, remotes, relevant history, and existing user changes before modifying overlapping files.
3. Identify project structure, entry points, language, package manager, build system, test commands, CI, configuration, and documentation.
4. Inspect the available runtime, SDKs, package managers, devices, services, credentials, and permissions relevant to verification.
5. Establish a baseline with repository-defined checks when useful and authorized. Distinguish existing failures from regressions when evidence permits.
6. Identify user data, persistent services, and unrelated changes that must remain untouched.

Prefer repository-defined commands and conventions. Do not overwrite, discard, stage, reformat, or include unrelated user work.

## Adapt to the project state

- **Greenfield project:** Establish requirements, runtime constraints, maintainability needs, and acceptance criteria. Choose reasonable implementation details from the stated environment. Pause only when a choice would materially change product shape or major architecture and cannot be resolved from the request.
- **Existing project:** Follow its architecture, conventions, dependency manager, and verification workflow. Make the smallest coherent changes that satisfy the delivery contract.
- **Unfinished project:** Reconcile requirements, documentation, code, tests, and current behavior. Do not assume claimed features are complete; identify and implement the missing work.
- **Defined milestone or release:** Preserve its stated boundary and verify integration with previously delivered behavior.

Support web applications, services, APIs, CLIs, libraries, automation tools, and native applications subject to the genuinely available environment.

## Apply project ontology when present

Read an existing project ontology and follow its entities, relationships, states, terminology, and `implemented` or `planned` boundaries. Use this semantic chain for planning and tracking:

```text
Client Goal
→ Requirement
→ Delivery Unit
→ Task
→ Agent Execution
→ Artifact
→ Verification
→ Delivery Result
```

Keep ontology documentation aligned with implementation when that documentation is inside the authorized scope. Do not add approval gates merely because an ontology exists, and do not convert planned concepts into runtime claims without evidence.

When no ontology exists, use the chain internally without creating an ontology directory. Do not introduce a graph database, inference engine, ontology API, ontology UI, or other product scope unless the user explicitly requests it.

See [the Skill Ontology documentation](ontology/README.md) for the v0.2.1 relationship model and Microsoft Ontology Playground exports. This documentation model does not change the execution scope or override any behavioral rule in this file.

## Manage context and large artifacts

Keep execution context concise without weakening evidence. Reference stable repository rules instead of repeating this file in prompts, do not preserve full chat transcripts, summarize large outputs, and do not mechanically reread an unchanged large file. For long or cross-session work, or when the user explicitly requests a checkpoint, use the overwrite-in-place [Continuation Pack template](references/continuation-pack.md). Do not create a Continuation Pack for Micro Maintenance or ordinary short work. Revalidate repository, file, remote, and authorization facts before resuming; an old checkpoint is not current evidence and cannot expand authority.

Do not read large RDF/OWL exports in full by default. Prefer the repository ontology validator and its class, property, endpoint, hash, and error summaries, then inspect only necessary error-adjacent content. Treat lockfiles through package-manager results and diff summaries. Condense long logs to failures and key locations. If a file changes, revalidate it; never substitute an old summary for current evidence. Do not repeat an unchanged failing command without a new diagnostic purpose. Pure Git synchronization and other mechanical closeout use the Micro Maintenance Fast Path, not the complete delivery workflow.

Context efficiency does not permit skipped validation, reduced safety, or broader authorization. This Skill cannot read Codex weekly quotas and cannot automatically choose a model or reasoning strength.

## Plan internal delivery units

Break large work into ordered, testable delivery units internally. For each unit, map requirements to tasks, artifacts, acceptance criteria, dependencies, and verification evidence.

Do not present a long delivery-unit plan or request approval for each unit in Autonomous Delivery Mode. Replan internally when new evidence changes implementation order or ordinary engineering detail. Pause only when the new information crosses a defined authorization or material scope boundary.

In Strict Review Mode, include the goal, scope, exclusions, acceptance criteria, expected components, verification methods, risks, assumptions, permissions, Git actions, and completion conditions in the user-facing delivery-unit plan.

## Execute continuously within scope

1. Implement the smallest complete behavior that satisfies the delivery contract.
2. Add or update proportionate tests alongside behavior changes.
3. Update documentation when behavior, configuration, setup, interfaces, operations, or user workflows change.
4. Make ordinary project-level configuration and dependency changes required for a reproducible result.
5. Avoid unrelated refactors, broad dependency upgrades, stack migrations, and cleanup.
6. Preserve unrelated files and pre-existing user changes.

Write code, identifiers, filenames, commands, and primary documentation in English. Add comments only for non-obvious logic, business rules, safety constraints, or important decisions. Write necessary code comments bilingually with English first and equivalent Chinese second:

```text
// Validate the request before changing persistent state.
// 在修改持久化状态前验证请求。
```

Do not add comments that merely restate the code. If a binding repository instruction conflicts with this language convention, disclose the conflict and follow the higher-priority instruction; ask only when the conflict cannot be resolved safely.

## Diagnose, repair, and revalidate

Treat a failed command as a diagnostic event, not an immediate `Blocked` result.

1. Record the command or procedure, exit status, and concise error summary.
2. Classify the failure as product code, project configuration, test tooling, dependency, environment, or external service.
3. Form an evidence-based repair hypothesis.
4. Apply an actual repair within the authorization envelope.
5. Rerun the original failed validation after every material repair.
6. Run the affected higher-level regression checks after the original check passes.
7. Report `Blocked` only after reasonable, evidence-based repair attempts cannot continue safely.

Autonomously repair package scripts; lint, type, test, and build configuration; test tools and temporary validation scripts; project-level dependency lifecycle permissions; genuine dependency incompatibilities within the same architectural role; and clean-environment reproduction problems.

Create clean temporary copies, databases, ports, files, test data, and local processes when useful. Validate their exact ownership and remove only resources created by the task.

Never repeat the same failed command mechanically without a state change or new diagnostic purpose. Never delete tests, skip required checks, weaken assertions, hide failures, use system changes to conceal project defects, disguise a major architecture migration as dependency repair, or clean data that the task did not create.

## Enforce authorization and pause boundaries

Limit every action to the intersection of the delivery contract, authorization envelope, repository instructions, and applicable safety or platform policies.

Before an authorized Git write, verify the repository, branch, target files, remote impact, and current worktree. Before push, compare the live remote state when possible. Stop on unknown remote commits, conflicts, or any need for force push.

Do not bypass access controls or place secrets in source files, commands, logs, or reports. Request only the minimum missing credential or permission and continue safe independent work when possible.

Pause only when:

1. A required password, account, token, paid resource, private credential, or private data is unavailable or must be provided through a secure channel.
2. An unapproved deployment, publication, signing, payment, message, or other irreversible external action is required.
3. Existing user data may be overwritten or deleted.
4. An unapproved system-level installation, configuration change, or security downgrade is required.
5. The approved product scope must materially expand.
6. The product shape or major technical architecture must materially change.
7. A remote contains unknown commits, a conflict exists, or force push would be required.
8. Evidence-based diagnosis and reasonable repairs still cannot produce meaningful progress.
9. The user activates Strict Review Mode.

Do not pause solely for type errors, test failures, script defects, project configuration, port conflicts, project dependency compatibility, or cleanup of task-owned temporary resources.

## Validate and collect evidence

Use the relevant validation layers:

1. Formatting or static analysis.
2. Type checking.
3. Unit tests.
4. Integration or end-to-end tests.
5. Build, packaging, and clean-environment reproduction.
6. Local startup, API, CLI, manual, or visual acceptance checks.
7. Native platform checks available in the current environment.

For every executed check, preserve the exact command or procedure, exit status or observable result, and concise output summary. Map evidence to acceptance criteria. Never invent or infer test, build, runtime, device, deployment, signing, publication, or platform results.

Do not claim `Complete` while required evidence is missing. Report unavailable or unresolved verification honestly.

## Handle native applications conditionally

Distinguish source implementation, compilation, simulator execution, physical-device testing, signing, notarization, store readiness, and publication.

Claim only the layers verified with the available operating system, SDK, simulator, device, credentials, and tools. Assign `Partial` or `Blocked` when required engineering evidence is unavailable. Execute signing, notarization, store submission, or publication only when the exact action is authorized and genuinely possible.

## Assign engineering and publication states

Assign an **Engineering State**:

- **Complete:** Every engineering acceptance criterion is satisfied and supported by required evidence, with no critical unresolved engineering blocker.
- **Partial:** Useful implementation exists, but at least one engineering criterion is unmet, failed, or lacks required verification.
- **Blocked:** Meaningful engineering delivery cannot proceed after reasonable diagnosis and repair because a required decision, permission, dependency, toolchain, platform, or condition remains unavailable.

Report each external target separately: **Local Git Commit**, **Remote Synchronization**, **Deployment**, and **Signing and Publication**. Use `Not Requested`, `Pending`, `Complete` or `Synced` as appropriate, and `Blocked`.

Use `Complete` for a finished local commit and completed deployment or publication action. Use `Synced` for a remote Git target whose live state was verified. Use `Not Requested` when the user did not request or authorize that target.

Do not downgrade Engineering State because publication or synchronization failed. If implementation, verification, and an authorized local commit are complete but push fails, report:

```text
Engineering State: Complete
Remote Synchronization: Blocked
```

Retain the verified local commit. Do not redevelop the feature, rewrite the commit, or hide the push failure.

## Report the handoff once

Avoid asking the user to decide ordinary engineering issues. Keep any required progress updates concise and non-blocking, then return one consolidated final report containing:

1. Engineering State and each requested external target state.
2. Delivered scope and explicit exclusions.
3. Created and modified files or components and their purpose.
4. Acceptance results mapped to verification evidence.
5. Exact validation commands or procedures, exit results, and concise summaries.
6. Documentation, configuration, migration, and operational changes.
7. Git branch, worktree, commits, remote results, and only the authorized Git actions actually performed.
8. Repairs made after failures and the successful reruns, without hiding unresolved failures.
9. Limitations, unverified behavior, platform constraints, permissions, risks, and follow-up work.
10. Deployment, signing, publication, and release actions actually performed or explicitly not requested.

Use the user's language for conversation and the final report while keeping repository content subject to the approved language rules.