In a previous post, we showed how we wired Claude Code plugins capabilities into every developer’s environment with zero setup using a marketplace repo, Distributing Claude’s custom capabilities across to all developers in the organization.
This post is about the next step:
Using Claude Code to actually take over repetitive work - not just answer questions.
We’ll look at three building blocks:
Skills- reusable capabilities Claude can invoke autonomouslyAgents- workflows that orchestrate skills and reasoningSlash‑commands- one‑line triggers that kick those workflows off
And we’ll show how they combine with project context and historical examples so Claude can do real work safely, with a human still reviewing and approving the results.
The recurring task: “Add yet another endpoint”
Every backend team has some version of this task:
“Add a new API endpoint following our conventions, with validation, tests, metrics, and docs.”
It’s never exactly the same, but the steps rhyme:
Update routing / controller
Wire in domain logic
Touch tests, metrics, and docs
Follow naming, error, and logging conventions
We want Claude to handle 80% of the grunt work while still asking when it’s unsure.
Building Claude's Capabilities
Step 1 - Turn patterns into a Skill
In the previous post we used CLAUDE.md to describe project conventions. Now we bundle some of that knowledge and behavior into a skill. A skill is a small, discoverable unit of behavior and knowledge - think of it as a tiny plugin that encapsulates a pattern, policy, or action the agent can run. In Claude Code, skills live under skills/ as directories with a SKILL.md file. Claude discovers and invokes them automatically when relevant. Architecturally, skills are pluggable components that sit alongside your code and docs. The runtime discovers them, matches them to triggers or queries, and invokes them on demand. Importantly, skills don’t bloat the model’s chat context, they’re executed or referenced by the runtime when needed, so you get richer, reusable behavior without consuming extra conversation token budget. Claude Docs
For our “new endpoint” example, we will create the following Skill:
skills/new-endpoint/SKILL.md
Conceptually, it could say:
---
Name: new-endpoint
Description: >
Help design and scaffold a new HTTP endpoint.
Triggers: >
- Adding a new API route, controller or endpoint
- Defining request or response schemas
---
# New Endpoint Skill
## Input
1. Endpoint path
2. Request parameters
3. Response code & body
Invoke AskUserQuestion tool to clarify and add missing data
## Instructions
1. Read CLAUDE.md from repo root to learn conventions.
2. Scan existing endpoints in this service to infer patterns.
3. Look for 3-5 historical similar PRs (ask the user to provide them if you can’t find any) that added similar endpoints and extract naming, error handling, tests, and metrics patterns.
4. Invoke the lightweight planner to create plan for the new endpoint and ask the user to confirm:
- Path, method, auth
- Expected inputs/outputs
- Service ownership and criticalityNote the key bits:
It explicitly reads CLAUDE.md and the codebase for patterns
It mines historical PRs instead of guessing
It asks the user questions to clarify context
Claude can now invoke this Skill whenever it thinks “new endpoint” work is happening.
Step 2 - Wrap the Skill in an Agent that asks questions
Skills provide capabilities, an Agent orchestrates a full workflow. Plugins expose agents via agents/ markdown files. Claude Docs
We can define a new-endpoint-agent in our backend‑development plugin:
---
Name: new-endpoint-agent
Description: >
Plan and scaffold a new API endpoint following project conventions, using CLAUDE.md and historical examples.
---
You are an agent that:
1. Use the new-endpoint Skill to:
- Read CLAUDE.md
- Inspect existing endpoints
- Find similar historical PRs
- Plan the new endpoint, logic and tests
2. Summarize the conventions you inferred in a short checklist.
3. Ask the user clarifying questions when information is missing, e.g.:
- Is this endpoint public or internal?
- Which service owns it?
- What are the performance / reliability constraints?
4. Update the plan Proposed by the new-endpoint Skill if needed. verify: files to touch, tests to add, edge cases.
5. After user approval, apply changes step‑by‑step, narrating what you do.
6. Finish with a review checklist for the developer to verify.A typical interaction might look like:
User: “Add a GET /reports/{id} endpoint to fetch a report summary.”
Agent:
“Is this endpoint authenticated? If so, which roles can access it?”
“Should we expose only metadata, or full report contents?”
“Do we need rate limiting or caching?”
Only after those gaps are filled does it touch code. This is crucial, context isn’t just files - it’s also what the user didn’t say yet.
Step 3 - Make it one command away with a slash‑command
We don’t want developers to remember agent names. That’s where slash‑commands come in: Markdown files in commands/ that expand to instructions when you type /something. Claude Docs
In our backend‑development plugin we add:
---
Name: /new-endpoint
Description: "Plan and scaffold a new API endpoint."
Params:
- Name: path
Type: string
- Name: method
Type: string
Handler:
Type: agent
Agent: new-endpoint-agent
---
Given an API endpoint to add, work with the user to design and scaffold it.
Always:
- Load conventions from CLAUDE.md
- Look at similar historical changes
- Ask clarification questions before editing
- Narrate your changes and end with a review checklistNow any engineer can type:
/new-endpoint path=/reports/{id} method=GET
…and Claude will:
Load project conventions
Inspect existing endpoints and historical examples
Ask missing questions
Propose and apply a plan
Hand you a checklist to review
Why we obsess over context and historical examples
Design choices make this pattern work reliably:
Context first, code second
The agent’s first move is to read CLAUDE.md and scan the codebase. We deliberately keep the plugin generic and let each project define its exact conventions in-repo. That keeps the plugin small and the context window focused.
Historical examples over abstract rules
Instead of only telling Claude “we like X,” we show it how we’ve done X before via real PRs and commits. That gives it concrete patterns (file sets, naming, tests) to copy, and reviewer comments to learn from. The responsibility of the developer is to make sure that the agent isn’t learning from “bad examples”. Instruct the agent to disregard older PRs (that might be irrelevant), and to look for PRs with good coding principles and test coverage. Moreover, the developer MUST oversee the agent's work and make sure coding standards are kept.
Historical examples narrow the search space
PRs of similar work don’t just teach how to do something, they also show where to do it. By pointing Claude at a small, relevant set of files, historical examples dramatically narrow the search space. This reduces the chance the agent misses critical parts of the implementation or makes changes in the wrong places.
When the agent still doesn’t know something, it doesn’t guess - it asks you. That process (context → history → clarifying questions → action) is what makes it safe to let the agent own more of the repetitive work.
Where we’re going next
The “new endpoint” example is just one pattern. The same trio of Skill + Agent + Slash‑command works for many repetitive work such as:
/upgrade-dependency- safely update dependencies following prior upgrades/migrate- mechanical refactors with project‑specific rules/add-feature-flag- introduce flags using existing rollout and cleanup conventions
Because everything is just markdown in a plugin (skills/, agents/, commands/), we can evolve these workflows continuously without deploying new services. Claude Docs
Our goal is simple: if a task has been done three times the same way, the fourth time should start with “/…” - and Claude should already know your conventions, history, and what to ask when the ticket is underspecified.