Agent Skills give agents progressive access to instructions, reference files, and scripts without loading everything into context at once.
2
Skills and MCP solve different problems: MCP provides integrations and tools, while Skills explain workflows and product-specific rules.
3
A useful Skill needs an evaluation loop that compares agent behavior with and without the Skill, while checking that the evaluation itself measures the intended behavior.
Summary
Pedro Rodrigues explains how Supabase uses Agent Skills to guide coding agents through product-specific workflows. He starts with the Skill format, where a small front matter block tells the agent when a Skill applies and linked files provide more detail only when needed. He then compares Skills with MCP, arguing that MCP is better for integrations and remote tools, while Skills provide instructions, workflows, and scripts. The workshop demonstrates this with a Supabase performance review app. An agent creates a database view, but misses PostgreSQL's security-invoker requirement and bypasses row-level security. A Supabase security Skill adds that requirement and changes the agent's migration. Rodrigues then builds an evaluation harness with scenarios, assertions, and with-Skill and without-Skill conditions. He is honest about the difficulty: evals can fail because the grading logic checks the wrong thing, and agent behavior is nondeterministic. Production Skills need versioning, maintenance, and cleanup like other CI artifacts.
A Skill is a small entry point into a larger workflow
Rodrigues describes Skills as folders containing instructions and files for repeated workflows, custom information, or scripts. The required file is skill.md, with front matter containing a name and description. The description tells the agent what the Skill does and when it should load the rest. Reference files can contain ordinary Markdown, while scripts can be written in Bash, Python, or another suitable language. Reference files may link to other files, so a Skill can form a graph rather than a single document.
Progressive disclosure keeps unused detail out of the agent context
The main benefit Skills add around tools such as MCP is progressive disclosure. The agent first receives the Skill's front matter, which acts as an envelope. It can then decide whether to load the rest of skill.md and its referenced material. Rodrigues compares this to a book: skill.md is an expanded index, and the reference files are its pages or chapters. This lets a Skill carry detailed product knowledge without placing all of it in the initial context.
Skills and MCP should be used together for different jobs
Rodrigues says an integration should use MCP, especially when the agent needs access to a service or does not have Bash. MCP tools can run remotely and include authentication through the protocol. Skills provide the context MCP tool descriptions do not have room to contain, including workflows and product-specific instructions. Scripts run in the local environment and depend on its operating system. In his database example, he recommends an MCP tool to retrieve schema information and a Skill to explain how the agent should retrieve it in chunks.
The workshop exposes a security bug that a coding agent misses
The demo application is a performance review system with employees, managers, and an HR representative. Rodrigues asks an agent to create a department statistics view showing headcount and average salary. The agent creates the view and reports success, but Bob, an engineering manager, can see HR and product information. An employee can also see data that should be restricted. The problem is PostgreSQL view behavior: by default, a view can use the permissions of its creator and bypass row-level security on the underlying tables.
A product Skill can add database rules the model does not reliably infer
The prepared Supabase security Skill tells the agent to use the security-invoker option when creating the view. Rodrigues explains that, since PostgreSQL 15, this option enables the row-level security policies on the view. The Skill also includes checks for row-level security on public or exposed schemas. When the agent loads the Skill, its migration includes the security-invoker flag. The live demo still has other policy problems, so the final application behavior is not fully fixed, but the agent's database change clearly differs after the Skill is loaded.
An agent may decide whether to load a Skill from its description, so Rodrigues recommends testing both cases where it should load and cases where it should not. Developers can inspect the Claude Code CLI to see whether the Skill loaded, then revise the description and repeat the tests. He found that putting the verb "use" at the start of the description increased loading in his Claude experiments. A slash command followed by the Skill name gives an explicit way to load it in Claude Code.
Eval scenarios must describe the behavior that actually matters
Rodrigues says the hardest part of creating evals is writing representative scenarios and deciding what good behavior means. An eval can include a prompt, expected output, tool-call assertions, and success criteria for an LLM judge. The Agent Skills Open Standard format he uses stores these scenarios in eval.json. The harness resets the local database, runs the agent headlessly, and tests conditions with and without the Skill. This creates a first automated comparison instead of relying only on a manual demonstration.
The workshop's evaluation initially reports that the run with the Skill failed and the run without it passed. Rodrigues finds that the assertion was inspecting the wrong database metadata instead of checking the view directly. Both outputs were effectively the same, while the manual test had already shown that the Skill caused the security-invoker flag to be added. His example shows that evaluation failures can come from the evaluator rather than the agent. LLM-based grading adds another source of variation because the judge can also behave nondeterministically.
Production Skills need the same maintenance as documentation and CI artifacts
For production, Rodrigues recommends keeping only the Skills needed for the particular environment or workflow. He says Skills should be treated as documentation that lives in the repository, with updates included in the normal research and development workflow. Teams can periodically check whether a Skill still completes its intended workflow and whether users still load it. A Skill that is no longer used may not deserve to remain installed, even though progressive disclosure makes unused descriptions relatively cheap.
