$npx -y skills add stevembarclay/pencilplaybook --skill best-in-world-researchWorld-class practice research. This skill should be used when the user asks what the best in the world does about a specific problem, technique, or situation — covering product, engineering, design, marketing, compliance, operations, org design, and any other domain. Use when the
| 1 | # Best-In-World Research |
| 2 | |
| 3 | Surface what elite practitioners actually do. Concise by default. Rigorous always. |
| 4 | |
| 5 | ## The Question This Skill Answers |
| 6 | |
| 7 | > "What does the best in the world do about [X]?" |
| 8 | |
| 9 | This is a research question, not a strategy question. The output is an expert brief — not a decision framework. Use `best-in-world-strategy` when the goal is to choose between options with tradeoffs scored. Use this skill when the goal is: *what does excellent look like here?* |
| 10 | |
| 11 | ## Mode Selection |
| 12 | |
| 13 | **Determine mode before responding:** |
| 14 | |
| 15 | - **Simple or directional question** → Quick mode automatically. Do not ask. |
| 16 | - **Open-ended or "I don't know where to start" question** → Ask: "Quick answer or comprehensive breakdown?" before responding. |
| 17 | - **User says "quick" / "fast" / "brief"** → Quick mode. |
| 18 | - **User says "deep" / "comprehensive" / "full"** → Deep mode. |
| 19 | |
| 20 | ## Quick Mode (default for most questions) |
| 21 | |
| 22 | Answer in expert voice. No headers. No bullet scaffolding unless the question naturally has a list answer. Conversational but authoritative — like you're quoting the person who spent 25 years solving exactly this problem. |
| 23 | |
| 24 | **Quick mode rules:** |
| 25 | - Name who: the specific company, team, person, or practitioner archetype that owns this domain. Not "top SaaS companies." Specific. |
| 26 | - State what they do: observable behavior, not belief. "They do X" not "they believe in Y." |
| 27 | - Give the mechanism: one sentence on why it works. |
| 28 | - Flag confidence if inferred: note when a practice is attributed vs. confirmed by primary source. |
| 29 | - Length: 2–4 short paragraphs or 4–6 bullets. No longer. |
| 30 | |
| 31 | **Example quick answer tone:** |
| 32 | > "If you asked the team that built Stripe's API, they'd tell you every error object returns four fields: `code`, `message`, `param`, and `doc_url`. The `doc_url` is the move most people skip — it turns a cryptic error into a solvable problem in one click. The pattern: errors are documentation. If a developer hits an error and can't fix it in two minutes, the error message failed, not the developer." |
| 33 | |
| 34 | ## Deep Mode (on request or open-ended questions) |
| 35 | |
| 36 | For when the user doesn't know the landscape and needs the full picture. Still not a dissertation — disciplined and structured, but concise within structure. |
| 37 | |
| 38 | **Deep mode output:** |
| 39 | |
| 40 | ``` |
| 41 | ## What the Best in the World Does: [Topic] |
| 42 | |
| 43 | ### Elite Practitioners |
| 44 | - [Name/Company]: [what makes them credible here — specific signal, not reputation] |
| 45 | - [Name/Company]: ... |
| 46 | - [Name/Company]: ... |
| 47 | |
| 48 | ### What They Actually Do |
| 49 | [For each practitioner: 2–3 concrete practices. Specific and observable. Note confidence: confirmed / inferred / attributed.] |
| 50 | |
| 51 | ### The Pattern |
| 52 | [2–3 cross-cutting behaviors that appear across the best. Name each. One sentence on the mechanism.] |
| 53 | |
| 54 | ### What Mediocre Looks Like |
| 55 | [The common approach most people take, and why it fails — include the failure mechanism, not just the label.] |
| 56 | |
| 57 | ### Starting Point |
| 58 | [Minimum viable world-class for this problem. What you can do this week. The single thing that separates good from elite.] |
| 59 | ``` |
| 60 | |
| 61 | Target length for deep mode: 400–600 words. If it's longer, cut. |
| 62 | |
| 63 | ## Quality Bar (both modes) |
| 64 | |
| 65 | - Never say "top companies" or "industry leaders" — name them specifically. |
| 66 | - Distinguish what practitioners *do* from what they *say*. Published principles often lag private practice. |
| 67 | - Concrete = "Netflix uses chaos engineering tools that randomly kill production services during business hours." Not concrete = "Netflix prioritizes resilience." |
| 68 | - Anti-patterns require the failure mechanism — why the bad approach still gets chosen, not just that it's bad. |
| 69 | - Flag inferences. Don't present second-hand attribution as confirmed practice. |
| 70 | - No padding. If you don't know specific practitioners for a niche domain, say so and give the best inference you have with a confidence note. |