---
name: lightspeed-release-handoff-generator
description: create release notes, launch handoff packs, client handover documents, support transition notes, post-launch monitoring plans and internal delivery closure reports for lightspeed figma design system to wordpress block theme, block plugin, woocommerce, publishing, tourism and hybrid-theme projects. use when the user has launch qa results, github issue drafts, implementation notes, prds, technical briefs, qa findings, deployment notes or project memory and needs a clean release/handoff package after launch or before support transition.
---

# LightSpeed Release Handoff Generator

## Purpose

Create practical release and handoff assets for LightSpeed WordPress projects after implementation and launch QA.

Use this skill when a project needs to move from build/launch into client review, support, retainer maintenance or post-launch monitoring.

## Core rule

Do not invent completed work, launch outcomes, resolved issues, monitoring results or client approvals. If evidence is missing, mark it as pending or requiring confirmation.

## Inputs to accept

Accept any combination of:

- PRD
- Figma-to-WordPress technical brief
- implementation plan
- GitHub issue drafts or completed issue notes
- QA findings register
- launch readiness audit
- launch QA plan
- release notes
- deployment notes
- project memory bank
- redirect/schema/GA4/policy/parity audit outputs
- client sign-off notes
- support/retainer requirements

## Outputs to generate

Generate one or more of:

- release notes
- client handoff summary
- internal handoff summary
- support transition brief
- post-launch monitoring plan
- known issues register
- rollback and escalation notes
- training and documentation checklist
- maintenance and retainer onboarding notes
- post-launch 7/30/60/90 day review plan
- project closure summary

## Workflow

1. Identify project stage: pre-launch handoff, launch complete, support transition, retainer onboarding or project closure.
2. Review available evidence and classify source confidence.
3. Separate client-facing notes from internal delivery notes.
4. Summarise what changed, what shipped and what remains pending.
5. Flag known issues, accepted risks, post-launch actions and monitoring needs.
6. Create support transition notes with owners, routes and escalation rules.
7. Include documentation/training needs where relevant.
8. Output Markdown suitable for Google Docs, GitHub, Asana or a downloadable project pack.

## Required sections

For full release handoff packs, include:

- Executive summary
- Release scope
- What changed
- What was tested
- Known issues and accepted risks
- Client handoff notes
- Internal LightSpeed handoff notes
- Support transition notes
- Monitoring plan
- Documentation/training checklist
- Open decisions
- Next actions

## Reference loading

Use these references as needed:

- `references/release-handoff-workflow.md` for the full workflow.
- `references/release-notes-rules.md` for release-note formatting.
- `references/client-handoff-rules.md` for client-facing summaries.
- `references/support-transition-rules.md` for support and retainer transition.
- `references/post-launch-monitoring.md` for monitoring plans.
- `references/known-issues-rules.md` for risk and issue status language.

## Quality standard

Use UK English. Be practical, specific and non-alarmist. Avoid vague “successful launch” statements unless launch evidence exists. Clearly mark pending validation, unresolved issues and follow-up owners.

---

*Built by 🧱 LightSpeedWP with ☕, 🚀, and open-source spirit!*