Skills Are the New Org Chart: Agentic Engineering with Claude Skills (Part 1)

EPD organizations have always been organized around vertical skillsets. Backend engineers. Frontend engineers. QA. DevOps. Design. Product. Each role is a concentration of knowledge: patterns, conventions, review criteria, and domain expertise that takes years to accumulate.

Skills in Claude Code (Anthropic's CLI for AI-assisted development) let you encode that knowledge as a markdown file in your repo. You write a SKILL.md file describing a process, and it becomes a slash command: type /create-endpoint in your terminal during a Claude Code session, and the AI follows your encoded procedure.

• A backend engineer's knowledge of API scaffolding becomes /create-endpoint
• A designer's WCAG compliance checklist becomes /check-a11y
• A staff engineer's architecture review criteria becomes /review-architecture

This isn't hypothetical. We built an internal skills marketplace organized by role: engineer, designer, PM, staff-EM, staff-SDET, staff-PM. Each role is a directory containing skills (slash commands that encode a process) and agents (AI personas that adopt a specific reviewer's mindset).

The result: a junior engineer can run /review-architecture and get the same structured feedback a staff engineer would provide. A PM can run /scope-feature and get a scope document that follows the team's established template.

When knowledge is encoded in a repo rather than locked in someone's head, the org chart starts to look different.

In this post (Part 1):

1. The shift: from roles to skills: why vertical skillsets are becoming reusable artifacts
2. What a skill actually is: anatomy of a Claude skill
3. When to create a skill vs. build a product: the decision tree engineers need
4. Skills across EPD: real examples from engineering, design, product, and QA
5. Skills beyond EPD: voice encoding, persona reviews, document processing
6. What this means for org design: the practical implications

Part 2 will be a hands-on walkthrough of building a skill from scratch.

---

The shift: from roles to skills

Here's how EPD organizations have traditionally worked: you hire a backend engineer who knows your service layer patterns, your error handling conventions, your logging standards, and your deployment pipeline. That knowledge lives in their head.

• When they review a PR, they apply that knowledge
• When they onboard a new hire, they transfer a fraction of it
• When they leave, most of it goes with them

Skills invert this model. Instead of knowledge living in people, it lives in the repo:

• A review checklist that exists in a senior engineer's memory becomes /verify-sprint, a command anyone can run
• A scope document template that a PM keeps in Notion becomes /scope-feature. It generates a structured scope doc by reading documentation you maintain alongside your code: module descriptions, architecture notes, and pattern guides that give the AI enough context to navigate autonomously

The shift isn't about replacing people. It's about making expertise composable and shareable. A skill is a unit of institutional knowledge that:

• Survives turnover: the knowledge stays in the repo when people leave
• Scales instantly: 10 engineers can run /review-architecture at the same time
• Compounds over time: every failure mode encoded as a checklist item makes the skill better
• Crosses team boundaries: a PM's scoping skill can reference the engineer's service documentation
• Portable across repos: a skill built for one project works in any project with the same conventions

This is the same pattern we saw with CI/CD. Before CI, "knowing how to deploy" was a person's skill. After CI, it was a pipeline in the repo. Skills do the same thing for higher-level knowledge: review criteria, scoping processes, design system enforcement, sprint planning.

---

What a skill actually is

A skill is a markdown file that tells Claude Code how to perform a specific task. It lives in your repo at .claude/skills/<name>/SKILL.md and is invoked as a slash command.

The frontmatter defines metadata: name, description, and whether users can invoke it directly. The body contains step-by-step instructions, checklists, templates, or any procedure the AI should follow.

Here's a real example: a sprint verification skill that runs before every merge.

---
name: verify-sprint
description: Run the full pre-merge verification checklist
user-invocable: true
---

# verify-sprint

Run every check below. Report a pass/fail summary at the end.

### Code Quality
- [ ] All tests pass (backend unit, API, contract)
- [ ] Lint passes with zero warnings
- [ ] No files changed outside the sprint scope

### Contract Safety
- [ ] Backend schema changes have matching frontend types
- [ ] No field renames without migration path

### Documentation
- [ ] Changed modules have updated documentation
- [ ] API changes reflected in endpoint inventory

That's it. A markdown file with a checklist. When you type /verify-sprint, Claude reads the skill and executes every check against the current codebase. No code to write, no tool to install, no API to call.

Skills can also include supporting files:

• References: markdown files with templates, schemas, or domain knowledge that the skill reads during execution
• Hooks: shell commands that run automatically before or after specific actions (e.g., run lint before every file edit, run tests after every commit)
• Agents: specialized AI personas that adopt a specific role and review criteria (e.g., a "staff-em-reviewer" agent that evaluates architecture decisions the way a staff engineer would)

---

When to create a skill vs. build a product

As engineers, our instinct when we see a repeatable problem is to build a product: a dashboard, a CLI tool, a web app. Skills occupy a different space. They're for workflows that are repeatable but don't need a UI, where the output is text or files, and where the value is in encoding a process, not building an interface.

Make it a skill when:

• You do the same thing every sprint (verify, scope, report, audit)
• The output is a document, a checklist result, or a code change
• The process is currently in someone's head or a wiki page nobody reads
• Multiple people need to do it the same way
• The quality depends on not forgetting steps

Build a product when:

• Users need an interactive interface
• The workflow requires real-time collaboration
• You need persistent state or a database
• Non-technical users need to use it

