agentleFS
Sign inStart free
malinskibeniaminmalinskibeniamin/skills/product/SKILL.md

product

Skill4 starsChanged 11 days agoMITView on GitHub

Keep work on track to business value: one lane, beneficiary, why now, evidence, reachability, smallest reversible slice. Use on every PR, plan, auto-review, or drift check.

14 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 13 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check value/reach. Correctness: /review.

    line 8
  2. Distinctive:

    Every change serves one primary lane.

    line 13
  3. Very specific:

    Intent: read the plan or PR body, linked issue, commits, and full diff.

    line 33
  4. Distinctive:

    Cost to own: run cost, new surface, dependencies, on-call load, and review time, against the simplest alternative.

    line 43
  5. Distinctive:

    justified: every step answered with evidence.

    line 58
  6. Distinctive:

    unjustified: no beneficiary or trigger, speculative surface, or cost above payoff.

    line 61
  7. Distinctive:

    Never block on taste alone.

    line 71

“Common” is measured: kept by at least 6 in 10 of the 13 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

For a material product or design fork, read the Poteto adaptation.

Check value/reach. Correctness: /review; truth: /lie-detector. Apply the product hat inline in /review, /grilling and auto-review, or standalone. RULES.md grades independent evidence sets; CRAFT.md owns author practice. Read review split.

Lanes

Every change serves one primary lane. Mixed purposes split into separate PRs.

LaneEarns its time byEvidence that counts
Keep the lights onSaving money or preventing loss: failures, idle cost, toil, dead surface, billing and upgrade pathsIncident or repro, dollars, hours of toil, verified fix
Quality of lifeSpeed and reputation: CI and dev loop, latency, actionable errors, docs that run, flakesBefore and after numbers, who is unblocked, how often
FeatureMaking money: a named buyer, segment, launch, or demo can do something newNamed demand, a reachable surface, an adoption signal
TasteKeeping the next change cheap: one source of truth, paved paths, class guards, deletionDrift or carrying cost it already caused, a second caller

Modes

ModeWhenOutput
PlanIssue, spec, or plan before code; the /grilling product hatVerdict, Given/When/Then acceptance, cheapest disproof, slice plan
AuthorWriting a PR, including /commit-push-prThe Lane: line and a body that answers the reviewer (CRAFT.md)
Review/review, auto-review routine, explicit askVerdict line and at most three findings
TrackA long branch, a stack, or work that keeps growingon track, drifting, or park, with the scope to cut

Procedure

  1. Intent: read the plan or PR body, linked issue, commits, and full diff; never trust a summary over code. Record the declared lane (Lane: line), or infer it and say so.
  2. Beneficiary: name the role and what changes for them. "Users" or "cleanup" alone is not a beneficiary.
  3. Why now: find the trigger (incident, customer ask, launch, deal, cost spike, measured regression, blocked consumer). None means the work competes with the roadmap.
  4. Evidence: measured > reproduced > named > asserted. Performance, cost, and reliability claims need numbers; a disproved hypothesis closes the work.
  5. Reach: trace the value to a surface the beneficiary uses today: UI, API, CLI, docs, a flag that is on somewhere. Merged but unreachable earns nothing yet.
  6. Cost to own: run cost, new surface, dependencies, on-call load, and review time, against the simplest alternative.
  7. Slice and safety: smallest independently useful slice, default off with a rollback, live consumers protected, one-way doors left to their owner.
  8. Rules: RULES.md Justification, Scope, and Evidence always; the lane's section; and Delivery, Trust, or Money when the diff touches rollout, customer-visible output, or billing. Load CRAFT.md for non-generated source or test changes. Enforce S and A; apply B when the diff plainly matches; C only when asked.

Track mode compares the branch with its stated outcome: work outside the lane is drifting (name the cut or the follow-up PR); value that cannot land yet is park (name the reopen condition).

Verdicts and severity

  • justified: every step answered with evidence. Approve quietly.
  • thin: real value, but evidence, acceptance, reach, or rollout is missing; ship after the named fix.
  • unjustified: no beneficiary or trigger, speculative surface, or cost above payoff; rethink the scope or park it with a reopen condition.
  • P1 Value: false success or a silent no-op; a lost or double charge; a live-path break with no off switch; a one-way door taken without its owner; a public claim that is not true.
  • P2 Value: missing beneficiary, trigger, evidence, acceptance, or rollout; speculative surface; mixed lanes.
  • P3: a nudge; automation never posts it.

Never block on taste alone. Grade sets how firmly a rule applies; severity comes only from this list.

Automated review

Silence means the value case is clear: a justified change gets only the verdict line. Otherwise post one top-level Value comment with at most three P1 or P2 findings, each with its rule id, consequence, and smallest fix. Never restate the PR. Value-only findings comment and never request changes; the owner decides. Judge bot findings on merit.

Output

product: <ktlo|qol|feature|taste> (<declared|inferred>) -- <justified|thin|unjustified> -- <beneficiary>; trigger: <why now>; evidence: <strongest proof>
- [P1|P2 Value] <rule id> <gap> - <consequence> - <smallest fix>

Plan mode adds the acceptance scenarios and the cheapest disproof. Track mode puts on track, drifting, or park in the verdict slot. Name what the review could not verify and who should make the final call.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free