agentleFS
harlan-zwharlan-zw/brundlefly/skills/copywriting/SKILL.md

copywriting

Skill7 starsChanged 33 days agoMITView on GitHub

Writes user-visible product strings against COPY.md, and creates or audits that file. Use whenever someone asks for UI copy such as a button label, error message, toast, empty state, or meta description, for marketing copy, or for a check that product descriptions have drifted apart.

191 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use paywalls, popups and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • CesarjoquinSkill

    paywalls

    When the user wants to create or optimize in-app paywalls, upgrade screens, upsell modals, or feature gates. Also use when the user mentions "paywall," "upgrade screen," "upgrade modal," "upsell," "feature gate," "convert free to paid," "freemium conversion," "trial expiration screen," "limit reached screen," "plan upgrade prompt," "in-app pricing," "free users won't upgrade," "trial to paid conversion," or "how do I get users to pay." Use this for any in-product moment where you're asking users to upgrade. Distinct from public pricing pages (see cro) — this focuses on in-product upgrade moments where the user has already experienced value. For pricing decisions, see pricing.

    Also in 17 projects that use this

  • CesarjoquinSkill

    popups

    When the user wants to create or optimize popups, modals, overlays, slide-ins, or banners for conversion purposes. Also use when the user mentions "exit intent," "popup conversions," "modal optimization," "lead capture popup," "email popup," "announcement banner," "overlay," "collect emails with a popup," "exit popup," "scroll trigger," "sticky bar," or "notification bar." Use this for any overlay or interrupt-style conversion element. For forms outside of popups, see cro. For general page conversion optimization, see cro.

    Also in 16 projects that use this

  • ukunal91appSkill

    revops

    When the user wants help with revenue operations, lead lifecycle management, or marketing-to-sales handoff processes. Also use when the user mentions 'RevOps,' 'revenue operations,' 'lead scoring,' 'lead routing,' 'MQL,' 'SQL,' 'pipeline stages,' 'deal desk,' 'CRM automation,' 'marketing-to-sales handoff,' 'data hygiene,' 'leads aren't getting to sales,' 'pipeline management,' 'lead qualification,' or 'when should marketing hand off to sales.' Use this for anything involving the systems and processes that connect marketing to revenue. For cold outreach emails, see cold-email. For email drip campaigns, see email-sequence. For pricing decisions, see pricing-strategy.

    Also in 38 projects that use this

  • roerohanSkill

    emails

    When the user wants to create or optimize an email sequence, drip campaign, automated email flow, or lifecycle email program. Also use when the user mentions "email sequence," "drip campaign," "nurture sequence," "onboarding emails," "welcome sequence," "re-engagement emails," "email automation," "lifecycle emails," "trigger-based emails," "email funnel," "email workflow," "what emails should I send," "welcome series," or "email cadence." Use this for any multi-email automated flow. For cold outreach emails, see cold-email. For in-app onboarding, see onboarding.

    Also in 21 projects that use this

  • timruebenachSkill

    competitor-profiling

    When the user wants to research, profile, or analyze competitors from their URLs. Also use when the user mentions 'competitor profile,' 'competitor research,' 'competitor analysis,' 'profile this competitor,' 'analyze competitor,' 'competitive intelligence,' 'competitor deep dive,' 'who are my competitors,' 'competitor landscape,' 'competitor dossier,' 'competitive audit,' or 'research these competitors.' Input is a list of competitor URLs. Output is structured competitor profile markdown files. For creating comparison/alternative pages from profiles, see competitor-alternatives. For sales-specific battle cards, see sales-enablement.

    Also in 25 projects that use this

  • silvainfmSkill

    competitor-alternatives

    When the user wants to create competitor comparison or alternative pages for SEO and sales enablement. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' or 'competitive landing pages.' Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. Emphasizes deep research, modular content architecture, and varied section types beyond feature tables.

    Also in 33 projects that use this

  • +4 more from Cesarjoquin

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. 0 are common, 16 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 179 edited versions we read keep these.

  • 16

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep approved wording exact.

    line 15
  2. Distinctive:

    Read the target project's instructions before editing.

    line 19
  3. Distinctive:

    Create or audit COPY.md only.

    line 21
  4. Distinctive:

    Use the approved wording and register.

    line 27
  5. Very specific:

    Use the target project's supplied document ownership rules.

    line 33
  6. Very specific:

    When they disagree: VISION.md wins over everything, GLOSSARY.md wins on a product noun, and COPY.md wins on the sentence around it.

    line 34
  7. Distinctive:

    Read a supplied GLOSSARY.md before naming a concept.

    line 37
  8. Distinctive:

    If no glossary exists, preserve established names and ask about new concepts rather than generating another artifact.

    line 38
  9. Very specific:

    If the string is wrong, change it in COPY.md first, then propagate.

    line 45
  10. Distinctive:

    State supported specifics: Use inspected names, quantities, and behavior when they help the reader.

    line 52
  11. Distinctive:

    Copy is not decoration: If a section needs filler to look finished, the layout is wrong.

    line 54
  12. Distinctive:

    Never invent a stat, a testimonial, or a feature to fill space.

    line 55
  13. Distinctive:

    Keep labels brief and specific.

    line 64
  14. Distinctive:

    If an approved asset needs correction, show the exact proposal and follow the existing approval rules.

    line 67
  15. Distinctive:

    Before removing a substantial section or feature, explain the proposed loss and ask unless already authorized.

    line 68
  16. Distinctive:

    Read the workflow reference and the COPY.md template before creating or auditing a copy file.

    line 72
  17. Distinctive:

    Use init for a requested missing copy file, audit for drift, and write for a specific surface.

    line 73
  18. Distinctive:

    Read copy examples before writing a surface or proposing a canonical asset change.

    line 74
  19. Distinctive:

    Ask only about unresolved voice or canonical wording decisions.

    line 75

