product-completion-wrap

---
name: product-completion-wrap
description: Apply a vendor-neutral post-build completion standard to an existing product repository. Use when explicitly asked to finish, harden, package, validate, prepare, or launch a substantially completed product. Covers functional closure, engineering, security, branding, legal drafts, UI, website, SEO, payments, email, testing, operations, documentation, and evidence-based release readiness.
disable-model-invocation: true
argument-hint: "[product-name] [optional domain, deployment target, constraints]"
---

# Product Completion Wrap

Execute the post-build product-completion mission for `$ARGUMENTS`.

This skill is a repository-level completion and release-governance wrapper. Use it after the core implementation is substantially complete. It is not an initial discovery, product-definition, or scaffolding skill.

## Load the governing standard

Before modifying the repository, read:

`${CLAUDE_SKILL_DIR}/references/completion-standard.md`

Treat it as authoritative. Apply every relevant section and explicitly classify every non-applicable section.

## Non-negotiable rules

- Discover the actual stack, architecture, providers, deployment model, business model, and repository conventions. Do not assume them.
- Preserve working functionality and unrelated owner changes.
- Validate in a safe local or non-production environment before production release.
- Never expose, print, commit, or copy credentials, private keys, customer data, confidential production data, or payment secrets.
- Never claim deployment, security, legal approval, accessibility, indexing, monitoring, payment activation, customer use, revenue, or production readiness without evidence.
- Separate implemented configuration from externally verified activation.
- Use product-specific and jurisdiction-aware legal drafts, with professional-review requirements stated honestly.
- Ask only for genuinely unresolved, credential-gated, destructive, irreversible, financial, legal-acceptance, publication, customer-messaging, or externally controlled decisions.
- Do not perform production-impacting, destructive, financial, public, or customer-messaging actions without explicit authority.
- Prefer safe, maintainable, proportionate solutions over unnecessary rewrites or decorative complexity.

## Required execution sequence

### 1. Establish repository truth

Inspect repository instructions, README files, requirements, plans, ADRs, issues, TODOs, manifests, lockfiles, services, workers, databases, migrations, integrations, environment templates, infrastructure definitions, tests, quality tooling, documentation, legal content, git status, recent history, brand assets, domains, and public claims.

Do not reset, discard, overwrite, or silently reformat unrelated uncommitted work.

Run the existing baseline checks before material changes. Create or update:

`docs/completion/BASELINE_ASSESSMENT.md`

or the repository's established equivalent.

### 2. Build the completion gap register

Compare intended capability with actual capability. Identify incomplete workflows, mock or placeholder production paths, dead or disconnected UI, hard-coded values, missing validation and recovery states, unsupported claims, stale documentation, secret exposure, missing migrations, security weaknesses, accessibility problems, legal or consent gaps, payment and entitlement gaps, email and lifecycle gaps, and missing deployment, backup, rollback, monitoring, incident, or support controls.

Prioritise by safety, data risk, customer impact, commercial impact, and dependency.

### 3. Execute every safe workstream

Complete all applicable work across:

1. Functional closure.
2. Architecture and engineering hardening.
3. Security review and remediation.
4. Brand and design system.
5. UI, public website, accessibility fundamentals, SEO, and indexing readiness.
6. Product-specific legal, privacy, cookie, subscription, refund, and acceptable-use drafts.
7. Payment-provider sandbox integration, webhook handling, billing lifecycle, and entitlement enforcement where applicable.
8. Transactional email and customer-lifecycle communication.
9. Comprehensive automated and manual verification.
10. Deployment, backup, restore, rollback, monitoring, incident, and operational readiness.
11. Documentation, launch assets, evidence, and owner actions.

A successful build or green test suite does not make other applicable workstreams optional.

### 4. Maintain evidence while working

Create or update the repository's authoritative equivalents of:

