Revenue-Centric Design: 134 principles, twelve files, and a license that is really a permission letter

The twelve theme files add up to exactly 134

The counts hold up. Conversion and Landing Pages holds 24 principles, Onboarding and Activation 20, Pricing and Monetization 15, Revenue-Centric Design 13, Churn and Retention 13, Product Strategy and Features 13, Positioning, ICP and GTM 8, Behavioral Science Toolkit 7, AI-Era Differentiation 7, Metrics and Experimentation 6, Checkout and Forms 5, and Dashboards and Data Visualization 3. Those twelve figures total 134, matching the headline number in the title line. The sourcing line says the same 134 principles were distilled from 136 curated posts, and the repository does not say what happened to the other two, whether one post yielded two principles or two posts yielded none. Every principle carries a link back to its original post, and the README is explicit that it reproduces distilled principles rather than the posts verbatim.

The nine principles in the README are a subset of thirteen

The README carries a spine of nine RCD principles, starting with neutrality is omission and ending with price is a filter. The reference file for the same theme, references/revenue-centric-design.md, is credited with 13 principles covering the RCD principles, the design process and the method. So four of them sit outside the spine, and the spine is a reading order rather than the whole set. That distinction matters for how the skill behaves: the nine are the ones an agent meets first and can recite without opening anything, the remaining four only appear once it loads the theme file. Anyone auditing coverage should read both, and anyone quoting the philosophy from memory will be quoting a subset.

Two ways to install, one documented way to refresh

The supported route is one line:

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

That pulls the skill into the agent's skills directory, with .claude/skills/ and .agents/skills/ given as the shapes it writes to. The manual route is a clone straight into the same location:

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

Refresh is documented only for the first route, with npx skills update revenue-centric-design and a bare npx skills update to refresh everything installed. Both re-fetch from GitHub, and the agent picks up new content on its next session, which means an update is not visible until the session restarts. The manual clone has no documented refresh path in the file at all, so a reader who chose the second route is left to work out the upgrade story themselves.

The license is a permission letter with two conditions

What governs the material is not a standard open source license. The stated terms are source-available under custom conditions: attribution required, and no gambling, betting or casino use, including loot box and real money gaming mechanics. The origin of those conditions is stated plainly: permission to reuse the material was granted on the explicit condition that it is never used for that category of product, and the skill instructs agents to decline such requests rather than answer them. The ideas themselves remain the author's, and every principle links back to the post it came from. so a redistribution pipeline should note the gap: no recognised license identifier appears with the repository metadata, while a LICENSE file does sit at the root. Confirm which text governs before you mirror the content anywhere.

Every principle ends in a citation rather than a number

Each entry follows the same six-part shape: Principle, Apply when, The move, Evidence, Visual, Source. The lever names are the part that travels well into an agent's vocabulary: the decoy effect, the Swiss Knife Index, good-better-best tiers, Eugene Schwartz's awareness levels, loss aversion, the peak-end rule. The action is concrete by design, since that is what Apply when and The move are for. The proof, though, is two pointers outward rather than a figure in the file, one to a diagram under assets/ and one to a post. So the skill hands an agent the name of a lever and where to read about it, which is exactly the right shape for progressive disclosure and exactly the wrong shape for anyone who needs an effect size to decide whether to ship.

The weighting follows posting volume, not the design surface

Coverage is uneven in a way that maps to what the author wrote about rather than to how much each area deserves. Four topics, KPIs, actionable panels, the F-pattern and role context, are held by three principles in the dashboards file, while hero copy, CTAs, social proof, awareness levels and CRO share 24 in the landing pages file. Checkout gets 5, spread over checkout, lead forms, cart abandonment and field friction. Metrics and Experimentation gets 6 for A/B rigor, vanity metrics and the churn to LTV arithmetic. Read the table as an index of where the source material was dense. A team with a serious experimentation programme will find six principles waiting there, and a team redesigning a dashboard will find three.

Three dates, and only one of them is a coverage date

The title line says last updated 3 September 2026. The coverage line underneath says the curated posts run from 3 November 2025 to 26 Aug 2026, 136 posts in all, and that anything newer is not included. Those are different things: the file was last touched after the newest post it contains. The repository's own last push falls on 4 September 2026, a day after the stated update date, so the version line and the commit line agree with each other and both sit outside the window of source material. The Updating section is candid that this is a point in time snapshot and spells out the extension procedure by hand: gather the newer posts, distil each into the same principle shape, file it under the right references/ theme, then bump the dates in the README and in CHANGELOG.md.

Recorded as Python, with the update path described by hand

The repository is classified as Python, and the top level holds .gitignore, CHANGELOG.md, LICENSE, README.md, SKILL.md and three directories, assets/, references/ and updater/. The agent entry point is SKILL.md, and the diagrams the principles cite live in assets/. What sits in updater/ is not described anywhere in the file, and the only update procedure given is the four manual steps above. So a Python script, if that is what the directory holds, is not wired into any command a reader is told to run, and a reader in a hurry has no way to find out whether running it would overwrite hand-written principle files or merely re-fetch posts. Look before you run anything from that directory.

Editorial conclusion

Take Revenue-Centric Design if you want a fast index into named conversion levers with a fixed shape, and you are willing to follow every principle back to its source post for the actual evidence. Two things to settle before you rely on it. First, the material is a snapshot of one author's public writing between 3 November 2025 and 26 August 2026, so anything he has posted since is not in it, and the documented refresh is a manual procedure rather than a command. Second, the terms are custom: attribution required, no gambling, betting or casino work including loot box and real money gaming mechanics, and the ideas remain his. If your product sits anywhere near real money gaming, the skill itself instructs agents to decline, so do not treat that as a guideline to route around. The repository metadata carries no recognised license identifier, even though a LICENSE file sits at the root, so confirm which text governs before you redistribute it.

Frequently asked questions

Official sources

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