skills/copywriting/SKILL.md
Writes and edits short product and marketing copy, including landing pages, CTAs, onboarding strings, product descriptions, email subjects, UI state copy, and AI-ism cleanup. Use when asked to "write copy", "fix the copy", "make this shorter", "improve the CTA", "rewrite from first principles", "remove AI-isms", "clean up AI writing", or "flag AI patterns". For blog posts use blog-post; for slide copy use presentation-creator; for docs use docs-writing; for product behavior decisions use product-design.
npx skillsauth add mblode/agent-skills copywritingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
blog-post), slide or deck copy (use presentation-creator), API/product/reference docs (use docs-writing), or deciding which action exists, its scope, consequence, reversibility, or reachable states (use product-design; this skill writes final wording once those are decided).Two modes, auto-detected (do not ask):
| File | Read when |
|------|-----------|
| references/frameworks.md | Pick a framework (Write Step 4); audit against the nine frameworks (Edit Step 3) |
| references/page-types.md | Copy norms for a known page type (Write Step 4) |
| references/word-lists.md | Flag Tier 1/2/3 AI vocabulary (Edit Step 4) |
| references/ai-patterns.md | Flag structural/sentence-level AI tells; P0/P1/P2 triage (Edit Step 4) |
| references/sweeps.md | Run the seven line-level sweeps (Edit Step 5) |
| references/ui-states.md | Name actions, write destructive CTAs, error/success/empty/loading-state and permission copy |
Writing progress:
- [ ] Step 1: Gather context
- [ ] Step 2: State the brief, then write
- [ ] Step 3: Discover brand voice
- [ ] Step 4: Choose framework and load references
- [ ] Step 5: Write 2-3 alternatives
- [ ] Step 6: Recommend and explain
- [ ] Step 7: Verify every line before handing back
Settle all four before writing, from the user or from the files. Where the files do not settle one, infer it and name the inference in Step 2; the failure mode is an invented audience or goal presented as fact.
Traffic source sets temperature: cold needs more Why; warm can lead with How or What.
State the brief and keep going. Mark every field you inferred rather than were told, so the user can correct it against real copy instead of against a question:
Brief:
- Page: [page type]
- Goal: [single action]
- Reader: [specific audience]
- Core outcome: [what changes for the reader]
- Tone: [inferred from brand voice or user-stated]
- Traffic temperature: [cold / warm / hot]
Inferred (correct me): [fields you guessed]
Stop and ask before writing only when a wrong guess makes the work useless or unsafe: the copy ships in this turn with no review, or the goal is genuinely unknown and each candidate goal produces different copy.
Find voice signals before inventing one; never default to generic corporate warmth.
Note the inferred voice in the brief.
Load references/frameworks.md, plus references/page-types.md when the target is a homepage, landing, pricing, feature, or about page. Choose the primary framework from the brief:
| Situation | Lead framework | |-----------|---------------| | Cold traffic, unfamiliar product | Why/How/What (Simon Sinek) | | Feature-heavy product | Benefit Not Feature | | High-trust audience, low awareness | Show Don't Tell | | Transactional page, known intent | CTA Clarity | | Long-form sales page | Problem → Agitate → Solution (PAS) |
Layer frameworks freely. Why/How/What almost always applies to hero copy.
Write exactly 2-3 distinct alternatives, labeled Option A, Option B, Option C. Each must:
Pick one; state which and why in one sentence. For each unpicked option, give one specific edit note: what would make it stronger.
Check each line of every option: leads with Why, names a concrete outcome, no banned word, no em dash as ordinary punctuation. New copy containing a banned word is not an option to present; rewrite it first.
Editing progress:
- [ ] Step 1: Read all copy-bearing files
- [ ] Step 2: Set the north star
- [ ] Step 3: Audit against persuasion frameworks
- [ ] Step 4: Remove AI writing patterns
- [ ] Step 5: Run seven sweeps
- [ ] Step 6: Flag weakest elements with labels
- [ ] Step 7: Rewrite flagged sections
- [ ] Step 8: Output before/after diff
Scan every reader-facing surface: README headers, landing components, hero, CTAs, product descriptions, feature lists, onboarding strings, meta descriptions, email subjects. Ask which files if unclear; never audit copy you haven't read in context.
Write one sentence before auditing: "[User] can now [do X] without [old pain]." Every flag and rewrite serves it. If you can't write it confidently, ask; the copy is unfixable until the value proposition is clear.
Load references/frameworks.md. Check every major copy block against each framework, and carry forward only the highest-impact problems; Step 6 sets the flag budget.
Load references/word-lists.md and references/ai-patterns.md. Flag each AI-ism with [AI-ISM] plus its pattern type:
word-lists.md): always flag and replace.word-lists.md): flag when 2+ appear in one paragraph.ai-patterns.md): formulaic openings, chatbot artefacts, "let's" transitions, significance inflation, copula avoidance, em dashes as ordinary punctuation.The em dash and its -- substitute are Tier 1 tells in their own right; ai-patterns.md section 1 holds the threshold, section 7 the P0/P1/P2 triage.
Skip for persuasion-only edits. If the user asked for AI pattern removal, run this first, before the sweeps.
Load references/sweeps.md; run all seven in order. Each targets a distinct failure mode; don't skip any because copy "looks fine".
Attach a label inline to every weak line. Use exactly these labels:
| Label | Meaning |
|-------|---------|
| [WHAT-NOT-WHY] | Leads with product/feature, not user motivation |
| [FEATURE-NOT-BENEFIT] | Describes what the product has, not what changes for the user |
| [TELL-NOT-SHOW] | Adjective claim without proof ("powerful", "seamless", "easy") |
| [VAGUE] | Generic; could describe any product in the category |
| [PASSIVE] | Subject is acted upon instead of acting |
| [VOICE-DRIFT] | Breaks from the dominant voice of the surrounding copy (register, tense, or person) |
| [PAIN-NOT-NAMED] | States benefits without naming the frustration the reader arrived with |
| [DEAD-WEIGHT] | Adds nothing not already conveyed; safe to cut |
| [JARGON] | Technical term that obscures meaning for non-experts |
| [NO-PROOF] | Claim needing a number, example, or testimonial |
| [WEAK-CTA] | CTA describes the action, not the outcome |
| [STATE-COPY] | Vague, leaky, or dead-end state string (error, success, empty, loading, permission), or a destructive CTA labeled "Confirm"/"OK"/bare verb (see references/ui-states.md for rule IDs) |
| [AI-ISM] | AI writing pattern: Tier 1 word, Tier 2 cluster, or structural tell |
Flag the 3-7 weakest elements, prioritised by impact on conversion or comprehension.
## Copy Audit: [file or component name]
**North star:** [one-sentence value prop]
---
### [Section name]
**Before:**
> [original text]
**Issues:** `[LABEL]`, `[LABEL]`
**After:**
> [rewritten text]
**Why:** [one sentence explaining the change]
---
### Summary
- N issues flagged across N sections
- Top pattern: [most common label]
- Confidence: [high / medium; note if copy context was limited]
Verify each "After" line before handing back: leads with Why, names a concrete outcome, no banned word, no em dash as ordinary punctuation. A rewrite that reintroduces an AI tell is a regression.
The never-write set. Applies in both modes, no exceptions, so it lives here rather than behind a reference load:
delve, leverage (verb), robust, seamless, holistic, paradigm, game-changing, cutting-edge, innovative, synergy, revolutionary, effortless, world-class, powerful
Also ban "simple" as a claim ("our simple onboarding"): never earned upfront, reads as an unkept promise.
references/word-lists.md holds the wider tiered AI vocabulary with replacements; that list is for detection in Edit mode, not a second copy of this one.
| When | Run |
|------|-----|
| After rewriting technical documentation copy | docs-writing |
| To optimise meta descriptions and page titles | optimise-seo |
| To review the full UI including copy in context | ui-audit |
| Landing page visual design, CRO strategy, conversion benchmarks | ui-design (marketing track) |
| The product decision of which action exists and its scope and consequence | product-design |
development
Fans out four concurrent review agents over the current diff, then APPLIES fixes directly to the working tree and verifies the build. Mutates code; it does not produce a report. Covers reuse (duplicate logic, hand-rolled stdlib, reinvented platform features), quality (hacky patterns, React/TypeScript hygiene, over-memoisation, exhaustive-deps, `any`, dead code, `CLAUDE.md`/`AGENTS.md` violations), efficiency (unnecessary work, missed concurrency, hot-path bloat), and test discipline (bug fixes without a repro test, useless tests to delete, missing tests only when they prevent a named failure). Use when the user says "tidy this up", "simplify", "clean up this diff", "polish my changes", "check for duplication", or "any reuse opportunities?", i.e. when the intent is to have the changes made automatically. For a read-only report that lists findings without touching files, use `pr-reviewer` instead. This skill edits code; for the PR's title, description, or commit history, use `pr-creator`.
development
Decides what an interface should do before UI is built or audited: interaction choice, action scope and consequence, reachable states, resilience, and accessibility as task completion. Works from a brief, spec, mockup, intent, or existing UI. Use when asked "is this the right interaction", "design the flow", "what control should this use", "what should this action affect", "which states should this have", "make this resilient", or "what breaks here". For building or styling use ui-design; for built-code audits use ui-audit; for copy wording use copywriting.
development
Builds and stress-tests implementation plans in two modes. Create mode scans code and docs, asks one question at a time with a recommended answer, runs a blindspot pass when the user is new to the area, then writes a plan file. Review mode scores completeness, feasibility, scope, testability, risk, and assumptions, verifies checkable claims, and writes resolutions back until every dimension reaches 5/5. Use when asked to "create a plan", "plan this feature", "I want to build X", "grill me", "think this through", "blindspot pass", "unknown unknowns", "this is new to me", "review my plan", "rubber duck this", "stress test this plan", "is this plan ready", "get this plan to 5/5", "what am I missing", "verify this claim", "prove this plan", "fact-check this plan", or when the user explicitly wants a plan artifact before implementation. For code review use pr-reviewer; for architecture briefs use define-architecture.
tools
Audits the smallest relevant developer-facing surface of a library, CLI, SDK, or npm package across API contracts, errors, CLI behavior, public types, onboarding, and config. Uses candidate-first rule loading, bounded local evidence, and compact root-cause findings. Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK". For end-user UI use ui-audit, for agentic-app trust use ax-audit, for docs prose use docs-writing, for README work use readme-creator, and for repo architecture use define-architecture. Inside a product that also ships a UI, this is the skill for the developer-facing half, so pick it when the complaint is about an import, command, error string, exported type, or config rather than a screen.