Agentic Workshop
Module 05 · 55 min

Reusable commands, Skills, and plugins

Course by Nello Castellano

A good reusable workflow reduces repetitive decisions without hiding responsibilities. You will learn when a command is enough, when a structured skill is needed and what to check before introducing a plugin.

Lessons

What you will tackle, step by step

5.1

Built-in Commands, Skills and Plugins

Today a custom command and a Skill are not two mandatory steps on the same ladder. In Claude Code both can appear as `/name`; for a new workflow, you usually start from a Skill. A plugin becomes useful when you need to distribute multiple components as a single package.

Claude Code includes its own commands, such as `/help` and `/compact`. The old custom commands have now merged into Skills: both `.claude/commands/review.md` and `.claude/skills/review/SKILL.md` can create `/review`, but the Skills folder is the recommended form because it supports resources, scripts and automatic invocation.

A plugin distributes a broader set of capabilities, for example Skills, agents, hooks and MCP servers. Start with the smallest contract that solves the problem: if a single review skill is enough, don't immediately turn it into a package with ten integrations to inspect and maintain.

See it in practice · Choose the format for release notes

Every Friday you have to turn a list of selected commits into internal notes, without publishing them and without reading the entire company history.

  1. Directly create a local Skill with two inputs, commit interval and target audience, and a fixed output: changes, fixes and known risks.
  2. Add two approved examples and an editorial checklist, because categories and tone are part of the method and should not depend on memory of the chat.
  3. Keep the Skill read-only and leave the output as draft; approval and publication remain separate human actions.
  4. Evaluate a plugin only if you need to retrieve commits from multiple repositories and send the draft to an external system, defining identity, permissions and error handling.

Result: Workflow grows when a real need emerges. Don't introduce credentials or integrations until a local Skill already produces a reliable draft.

5.2

Input and output before instructions

Before writing instructions, define the contract: what goes in, what goes out, and what failure looks like. A contract doesn't guarantee a correct answer, but it makes it possible to notice when it isn't.

Define what enters, which values are mandatory and how an error is reported. Then specify an output that a human or another tool can verify. A stable format avoids different interpretations between runs.

For a review, each report — often called a finding — can contain severity, file, line, risk, and remedy. If no problems exist, the output should explicitly say so and indicate what checks were performed.

See it in practice · Check a supplier invoice before importing

A workflow reads a CSV and reports suspicious rows. It must not correct amounts or load anything into the business system.

  1. Define input: UTF-8 file under 5 MB, required columns `invoice_id`, `date`, `net`, `tax`, `total` and currency declared only once.
  2. Validate structure and types before parsing; if a column is missing, return `invalid_input` with the precise name and do not attempt to reconstruct the values.
  3. Fix the output for each anomaly: row, violated rule, observed values and explanation; add total count and checks performed.
  4. Use three tests: valid invoice, inconsistent total and file without `tax`; confirm that no test modifies the source file or calls the business system.

Result: Whoever approves the import receives a comparable report and can distinguish a clean invoice from a file that the workflow was unable to read.

5.3

Anatomy and test of a skill

A Skill is not just a longer prompt. It is a reusable method with trigger conditions, necessary materials, orderly steps and a clear definition of when the work is finished.

An effective skill has a `SKILL.md` file: its frontmatter declares at least the name and description, while the body explains when to activate it, which resources to read, the order of the steps, and the Definition of Done. It may indicate allowed tools and include small, inspectable examples or scripts.

Test it on a normal case, an incomplete input, and a case that should reject. The skill is not ready if it only works when the user already knows all its assumptions.

  1. Define the trigger, scope, and cases in which the skill should not activate.
  2. Specify mandatory inputs, permissions, and output format.
  3. Organize instructions, resources, and scripts into inspectable components.
  4. Try normal case, incomplete input, and safe rejection.
  5. Compare the produced artifact with an explicit Definition of Done.
See it in practice · A Skill to anonymize support tickets

Want to create examples for documentation from real tickets, removing personal data without altering the technical meaning.

  1. Create `.claude/skills/anonymize-ticket/SKILL.md`. In the frontmatter, set `name`, a `description` that explains when to activate it, and only the necessary `allowed-tools`; in the body, limit the work to the texts provided for anonymization.
  2. Specifies categories to detect, such as names, emails, order numbers, and IP addresses, and the stable substitution format `[EMAIL_1]`, `[ORDER_1]`.
  3. Order steps: sensitive data inventory, replacement, second scan and final report; prohibits saving or sending externally without authorization.
  4. Test a normal ticket, one with missing text, and one that contains credentials: in the last case, the Skill must refuse to reproduce them and ask for an already-redacted source.

Result: The Skill produces consistent examples and a report of substitutions, but retains a clear limitation: it does not become a conduit for copying or storing secrets.

5.4

Provenance and permissions

Installing an external capability means extending trust to code, instructions, and updates that you don't directly control. The package name and a polished description do not tell you what it can read or modify.

Before installing external skills, check the author and version, then open what will actually be installed: Skills and related dynamic commands, agents, hooks, MCP endpoints, scripts, dependencies and permissions. A friendly description does not prove that actual behavior is safe.

Prefer fixed versions and limited environment testing. Record why the tool is needed and how to remove it. Reuse should reduce operational overhead, not create an opaque dependency.

See it in practice · Evaluate a plugin that prepares calendar events

The team wants to turn approved deadlines into event drafts. The plugin comes from a public repository and requires calendar access.

  1. Verify author, repository, signed release and change history; compare the downloaded package with the declared version.
  2. Read manifests, scripts and dependencies: Allow reading of selected deadlines and creation of drafts, but deny access to unnecessary contacts, emails and files.
  3. Install the fixed version in a trial calendar without personal data; simulates expired token and unreachable service, checking that no partial events are created.
  4. Documents reason for adoption, owner, token revocation process, and removal; enable the real calendar only after a review of the output.

Result: The decision does not depend on perceived reputation. You know what data passes through the plugin, what actions it can perform and how to stop access without leaving active credentials.

Guided example

Contract of /review

Task Notes needs repeatable reviews that do not modify the code.

Input: selected Git diff
Permissions: read-only
Steps: behavior → risks → missing tests
Output: severity | file:line | explanation | remedy
Error: report empty input; do not invent findings