advice_adoption_review v1.0.0

name: advice_adoption_review description: Review outside advice before it changes how you work: break a post, article, talk, or tip list into single claims, test each claim against your actual setup, costs, and constraints, and return an adopt, adapt, or skip call with a short spec for each, plus a re-home check before any skip stands. Triggers when someone shares advice and asks if they should follow it, wants a second opinion on a method, book, thread, or system, or is about to copy a workflow from another team, creator, or company.

Advice Adoption Review

Purpose

Stop advice being taken whole or refused whole. A useful article usually mixes claims that fit your setup, claims that fit after a change, and claims that only worked in the author's setting. This skill separates them, tests each one against your real constraints, and banks a verdict per claim that you can act on and revisit.

The method borrows from three established sources. Critical appraisal, as the Critical Appraisal Skills Programme defines it, judges trustworthiness, value, and relevance in a particular context. Rogers' work on how innovations spread names five attributes that shape adoption: relative advantage, compatibility, complexity, trialability, and observability. The ADAPT guidance in BMJ 2021 and the FRAME reporting framework cover the adapt case: state the mechanism, record what changed and why, and say whether the change keeps the core intact. Full notes in references/fit-tests.md.

Workflow

1. Freeze the source. Record the title, author, date, and link. Quote or closely paraphrase each claim from the source itself, not from a summary of it. If you cannot get the original, say so and grade the evidence down for every claim that depends on the missing text.

1. Snapshot your setup first. Before scoring anything, write down the goal the advice would serve, your current way of doing it, team size, tools, time and money available, hard constraints, non-negotiables, and how hard the change would be to undo. Scoring before this snapshot produces verdicts for a generic reader, not for you. Start a file with python3 scripts/review.py new --title "<title>" --source "<source>" and work inside it.

1. Break the piece into single claims. One row per claim in the claim table. Split bundled advice until each row can be true or false, or doable or not doable, on its own. Label each row by type: fact, causal, prescription, or assumption. Pull hidden assumptions into their own rows. Advice often rests on an unstated starting point, such as a team of ten, a budget, or an audience the author already had.

1. Grade the evidence per claim. Use the grades in references/fit-tests.md: strong, moderate, weak, anecdote, or none. Ask three questions per claim. Can you trust it? If true, how much does it matter? Was it shown in a setting close enough to yours to travel? Count the missing cases before you trust a success story. Ask how many people tried this and stopped, and what the normal result is, not just the best result.

1. Run the fit tests per claim. Score each claim pass, partial, or fail on fit, using the five tests in references/fit-tests.md: relative advantage over what you do now, compatibility with your tools, habits, and rules, complexity, trialability on a small slice, and observability of the result. Then run the context sweep once per review, covering the idea itself, the outer setting, the inner setting, the individuals who must change, and the process that will own it. Count all four costs for any claim headed for adopt or adapt: direct, attention, reversal, and lock-in.

1. Give one verdict per claim. Adopt, adapt, or skip. No whole article verdicts.

• Adopt means take it as written, and it still needs a pilot in step 7.
• Adapt means change it to fit, and write an adapt spec: what changed, the core mechanism kept intact, the reason tied to a named constraint, whether the change is planned, and a review date. If you cannot name the core mechanism, you are not adapting the advice, you are inventing a new idea and borrowing its name. Grade it as your own idea instead.
• Skip means refuse it for this setup, and it does not stand until step 6b is done.

6b. Re-home every skip. Check four other homes before a skip stands: a different project, a different person, a different time with a named trigger, and a different form that keeps the principle and drops the ritual. Record the outcome as moved, parked with its trigger, or discarded with the reason it fits nowhere you can name. Parked claims go on a dated list outside the review.

1. Pilot every adopt and adapt. Run the smallest trial that could prove the claim wrong: one project, one week, one slice of the work. Name the metric before the trial starts, record the baseline, set a stop rule, and set the review date. For a high cost or hard to reverse adoption, run a short premortem first: assume the change has failed in three months and write the most likely reasons, then check whether the trial would catch each one early. At the review date, confirm, adapt again, or drop the claim, and write the result next to the original verdict.

1. Bank the review. Save the finished file where a future review can find it. Run python3 scripts/review.py check <review.md> and fix every failure it reports. A review that lives only in a chat thread will be re-argued from scratch in a month.

Worked example: references/worked-example.md reviews the Daily Scrum from the Scrum Guide for a solo operator working with AI agents. It adopts two claims, adapts two, and parks one, with the reasoning shown per claim.

Output Contract

One markdown review containing all of the following:

• Source card: title, author, date, link, and a note on whether the original was read
• Setup snapshot: goal, current method, constraints, non-negotiables, reversibility
• Claim table with columns: number, claim, type, evidence grade, fit result, verdict
• One short fit note per claim naming the decisive test or constraint
• Adapt spec per adapted claim: what changed, core kept, reason, planned or not, review date
• Re-home check per skipped claim: homes checked, outcome (moved, parked with trigger, or discarded with reason)
• Pilot plan per review with any adopt or adapt: smallest trial, metric with baseline, stop rule, review date
• Verdict summary: counts and lists for adopt, adapt, skip, and parked

Operating Rules

• Never give a verdict on a whole article, book, or system. Verdicts belong to claims.
• Never adopt on anecdote alone. An anecdote grade caps the verdict at adapt with a pilot, and only when the fit is a pass and the cost is low and reversible.
• Never skip on taste. A skip needs a failed fit test, a named constraint, a cost that outweighs the graded value, or a re-home check that found no home. Write which one.
• Keep the author's context visible. When a claim only makes sense at the author's scale, budget, or audience size, write that context in the claim row instead of quietly shrinking the claim to fit.
• Separate the source's claim from your inference. If the source says a practice and a result happened together, the causal claim is yours until the source shows the link. Label it as an assumption row.
• Count switching costs against relative advantage. Advice that beats your current method by a little and costs a week to adopt is a skip or a park, not an adopt.
• Prefer a reversible trial to a long debate. When a claim is cheap to test and hard to settle by reading, test it and let the pilot decide.
• Revisit parked claims on their trigger, not on a schedule. A trigger is an event, such as a hire, a budget line, or a scale threshold. A date alone is not a trigger.
• Keep the review plain. Short claims, short reasons, no padding. If a row needs a paragraph to defend, the claim was probably two claims.