Spiky Point of View
Sharpen a post, essay or talk thesis into a spiky point of view: a belief you will advocate for that others can disagree with.
Based on Wes Kao's public method.
Not affiliated with or endorsed by Wes Kao. Each step cites the public work it comes from: 15 sources.From balanced observation to a clear stance
Turns a bland opinion into a debatable claim with a mechanism and an action.
AI agents are powerful, but companies need to be thoughtful about how they deploy them.
Most teams should give their first agent fewer tools, not more. Every tool we added in our pilot widened the space of wrong actions faster than the useful ones. Start with one tool and one job. Add the second only when logs show the agent stalling for lack of it.
Illustration from the skill's worked example, not a recorded run.
What it does
When your agent should reach for this skill.
Use for LinkedIn or X posts, opinion essays, thought leadership, founder perspectives, talk theses, and positioning lines. Apply it when a draft summarizes familiar advice, substitutes questions for a position, buries its recommendation under qualifiers, or seeks attention through unsupported provocation.
Work within the author's actual domain and experience. Preserve their intended audience, purpose, format, and voice. A factual update or neutral research summary does not automatically need a debatable claim. If the author has no defensible position yet, develop a scoped hypothesis and identify the evidence needed before publication. Never manufacture personal conviction, customer stories, or results. 15
The method
12 steps, restated from Wes Kao's public work. Numbers link to the sources.
1Define the brief
Identify the author, credible domain, audience, desired change in belief or behavior, and channel constraints. Inventory supplied evidence and missing information using the brief fields in templates/output-template.md. Ask only for gaps that materially affect the claim.
2Mine candidate positions
Use the prompts in references/method.md. Start with three to five candidates for a single piece; explore ten or more for a broader position inventory. Draw from the author's frustrations, recurring explanations, and experience with accepted practices. 12
3Separate facts from interpretation
For each candidate, identify what was observed, what it might mean, and what the author recommends. Follow references/method.md to move beyond an interesting fact toward an owned conclusion. 36
4Apply the five traits
Check debatability, useful purpose, audience learning, defensibility, and conviction against references/method.md. Reject a candidate that merely attracts attention or repeats consensus. Repair a promising candidate before discarding it. 1
5Write a credible opposing view
Use the disagreement test in references/method.md. Explain why a knowledgeable peer would choose differently. Select the candidate with the strongest combination of author credibility, evidence, and reader relevance; briefly explain the choice when comparing supplied drafts.
6Sharpen the claim
Name the situation, disputed practice or frame, and recommended alternative. Use references/method.md and examples/worked-examples.md to replace broad slogans with bounded, meaningful assertions. Add numbers only when supported.
7Build the reasoning
Connect evidence to interpretation and action. Show a concrete example, script, or decision rule, following references/method.md. Distinguish firsthand evidence from assumptions and proposed tests. Never treat an invented illustration as the author's history. 913
8Calibrate certainty
Match wording to evidence, stakes, and the author's authority. Use references/method.md to preserve necessary uncertainty while removing defensive filler. A confident style does not convert a hypothesis into a fact. 58
9Handle the obvious objection
Anticipate the most likely substantive challenge and answer it in a proportionate passage. Follow references/method.md. Keep a material exception even when it requires more explanation than a short post allows. 8
10Assemble the deliverable
Fill the publishable section of templates/output-template.md: claim, evidence or mechanism, objection, and reader consequence. Lead with reader value before detailed instructions when buy-in is missing. Answer substantive questions before inviting discussion. 3414
11Review and revise
Run checklists/review-checklist.md. Resolve failures by changing the claim, evidence, scope, or wording. Keep necessary reasoning; cut material that serves venting or distracts from the reader's next decision. 715
12Return and test
Return the requested piece, with a short rationale or evidence gaps only when useful. Use references/method.md to propose audience testing when appropriate. Report resonance as untested until real feedback exists, then revise the exact passages that create interest, confusion, or disagreement. 12
Worked example
How the method plays out on one case.
1: Founder perspective on agent tools
Brief and fictional inputs
A founder wants a LinkedIn post for teams deploying their first internal agent. In this invented scenario, the founder's team added several tools during a pilot. The agent sometimes selected a plausible but incorrect tool, and debugging required untangling those choices. The supplied fictional record contains no measured failure rate or comparison proving a universal advantage for fewer tools.
Weak first draft
AI agents are powerful, but teams should be thoughtful about deployment. Good guardrails and the right tools are essential. What do you think is the best approach?
Applying the method
- Observation: More tool choices made this particular pilot harder to diagnose.
- Interpretation: Early deployment should prioritize understandable behavior over breadth.
- Assertion: Begin with the smallest tool set that completes a useful job.
- Credible opposing view: Broader tool access exposes workflow needs sooner and gives the agent more ways to recover.
- Obvious objection: A restricted agent may not be able to finish useful work.
- Boundary: This is a starting recommendation for a team's first internal deployment, not a claim about every mature agent.
Improved result
Give your first internal agent the smallest tool set that can finish one useful job.
In our pilot, adding tools gave the agent more plausible choices, including choices we did not intend. When it failed, we had to untangle tool selection before we could diagnose the underlying task.
Broader access may help you discover new workflows. For a first deployment, I would prioritize a workflow we can understand and support.
Pick a job worth completing. Give the agent the tools that job requires. Add another tool when a reviewed failure shows a capability is missing, then check whether the addition solves that problem.
Rules that made the difference
The opening advocates a disputed priority rather than repeating accepted advice. The opposing view names a real benefit of breadth. The pilot story supports a bounded recommendation without inventing a percentage. The final passage shows a decision rule and explains what to do differently. 13913
Confidence stays at the level of a founder's recommendation based on one pilot. If a real user has no such pilot, replace the experience paragraph with an explicitly proposed mechanism and present the recommendation as a hypothesis to test. 5
2 more worked examples in examples/worked-examples.md.
What's in the package
7 files, pinned at d5668a9. Open any file on GitHub.
SKILL.mdEntry point the agent loads: when to use the skill and the procedure.6,398 bytesLICENSEApache-2.0 license.10,756 bytesreferences/method.mdThe method in full, step by step, with citations.14,442 bytesreferences/sources.mdEvery public source the method is built from.4,149 bytesexamples/worked-examples.mdWorked examples showing the method applied end to end.6,329 bytestemplates/output-template.mdThe output format the agent fills in.4,744 byteschecklists/review-checklist.mdChecks the agent runs before handing back the result.5,068 bytes
Sources
The public work this skill is built from. Read Wes Kao's originals.
- Spiky point of view: Let's get a little controversial URLweskao.com
- My spiky points of view: 15 examples to inspire your SPOV URLweskao.com
- Why high performers make assertions: The difference between insights, suggestions, and assertions URLweskao.com
- Asking questions = no skin in the game. If you ask a question, try to answer it URLweskao.com
- Tone and words: Use accurate and precise language URLweskao.com
- Be objective, not detached URLnewsletter.weskao.com
- How to be concise URLnewsletter.weskao.com
- My episode on Lenny's Podcast URLnewsletter.weskao.com
- The Super Specific How: How to make your cohort-based course more rigorous URLweskao.com
- Using affirmative phrases: "Do this" versus "Don't do that" URLweskao.com
- Take 3 minutes to delete these words and improve your writing forever URLweskao.com
- Eyes light up (ELU) URLweskao.com
- Rigorous thinking: No lazy thinking URLnewsletter.weskao.com
- Sales, then logistics URLnewsletter.weskao.com
- Strategy, not self-expression: How to decide what to say when giving feedback URLnewsletter.weskao.com
The skill file also covers: Files in this skill. Read the full SKILL.md.
Edge wrote this skill from Wes Kao's public writing and talks listed above. It is not affiliated with or endorsed by Wes Kao. If something misrepresents the method, write to [email protected] and we will correct or remove it.