---
name: turn-approved-website-briefs-into-release-review-evidence
description: 'Implement an approved marketing-site brief in an authorized repository, verify the actual change set, and prepare traceable release and rollback evidence without deploying it. Use when when an approved marketing brief is ready for repository implementation; when an existing approved page change needs traceability through tests and release review; when content and engineering owners need one handoff record.'
compatibility: 'Instruction-only Agent Skill. Requires an Agent Skills-compatible client and access to the tools or systems named in the instructions. No executable scripts are bundled.'
metadata:
  publisher: RichlyAI
  product: Amo.ng
  amo_id: AMO-S-000039
  canonical_url: 'https://amo.ng/skills/turn-approved-website-briefs-into-release-review-evidence'
  package_version: 1.0.0
  source_type: workflow
  source_amo_id: AMO-W-000034
  source_content_sha256: baad711f99cd883dea2046ce661fa4d09216cc6de0e0c6eb5b41940143ad6489
---

# Turn Approved Website Briefs into Release-Review Evidence

## When to use this Skill

- When an approved marketing brief is ready for repository implementation; when an existing approved page change needs traceability through tests and release review; when content and engineering owners need one handoff record.

## When not to use this Skill

- To invent positioning or claims; to change DNS, hosting, live CMS, analytics, advertising, production forms, or deployment settings; or when content rights, repository access, or the approved brief are missing.

## Required inputs

- Approved offer, audience, page, conversion, content, asset, claim, and SEO brief
- Authorized repository/worktree, routes, stack conventions, and permitted local commands
- Approved form and integration contracts with safe fixtures, mocks, or disabled adapters
- Acceptance criteria for responsive behavior, semantics, accessibility, metadata, links, performance, and failure states
- Allowed files/actions, reviewers, release process, monitoring expectations, and rollback context

Use [INPUT-TEMPLATE.md](assets/INPUT-TEMPLATE.md) to organize the supplied information.

## Required tools or access

Published source tool designations: ChatGPT, Codex. These are source designations, not portable-client compatibility claims. Use only authorized access described in the inputs and source instructions. Do not claim access or inspection without evidence.

## Procedure

Before starting, read [SOURCE.md](references/SOURCE.md), including the exact Prompt instructions and any ordered Workflow steps, review notes and carry-forward requirements.

Use W34 in order. Confirm the supplied brief and claim evidence, implement only approved pages/components/forms in the authorized repository, verify the actual diff and relevant tests, and prepare release, monitoring, recovery, and rollback controls. Keep production integrations mocked or disabled where credentials are absent. Separate observed test evidence from assumptions and unrun checks.

Published expected output:

An approved brief, brief-to-code traceability, repository change manifest, form/integration state record, verification matrix, accessibility/performance/metadata limitations, rollback instructions, and accountable release-owner handoff.

## Review gates

Read and apply the source review instructions in [SOURCE.md](references/SOURCE.md) before acting. Keep proposed, unrun and executed actions distinct; preserve missing evidence and obtain the human approvals required by the source.

- Step 1: Stop if audience, offer, conversion action, claim authority, or approval owner is unresolved; do not continue until the content owner approves the brief and claim boundaries.
- Step 2: Stop for missing repository/authority, secrets, destructive or production actions, or a brief conflict.
- Step 3: Hold if the actual diff, acceptance criteria, or executable evidence is unavailable.
- Step 4: Do not authorize deployment if approvals, rollback, secrets handling, or observable release evidence are incomplete.

## Completion criteria

Complete when every in-scope brief requirement has a code and evidence disposition; actual changes and relevant tests are recorded; forms and integrations are bounded; broken links, responsive states, semantics, metadata, failure paths, and applicable budgets are checked or marked unrun; unresolved blockers and owners are explicit; rollback is practical; and deployment remains an accountable release decision.

Use the [completion checklist](references/COMPLETION-CHECKLIST.md) and record unresolved items.

## Limitations

Preserve unrelated work. Do not request credentials or secrets, use unapproved personal data or production form submissions, invent content or results, alter live systems, enable customer-facing forms or external communications, or merge, push, or deploy without separate accountable authorization. Treat unrun or failed material checks as blockers; do not claim accessibility, security, readiness, or successful implementation without executed evidence and owner approval.

This is an instruction-only package. Packaging does not execute work, grant access or independently verify the package. Existing public verification in amo.json describes only the identified published source resources.

## References

- [Published source instructions](references/SOURCE.md)
- [Completion checklist](references/COMPLETION-CHECKLIST.md)
- [Input template](assets/INPUT-TEMPLATE.md)
- [Rights](RIGHTS.md)
- [Canonical Amo.ng Skill](https://amo.ng/skills/turn-approved-website-briefs-into-release-review-evidence)