product-thinking
Think like a product manager before changing React Doctor's public surface — CLI commands/flags, the 0–100 score, config (doctor.config.*), the JSON report schema, package APIs (inspect()/diagnose()), the GitHub Action, the website, and the canonical prompts. A step-by-step runbook for a user-facing change — locate the surface, search for a reuse candidate, wire one telemetry metric, add the compatibility artifacts (changeset / schemaVersion / action tag), update docs, and record a kill metric. Not for lint rules, which have their own pipeline. Also runs when the user types `/product-thinking`
Profile →npx skills add millionco/react-doctor --skill product-thinking --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Product Thinking A runbook for changing anything a user interacts with. The agent defaults to building exactly what was asked; this pass adds the product checks it skips — whether the change earns its permanent place on the surface, and how you'll know it worked. Work the steps before you write code, fill in the brief as you go, and fold that brief into the PR. Use it to push back when a change isn't justified, not just to wave one through. ## When to run it Run the pass whenever a diff touches a surface a user — a developer running React Doctor, or their CI — depends on. Every surface is a contract: once it ships, people build on it and you can't quietly take it back. Find where the surface lives first, so you edit the right place and can search it for something to reuse before adding. | Surface | Where it lives | Why it's load-bearing | | -------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | CLI command / flag | `cli/index.ts`, `cli/commands/*.ts`, `cli/utils/inspect-flags.ts` | Every flag is forever — it has to be parsed, d
- When to run it
- Steps
- 1. Write the job and the change
- 2. Search before adding
- 3. Wire exactly one metric
- 4. Pick the default and add the compatibility artifacts
- 5. Update the docs
- 6. Record the kill metric
- 7. Run checks
- Brief
- Stop and ask when
- Product principles (React Doctor)
bunx @rayhanadev/truffler "<name or behavior>" packages --kind function,interface,type,constant --limit 20 rg -n "<flag-or-option-name>" packages/react-doctor/src/cli packages/core/src/types nr typecheck && nr test && nr lint nr smoke:json-report # only if you touched the JSON report
What does the product-thinking skill do?
Think like a product manager before changing React Doctor's public surface — CLI commands/flags, the 0–100 score, config (doctor.config.*), the JSON report schema, package APIs (inspect()/diagnose()), the GitHub Action, the website, and the canonical prompts. A step-by-step runbook for a user-facing change — locate the surface, search for a reuse candidate, wire one telemetry metric, add the compatibility artifacts (changeset / schemaVersion / action tag), update docs, and record a kill metric. Not for lint rules, which have their own pipeline. Also runs when the user types `/product-thinking`
How do I install it?
Run `npx skills add millionco/react-doctor --skill product-thinking --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From millionco/react-doctor, a repository with 14,264 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.