product-description-writer
Skill1 starsChanged 39 days agoMITView on GitHub
Writes the single on-site PDP master copy - a benefit-led, scannable product detail page in the brand's voice - from a raw spec sheet or feature list. Use when you have a spec list, feature bullets, or a bare template description for one product and need conversion copy for its on-site product detail page. Do NOT use for Amazon or marketplace listings - use amazon-listing-optimizer instead; do NOT use to spin one master into many size/color variants - use variant-copy-scaler instead.
In this repository8 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Every benefit traces to a spec in the source.
- Distinctive: line 26
Every objection a buyer would have before adding to cart is answered honestly.
- Very specific: line 34
Do not invent performance numbers, certifications, materials, or health/safety/earnings claims.
- Distinctive: line 35
Do not open with "premium quality" or any generic category claim.
- Distinctive: line 36
Do not fabricate scarcity, countdowns, or low-stock urgency.
- Distinctive: line 37
Do not keep features that translate to no buyer benefit.
- Distinctive: line 38
Do not end with a bare "Buy now" - restate the benefit in the CTA.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Product Description Writer
Translate a product's specs into the on-site PDP master copy: benefit-led, scannable, in the brand's voice, decidable in eight seconds on a phone.
Workflow
- Gather inputs. Get the spec/feature list, the target customer, and the brand voice. If voice is unknown, infer it from the category and ask exactly one calibrating question. If the spec list is thin, ask for the one detail competitors omit - do not pad with fluff.
- Find the one reason they buy. Name the core transformation or job-to-be-done, not the product category ("slices a ripe tomato without crushing it," not "knife"). This is the lead hook.
- Translate each spec to a benefit. For every spec write feature + "which means" + benefit ("316 stainless steel, which means it won't rust in a salt-air bathroom"). Keep the spec for credibility, the benefit for desire. Drop any feature that translates to nothing the buyer cares about.
- Surface and answer objections. Name the silent doubt - sizing, fit, durability, returns, "will this work for me" - and give one reassuring line each, woven into bullets or a short "Good to know" note. If it runs small, say so.
- Assemble for the F-pattern scan. Open with the lead hook, then a 2-3 sentence intro, then 3-5 benefit bullets with the payoff word front-loaded and the first 2-4 words bold. Close with a benefit-restating CTA. Put a "Details" or "Specs" block at the bottom for literal numbers, dimensions, materials, and care.
- Calibrate voice. Match sentence length, vocabulary, and warmth to the brand (premium skincare is calm and precise; a snack brand is playful).
Quality bar
- The first line works as a standalone hook - many shoppers read nothing else.
- Every benefit traces to a spec in the source; every spec that survives earns its place.
- Sentences stay under 20 words; bullets front-load the payoff.
- Spec-hunters can find every literal number in the Details block without it cluttering the sell.
- Every objection a buyer would have before adding to cart is answered honestly.
Deliverable
Produce the complete PDP master copy as one paste-ready block: lead hook line, 2-3 sentence intro, 3-5 benefit bullets (payoff front-loaded, opening words bold), objection-handling lines or a "Good to know" note, a benefit-restating CTA, and the Details/Specs block with every literal number, dimension, material, and care instruction from the source. Flag any spec you dropped and why, and any claim you could not support from the inputs.
Do NOT
- Do not invent performance numbers, certifications, materials, or health/safety/earnings claims. Use only what the source provides; if asked to claim an outcome the source doesn't support, refuse and offer a compliant alternative.
- Do not open with "premium quality" or any generic category claim.
- Do not fabricate scarcity, countdowns, or low-stock urgency. Use urgency only when it is true (limited batch, seasonal, real low stock).
- Do not keep features that translate to no buyer benefit.
- Do not end with a bare "Buy now" - restate the benefit in the CTA.
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
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.

