final-client-handoff ยท diff
git:20260621.2caaecc to git:20260905.f7824ba
14 added, 11 removed. Audit A to A.
---
name: final-client-handoff
- description: "Prepare final website handoff. Use after completing a site, app, landing page, redesign, deployment, or production QA to summarize changed files, commands run, checks passed, local/deployed URLs, environment variables, content/CMS notes, known limitations, untested areas, and recommended next steps."
+ description: "Prepare verified ownership and delivery notes."
---
# Final Client Handoff
Use this skill to give the user a calm, accurate closeout they can trust and act on.
+ ## Closeout modes
+
+ For a small change, report changed files, actual checks and remaining limits; no release manifest is required. For a client release, aggregate existing applicable ownership, tested/untested, recovery and release evidence using the full procedure below.
+
## Workflow
- 1. Inspect the project, scripts, routes, local/deployed URL, production surfaces, and available QA/deployment tooling.
+ 1. Inspect the affected surface, relevant project scripts, target URL and available inspection tooling; reuse existing context.
2. Read [Final Client Handoff Guide](references/final-client-handoff-guide.md) before claiming the site is ready.
3. Run the narrowest meaningful checks for the risk: visual, mobile, accessibility, performance, forms, media, SEO, analytics, deployment, or handoff.
4. Fix issues when they are in scope; otherwise record exact evidence and remaining risk.
5. Summarize commands, URLs, screenshots/checks, changed files, and what was not tested.
- ## Always Protect
+ For a full client release, use [references/release-handoff-template.md](references/release-handoff-template.md) for the release, monitoring, recovery, and ownership record. Validate it with `python3 "<skill-root>/scripts/verify-handoff.py" <handoff.json>`.
- - Inspect before changing or shipping: framework, package scripts, build output, routes, forms, media, animation stack, deployment target, environment variables, analytics, SEO metadata, accessibility risks, and available browser QA tooling.
- - Do not claim something was tested unless it was actually tested; report exact commands, URLs, screenshots, viewports, failures, skipped checks, and remaining risk.
- - Verify desktop and mobile rendered output, not only source code. For visual or motion work, inspect screenshots, browser behavior, console errors, network failures, and responsive layout.
- - Treat forms, checkout, booking, CMS content, analytics, environment variables, and deployments as production surfaces with error, loading, empty, success, and rollback states.
- - Respect accessibility, performance, reduced-motion, and no-JavaScript/no-WebGL/no-autoplay fallbacks where relevant.
- - Keep secrets out of code, logs, screenshots, summaries, widgets, and committed files.
- - Prefer project-local tooling and existing scripts before adding dependencies. Explain any new dependency before installing it.
- - End with a concise handoff: changed files, commands run, checks passed, checks not run, deployment URL if any, and next risks.
+ ## Scoped execution
+
+ Apply the [shared web contract](../website-operating-rules/references/scoped-web-contract.md) once when execution crosses phases; reuse it if already read. Load only the specialist guidance relevant to the requested surface and deliverable.
+
+ For helper-driven evidence, use the [typed record schema](references/evidence-record-schema.md). The helper validates structure only; use actual inspection/test results for claims.
+
+ Resolve `<skill-root>` to this skill folder's actual absolute location; preserve project-local module resolution for Node capture tools.