Claude skills and plugins — turning prompts into reusable building blocks

TL;DR. A prompt becomes a saved prompt when one operator uses it twice. A saved prompt becomes a skill when three operators use it regularly. A skill becomes part of a plugin when you have three or more skills the team installs together. Each step up adds reuse and consistency at the cost of more upfront authoring. The decision is a question of usage, not engineering ambition.

The three (well, four) layers#

The pyramid is intentional. Most workflows live happily as saved prompts forever. The handful that earn the upgrade to a skill are the ones where consistency across operators matters more than flexibility.

When a saved prompt should become a skill#

Four triggers that mean it is time:

• Three or more operators use the same prompt regularly. The prompt is no longer one person's preference — it is the team's process.
• The prompt has multiple steps (research → draft → format) and consistency matters. Skills enforce the steps; saved prompts hope.
• Output schema is fixed — every run produces the same Excel structure or the same Word headings. Skills lock the schema; saved prompts re-derive it each time.
• The prompt depends on a connector (Slack, Notion, Salesforce). Connector calls are easier to wire once in a skill than to retype each session.

If none of those apply, leave it as a saved prompt. Premature skill-isation is a real failure mode.

Anatomy of a skill#

A skill is a small set of files, not a code project:

• A SKILL.md describing what the skill does, when to invoke it, expected inputs and outputs.
• Helper scripts or templates the skill can reference (a sample Excel, a Word template, a system prompt).
• Optional: a list of MCP tools the skill uses (which connectors, with which scopes).
• Lives inside a plugin folder or in the workspace under .claude/.

You can author a skill without being an engineer — it is a structured markdown document, not code. What an engineer adds is rigour around the schema, the error cases, and the connector wiring.

What a plugin is#

A plugin is a set of skills bundled together with a manifest. Installable from a marketplace or a private location. Tinkso's typical engagement ships one plugin per function: tinkso-finance-pack, tinkso-marketing-pack, tinkso-ops-pack. The team installs once; every operator on that function gets the same skills.

Plugins are how skill development scales beyond the pilot team. One operator's clever skill becomes the function's standard.

The skill development process (Tinkso method)#

1. Identify candidates from the pilot team's saved prompts. Sort by frequency × multi-operator use.
2. Co-design the schema with the operator who runs it most. The operator's expectations of the output shape become the skill's contract.
3. Author the skill, test against real past inputs (not synthetic data).
4. Deploy via plugin install so every operator on that function gets it at the same time.
5. Train the team on invocation — by name, with required arguments. Five minutes per skill is usually enough.

We code the first three skills with the operator watching, then the team writes their own. That is the test of whether the rollout took: can your team author a skill without us in the room?

Common skills mid-market clients ship in the first 90 days#

• Month-end close pack assembler — see Month-end close.
• Account research brief — see Account research.
• Newsletter assembler — see Content engine.
• Onboarding pack generator — see Onboarding packs.
• Compliance checklist runner — see Compliance checklists.

These are the skills that show up in roughly every mid-market deployment, with names varied per industry. If three of those map to your function, you have your first plugin.

Tinkso's take#

The prompt → saved prompt → skill arc is the cleanest signal we have for "this team is getting serious." Most clients hit it around week five of a deployment. We treat the first plugin as a milestone, not a polish step.

The temptation in week two is to skip ahead and build skills before the saved-prompt phase has produced enough usage signal. Resist. A skill built from one operator's preference is a skill the rest of the team will quietly route around.

Try this#

Open your CLAUDE.md. Find one saved prompt that appears in three operators' workflows. That is your first skill candidate. Note its inputs, outputs, and the one decision the operator makes mid-prompt — that decision is the schema field you need to expose in the skill.