Skip to content

Reusable Skills and Automation

If you find yourself typing the same multi-paragraph prompt for the fifth time — "review this diff for security issues and style," "turn this idea into a feature plan," "analyze these logs and suggest a root cause" — stop. That prompt is a process, and processes should be saved, not retyped.

Turning a repeated workflow into a reusable skill, slash command, script, or repo automation is one of the highest-leverage moves in AI-assisted development. It is also a direct answer to two of the AI's core limits.

Why this fights the limits. An agent does not learn from one session to the next (limitation #2): the brilliant prompt you crafted yesterday is gone tomorrow unless you wrote it down. A saved skill is that learning, made durable and shareable. And because a good skill is loaded only when relevant, it keeps your context window lean instead of bloating every prompt (limitation #1).

Turning a repeated prompt into a shared skill — and where automation stops helping — 2 min 1 s.

What "reusable" can look like

The same idea shows up at several levels of formality. Pick the lightest one that fits:

Form What it is Good for
Saved prompt A snippet you paste One-off personal habits
Slash command A .md file you trigger with /name An explicit, repeatable entry point
Skill A folder with instructions Claude can auto-invoke, plus optional scripts/templates Richer workflows the agent should apply on its own
Script A plain shell/Python script Deterministic steps that should not be left to the model
CI/CD automation An agent that runs in your pipeline Things that must happen on every PR, unattended

Workflows worth turning into skills

Common, high-value candidates:

  • Create a feature plan — codify the brainstorm → plan flow from feature to plan to handoff so every feature starts the same disciplined way.
  • Review a PR diff — a consistent checklist (correctness, security, tests, style) applied to git diff every time.
  • Add tests to project standards — generate tests that match your conventions, not generic ones.
  • Analyze logs and suggest an RCA — feed in logs, get a structured root-cause hypothesis.
  • Prepare a release checklist — version bump, changelog, migration notes, smoke tests.

The win is consistency: the tenth PR review uses the exact same rigor as the first, regardless of who triggered it or how tired they are.

Project-level vs personal skills

There are two homes for a skill, and the distinction matters for a team.

  • Personal skills live in your user config (e.g. ~/.claude/). They follow you across every project — your own habits and shortcuts.
  • Project skills live in the repo (e.g. a .claude/ directory committed to git). They follow the project and are shared with everyone who clones it.

For teams: commit shared workflows to the repo. A project skill is a way to encode "how we do things here" so the agent enforces team conventions automatically, for every contributor, without anyone memorizing a style guide. New teammates inherit the team's accumulated know-how on day one.

What lives in a project .claude/ folder

As an illustration only, one internal project (AuditAgent) keeps a project-level .claude/ directory committed to its repo. In practice such a folder typically holds things like:

  • settings.local.json — a pre-approved permission allowlist (which commands and tools the agent may run without asking), so the team's common operations — running the test suite, the linter, type-checks, fetching the docs they trust — happen smoothly instead of prompting every time. See Security, permissions and sandboxing and MCP and config for how these allowlists work.
  • Skills / slash commands — the repeated workflows above, written down once and shared.
  • Subagent and worktree config — settings for how the team runs parallel and delegated work.

The point is simply that the .claude/ folder is where a team's AI workflow knowledge accumulates inside the codebase, versioned alongside the code it serves.

Improve skills as the team learns

A skill is not write-once. The first version will be imperfect. When you notice the agent doing the wrong thing despite the skill — or doing something well that the skill should have asked for — edit the skill. Over time this is how the team's collective experience compounds: each lesson learned gets folded back into the shared instruction so nobody has to learn it the hard way twice. This is the closest thing to "the AI learning over time," except the learning lives in your repo, owned by you.

This has a name: compound engineering. The principle that each unit of engineering work should make the next one easier, not harder — by feeding what you learn back into skills, plans, and reviews rather than throwing it away. Every's compound-engineering-plugin packages the idea as a set of skills; the mindset matters more than the plugin, but it's a good concrete reference.

CI/CD review agents

The most hands-off form of reuse is an agent that runs in your pipeline: on every pull request, an agent reviews the diff, flags issues, and comments — no human has to remember to trigger it. This puts a consistent baseline of scrutiny on every change. Treat its output as advisory input to human review, not a gate that replaces it.

Claude Code ships a first-party way to do this: its GitHub Action (and companion GitHub app) can review every PR and respond to @claude mentions right in the pull request, so the review runs on each diff without anyone kicking it off. See the Claude Code GitHub Actions documentation.

Warning: automation supports discipline, it does not replace it

This is the part to take seriously. A skill that "reviews PRs" does not mean PRs are now reviewed — it means a first pass happens consistently. The danger is exactly the opposite of what you would hope: well-automated workflows make it tempting to stop paying attention.

  • A review skill can miss what it was not told to look for.
  • A test-generation skill can produce tests that pass without actually testing anything meaningful.
  • A plan skill can produce a confident plan built on a wrong assumption.

The rule: automation amplifies the engineering discipline you already have. It does not create discipline you lack. Keep a human accountable for every output that matters. If your team did not review code carefully before, automating the review will not fix that — it will just generate a green checkmark on top of the same problem.

Tooling in Claude Code

  • Skills and slash commands are the built-in mechanism for all of the above. Files in .claude/skills/ (auto-invocable, can bundle scripts and templates) or .claude/commands/ (explicit /name triggers) create reusable workflows; project-level lives in the repo, personal-level in your user config. See the Claude Code skills documentation and the Skills and plugins guide.
  • The skill-creator plugin helps you build, edit, and test a new skill rather than writing the folder structure by hand — useful when you are turning a repeated prompt into a proper, shareable skill for the first time.
  • Don't always start from scratch. Practitioners publish skills you can read, adapt, or install outright — mattpocock/skills is a broad everyday-engineering set, and the avoid-ai-writing skill (which strips the tells that make prose read as machine-generated) is a compact, well-structured example worth studying before you author your own. See the Catalog for more.

See also

Sources