Scale Your Top 1%
Every company has a best person for something.
The lawyer who knows which clause will blow up the deal. The tech lead who catches a bad boundary in the first diagram. The writer who knows what "good" looks like before anyone else can explain why. The marketer who can tell in one pass whether a line sounds like the brand. The person everyone pings before a big decision ships.
They are not overwhelmed because the work is mysterious. They are overwhelmed because their judgment is hard to access. It lives in their head, their calendar, and the same conversations every week. Everyone else waits. The best operator becomes the bottleneck without meaning to.
The default fix in 2026 is to "build an agent." That often skips the simpler move. Before you automate consequences, centralize expertise so it is available to everyone, 24/7, in the tools your team already uses.
Centralize expertise before you automate consequences.
A skill is how you do that. An agent is what you add later when the same judgment needs to touch live systems. Read the argument here. If you want to actually set one up this week, skip to the Working Examples at the end.
1. Skills Are Judgment. Agents Are Judgment Plus Keys.
A skill is a short, durable file your team can load into an AI session: checklists, red lines, examples of good and bad, when to escalate. It teaches the model how your best operator thinks in one domain. By itself, it does not send email, change a database, or deploy a website.
An agent, in the sense most teams mean, is that same expertise plus the ability to act: connected tools, approved access to Supabase or Vercel, a webhook your server runs, sometimes a loop. Connected tools, like database or website-hosting connectors, let the same judgment check live systems. An agent can do things in the world, not only advise. Skills change reasoning; agents change systems.
- Skill: a file anyone can run at 9 p.m. on a Sunday, same bar as Tuesday at 10 a.m.
- Agent: skill plus connections that need extra care (deploys, migrations, payment events).
Judgment scales as a file before it scales as a fleet.
If you jump to agents before the expertise is written down, you do not get leverage. You get faster mistakes with better tooling.
2. Your Best Operator, Available to Everyone
The goal is not to clone your strongest people or remove them from hard problems. The goal is to make their defaults accessible so the org stops treating them as the only operator.
Ask each domain's best person to spend one sitting, about 60 to 90 minutes, writing how they already decide. Not "learn AI." An export of what they repeat in reviews, calls, and the Slack threads that never quite become documentation.
Ship that as a skill anyone can invoke when the work matches. Sales runs the legal skill on a standard vendor agreement before counsel gets involved. A new hire runs the brand voice skill before a campaign goes out. An engineer runs the software implementation design skill before a build starts.
Your best lawyer is still your best lawyer. They are no longer your only lawyer on terms you have seen forty times. Your best architect is still your best architect. They are no longer in every early thread explaining the same boundary rules.
That is the shift: 24/7 access to defaults, human access to exceptions.
You are not automating the expert away. You are making their judgment easy to reach so they can focus on what only they can do.
The same expertise can live in Claude, OpenAI, Cursor, or whatever agentic platform your company already pays for. Copy the skill file or paste it into project instructions. The button changes. The bar does not.
3. The Bigger Picture: Your Context Graph
One skill is useful. Five skills start to look like an operating system. Over time, those files plus the connections you approve (database access, deploy checks, payment webhooks) become something larger: a context graph.
The name matters less than the behavior: your company stops rediscovering what its best people already know.
Think of it simply:
- Nodes are skills: legal, brand voice, software design, security pre-ship, editor rubric.
- Edges are the approved links to real tools when judgment needs live truth.
- The graph is how your company thinks and acts when the best people are offline.
The legal skill knows when to escalate. The brand skill knows what not to say. The deploy connection knows whether the latest version is actually live.
Most organizations have a social graph (who reports to whom) and a data graph (what is stored where). Few have deliberately built a judgment graph: encoded expertise that compounds instead of resetting every time someone new joins or someone senior goes on vacation.
Centralizing expertise is how you start that graph. Each skill is a node anyone can load. Each careful MCP or API connection is an edge you chose on purpose, not a tangle of one-off prompts.
This ties directly to the move we have been tracing in Stay Naive: as teams inherit more surface area with fewer people, standards have to travel without headcount. A context graph is how standards become infrastructure instead of heroics.
You do not need the whole graph on day one. You need the first node.
4. Five Skills Worth Centralizing First
Pick one lane this month. These five cover most operator-heavy companies.
Legal review. Your general counsel or commercial lead encodes first-pass rules for vendor contracts, customer terms, and data-privacy clauses: liability, data processing, termination, what always goes to a human. Sales and ops get a consistent first pass without burning senior time on basics.
Software implementation design best practices. Your tech lead encodes how you design and ship software: boundaries, migration order, rollback, what must never ship without review. Not generic "implementation" theater. The real build bar. We use this lane as the example in the next section and in the Working Examples.
Editor review rubric (writing). Your strongest editor encodes thesis, structure, specificity, and ranked feedback. Memos and posts stop depending on who drafted them.
Brand voice and marketing messaging. Marketing or the founder encodes tone, positioning, words to avoid, and good and bad examples. On-brand drafts without a brand cop in every thread.
Software security and privacy pre-ship checklist. Your security-minded lead encodes the software release gate: access, PII, secrets, logging, staging vs production. Same checklist for every ship, not a different conversation each time.
Most of these stay skills only. That is the point. Judgment first. Keys later, if ever.
5. What Good Looks Like (Without the How-To)
Software team
Picture a ten-person company with one tech lead everyone waits on.
Before the skill, every feature started with the same questions in Slack: Where does billing live? Can this service touch that table? What happens if the migration fails?
After the skill, those defaults live in a file. Anyone on the team can run them when the lead is in a meeting, on vacation, or asleep. The lead still owns the hard calls. They stop re-answering the easy ones.
What went into the file (about 90 minutes of their time): a simple diagram every design note must include, who owns which data, migration and rollback rules everyone already knows but never wrote down, and what must never ship without explicit human review.
What the team gets: the same architectural bar at any hour. What the lead gets back: hours each week that used to be repeat explanations. They show up for novel systems and real tradeoffs. The skill holds the defaults. The expert holds the exceptions.
Marketing and ops
Same pattern, no code required. The founder encodes the brand voice skill: tone, positioning, phrases to avoid, two examples of headlines that sound like you and two that do not.
A coordinator drafts a launch email at 8 p.m., runs the brand skill, and gets a useful first pass without pinging the founder. The founder still owns the campaign bet and the awkward positioning calls. They are not the only person who can spot an off-brand line before it ships.
That is the whole point for non-technical teams: the best operator stays the best operator. Everyone else stops waiting for them to wake up.
When either lead updates one rule, everyone loads the new default on the next task. That is how a context graph compounds.
6. When Judgment Needs Keys (Stay Conceptual)
The software implementation design skill is enough for most reviews. You escalate only when the same rules need live truth from your stack.
Three layers, in order:
- Skill: how we decide (available 24/7 in chat).
- Connected tools (MCP): read or act inside services like Supabase (database) or Vercel (deployments), with a human approving each step.
- Your API: the outside world calls you on a schedule (for example, Stripe sending a payment event to your server).
You do not need all three this quarter. You need the skill first.
For non-technical operators, the pattern still holds: a Notion or Google Drive skill for "how we organize client work" can be skill-only forever. Technical teams often add Supabase and Vercel when software is the product. Commerce teams add Stripe when money events need a reliable front door.
7. The Rubric
When someone says "we should build an agent," ask:
- Is the judgment still tribal? Your best operator writes or updates a skill. Stop until that exists.
- Do we need live truth from a system? Same skill, plus an approved connection (often Supabase or Vercel for software teams).
- Does the outside world need to reach us on a clock? Same skill, plus a thin API (webhook or scheduled job), with the security skill defining what "safe" means.
As smaller teams inherit enterprise-shaped complexity (the argument from Enterprise Problems Are Coming for Everyone), skills are how you afford standards without headcount. Agents are how you afford throughput with control, but only after judgment is centralized and accessible.
The Bottom Line
The bottleneck is rarely the model. It is expertise locked inside your best operators.
Centralize it. Make it available to everyone, 24/7. Let your strongest people work on exceptions and bets that matter. Let everyone else run their defaults in the LLM you already use.
Start your context graph with one skill this week. The Working Examples show you how.
Your best operator should be available to everyone. Not busy being the only operator.
Reflection Point
Who keeps answering the same question? Start there. Make their defaults available to everyone.
Want to try it yourself? Start here. One skill, one evening, no workshop.
Working Examples
Everything practical, in one place. Use the examples below when you are ready to build the first node. Technical steps start at section C; section D is optional.
A. Create your first skill (about an evening)
We use Claude Code as the example because the / menu and skill-creator are the gentlest on-ramp. The same expertise works in Cursor, ChatGPT, Claude on the web, and OpenAI projects: paste the skill text or drop the file where your tool keeps instructions.
1. Open Claude Code in a project folder (your IT person or a technical teammate can help you open the terminal once; after that, you mostly type in plain English).
2. Type /. A menu appears: built-in commands and your custom skills. This is how the team discovers what is available.
3. Run /skill-creator and describe what you want, for example: "Create a skill for first-pass legal review on vendor contracts." Or ask your best operator to dictate their checklist while someone else types.
4. Test it. Type / and pick your new skill, or ask: "Review this paragraph using our legal skill."
5. Share it. Save the file where the team can reach it: a shared drive, project folder, or each person's skills folder. For chat-only tools, paste the skill into project instructions so the whole company gets the same bar.
Reference: Extend Claude with skills
You are done when: a non-expert got a useful first pass without paging your best operator.
B. Five starter skills (copy the pattern)
For each, one expert spends 60 to 90 minutes on bullets and red lines. Everyone else invokes the skill name or pastes the file.
- Legal review: escalate list + first-pass checklist on vendor paper and data-processing addenda.
- Software implementation design: diagram template, data ownership, migration order, rollback, human gates before production.
- Editor review rubric: thesis, structure, specificity, ranked edits.
- Brand voice: tone, banned words, good and bad headline examples.
- Software security pre-ship: access, PII, secrets, logging, staging vs production.
C. Connect tools when you are ready (optional)
Only after the skill exists. A technical teammate can handle the first two connection steps in an afternoon; you approve what runs.
Supabase (database backend for apps)
- Sign up at supabase.com/dashboard (Google sign-in works).
- Follow Supabase MCP setup for your AI tool. Browser login is normal.
- Use a development project, not production, while learning.
- Example ask: "Using our software implementation design skill, list what tables we need for customers and orders before any migration."
Vercel (website hosting and deploys)
- Sign up at vercel.com/signup.
- In Claude Code, your teammate runs:
claude mcp add --transport http vercel https://mcp.vercel.com, then you type/mcpin chat to sign in once. - Docs: Vercel MCP
- Example ask: "Did our last preview deploy succeed? Flag anything missing against our security pre-ship skill."
Other MCPs worth knowing (non-technical teams)
- Notion or Google Drive connectors, where your stack supports them, for "how we file work" and client context without touching code.
- Stripe, when you take payments, pairs with section D below.
You stay in control: approve each action the model requests. The skill still defines what "good" means.
D. Stripe webhook (saveable pattern, not a deep dive)
When payments need to talk to your app reliably, the skill should already say: verify signatures, never process the same event twice, respond quickly, log failures.
Setup sketch your team can hand to a developer:
- In Stripe Dashboard → Developers → Webhooks, add endpoint:
https://yourdomain.com/api/webhooks/stripe - Copy the signing secret into your app's environment variables.
- One route accepts POSTs, verifies Stripe sent it, handles the event once, returns OK.
The AI can draft that route to match your skills. Your server runs it in production, not an open chat window.
More when you need it: Stripe webhooks
You are done when: you can explain "skill for judgment, webhook for money events" in one sentence.
E. Quick decision guide
- Unclear how we decide? Write a skill. Make it available 24/7.
- Need live data or deploy status? Same skill + Supabase or Vercel (dev first, human approves).
- External system must call us on a schedule? Same skill + one webhook route + security skill sign-off.
Start with one node in your context graph. The rest compounds.