# AI-Generated Dependency and API Claim Verification

Amo ID: AMO-P-000277
Version: 1.1.0
Public URL: https://amo.ng/prompts/ai-generated-dependency-and-api-claim-verification

Summary: Checks AI-generated code for hallucinated packages, wrong versions, unsupported APIs, and framework claims before merge.

Use this for: Use this to verify dependency and API claims in generated code against the repo, lockfiles, types, and authoritative docs before merge.

Category: Codex & Coding
Tool: Codex
Difficulty: Expert
Prompt type: review

## Best Use Cases

1. Generated Code Merge Review
2. Dependency Claim Verification
3. Framework API Compatibility Check
4. Lockfile And Type Definition Audit
5. Unsupported API Finding Triage
6. Pre-Release Generated Code Gate

## Prompt Body

Verify dependency, package, framework, and API claims introduced by AI-generated code before merge.

Context to provide:
- Repository scope and task: [Repository scope and task]
- Relevant files and instructions: [Relevant files and instructions]
- Observed evidence: [Observed evidence]
- Constraints and authorized changes: [Constraints and authorized changes]
- Environment details without secrets: [Environment details without secrets]
- Verification commands and acceptance criteria: [Verification commands and acceptance criteria]

Objective:
Determine whether generated code relies on packages, versions, imports, methods, configuration keys, framework behavior, runtime features, or API signatures that are unsupported by the repository’s installed dependency set or by authoritative documentation. Produce a defensible review artifact for the release owner or package maintainer before merge.

Scope boundaries:
- Focus only on dependency, package, framework, runtime, type, and API claims introduced or materially affected by the generated code.
- Do not perform a broad dependency upgrade, architectural rewrite, style review, or generic code review.
- Do not assume an API exists because it appears plausible.
- Do not claim documentation, commands, tests, approvals, or files were inspected unless you actually inspected them.
- Separate direct observations from inferences and mark anything unverified.
- If authoritative documentation is unavailable, use installed package source, generated types, local docs, lockfiles, manifests, and compiler or test output where available; otherwise classify the claim as Unresolved and state what evidence is needed.
- Use exactly these claim outcomes:
  - Verified: admissible evidence confirms the claim for the installed or target version.
  - Contradicted: admissible evidence shows the claim is false or incompatible.
  - Unresolved: relevant evidence is missing, inaccessible, incomplete, or conflicting, so no conclusion is supportable yet.
  - Unsupported: no admissible evidence supports the assertion after the available repository and authoritative sources are checked.
Do not collapse Unresolved and Unsupported into a generic warning. Preserve uncertainty and identify the evidence needed to resolve each open claim.

Missing-input gate:
- Treat the generated change, applicable repository instructions, dependency manifests or lockfiles, target runtime or package version, and relevant API evidence as blocking when their absence or conflict prevents a claim from being scoped. Request all blocking items in one consolidated clarification and leave the affected claim Unresolved until they are supplied.
- Continue with non-blocking gaps only when each is recorded as Unknown or Unresolved, with the evidence needed and the consequence for merge or release confidence.

Required process:
1. Inspect relevant files first.
   - Review the generated diff or branch.
   - Inspect dependency manifests, lockfiles, package manager configuration, runtime configuration, framework configuration, relevant imports, generated or installed type definitions, and nearby usage patterns.
   - Identify every dependency or API claim introduced by the generated code before deciding whether edits are needed.

2. Build a claim inventory.
   Include claims such as:
   - Package or framework is available.
   - A package version supports a named API, export, method, hook, decorator, CLI option, configuration key, schema field, or runtime behavior.
   - Import paths, module formats, peer dependencies, plugins, adapters, or provider names are valid.
   - Type signatures, return values, error shapes, async behavior, or environment requirements match the generated code.

3. Verify each claim against evidence.
   Use the strongest available evidence in this order where practical:
   - Repository manifests and lockfiles.
   - Installed package source or type definitions.
   - Existing repository usage and tests.
   - Package manager, compiler, typechecker, linter, or framework diagnostics.
   - Authoritative documentation or release notes supplied or accessible in the environment.