The insight engineers miss: a lot of problems we solve by building products could be solved with a skill in a repo. Sprint reports, scope documents, architecture reviews, test coverage audits, security checklists, onboarding verifications: these are all processes that produce documents, not interfaces. A skill handles them in minutes. A product takes weeks and needs maintenance.

---

Skills across EPD

Here's what a skills-based approach looks like across each EPD function, drawn from a real internal skills marketplace.

Engineering skills

Skill	What it does
/create-endpoint	Scaffolds a new API endpoint following service layer conventions, error handling, and logging patterns
/create-service	Generates a service class with dependency injection and the team's established patterns
/pre-removal-check	Greps all consumers before removing a backend symbol: prevents broken imports
/run-tests	Executes the right test suite with proper markers and flags for the changed code
/verify-sprint	Runs the full verification checklist: tests, lint, contract checks, stale docs
/refresh-docs	Scans for stale codebase documentation and updates it based on code changes

The /pre-removal-check skill is a good example of encoded institutional knowledge. A senior engineer knows to grep for consumers before deleting a function. A junior engineer doesn't. The skill makes it automatic.

Design skills

Skill	What it does
/audit-ui	Comprehensive UI audit across accessibility, performance, theming, and responsive design
/check-a11y	WCAG AA accessibility audit with severity-rated findings and remediation instructions
/component-spec	Generates a complete component specification from the design system
/review-styles	Reviews changed files for Tailwind violations: wrong radius, padding, colors

These skills are especially valuable when engineers are writing UI code without a designer in the loop. The design system enforcement happens automatically instead of in PR review comments two days later.

Product management skills

Skill	What it does
/scope-feature	Produces a structured scope document by analyzing codebase documentation
/plan-sprint	Creates a sprint plan with task breakdown, agent assignment, and verification checklist
/sprint-report	Generates a post-sprint report with verification results, metrics, and learnings
/check-api-contracts	Detects schema drift between backend Pydantic models and frontend Zod schemas

The /plan-sprint skill encodes dozens of learnings from production sprints: agent lifecycle management, test strategies, capacity planning, and coordination patterns. That's institutional knowledge that would take a new PM months to absorb, available as a slash command on day one.

Staff-level review skills

Skill	What it does
/review-architecture	Reviews an architecture document for production readiness, failure modes, and versioning
/review-test-coverage	Audits test coverage across all layers: inventories files, maps coverage by domain
/bug-report	Systematic bug hunt on a feature: happy path, edge cases, error states, with severity ratings
/review-scope	Reviews a scope doc for user value, missing journeys, and unclear success criteria

These are the most powerful skills in the set. They encode the review criteria of your most experienced people into a command anyone can run. The /bug-report skill produces severity-rated findings with exact file locations, reproduction steps, and root cause analysis: the same output a staff SDET would produce, available to any engineer on the team.

---

Skills beyond EPD

The most surprising thing about skills is how far they extend beyond code.

• Voice-encoded writing. Captures a specific writing style: structure, tone, vocabulary, and formatting rules. Useful for teams where strategy documents, investor updates, or thought leadership pieces need to follow a consistent voice regardless of who drafts them.

• Persona-based reviews. Reviews documents through the lens of a specific stakeholder: a CFO evaluating financial rigor, a compliance officer checking regulatory language, or an operations leader pressure-testing feasibility. Encode their criteria once, get that perspective on demand.

• Diagram generation. Creates Excalidraw diagram JSON files following specific visual design principles: layout rules, color palettes, typography standards. Instead of opening a design tool, you describe what you want to visualize and the skill produces a diagram that follows your team's visual language.

• Document processing. PDF manipulation, PowerPoint generation, Word document creation: extracting text, filling forms, creating formatted outputs from templates.

• Context generation. Analyzes an entire codebase and generates a structured documentation layer: discovering patterns, mapping modules, and creating cross-references that let the AI navigate your code autonomously. This is the foundational skill: it creates the context that makes all other skills more effective.

These examples show that skills aren't just an engineering tool. They're a knowledge encoding mechanism that works anywhere you have a repeatable process that produces a document or artifact.

---

What this means for org design

If skills can encode the knowledge of a backend engineer, a designer, a staff architect, and a PM, what does that mean for how we organize?

It doesn't mean fewer people

It means different leverage. A senior engineer who encodes their review criteria as a skill doesn't become redundant: they become a force multiplier. Their knowledge runs 10 times a day instead of once. They spend less time on routine reviews and more time on the novel problems skills can't handle.

It means flatter expertise curves

A junior engineer with access to /review-architecture, /verify-sprint, and /check-api-contracts produces work that's closer to senior-level quality. Not because they have senior judgment, but because the senior judgment is embedded in the toolchain.

It means knowledge stays in the repo

When someone leaves, their skills stay. When someone joins, they inherit the team's accumulated knowledge on day one. The onboarding cost drops because the conventions are executable, not just documented.

It means cross-functional work gets easier

A PM can run /audit-ui on a feature they're scoping. An engineer can run /review-scope on a scope doc before starting implementation. The boundaries between functions become more permeable because the expertise is available as a command, not locked behind a role.

---

The org chart doesn't disappear. But it shifts from "who knows how to do this" to "who decides what we should do." The knowledge layer becomes infrastructure. The human layer becomes judgment.

---

Part 2 will walk through building a skill from scratch: the portfolio analysis skill I built for personal finance, from idea to published artifact. For the engineering workflow that skills plug into, see Agentic Engineering with Claude Code.

For Anthropic's official skills repository, see the Claude Skills repo. For a well-built community example, see Cole Medin's Excalidraw Diagram Skill.