Yesterday a Reddit builder dropped an open-source skill called Adaptive Product Language, and the twist is what it does before it writes a single word.
What’s new
u/Life_Assist5275 built a skill for product copy, not general prose. It covers landing pages, login and registration, onboarding, forms, pricing and paywalls, errors, empty and loading states, CTAs, bilingual interfaces and product audits. Think of all the small strings in an app that nobody plans for until launch week: the “something went wrong” toast, the blank screen a new user sees before they add their first item, the button that says “Submit” when it should say “Create invoice.” Those are the places this skill is aimed at. The repo is here: https://github.com/RicardoGurrola15/adaptive-product-language
The design principle is one line: text without context is erratic. Ask a model for a paywall headline with no background and you get a polished sentence about “unlocking your full potential.” Ask it with the real feature list and the real price, and you get something a user can actually act on.
The twist
This is not a vocabulary pack, and it doesn’t touch model weights. It doesn’t force a fixed word list either. It reads your project context first: product type, audience, market, supported features, pricing, terminology and locale. Then it routes your request into a smaller module: compose, improve, audit, localize or remediate.
That routing step matters more than it looks. A request to “audit the signup flow” needs a different mindset than “write a signup flow,” and splitting them keeps each pass focused instead of mushy. The context also acts as a fence. If your app has no offline mode, the skill has nothing to build an offline-mode claim from.
The point is to cut the stuff that makes AI copy feel off:
- generic AI-sounding phrasing
- literal translations
- unsupported claims
- ambiguous CTAs
- inconsistent terminology
- copy that doesn’t match what the product actually does
Inconsistent terminology is the sneaky one. If the dashboard says “workspace,” the onboarding says “project” and the error says “account,” users quietly wonder whether those are three different things. A shared context block fixes that at the source.
The author is also upfront about results. They ran small comparisons with Gemini, Claude and Codex. In the Gemini and Claude samples, the skill’s output was shorter and avoided some unsupported claims. In the Codex pilot, quality was equal to the baseline. They say plainly that this isn’t statistically significant and that they are not claiming it always improves quality. I like that. Small sample, honest write-up.
Mini-workflow you can steal (even without the repo)
- 🧭 Write a short context block: product type, audience, market, what features really exist, pricing, key terms, locale. Keep it to a page or less. Add a “words we use / words we avoid” line so terminology stays steady.
- 🎯 Name the job before you ask for copy: compose, improve, audit, localize or fix an error state. One job per request. Mixing “rewrite this and also translate it and also check it” is how you get muddy output.
- 🚧 Add a constraint: “Don’t mention any feature that isn’t in the context block.” If you want extra safety, ask the model to flag anything it was tempted to claim but couldn’t support.
- 🔍 Run a review pass: check every claim against the feature list, and check every CTA for ambiguity. A good test is whether a stranger could tell what happens after the click.
- Compare against your baseline prompt on the same task. Keep what’s actually better. Save both versions side by side so you can see the difference instead of trusting a feeling.
Pro tips from the thread
- One commenter suggested scoring copy by information density. That’s a neat answer to the author’s question about rating quality without rewarding repetitive phrases. Fewer words that carry more verifiable facts should win. A quick way to try it: count the concrete, checkable facts in each version and divide by word count.
- Another recommended testing on real onboarding flows and error messages first. That’s where confusing copy hurts users most, so it’s where a skill like this proves itself fastest. Pick the error your support inbox hears about most and start there.
- Watch length. The author’s own open question is how to keep a context-heavy skill from getting expensive or wordy. Measure your token cost next to your quality score. If the context block grows past what the task needs, trim it to the fields that change the output.
- If you ship in more than one language, run the localize pass on its own and have a native speaker read it. The skill aims to avoid literal translations, but a human ear still catches what a checklist won’t.
Where it’s still open
The author wants feedback on whether the routing and context model are practical, how to evaluate copy quality, how to keep the skill lean, and which failure cases belong in the benchmark. It’s an early public version, and critical feedback is explicitly welcome. If you’ve ever watched a model invent a feature your product doesn’t have, that story is exactly the kind of failure case the benchmark needs.
Your move
Grab the repo, point it at one real error message or onboarding screen, and compare it with your usual prompt. If you find a failure case, take it back to the thread. That’s how a 2-upvote post turns into a solid tool! ⚓
Frequently Asked Questions
Q: How do you score product copy without rewarding filler?
Word count is a weak signal, because a short answer can still be padded. One commenter suggested measuring information density per sentence instead, so each sentence should add a new fact, action, or constraint. If a sentence only restates the one before it, it is filler, and this check catches the ‘say it three ways’ problem quickly.
Q: Where should I test it first?
Start with onboarding flows and error messages. One commenter pointed out that confusing copy causes the most frustration there, and a user stuck on a form or facing a vague error is more likely to quit than one reading a weak headline. Run the skill on a real flow you already have, then compare the new copy with the old copy by watching where people hesitate.
Q: Why feed the skill product context at all?
Without facts about the product, a model fills the gaps with generic adjectives and claims the product may not back up. One commenter put it simply: most copy tools spray adjectives without knowing what the product does. The author’s early tests showed shorter outputs with fewer unsupported claims in some models, but the Codex pilot matched the baseline, so context helps without guaranteeing better results.
Can a modular skill improve product copy without inventing product features?
by u/Life_Assist5275 in PromptEngineering