4. Identify root cause before editing.
   For each Contradicted, Unresolved, or Unsupported claim, determine whether the issue is caused by hallucinated API usage, wrong package name, incompatible installed version, missing peer dependency, incorrect import path, runtime mismatch, stale documentation, incomplete local install, or insufficient evidence.

5. Correction policy.
   - Prefer no code edits unless a minimal correction is clearly justified by evidence.
   - If editing is necessary and within scope, apply the smallest safe change.
   - Preserve existing behavior and public interfaces unless the merge or release context explicitly authorizes a change.
   - Avoid broad rewrites, opportunistic refactors, dependency upgrades, and speculative migrations.
   - If the safest fix requires a dependency upgrade or product decision, do not perform it silently; document the decision required from the release owner, package maintainer, or security reviewer.

6. Verification.
   - Run syntax checks, type checks, targeted tests, or package manager inspection commands where available and appropriate.
   - If a command cannot be run, state why and list the verification gap.
   - Mention verification results exactly: command, outcome, and relevant error excerpt or confirmation.

Required deliverable:

A. Claim inventory
Provide a table with:
- Claim ID
- Generated-code location
- Claim being made
- Dependency, framework, runtime, or API involved
- Why the claim matters for merge safety

B. Version-and-source verification matrix
Provide a table with:
- Claim ID
- Installed or resolved version observed
- Evidence source inspected, with file path, lockfile entry, type definition, package source, command output, or documentation reference
- Claim status: Verified, Contradicted, Unresolved, Unsupported, or Not applicable
- Notes distinguishing observation from inference

C. Contradicted, unresolved, or unsupported claims
For each Contradicted, Unresolved, or Unsupported claim, include:
- Finding title
- Severity for merge: Blocker, High, Medium, or Low
- Direct evidence
- Root cause
- Expected failure mode
- Confidence level
- Missing evidence, if any

D. Minimal correction plan
For each finding, provide:
- Smallest safe correction
- Whether code change, dependency decision, documentation check, or owner decision is needed
- Files likely affected
- Behavior expected to remain unchanged
- Risk of the correction

E. Changes made, if any
- List every file changed.
- Summarize the exact purpose of each change.
- If no files were changed, state: No files changed during this verification pass.

F. Reproducible verification record
Include:
- Files inspected
- Commands run, if any
- Tests or checks run, if any
- Results observed
- Checks not run and why
- Open questions for the accountable owner named in [Merge or release context and accountable owner]

Completion criteria:
- Every generated dependency or API claim in scope is inventoried.
- Each claim is classified as Verified, Contradicted, Unresolved, Unsupported, or Not applicable using the stated evidence rules.
- Every Unresolved or Unsupported claim identifies the missing evidence, responsible evidence source or owner where known, and the consequence of proceeding without resolution.
- Unsupported claims have root cause and expected failure mode.
- No broad upgrades or rewrites are proposed as the default fix.
- Verification record is sufficient for the release owner, package maintainer, or security reviewer to reproduce or challenge the conclusion.

## Variables to Replace

1. Repository scope and task
2. Relevant files and instructions
3. Observed evidence
4. Constraints and authorized changes
5. Environment details without secrets
6. Verification commands and acceptance criteria
7. Merge or release context and accountable owner

## How to Use

Open Codex in the target repository. Replace every bracketed placeholder with the generated-code branch or diff, dependency manifests and lockfiles, runtime/package manager details, any authoritative docs or source references, and the merge context with the accountable owner. Let Codex inspect the relevant files before drawing conclusions. Paste or upload any external documentation that is not available in the repo. After running, have the release owner, package maintainer, or security reviewer verify unresolved claims and approve any dependency upgrade or compatibility decision before merge.

## Example Use Case

A team receives an AI-generated pull request that uses a new framework helper and a package export that look plausible but may not exist in the installed versions. The prompt guides Codex to inventory those claims, verify them against package.json, pnpm-lock.yaml, installed type definitions, and framework docs, then produce unsupported API findings and a minimal correction plan without turning the review into a broad refactor.

## Tags

1. codex
2. software-quality
3. verification
4. dependency-review
5. api-contracts
6. repository-inspection
7. evidence-based-review

## Dates

Published: 2026-08-19
Updated: 2026-08-19