- “i didn’t scale for what looks cool. i scaled for productivity.”
- “the models are really really good. what matters more is the harness and the tools you provide — and the one thing that you and i have that the models don’t have is my specific workflow, my specific taste, my specific strategy of doing things. and those can be codified in skills.”
- “when it messes up, you thank god. you don’t complain. this is the moment where you identify the error, tell it the error, it fixes it, and you tell it to update the skill file so this doesn’t happen again.”
the core argument of this episode is a direct challenge to the dominant approach of building elaborate agent systems: the models are now genuinely excellent, which means the limiting factor is no longer model intelligence but context quality — and most people are wasting that context on redundant instructions the model already knows while skipping the actually valuable part, which is codifying their own specific workflows into progressively-disclosed skills. the right way to build skills is not to write them from scratch or download them from a marketplace, but to walk the agent through the workflow step by step in a live conversation, achieve a successful run, then have the agent convert that demonstrated context into a skill file — and recursively improve it every time it fails. the overall philosophy is minimal context usage, skills over agent.md files, and scaling for productivity over scaling for what looks impressive.
- skills use progressive disclosure; agent.md files burn tokens on every single turn. when a skill.md exists, only the name and description enter the context window — the full content is only loaded when the agent determines it needs that skill. an agent.md file adds its entire content (potentially thousands of tokens) to every conversation turn. this distinction is not just about cost; it is about keeping the context window fresh and the model performant. the speaker tested a 116-line skill: as a skill it costs 53 tokens (name + description); as an agent.md it would cost 944 tokens every single turn.
- you cannot create a good skill without first having a successful run. the agent cannot write a useful skill from a verbal description alone because it has no reference for what “correct” actually looks like in your specific workflow. the correct sequence is: identify the workflow → walk through it step by step with the agent in live conversation → achieve a complete successful run → then ask the agent to review what it just did and convert that into a skill. skipping the live workflow phase produces skills that fail in unexpected ways because the gaps in the workflow have never been discovered and closed.
- errors are the mechanism for recursive skill improvement, not evidence of bad technology. every time a skill-driven workflow fails, the agent can describe exactly why it failed. you feed that failure description back to the agent, it fixes the issue, and you instruct it to update the skill file to prevent the same failure recurring. five loops of this process is what turns a fragile, one-source report into a ten-source report that runs flawlessly every time, autonomously, for ten minutes. the frustration most people feel is the frustration of skipping this investment period.
the speaker’s core intention is to correct the widespread misunderstanding that more infrastructure — bigger agent.md files, more sub-agents, downloaded skill packs, elaborate harnesses — produces better results, when the actual leverage is minimal context usage combined with skills built from genuine workflow experience. his deeper message is that the human contribution — your specific workflow, taste, and strategy — is precisely what llms cannot supply themselves, and codifying that unique knowledge into well-built skills is both the highest-value activity and the best defence against becoming redundant as models improve.
- context window composition — the full context at any point includes: the provider system prompt, the agent.md or claude.md file (if used), skills (name + description only, progressively), tools, the codebase or project files, and the conversation history; understanding what fills this window is the foundation of everything else
- progressive disclosure — the mechanism by which skills work: only the name and description enter context at all times; the full skill content is loaded only when the agent determines it is needed for the current task; this is the fundamental advantage of skills over agent.md files
- agent.md / claude.md files — persistent context additions that load their full content on every conversation turn; only justified for genuinely proprietary company information or highly specific methodology that must be referenced in every single interaction; 95% of use cases do not meet this bar
- skills — markdown files containing a name, description, and detailed workflow information; the description is the key — it must be specific enough for the agent to recognise when the skill is relevant; the speaker is a “skills maxi” and considers them the highest-leverage tool available
- recursive skill building — the iterative improvement loop: build skill from successful run → use skill → identify failure → feed failure back to agent → agent fixes → agent updates skill file → repeat until flawless
- scaling for productivity vs. scaling for what looks cool — the distinction between building agent systems because they are impressive (many sub-agents, large harnesses, downloaded skill packs) vs. building bottom-up from one agent with proven workflows before adding complexity
- context window performance degradation — as the context window fills, model performance degrades; the optimal operating range is roughly 10–70% full; beyond 80–90% the model becomes noticeably less capable; minimising context usage keeps the model performant throughout a session
- token efficiency — every token in context costs money and consumes window space; the skill structure (53 tokens for name + description vs. 944 tokens for full content every turn) illustrates why architecture matters more than content quality alone
- llms as token predictors, not thinkers — the models map input to a vector space and find the statistically closest next tokens; they do not reason or understand in the human sense; this is why explicit step-by-step workflow context is required rather than high-level intent
- templates as foundational context — for coding projects, a solid boilerplate template effectively becomes the context that guides the agent; anticipated to have a renaissance as their role shifts from reducing manual setup to providing the semantic foundation for agent-built projects
- 95% rule for agent.md files — do not create an agent.md or claude.md file unless you have genuinely proprietary company information or a specific methodology that must be present in every single interaction; the default should be no persistent context file
- skill creation sequence — (1) identify a workflow; (2) walk through it live with the agent, step by step, correcting as you go; (3) achieve a complete successful run; (4) tell the agent to review what it just did and create a skill.md from that successful context; never skip step 2
- recursive skill improvement loop — use the skill → when it fails, ask the agent to describe the error → feed the failure back → tell the agent to fix it → tell the agent to update the skill file to prevent recurrence; repeat until the skill runs flawlessly
- do not download skills from marketplaces — downloaded skills lack the context of a successful run in your specific workflow and environment; they will fail in unexpected ways; review them for learnings but build your own; also a security risk (potential attack vector via malicious skill files)
- build one agent first — start with a single agent and build out proven skills before adding sub-agents; only add a sub-agent when you have pre-defined, proven workflows that genuinely benefit from delegation; avoid jumping to multi-agent architectures before the foundation is solid
- keep agent.md content minimal if you must have one — only include information the model genuinely cannot infer from context (e.g. a specific currency symbol, a proprietary methodology); do not include things the model already knows (e.g. “use react”, “use a dollar sign for money”)
- monitor context window usage — aim to keep the context window between 10–70% full during a session; architect skills and workflows to minimise unnecessary token consumption; recognise that performance degrades as the window approaches capacity
- give the agent failure information explicitly — when something goes wrong, ask the agent “why did you fail?” and “what error did you get?” rather than assuming it will self-diagnose; it will describe the failure accurately when asked, which you can then use to direct the fix
how was this video or article relevant to my current life? did it answer a specific question, enlighten me on a topic, etc.
- (to be filled in personally)
- (to be filled in personally)
- (to be filled in personally)
- (to be filled in personally)
- what workflows do i currently perform regularly that could be converted into skills — and have i ever actually walked an agent through any of them to get a successful run first?
- am i currently using an agent.md or claude.md file? if so, does its contents genuinely meet the proprietary/unique threshold, or am i burning tokens on things the model already knows?
- how full is my context window typically getting during active sessions — and is that degrading the quality of output i am getting toward the end of long conversations?
- what would it look like to build up from one agent with one well-built skill, rather than starting with a complex multi-agent system that has never had a proven workflow behind it?
- when my agent fails, am i logging those failures and using them to recursively improve the skill — or am i treating failures as frustrations and giving up?
- tools mentioned: openclaw (open-source local claude agent); claude code / anthropic; codex (openai coding agent); cursor; paperclip (multi-agent framework — reviewed but not recommended as a starting point); notion; google sheets; dub analytics; openai tokenizer (for measuring token cost of any text)
- concepts to explore further: progressive disclosure in ui/ux design (the skill mechanism mirrors this principle); context window architecture in llm agents; the leaked claude code system prompt (referenced as worth reading for developers); google’s memory indexing research paper (mentioned as potentially changing the landscape)
- before creating any skill, run the workflow live with the agent at least once to achieve a complete successful run; only then instruct the agent to convert the demonstrated workflow into a skill.md file
- every time a skill fails, treat it as a recursive improvement opportunity: ask the agent for the error, feed it back, get the fix, instruct the agent to update the skill file
- monitor context window usage during active sessions; if approaching 70%+ full, consider starting a fresh session rather than continuing to degrade performance
- before adding any new instruction to an agent.md file, ask: does the model already know this? if yes, do not add it
- audit any existing agent.md or claude.md files: remove anything the model already knows (tech stack, standard formatting, general conventions) and keep only genuinely proprietary or unique information
- identify one high-frequency workflow and run the full skill creation sequence: walk through it live → successful run → convert to skill → use it → improve recursively over five iterations
- do not download any skills from external marketplaces; instead, review them for structural ideas and build equivalent skills from your own successful runs
- resist adding sub-agents until at least one agent has proven, skill-backed workflows that would genuinely benefit from delegation
greg’s distinction between agents and skills is the most useful framing I’ve seen for understanding what this vault is already doing. skills (codified workflows that can be invoked) are exactly what the vault’s skills directory contains. the insight that “what matters more is the harness and the tools you provide, not the model” is validating — the vault’s CLAUDE.md and skills system is the harness, and the model is interchangeable.
- skills as codified workflow — a skill is your specific way of doing something, encoded so it can be invoked reliably. this is what the vault skills do.
- harness vs model — the model is the engine; the harness (prompts, context, skills) is the steering wheel. competitive advantage comes from the harness.
- when it fails, update the skill — errors become improvements to the system, not failures. the compounding loop.
- agents vs skills — agents are autonomous actors; skills are repeatable procedures. both are useful, at different levels of complexity.
the “codify your specific workflow” argument is the strongest case for investing in the vault architecture. the skills I’ve built and will build are intellectual property in the same sense as a business process — they encode judgment and taste that a generic prompt can’t replicate.
clear, practical, directly applicable to the current vault setup. greg isenberg’s explanation of the skills/agents distinction is more useful than most technical explanations of the same concepts. ★★★★☆
- which of my recurring workflows most need to be codified as vault skills right now?
- how do I know when something is ready to be a skill vs when it should remain a one-off prompt?
- greg isenberg – how i use obsidian + claude code to run my life — companion vault video
- vault’s .claude/skills directory — the live implementation of what greg describes
- codify after first use — when I do something for the first time using AI and it works well, immediately document it as a skill template for next time.
- N/A — skill-building is periodic.
- audit the current skills directory: which skills need updating? which recurring tasks don’t have skills yet?
- build one new skill this month for a task I do repeatedly from scratch