Skills package repeatable agent behavior into portable folders that can run across Claude, Codex, Cursor, and other tools.
2
A skill's description routes it to relevant tasks, while scripts and progressive disclosure provide deterministic data without filling every context window.
3
Skills improve through repeated use, evals, confidence checks, and reviews of the conversations and failures they produce.
Summary
Nick Nisi and Zack Proser explain skills as portable units of agent behavior. A skill can start as a small Markdown file, then grow into a folder with scripts, references, and other files. Its description helps the model decide when to load it, while constraints guide the result without prescribing every step. Scripts make parts of a workflow deterministic, such as supplying recent Git commits in a fixed format. The workshop builds a repo-roast skill and shows how to add progressive disclosure, confidence scoring, and evaluation. Nisi and Proser also cover practical questions about global skills, shared repositories, versioning, subagents, and memory. Their examples range from recruiting reports built from Slack and Notion data to image and video generation. They are candid that skill management still has rough edges, especially around conflicts, reviews, and model changes.
Skills prevent agents from starting every task with the same missing context
Nisi and Proser say that every new agent conversation starts from zero. Developers repeatedly explain project conventions, preferred tools, and the details of a workflow, even when they have worked on the same codebase all week. Files such as CLAUDE.md or AGENTS.md can provide persistent instructions, but those files load broadly, can affect unrelated tasks, and can still be ignored. Skills package a discrete unit of work with the information the agent must not miss. Proser compares this with bringing the DRY pattern into agent work, since the developer writes the instructions once instead of repeating them.
A small, specific skill can produce much better repository feedback
The speakers compare a generic request to review a repository with one that loads a skill containing about 30 lines of Markdown. Without task-specific context, an agent may say that the repository looks fine and offer generic advice. With a repo-roast skill, the instructions can encode local conventions and constraints, such as routing practices, semantic commits, or unacceptable README drift. The result should follow the format and standards the team expects. Nisi stresses that the skill is a repeatable way to teach the model how to perform the task, rather than a request whose output changes with the model or its current reasoning settings.
A skill is usually a folder whose description controls routing
A basic skill can be a skill.md file, but the speakers describe the broader structure as a folder. Its front matter includes a name and description. The description matters because the model uses it at runtime to decide whether the skill applies. The folder can also contain scripts, reference documents, and images. Proser says the description is an on-ramp for routing, while scripts provide a way to combine deterministic operations with an otherwise non-deterministic conversation. The skill's contents are loaded when relevant instead of placing every instruction into the agent's context at startup.
Constraints work better than prescribing every action
Proser warns that a common failure mode is writing a skill as a long, overly prescriptive novel. He recommends a small number of clear constraints, such as never being vague or requiring every code citation to include a specific line and Git commit reference. Nisi adds that users can state conventions and forbidden behavior while leaving the model room to determine the details. The repo-roast exercise gives attendees a general starting point and asks them to add requirements from their own work. The goal is a skill that produces a consistent kind of report without spelling out every internal step.
Scripts give agents a fixed starting point for changing data
The workshop demonstrates script interpolation with a command that finds stale to-dos and formats the output before the model sees it. Instead of asking the agent to find the latest commits and leaving the command and output format to its discretion, the skill runs an exact command and inserts its result. Proser says this saves tokens and avoids repeated tool exploration across terminal tabs. The model can then reason over a stable input. The same pattern fits morning reports, Git status summaries, and other workflows where a current but predictable data extract matters.
Shared skills need packaging and ownership conventions that are still developing
An audience member describes a team with engineers publishing similar skills, concerns about merge requests, duplicate routing descriptions, and skills becoming outdated when models change. Proser suggests that modified versions can remain local forks, while the speakers describe public, internal, personal, and monorepo-specific collections. Plugin marketplaces can install versioned packages into different tools, although the right packaging and filtering model is not settled. They admit that this is an active pain point. Their advice is to start using shared skills and learn from the problems instead of blocking adoption based only on anticipated governance issues.
Evaluation compares a skill against the model's unassisted performance
Nisi describes an evaluation framework that runs a task with and without a skill, then scores the results with a rubric. The skill should not make performance worse, and the team tracks how often it reaches the expected result. He describes the numbers as imperfect, but useful as a baseline when new models arrive. The same approach caught a problem in their Next.js installer skill: its detailed instructions made Claude Code worse because the model already handled Next.js well. Eval results gave them evidence to remove instructions instead of assuming that more guidance was better.
Confidence loops turn vague requests into reviewed execution plans
Nisi demonstrates an ideation skill that scores problem clarity, goal definition, success criteria, scope boundaries, and consistency. The score is not presented as precise mathematics. Its value is that it forces a dialogue before work begins. When the score is too low, the skill asks targeted questions, sometimes with multiple-choice answers. Once the request reaches a higher confidence level, it writes a contract with scope, exclusions, success criteria, and execution phases. Each phase can run in a fresh context. Proser compares the process to a good engineer drawing out the details during a whiteboard session.
"Skills are that next step. It's a way to make things more portable and you can use scripts to inject real data and you can make them composable."04:55
Who should watch
You repeat the same repository reviews, reports, or coding checks and want to turn them into reusable agent behavior.
Your team is deciding what belongs in global instructions, project instructions, a skill, or a subagent.
You want practical ways to test whether a skill improves an agent instead of trusting a promising prompt.