“Common” is measured: kept by at least 6 in 10 of the 179 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Copywriting

Help the intended reader understand the message and their next action. Respect their knowledge, attention, and context. Optimize for clarity, accuracy, and brevity without losing needed explanation. Design for varied reading, attention, and working memory needs, including ADHD and dyslexia. Storytelling and style techniques serve meaning, understanding, and connection. Preserve the supplied voice and truthful experience.

COPY.md owns canonical assets, each surface's register, and banned language. Keep approved wording exact. If it creates a reading problem, propose a change rather than silently paraphrasing it.

Ownership and dependencies

Read the target project's instructions before editing. Respect its branch, worktree, publication, and approval rules. This Skill does not own delivery. Create or audit COPY.md only. Do not create GLOSSARY.md or VISION.md automatically.

The failure mode this exists to stop

Independent rewrites can give one product conflicting descriptions, labels, and error messages. Readers must then work out whether those differences have meaning. Use the approved wording and register. Treat a new canonical string with the same caution as a public export.

Boundaries

Copywriting governs sentences a user reads: the exact wording, the register per surface, and the banned language. A supplied GLOSSARY.md governs what a concept is called. VISION.md governs what may be claimed. Use the target project's supplied document ownership rules. When they disagree: VISION.md wins over everything, GLOSSARY.md wins on a product noun, and COPY.md wins on the sentence around it.

Read a supplied GLOSSARY.md before naming a concept. If no glossary exists, preserve established names and ask about new concepts rather than generating another artifact.

Rules

  1. Read COPY.md before writing anything a user sees. Its canonical assets win over anything that reads better in the moment.
  2. Never paraphrase a canonical asset. A tagline with one word changed is a second tagline. If the string is wrong, change it in COPY.md first, then propagate.
  3. Never use banned language. The ban list carries a reason; the reason is what tells you whether a near-miss is also banned.
  4. Write in the register the surface calls for. A button is not a paragraph, and a hero is not a tooltip. COPY.md's register table decides, not the sentence's own momentum.
  5. A new canonical string does not get written silently. Propose it, say what it displaces, and get confirmation. Inventing quietly is the whole failure mode.
  6. State supported specifics. Use inspected names, quantities, and behavior when they help the reader. Source material claims and numbers. Concrete wording cannot establish authorship or make an unsupported claim accurate.
  7. Copy is not decoration. If a section needs filler to look finished, the layout is wrong. Never invent a stat, a testimonial, or a feature to fill space. Text that restates a heading, a value, or a visible fact is decoration too.

Rule 5 protects wording decisions that nobody has approved yet.

Review for the reader

Identify who reads each surface, what they already know, and what they need to understand or do. Apply clarity, including ADHD and dyslexia guidance, before accepting new copy or a proposed correction. Keep labels brief and specific. Put instructions, conditions, and consequences beside the action they explain. Explain errors without blame. Give a supported recovery action when one exists. Preserve required wording, register, and meaningful links. Recheck canonical assets after editorial changes. If an approved asset needs correction, show the exact proposal and follow the existing approval rules. Before removing a substantial section or feature, explain the proposed loss and ask unless already authorized.

Workflow

Read the workflow reference and the COPY.md template before creating or auditing a copy file. Use init for a requested missing copy file, audit for drift, and write for a specific surface. Read copy examples before writing a surface or proposing a canonical asset change. Ask only about unresolved voice or canonical wording decisions. Existing explicit approval remains valid. Preserve approved strings exactly. Prepare proposed wording before requesting approval. Review prose directly, or use an available im-part-human Skill optionally. Recheck canonical wording afterward.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.