Vendor deliverable acceptance review
Checks a vendor deliverable against the statement of work, acceptance criteria, test evidence, milestones, and prior defects, then produces a cited acceptance recommendation and remediation register. Use for supplier handoffs, agency work, project gates, or invoice-readiness reviews.
Veröffentlicht 21. Aug. 2026 · Aktualisiert 26. Aug. 2026
Voraussetzungen
Add the statement of work, acceptance policy, and test checklist. Define defect severity, tolerance, and conditional-acceptance rules. Map deliverable versions and defect IDs to source records. Specify escalation roles and invoice-readiness criteria.
Skill-Dokument
Das vollständige SKILL.md, das dein Agent liest und befolgt.
Vendor deliverable acceptance review
Purpose
Make a vendor handoff auditable. The review tests each contractual or agreed requirement, records evidence, separates blocking defects from observations, and states whether the package is accepted, conditionally accepted, or rejected under the supplied rule.
Scope
Assess the named deliverable version against scope, measurable acceptance criteria, test evidence, dependencies, and prior defects. Preserve the difference between a missing artifact and a failed criterion.
Excluded: changing the contract, negotiating with the vendor, approving payment, fixing the deliverable, or inventing a tolerance.
Data basis
- Statement of work, change orders, and deliverable specification.
- Submitted deliverable and delivery note with version, date, and included components.
- Acceptance checklist, test results, quality thresholds, and evidence links.
- Defect register with severity, owner, due date, and prior resolution status.
Result
An acceptance matrix, defect register update, and recommendation memo.
Quality criteria
- Every acceptance criterion has pass, fail, blocked, or not evidenced status with a source citation.
- Defects identify requirement, evidence, severity, impact, owner if stated, and remediation condition.
- Version and delivery date match the handoff record or are flagged.
- The recommendation follows the acceptance policy’s blocking-defect rule.
- Prior defects are marked re-tested, still open, or not re-tested with evidence.
Instructions
Use the statement of work and acceptance checklist as the authority; use the defect register for history, not as proof of current performance. Test only what the supplied evidence supports. A missing test result is not evidenced, not pass. Apply severity and conditional-acceptance rules exactly. Reconcile component counts and versions before making the recommendation.
Adapt before use
- Add the statement of work, acceptance policy, and test checklist.
- Define defect severity, tolerance, and conditional-acceptance rules.
- Map deliverable versions and defect IDs to source records.
- Specify escalation roles and invoice-readiness criteria.
Verwandte Skills
- Change request assessment
Assesses a project change request against the approved baseline and produces a traceable impact analysis for scope, schedule, cost, quality, risk, resources, and dependencies. Use for change control boards, project governance, variation requests, scope changes, and decision papers.
- Construction change-order pack
Builds a documented construction variation package from the change trigger, contract terms, quantities, rates, and time effects. Use for change orders, variation claims, owner instructions, design changes, and subcontractor pricing review.
- executive document brief
Creates a source-linked executive document brief deliverable using concrete fields, rules, exceptions, and review controls. Use for decision question, board memo, actual, forecast, reconciliation, quality review, or operational reporting.
- hr record data quality
Creates a source-linked hr record data quality deliverable using concrete fields, rules, exceptions, and review controls. Use for employee_id, hire_date, manager_id, duplicate, reconciliation, quality review, or operational reporting.