git:20260717.e1d5341 to git:20260718.206351f

13 added, 9 removed. Audit A to A.

---
name: marketing-claims-review
- description: Audit or rewrite product marketing claims against evidence from the shipped product. Use for landing pages, feature pages, pricing copy, comparisons, calls to action, or other product messaging that must remain accurate and clear to first-time visitors.
+ description: Audit or, when authorized, rewrite persuasive product claims against shipped-product evidence. Use for landing pages, marketing-heavy READMEs, feature or pricing pages, comparisons, and calls to action.
---
# Marketing Claims Review
- Make product messaging concrete, understandable, and no stronger than the available evidence.
+ Own claim substantiation, positioning, comparisons, and first-visitor clarity regardless of file location.
## Workflow
- 1. Confirm the pages and audience in scope.
- 2. Build a factual capability map from the product, code, documentation, demos, onboarding, APIs, and other current evidence. Mark capabilities as `shipped`, `partial`, `experimental`, `planned`, or `unsupported`.
- 3. Inventory material claims and classify each as `accurate`, `unclear`, `unsupported`, `exaggerated`, `stale`, or `false`.
- 4. Check whether a first-time visitor can identify the product, intended user, problem, mechanism, meaningful difference, limitations, and next action without unexplained internal terminology.
- 5. For each problematic claim, cite the supporting or contradicting evidence and recommend `keep`, `rewrite`, `move`, `remove`, `qualify`, or `prove`.
- 6. When rewriting is requested, replace hype with specific language and preserve distinctions between current, experimental, and planned behavior.
+ 1. Confirm pages, audience, and audit-only or authorized rewrite mode.
+ 2. Build a capability map with implementation and runtime evidence taking precedence over marketing prose, demos, and roadmap material.
+ 3. Classify material claims as `accurate`, `unclear`, `unsupported`, `exaggerated`, `stale`, or `false`.
+ 4. Test whether a first-time visitor can identify the product, intended user, problem, mechanism, difference, limitations, and next action.
+ 5. For each problematic claim, cite evidence and recommend `keep`, `rewrite`, `move`, `remove`, `qualify`, or `prove`.
+ 6. Rewrite only when authorized, preserving distinctions between shipped, partial, experimental, planned, and unsupported behavior.
- Do not infer capabilities from aspirations, present roadmap work as shipped, invent proof, or force parallel agents for a small site. Report the highest-impact trust and clarity problems first.
+ Use `docs-review` for repository-document structure and discoverability, and `docs-drift-review` only for drift caused by the current change. Comparative claims requiring external competitor evidence remain unverified unless authoritative evidence is available and its use is authorized.
+
+ Do not infer capabilities from aspirations, invent proof, or force parallel agents.
+
+ Finish with scoped claims, evidence, dispositions, authorized edits, and unresolved proof needs.