메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | marketing-claims-review |
| 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. |
Own claim substantiation, positioning, comparisons, and first-visitor clarity regardless of file location.
accurate, unclear, unsupported, exaggerated, stale, or false.keep, rewrite, move, remove, qualify, or prove.english-text-review and apply material findings without weakening substantiation, necessary qualifications, or intentional voice.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.
Report all repository changes that entered a target branch during one required date or period, grouped by product change and written as plain English for a broad audience. Use for daily, weekly, date-range, or relative-period change summaries rather than explaining one known diff.
Create one concise evidence-linked product journey record for one actor pursuing one goal. Use when product behavior needs traceable ownership, acceptance, telemetry, or service-flow documentation for a current decision or delivery gate.
Review documentation for drift caused by the current code or configuration change. Use to identify concrete inaccuracies and, when authorized, repair only directly affected documentation.
Audit or improve general repository documentation against implemented behavior. Use for deliberate README or documentation-quality work not owned by a more specific documentation skill.
Review English technical prose without modifying it. Use for plain-English feedback on comments, docstrings, documentation, commit or pull request text, issues, reports, runbooks, logs, errors, command help, and other human-readable technical writing rather than factual or marketing review.
Create one local commit for a completed, validated, and reviewed unit of work. Use only when the user explicitly requests a commit without pushing or other delivery actions.