XBuilderLAB/cheat-on-money: a Claude Code skill for finding side work and screening scams

The problem cheat-on-money refuses to solve the usual way

Most side-hustle material is written by people who profit from the reader's attention. The README states the project's own position plainly: it does not search for posts teaching you how to make money, calling those a polluted source that sells courses and farms followers. That single editorial decision shapes everything else in the repository.

What it targets instead is inference. You look at signals produced by parties with no stake in your decision, such as industry reports, job listings and procurement data, and reason backwards to what an individual could actually supply. A second problem follows from the first: platform rules change constantly, so anything the model remembers from training is suspect. The README sets a hard cutoff, treating sources older than 24 months as expired by default.

The intended user is someone with a specific skill set, a limited budget and a real region constraint who wants to test one opportunity cheaply before committing. It is not aimed at someone who wants a list of ideas to browse. The README describes the deliverable as a judgement framework plus live retrieval assistance, and states that final decisions and risk rest with the user.

Six sub-skills and the state file that connects them

The repository is a set of Claude Code skills, not a single program. Six commands are documented. money-init builds a profile covering skills, available time, capital, region and whether you are willing to appear on camera, and writes a state file. money-find searches for opportunities matching that profile and applies the scam filter. money-verify is described as the core skill and checks one specific opportunity. money-plan turns a chosen opportunity into an action plan with a low-cost first test. money-retro compares actual time and income against what you predicted. money-status prints a dashboard at any point.

The state file is where continuity lives. The template at templates/money-state.template.json is described as schema v2 and includes a tier field plus fields for the calibration loop. That loop is the part worth understanding: money-plan writes down an expectation covering investment, time to first payment and income; after you execute, money-retro reconciles actual against expected; the resulting lessons flow back into a lessons.md file in the working directory, and money-find and money-verify read it before starting the next round.

Tier assignment runs through shared-references/user-tiers.md, which sorts users into T0 through T3 by resources and skills. The README states that both opportunities and income expectations are given according to tier, which is a sensible guard against advice calibrated for someone with more capital or more free hours than you have.

Demand-signal inference, source grading and the anti-scam rubric

The method document is shared-references/demand-signal-method.md, described as the main method behind money-find. It covers source grading, a four-step inference procedure and cross-validation. Cross-validation is the load-bearing part: a single signal is not treated as evidence, and the README says multiple independent signals must agree.

Scam screening has a single source of truth. Both money-find and money-verify read shared-references/anti-scam-rubric.md, which holds the red lines and something the README calls C-prime timeliness checking. The stated posture is to reject on doubt rather than accept on hope. That is a deliberate trade-off. A rubric tuned to avoid false negatives will discard legitimate opportunities that happen to look unusual, and the README acknowledges the cost with the phrase about preferring to kill by mistake. If you are exploring genuinely novel work, this bias will frustrate you.

The README's closing statement is the clearest line in the repository: anything involving paying first, task-based order brushing, passing money through your account, or lending out your account is a scam or illegal, and you should walk away immediately. That is stated as a flat rule, not a heuristic.

Installing the skills and running a first verification

There is no package to install from a registry. The repository provides two shell scripts, install.sh for Claude Code and install-codex.sh for Codex. The README also shows the manual route, which symlinks each sub-skill directory into ~/.claude/skills/:

cd "$(dirname "$0")" 2>/dev/null
ROOT="$(pwd)"
for d in skills/*/; do
  name="$(basename "$d")"
  ln -sf "$ROOT/$d" "$HOME/.claude/skills/$name"
done

After running that loop, each sub-skill appears under ~/.claude/skills/ as a symlink back into the checkout, so edits in the repository take effect without reinstalling. The README notes that ./install.sh does the same thing.

For Codex, the README gives a single command:

./install-codex.sh

That script installs the sub-skills into ~/.codex/skills/ and adds local resource entry points to each one: references/ pointing at shared-references/, templates/, examples/ and adapters/. The README states the two installations coexist and that Codex usually needs an application restart or a new session before it sees the skill list. It also notes that the allowed-tools field inside SKILL.md is a Claude Code permission declaration, and that Codex ignores it, triggering skills from name and description alone.

Once installed, a first real use follows the README's typical flow. You say you want to make money, which routes to money-init and produces the profile and state file. Then you ask for opportunities, which routes to money-find. When a specific offer appears, you ask whether it is trustworthy, which routes to money-verify. The README does not document what the verification output looks like in detail; examples/worked-examples.md is described as holding high-quality worked examples used as reference by money-find and money-verify, so that file is the place to look for the expected shape.

The two data adapters and what they deliberately do not read

General web retrieval cannot get past login walls, so the repository adds two adapters that the README labels B-tier semi-automatic. You log in and search yourself, passing any slider challenge by hand, and the adapter reads only the public list currently on screen.

adapters/xianyu/ covers the transaction side: what is being sold, at what price, and how many people want it. The README frames this as evidence that someone actually pays. adapters/boss/ covers the hiring side: what roles are open, what they pay and which AI skills are requested, described as the most honest demand thermometer. The README is explicit that this adapter reads search result list pages only, because list cards carry public job, salary and company information while HR personal details sit on detail pages and in chat. The adapter does not touch those, and the README ties that restraint to red line A6 of the scam rubric. Both adapters share one Chrome profile.

The honest reading here is that this is a scraping workflow with a human in the loop, not an API integration. It depends on the current page layout of two specific sites, and neither the README nor the repository listing suggests a fallback when a layout changes. The README does not document rate limits, error handling or what happens when a search returns nothing.

Where the design is thin, and what to use instead

Three gaps stand out. First, no licence is stated. The repository listing shows no license file and the README does not name one, so anyone planning to redistribute or build on the skills should treat the terms as unknown until the maintainer adds a licence. Second, the anti-scam rubric is the single source of truth for both screening and verification, which means its quality sets the ceiling for the whole tool. The README does not describe how the rubric was derived or how it is updated. Third, maintenance is not something the README addresses; the last push to the default branch was on 2026-06-12, and the repository is not archived.

For a real alternative, consider the plain research route the project defines itself against: reading job boards and industry reports directly, without a skill layer. The difference is not the sources, which overlap, but the packaging. Doing it by hand means you decide each time what counts as an independent signal and how old is too old. cheat-on-money fixes those choices in shared-references/demand-signal-method.md and shared-references/anti-scam-rubric.md, which makes runs comparable across weeks at the cost of flexibility. If your situation does not fit the T0 to T3 tiers, the fixed rubric will be the thing that gets in your way.

A second alternative is the calibration loop without the skills: keep your own predictions and outcomes in a spreadsheet and read it before each decision. You lose the retrieval and the shared rubric, but you keep the feedback structure that the README treats as the reason the tool improves with use.

Editorial conclusion

Adopt cheat-on-money if you already work inside Claude Code or Codex and you want a repeatable procedure for judging side-work offers rather than another list of ideas. Skip it if you expect a curated catalogue of gigs, or if you cannot install skills into ~/.claude/skills/ or ~/.codex/skills/, because the repository ships no standalone application. Before relying on it, open shared-references/anti-scam-rubric.md and read the red lines yourself, then check whether the repository has published a licence, since the README does not state one.

Frequently asked questions

Official sources

1. Issues
2. README
3. XBuilderLAB/cheat-on-money on GitHub