Menu
Audit an implementation for unnecessary artifacts, test manipulation, hardcoded shortcuts, fake success, bypassed product paths, and unsupported completion claims
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | implementation-integrity |
| description | Audit an implementation for unnecessary artifacts, test manipulation, hardcoded shortcuts, fake success, bypassed product paths, and unsupported completion claims |
| disable-model-invocation | true |
Audit whether an implementation honestly satisfies the requested task through the real product path, with only necessary artifacts and evidence that supports its completion claims. This is a read-only audit; do not repair, delete, regenerate, commit, or deploy while using this skill.
Central question:
Did the agent solve the requested task honestly through the real implementation path, with only necessary artifacts and evidence that supports its completion claims?
This skill does not replace test-and-debug, public-code-review, or
release-deploy. Intended sequence:
implement-minimal -> test-and-debug -> implementation-integrity
-> public-code-review -> release-deploy
oss-plan or implement-minimalpublic-code-reviewtest-and-debugUse, in order of preference:
If acceptance criteria are unavailable, do not invent them. Provisional criteria may be derived from explicit repository evidence, but must be labelled as inferred. If there is no usable task definition or baseline, stop and request the missing input.
Define the comparison baseline before reviewing. Support:
HEADDo not silently choose a remote branch or fetch from the network. Record the selected baseline in the report.
Read the first of these that exists, then follow it:
${CLAUDE_PROJECT_DIR}/.claude/shared/LOW_RESOURCE.md$HOME/.claude/shared/LOW_RESOURCE.mdIf neither exists, continue with these built-in constraints: inspect changed files before the wider repository, run one command at a time, use targeted validation first, avoid watchers, avoid full builds and full suites unless required at a milestone, bound large output, do not install tools, and do not use subagents merely for speed.
Read the first of these that exists, then follow it:
${CLAUDE_PROJECT_DIR}/.claude/shared/CONTEXT_EFFICIENCY.md$HOME/.claude/shared/CONTEXT_EFFICIENCY.mdIf neither exists, apply this fallback: select files before reading; use targeted searches and bounded ranges; do not preload references; do not reread unchanged files; finish one atomic increment and stop; create a compact handoff before context is exhausted.
git status.gitignore, and
documentation changesRun these phases in order:
Phase 1 - scope and changed-file inventory
Phase 2 - artifact necessity audit
Phase 3 - test and validation integrity
Phase 4 - implementation-path integrity
Phase 5 - fake-success and bypass audit
Phase 6 - requirement-to-evidence mapping
Phase 7 - independent targeted validation
Phase 8 - verdict and human-review boundary
Produce, using templates/integrity-report.md:
End with exactly one:
integrity confirmed for tested scope
integrity partially confirmed
integrity not confirmed
blocking integrity issue found
Do not return integrity confirmed for tested scope unless all of the
following hold:
This skill is a read-only audit. It must not automatically modify
implementation code, delete artifacts, update snapshots, rewrite tests, change
tolerances, alter CI, edit .gitignore, install dependencies, regenerate
outputs, commit, push, deploy, or publish. After the audit, perform any repair
separately with implement-minimal.
Do not convert skipped validation into a pass.
Produce the report in the exact section order of
templates/integrity-report.md, ending with one
verdict. Then stop; repairs happen separately under implement-minimal.
Evaluate whether to add a new runtime or development dependency to a public open-source project before adding it. Use whenever a new package is proposed. Weighs standard-library alternatives, cost, transitive impact, maintenance, license, supply-chain risk, and low-resource effect, then decides add, do not add, or defer. Does not install anything.
Implement the smallest complete change that satisfies the current acceptance criteria for a public open-source project. Use when writing or editing code after a plan or a clear acceptance criterion exists. Avoids speculative abstraction, unrelated changes, obvious comments, and unverified validation claims. Keeps the project runnable after the increment.
Prepare a new public open-source repository, or convert a small existing directory into a clean publishable starting point. Use for an empty or nearly empty repo, a first local commit, or a first remote push. Do not use for routine feature work or releasing an established project. Never commits, creates a remote, or pushes unless explicitly requested.
Produce an execution plan before writing substantial code for a public open-source project. Use when starting or extending a feature to define the narrowest end-to-end slice, validation per step, trust boundaries, deployment path, and public-repository risks. Keeps the project runnable after every step. Does not write implementation code.
Review the current diff or a specified set of files as public open-source code before publishing or merging. Use to check code quality, public-repository safety (secrets and private data), documentation trustworthiness, provenance, onboarding, and maintainability. Reports grouped findings; does not fix them unless asked.
Prepare a public open-source project for release and deploy it to a detected target. Use at a release or submission boundary to verify setup, docs, secrets, tests, lint, build, and licenses, then follow the target-specific deployment path. Runs expensive checks sequentially. Never publishes, tags, commits, pushes, or deploys without explicit user intent.