- `docs/completion/REQUIREMENTS_TRACEABILITY.md`
- `docs/completion/SECURITY_REVIEW.md`
- `docs/completion/TEST_REPORT.md`
- `docs/completion/PRODUCTION_READINESS.md`
- `docs/completion/OWNER_ACTIONS.md`
- `docs/completion/GO_LIVE_CHECKLIST.md`
- `docs/completion/FILE_INDEX.md`
- `docs/brand/BRAND_GUIDE.md`
- `docs/legal/`
- `docs/operations/DEPLOYMENT_RUNBOOK.md`
- `docs/operations/BACKUP_RESTORE.md`
- `docs/operations/INCIDENT_RESPONSE.md`
- `docs/operations/ROLLBACK.md`
- `docs/launch/`
- `.env.example`
- `README.md`
- release notes or changelog

Do not duplicate an existing authoritative document. Update or cross-reference it.

For each material requirement record:

| Requirement | Implementation | Verification | Evidence | Status | Remaining action |
|---|---|---|---|---|---|

Use only:

- `COMPLETE`
- `PARTIALLY COMPLETE`
- `BLOCKED`
- `OWNER ACTION REQUIRED`
- `NOT APPLICABLE`
- `FAILED`

### 5. Verify the product

Run native repository checks and add missing high-value coverage where proportionate. Include unit, component, integration, API, contract, database, migration, authentication, authorisation, tenant-isolation, payment, webhook, email, negative-path, recovery, end-to-end, security, accessibility, responsive, performance, backup/restore, deployment, rollback, and smoke checks as applicable.

Record exact commands, environment, release or commit state, passed/failed/skipped/flaky counts, coverage, manual checks, known gaps, and unresolved defects.

### 6. Control release actions

Before production deployment, DNS changes, live payments, live transactions, customer email, publication, data deletion, or any irreversible action:

1. Confirm applicable non-production gates passed.
2. Create a recoverable release checkpoint.
3. Confirm the exact target and authorised action.
4. Protect secrets and never print them.
5. Execute only the authorised scope.
6. Run post-action validation.
7. Record evidence and rollback status.

Infrastructure access is not itself authority for a destructive, financial, public, or irreversible action.

When blocked, complete all safe preparation and provide precise owner steps without claiming the action occurred.

## Minimum gate ledger

Assess at least:

1. Core workflows.
2. Removal of production mocks and placeholders.
3. Reproducible production build.
4. Externalised configuration and protected secrets.
5. Database migrations and integrity.
6. Authentication, authorisation, and isolation.
7. Critical and high security findings.
8. Automated verification.
9. Critical manual journeys.
10. Brand consistency and UI quality.
11. Website and technical SEO.
12. Legal, privacy, consent, and professional-review state.
13. Payments and entitlements where applicable.
14. Email and lifecycle communication where applicable.
15. Accessibility fundamentals.
16. Backup and verified restoration.
17. Monitoring and alerting.
18. Deployment and rollback.
19. Production smoke tests when deployed.
20. Support, billing, cancellation, and account deletion.
21. Evidence-based product and marketing claims.

For every gate record evidence, status, blocker, and required action.

## Required final response

Return these sections in order:

1. **Executive verdict** — exactly one of `READY FOR PRODUCTION`, `CONDITIONALLY READY`, `NOT READY`, or `BLOCKED`.
2. **Product summary** — name, proposition, target user, commercial model, domain, deployment target, and environment status.
3. **Work completed** — functional, technical, security, brand, legal, commercial, testing, operations, and deployment.
4. **Gate ledger** — gate, evidence, status, blocker, required action.
5. **Test evidence** — commands, counts, coverage, manual checks, security checks, performance checks, environment, and gaps.
6. **Deployment status** — development, staging, production, DNS, TLS, database, monitoring, backup, rollback, and release identifier.
7. **Payment status** — sandbox/test and live evidence stated separately.
8. **Legal and privacy status** — each document and its review state.
9. **SEO and indexing status** — implementation, readiness, submission, and verified indexing stated separately.
10. **Security findings** — unresolved findings by severity and impact.
11. **Owner actions** — one numbered register ordered by launch criticality.
12. **File index** — important files created or modified by category.
13. **Go-live sequence** — before deployment, deployment day, first 24 hours, first 7 days, and first 30 days.

Begin immediately with repository inspection and the baseline assessment. Continue through every safe phase without unnecessary confirmation.