Revenue-Centric Design as an Agent Skill: What heliocosta-dev/revenue-centric-design Actually Installs

The gap this fills: conversion advice that an agent can actually retrieve

Most SaaS teams do not lack opinions about landing pages. They lack a shared vocabulary that survives handoff from a designer to a copywriter to an engineer. Revenue-centric-design packages that vocabulary as an Agent Skill: 134 principles drawn from the X/Twitter writing of Richard (@richardrx), a product designer working on conversion-rate optimization, churn reduction and applied behavioral science. The repository states he is ex-Volkswagen, ex-PayPal and ex-IBM, and that the material was distilled with his permission.

The intended reader is not a growth analyst hunting a dashboard. It is someone using Claude Code, Cursor, Codex, Copilot, Gemini or another skills.sh-compatible agent who wants the agent to reach for a named lever (the decoy effect, the Swiss Knife Index, Eugene Schwartz's awareness levels, loss aversion, the peak-end rule) while drafting a hero section, a pricing table or a cancellation flow. The throughline is the coined philosophy itself: design should serve the user and the business, value and revenue, not one or the other.

Progressive disclosure and the fixed shape of every principle

The architectural decision worth noting is that the skill does not load all 134 principles at once. The README describes progressive disclosure: the agent loads only the theme relevant to the question. The themes are separate files under references/, from conversion-and-landing-pages.md (24 principles) through pricing-and-monetization.md (15), onboarding-and-activation.md (20), churn-and-retention.md (13), behavioral-science-toolkit.md (7) and five smaller files, twelve themes in total. The entry point is SKILL.md, and informational diagrams live in assets/.

Each principle follows a fixed shape: Principle, Apply when, The move, Evidence, Visual, Source. That last field matters more than it looks. Every principle links back to its original post, which makes the file auditable when someone asks why a particular pattern is recommended. The repository is explicit that it reproduces distilled principles rather than the full posts verbatim, and that the underlying ideas remain the author's.

The trade-off is that retrieval quality now depends on the agent picking the right theme. A question that spans pricing and churn, such as whether to gate a feature behind an upgrade, may pull one file when two are relevant. Nothing in the README describes a cross-theme index.

Installing the skill and running a first pricing question

The primary install path is a single npx command. According to the README, it pulls the skill into your agent's skills directory, for example .claude/skills/ or .agents/skills/, and works with any Agent Skills-compatible agent.

npx skills add heliocosta-dev/revenue-centric-design

If you prefer not to use the CLI, the README gives a manual clone into a skills directory. The path below is the one it documents for Claude Code.

git clone https://github.com/heliocosta-dev/revenue-centric-design.git ~/.claude/skills/revenue-centric-design

Once installed, start a session and ask a question that maps to one theme, so the progressive-disclosure load has an obvious target. A pricing question is the clearest first test, because pricing-and-monetization.md covers decoy and anchoring, GBB, trial-with-card and upgrades. Ask your agent something like: "We are adding a third plan. Using the revenue-centric-design skill, walk me through the decoy and anchoring principles and tell me what to put on the middle tier." What you should see is an answer shaped as Principle, Apply when, The move, Evidence, Visual, Source rather than generic advice, with a source link back to the original post. If the answer arrives without that structure, the skill was not loaded and the theme file was never read.

To refresh later, the README documents an update command that re-fetches from GitHub; your agent picks up the new content on its next session.

npx skills update revenue-centric-design

A bare npx skills update refreshes every installed skill, which is worth knowing before you run it in an environment where other skills are pinned.

The gambling exclusion is a hard boundary, not a disclaimer

The README carries a usage boundary section that is unusually direct. The author granted permission to reuse the material on the explicit condition that it is never used for gambling, betting or casino work, including loot-box and real-money-gaming mechanics. The skill instructs agents to decline such requests, and the licence repeats the restriction.

For most SaaS teams this is irrelevant. For anyone building in that space it is disqualifying, and no amount of prompt engineering changes the position: the instruction to decline is part of the skill, not a suggestion layered on top. Treat it as a scope constraint when you evaluate the project, because it means the material is not a general-purpose behavioral-science reference you can apply anywhere.

The second boundary is temporal. The README calls the repository a point-in-time snapshot. Coverage runs from 3 Nov 2025 to 26 Aug 2026 across 136 posts, and anything posted after that date is not included. The README's own updating section is candid that extending it is manual work: gather the newer posts, distill each into the same principle shape, file it under the right references/ theme, then bump the dates in README and CHANGELOG.md. There is no scraper or scheduled job documented in the README, though the repository does contain an updater/ directory that the README does not describe.

Where a principles index is the wrong tool

An index of distilled principles is a poor fit when you need measurement. The metrics-and-experimentation.md theme has 6 principles covering A/B rigor, vanity metrics and churn-to-LTV math, but the skill does not run experiments, hold sample-size tables or read your analytics. If your question is "did this pricing change move NRR", the skill has nothing to say that your warehouse does not.

It is also weak as a source of truth for regulated or high-stakes copy. The principles are one practitioner's distilled writing, reproduced with attribution, not peer-reviewed research. The Evidence field in each principle points back to a post, which is a useful audit trail and also a reminder of the provenance: a designer's public writing, curated. Teams in finance, health or anything with a compliance reviewer should expect to translate the advice into their own policy language before shipping it.

Finally, the skill assumes an agent that supports the Agent Skills format. If your workflow is a static design system in Figma with no agent in the loop, installing this changes nothing about how your team works.

How it differs from a general design-principles prompt or a CRO checklist

The obvious alternative is pasting a design-principles prompt or a conversion checklist into your agent's system prompt. The difference is structure and provenance. A pasted checklist is flat: every item has equal weight and no trigger condition. Here each principle carries an Apply when clause, so the agent has a condition to match against your question rather than a list to recite. It also carries a Source link, which a hand-written prompt does not.

The second alternative is a book or a course on behavioral economics applied to product. Those go deeper on any single lever. What they do not do is sit inside the editor where the hero copy is being written, in a form the agent loads on demand. The trade-off runs the other way too: a book does not go stale in the same way, and this repository's coverage ends at 26 Aug 2026 by its own accounting.

A third comparison is a static internal wiki of CRO rules. A wiki is editable by your team and reflects your product's history. This skill is not editable in the same way without forking it, and its principles come from one designer's public writing rather than your own experiment log. The two are complementary only if you accept that the skill supplies vocabulary and your wiki supplies evidence.

Maintenance cost, licence terms and what a fork implies

The last push to the repository was on 2026-09-04, and the README's own last-updated line reads 3 September 2026. The repository is not archived. That is the extent of what the repository shows about activity; there are no releases retrieved, so versioning is by commit.

Upgrade cost is low on the consumption side. The documented update command re-fetches from GitHub, and the README states your agent picks up the new content on its next session. The cost sits on the contribution side: keeping the index current means manually distilling new posts into the fixed principle shape and filing them under the correct theme, then bumping two date fields. That is editorial work, not a build step.

Licensing needs care. The repository lists NOASSERTION, and the README describes it as source-available under custom terms: attribution required, no gambling, betting or casino use. The underlying ideas remain the author's. This is not an OSI-standard licence, so if your organisation has a policy that only permits permissively licensed dependencies, this repository will not clear it without a review. That is a description of the terms, not legal advice; read LICENSE yourself before redistributing or bundling the content.

Editorial conclusion

Adopt it if you already run a skills-compatible agent and want named conversion levers (decoy effect, loss aversion, awareness levels) delivered inside your design or copy workflow rather than in a separate browser tab. Skip it if your product is a betting, casino or gambling product, because the licence forbids that use and the skill instructs agents to decline such requests; skip it too if you need a live feed of new material, since this is a snapshot with coverage ending 26 Aug 2026. Before relying on it, open SKILL.md and one references/ file to confirm the fixed Principle to Apply when to The move to Evidence to Visual to Source shape matches how your agent loads context, and read LICENSE to confirm the attribution terms fit your distribution model.

Frequently asked questions

Official sources

1. heliocosta-dev/revenue-centric-design on GitHub
2. Issues
3. README