Use product-marketing when every homepage, email, or content brief begins with the same explanation of your business. It creates a reusable context file for the other marketing skills. It also suits an established product that has changed audience or positioning; its main output is a reviewed foundation, rather than an entire campaign.
Install and invoke
Run this in your project terminal to install only this skill for Claude Code:
npx skills add coreyhaines31/marketingskills --skill product-marketing -a claude-code
Node.js and npx must be available. For Codex, replace -a claude-code with -a codex. In the agent conversation, explicitly ask it to use product-marketing and supply your material. The installation command belongs in the terminal, not in your content brief.
Start with material you already have
Give the agent your README, homepage, pricing page, and a small set of customer interviews or support questions. It first checks .agents/product-marketing.md, with fallbacks for older locations and names. Without an existing document, choose a repository-based draft or a guided conversation. You can start without a codebase.
Example brief:
Use product-marketing to create context for this project.
Read README, the homepage, and pricing.md first. We help small design teams collect client annotations.
Studio owners buy the product; designers use it. Customer wording is in interviews.md.
Separate supported facts from positioning decisions I still need to confirm. Show me a first draft.
Review more than the feature list. Check whether users, champions, and budget owners have been confused. Alternatives may include email or spreadsheets, rather than just competing software. Explain what pushes customers away from their current approach, what attracts them to yours, and what makes switching uncomfortable. Identify customers who are a poor fit as well.
Make the output reliable enough to reuse
The document covers product basics, audience, pain, differentiation, objections, voice, customer language, and proof. Remove unsupported testimonials or benefit figures. A capability found in source code does not establish demand for it. Preserve what customers actually meant instead of polishing every quotation into a slogan.
After review, save the document at .agents/product-marketing.md. A new document starts at v1. Substantive changes increment the version and add a dated explanation at the top of the changelog; typo fixes do not need a new version. Future updates should focus on the affected sections rather than restart the entire interview.
If another marketing task keeps asking foundational questions, check that it is running in the same project and can read the file. Also check whether you retained a legacy path. When the positioning itself is stale, correct this shared document before rewriting downstream assets, so an outdated assumption does not spread through every campaign.
Maintain a context file other skills can safely reuse
The output is not public-facing ad copy. It is a product context file that other marketing skills read first. Sort inputs into confirmed, unconfirmed, and outdated. Product documentation can establish features; interviews can establish customer wording; a team aspiration is not yet a market fact. If .agents/product-marketing.md exists, inspect it before updating. Check older locations and filenames too, so two conflicting context files do not coexist unnoticed.
Have the agent fill in the product, audience, jobs and pains, alternatives, differentiation, objections, switching friction, voice, and approved proof. “Small businesses” is too broad by itself: identify a role, the work situation, and the current workaround. “Simpler than competitors” needs the specific step that is easier and its basis. Mark unsupported conclusions as hypotheses instead of filling every template field with confident-sounding guesses.
After review, record document version, date, and reason for the change. When price, capability, or positioning shifts, update this file before copywriting or emails reads it again. The review question is whether someone new to the product could use the document to distinguish a true marketing claim from an unsupported one.
Example: add a new audience without erasing the existing one
Suppose a product has served small design studios, and educational organizations now ask about team comments. Give the agent the current .agents/product-marketing.md, the actual inquiries, and the product differences relevant to education. Ask: “Use product-marketing to update the context. Preserve confirmed positioning for studios. Add an unvalidated education segment and separate customer quotations, product facts, and our own hypotheses. Show a diff before replacing the file.”
Check that the original audience’s value proposition remains accurate and a few inquiries have not been turned into a validated market claim. If the file says “all schools need this feature,” return to the source conversations and mark the sample size. After approval, update document version and changelog. Then have copywriting read the new version and specify which audience the page addresses, rather than merging both into a generic “team.”
Separate verified facts from assumptions in the context file
In a fictional vitamin C serum test, a user ran product-marketing to assemble a multi-section context file for later landing-page and outreach drafts. That shows how shared context reduces repeated briefing, not that its audience insights came from interviews. Add a source or “unverified” label to each important claim in your own file: buyer, daily user, alternatives, and objections. After changing positioning, check downstream pages for facts carried over from the old version.
For her real, public Agent Skills gallery, Phoebe Fu used this Skill to turn repository facts and public-signal research into audience, alternatives, differentiation, voice and proof, ending with a positioning statement for the site. Her coverage ledger leaves inapplicable pricing out and flags the auto-draft for human confirmation. The useful pattern is to let downstream copy see which claims have evidence and which remain working assumptions, instead of filling every field for its own sake.