Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ralfyishere/rules-with-receipts --skill product-thinkinggit clone --depth 1 https://github.com/ralfyishere/rules-with-receiptsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ralfyishere/rules-with-receipts/product-thinking)<a href="https://agentmods.dev/skills/ralfyishere/rules-with-receipts/product-thinking"><img src="https://agentmods.dev/badge/skills/ralfyishere/rules-with-receipts/product-thinking/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ralfyishere/rules-with-receipts/product-thinking"><img src="https://agentmods.dev/badge/skills/ralfyishere/rules-with-receipts/product-thinking.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00092 | $0.01585 |
| Opus 5 | $0.00046 | $0.00792 |
| Sonnet 5 | $0.00018 | $0.00317 |
| Haiku 4.5 | $0.00009 | $0.00159 |
Grade A, and why
Product Thinking scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Product Thinking
Purpose
Product decisions fail in a standard way: a feature gets built because it was requested, was buildable, and sounded good — and the underlying user problem was never stated, so nothing was actually solved and nobody can even tell. This skill enforces the decode: every feature is someone's proposed solution to an unstated problem, and the problem — plus real evidence anyone has it — is what decisions get made on.
When to use this skill
- Build/don't-build and prioritization decisions; roadmap tradeoffs.
- Interpreting feature requests and user feedback — especially specific, loud, or repeated asks.
- Scoping an MVP or first version; defining what "success" for a feature means.
- Evaluating product/business ideas (pairs with
structured-reasoningandfailure-mode-awareness).
When NOT to use this skill
- Executing an already-made product decision — building it well is
plan-gate+ siblings; re-litigating it isscope-fenceterritory. - Pure technical decisions with no user-behavior question in them.
- Contractual obligations ("client X paid for feature Y") — decode the problem anyway for design quality, but the build decision is made.
Operating procedure
1 — Restate the ask as a user problem. Template: [who], in [situation], is trying to [accomplish what], and is blocked/hurt by [what]. If you can't fill this from available evidence, that's the first finding — the request is a solution with no stated problem, and the next step is discovering whether one exists, not building.
2 — Decode the request, don't obey it. "Add an export-to-Excel button" might be: needs one number weekly (→ a scheduled email beats the button); needs data in another tool (→ integration/API); doesn't trust the dashboard (→ a trust problem no export fixes). The request constrains the solution space least; the problem constrains it usefully.
3 — Weigh the evidence of demand, not the volume of the ask:
- Requested by how many, and are they representative or just loud? n=3 vocal users is a signal to investigate, not a mandate to build.
- Distinguish "say they want" from "behavior shows they need" — workarounds in the wild (spreadsheets, scripts, support tickets) are stronger evidence than requests.
- Who would stop using / stop paying without it? That's the demand that matters, and it's usually a smaller set than the requesters.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 75 lines · 0 tokens per session scan A a3480cce894f
Product Thinking is a skill published in the GitHub repository ralfyishere/rules-with-receipts (2 stars, last pushed 2mo ago), licensed MIT. It adds 92 tokens to every session and 1,585 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
wayfinder
A planning method for large or unclear work that maps the decisions needed between the current situation and a defined destination. It records the map and decision tickets in an issue tracker.
triage
A structured issue-triage process that moves issues and, where configured, pull requests through classification and status steps. Triage means deciding what a report is, whether more information is needed, and who should handle it.
plan-to-tickets
Use when a large plan, PRD, feature, refactor, research plan, or multi-step coding task must be split into small ready-for-agent tickets with acceptance criteria, verification commands, blockers, and vertical tracer-bullet slices. Do not use for small tasks that should be implemented directly, single-bug fixes, or…
to-tickets
A method for turning a plan, specification, or conversation into small work tickets that each deliver a complete, testable slice of functionality. Each ticket records which other tickets must be finished first.
to-spec
A method for turning the current conversation and codebase understanding into a detailed software specification, then publishing it as an issue in the project’s issue tracker. An issue tracker is a tool for recording and managing development work.
alterlab-grant-reporting
Drafts post-award grant deliverables across funder formats — NIH RPPR (Annual/Interim/Final via eRA Commons), NSF annual/final project reports and the public Project Outcomes Report (Research.gov), and Horizon Europe / ERC periodic and final reports (technical Part A/B + financial statements on the EU Funding &…