Why skills are the new code in agentic development

Skills in agentic software development are reusable pieces of context that tell coding agents how to act, what standards to follow, and how to complete recurring work safely and consistently. As development shifts from hand-writing every implementation detail to expressing intent, skills increasingl

MMichael SwindellJune 25, 202617 min read

Skills in agentic software development are reusable pieces of context that tell coding agents how to act, what standards to follow, and how to complete recurring work safely and consistently. As development shifts from hand-writing every implementation detail to expressing intent, skills increasingly become the programmable layer teams maintain, test, version, and improve. That makes them closer to code than documentation. If your team works with coding agents, a platform like Levr fits naturally into this model by giving agents shared project context, workflow gates, test visibility, and memory, so skills can operate inside a real delivery system instead of floating around as disconnected prompts.

At a Glance

A practical model for managing agent skills like software assets

Agentic development scales when reusable context gets the same rigor as code.

● Core idea: Skills are not just notes for an LLM. They are reusable instructions that shape behavior across projects, tools, and workflows.

● Stack view: Modern agentic systems can be understood as models, tools, context, harnesses, factory lines, and full delivery factories.

● Main risks: Security, governance, duplication, poor collaboration, and skill rot become serious as teams create more reusable agent context.

● Engineering response: Static analysis, evals, dependency management, security scanning, and observability all map cleanly from code to skills.

● Team implication: Developers and engineering managers need a context development lifecycle, not just a software development lifecycle

The more often a piece of agent guidance gets reused, the more it starts behaving like a software dependency.

What does it mean to say skills are the new code?

Saying skills are the new code means reusable agent context is becoming the main programmable surface in agentic development. Instead of encoding every behavior directly in implementation, teams increasingly encode policies, workflows, and product knowledge in reusable instructions that shape how coding agents work.

Traditional software development revolved around implementation details. You wrote the exact logic, controlled the flow, and compiled the result into behavior. Agentic development changes that. More of the system behavior now comes from the combination of model capability, tools, and context.

In that setup, a skill is not just a prompt fragment. It is a reusable operating instruction. It might define how to review code, how to handle incident response, how to use a framework safely, or how to create tests in a specific repository. If a team uses the same instruction repeatedly, across people and projects, that instruction becomes a software asset.

This framing matters because software assets need discipline. They need testing, maintenance, ownership, and versioning. Treating skills like throwaway prose works only at very small scale.

What counts as a skill in agentic development?

A skill is reusable context that helps a coding agent perform a task correctly and consistently. It usually captures knowledge the model does not already have, would find inefficiently, or might apply unreliably without explicit guidance.

There are three especially useful categories.

Policies and practices

These include team conventions, security rules, framework usage patterns, API design rules, and coding standards. They answer questions like:

How should this team use a given framework?
What security boundaries must always be respected?
What style or architecture decisions are mandatory?

Product and system specs

These define the product, APIs, domain rules, or system behavior that a coding agent needs in order to build correctly. This matters most when the information changes quickly or cannot be inferred cheaply by trial and error.

Workflows

These tell the agent how to complete recurring work. Examples include incident response, code review flows, test creation routines, or rollout procedures. Sometimes the goal is capability. Sometimes it is consistency.

That last point is important. Even when an agent could improvise, teams may still want repeatable execution so humans can inspect, compare, and trust the result.

How do skills fit into the agentic development stack?

Skills sit inside a broader stack that includes models, tools, context, harnesses, and larger delivery pipelines. They matter because they are the layer where teams most directly program agent behavior without retraining the model itself.

A useful mental model looks like this:

Models: The foundational capability layer.
Tools: Utilities such as CLI commands, APIs, or MCP integrations that let agents act on the world.
Context: The instructions, rules, specs, and workflows that guide agent behavior.
Harnesses: Deterministic wrappers around probabilistic models that constrain behavior, define tools, and enforce rules.
Factory lines: Composed harnesses that create repeatable pipelines from request to shipped outcome.
Factories: Full delivery systems that combine many of the above into broader software processes.

In practical terms, tools give agents arms and legs. Context gives them direction. Harnesses provide guardrails. Pipeline composition turns isolated agent actions into something a team can rely on repeatedly.

Why are tools and harnesses not enough on their own?

Tools and harnesses make agents more capable, but they do not tell agents what your team considers correct. That team-specific guidance lives in context, which is why skills become the programmable layer that determines consistency, safety, and usefulness.

A grep command can search thousands of files efficiently. FFmpeg can modify media precisely. APIs can fetch system state or trigger actions. These are all powerful, but they are neutral.

They do not answer questions like:

Which coding pattern is approved here?
What acceptance criteria matter for this project?
How should incidents be handled in this organization?
What API constraints should never be violated?

Harnesses help by enforcing deterministic controls around the model. They can decide which tools are available, what config applies, and what hooks run before or after an action. They can even block certain operations unless required context is present.

But harnesses still depend on good context. A deterministic wrapper around poor guidance just makes mistakes repeatable.

How are skills loaded and used by coding agents?

Skills can be loaded in several ways, depending on how often they are needed and how expensive they are to carry in the context window. Teams usually split them into always-on rules, on-demand skills, and passive documentation.

This distinction helps control token usage and behavior.

Always-on rules

These are injected every time. They tend to cover global instructions, critical policies, or environment-wide constraints. Because they are always loaded, they must stay concise.

On-demand skills

These load when triggered by the task, the user, or the harness. This is often the best place for detailed workflows because they stay out of context until needed.

Passive context

These are documents available in the repository or knowledge base for the agent to find through search. Architecture docs and broader reference material often live here.

The key design question is not whether something is “context.” Everything is context in the end. The real question is when and how it should be loaded.

Why do skills need the same rigor as code?

Skills need code-like rigor because they are reused, compose with other assets, affect production behavior, and degrade over time. Once a team depends on them for delivery, they create the same reliability, security, and maintenance demands as software components.

Three forces make this unavoidable.

Reuse creates dependency

If a skill is used once, it is just task guidance. If it is reused across tasks and repos, it becomes shared infrastructure.

Composition increases blast radius

Skills can call tools, reference other skills, and participate in larger workflows. A weak skill can pollute an entire chain.

Change causes rot

Models improve. APIs change. frameworks evolve. Repositories shift. A skill that worked well a month ago may now be incomplete, inefficient, or actively harmful.

This is similar to software maintenance, but faster. In agentic environments, the half-life of correctness can be short.

What problems appear when teams scale skill usage?

Teams that scale skills usually run into the same cluster of problems: security, governance, duplication, weak collaboration, and lifecycle decay. These problems look familiar because they are familiar. They resemble software supply chain and code quality issues almost exactly.

Security risks

Some skills are malicious. Others are merely careless. Both are dangerous. A skill can encourage unsafe operations, expose secrets, or fail to declare necessary boundaries. The risk is not theoretical when agent logs, tool output, and shared context can surface sensitive data.

Governance gaps

Once many people publish and consume skills, teams need answers to basic questions:

Which skills are in use?
Who owns them?
Which versions are deployed?
Which ones were involved in a bad outcome?

Duplicate skills everywhere

Without a trusted system, teams create multiple versions of the same thing. Code review skills, test generation skills, incident response skills, and framework usage skills quickly multiply.

Low-trust collaboration

Shared repositories often become dumping grounds. If several similar skills exist and no quality signal tells you which one works, most developers stop trusting the repo and go back to writing their own.

Skill rot

Unmaintained skills age badly. A once-helpful workflow can become outdated, incompatible with a newer model, or misaligned with current repository practices.

Need a real control plane for agent workflows?

One way to keep skills useful is to connect them to shared issues, tests, gates, and observability instead of leaving them scattered across prompts and repos.

See how teams structure this →

How should teams evaluate and maintain skills?

Teams should evaluate and maintain skills using the same categories of engineering controls used for code: static analysis, dynamic testing, dependency management, security scanning, and observability. The exact tools differ, but the operating model is surprisingly similar.

1. Static analysis for skills

Static analysis inspects a skill without executing it. That can include:

Schema or formatting checks
Required field validation
Concision and structure checks
Security anti-pattern detection
Best practice review against official prompting guidance

This is the lowest-cost quality gate and should happen early.

For prompting best practices, official guidance from Anthropic on system prompts and tool use is a useful reference point for what good structure and activation design can look like in practice. See the Anthropic documentation on system prompts.

2. Evals as tests

Dynamic testing for skills usually takes the form of evals. You run the skill in a defined environment, observe the output, and judge the result.

You can think of evals in layers:

Skill evals: Test a single skill in isolation.
Project evals: Test a repository with multiple skills and project context present.
Broader model comparisons: See whether a different model materially changes performance for the same tasks.

Just like tests, scenario quality matters more than raw count. Weak evals can create false confidence.

3. Security testing

Skills should be scanned for unsafe behavior, secret exposure patterns, and supply chain risk. This is the same logic used in modern application security.

4. Dependency management

Once skills are versioned and shared, you need package-like controls. That means tracking installed versions, understanding what changed, and making it possible to roll forward or back when needed.

5. Observability and feedback loops

Lab quality is not enough. Runtime observation matters. Logs, pull request outcomes, failed tasks, and production issues help teams identify:

Which skills are helping
Which ones are failing
Where new skills are needed
Which existing skills should be deleted

This mirrors the broader shift seen in engineering workflows. According to the GitHub Octoverse and the Stack Overflow Developer Survey, developers increasingly rely on AI-assisted tooling, which makes quality controls around agent behavior more important, not less.

How do you build a context development lifecycle?

A context development lifecycle treats skills as maintained assets with creation, evaluation, distribution, consumption, observation, and improvement stages. The goal is to move human effort toward guiding and improving agent behavior rather than manually repeating implementation work.

A practical lifecycle looks like this:

Create context intentionally. Write reusable skills only for repeated tasks, standards, and workflows.
Evaluate it. Use static checks and dynamic evals before wider rollout.
Package and version it. Make installs and updates traceable.
Consume it securely. Apply governance and quality thresholds before adoption.
Observe real behavior. Use run data, PR outcomes, and logs as maintenance input.
Optimize or remove it. Improve what works. Delete what no longer helps.

This is where an agent-first control plane becomes useful. One way teams handle this in Levr’s workflow model is to define intent in natural language, let agents pick up scoped work, run automated verification, and keep human review as the merge gate. That structure gives skills a place to act consistently.

What role do harnesses and control planes play in this model?

Harnesses and control planes make skills enforceable and observable. Skills describe what should happen, while harnesses and delivery systems decide when skills load, what tools are allowed, what gates apply, and how outcomes are tracked across runs.

This distinction matters because many teams currently store skills in markdown, but markdown alone does not create operational discipline.

A harness can:

Load required rules automatically
Expose approved tools only
Run deterministic hooks before or after prompts
Block risky actions when required context is missing
Wrap model behavior in repeatable controls

A broader control plane can then connect that behavior to projects, issues, tests, and review gates. For teams coordinating multiple coding agents, Levr is relevant because the hard part is often not generating text, but keeping agents aligned through message passing, shared memory, and routing.

What mistakes do teams make when treating skills casually?

The most common mistake is treating skills like informal notes instead of production inputs. That usually leads to duplication, low trust, unclear ownership, poor security hygiene, and gradual behavior drift that only becomes visible after delivery quality falls.

Watch for these anti-patterns:

No quality gate: Anyone can publish a skill, but nobody can tell which one works.
No version tracking: A failure happens, but nobody knows what changed.
No evals: Teams assume a well-written skill is a working skill.
No runtime feedback: Skills are never updated from real outcomes.
No security review: Unsafe or secret-exposing instructions slip into shared use.
No deletion discipline: Old skills remain available long after they stop helping.

Software teams learned these lessons over decades with source code. Agentic teams are learning them again with context.

Technical Deep Dive FAQ

What is an agent skill in software development?

An agent skill is a reusable instruction set or context package that guides a coding agent through a task, policy, or workflow. It often captures team-specific information the model would not know on its own, such as framework conventions, product rules, security boundaries, or operational procedures. A skill becomes important when it is reused repeatedly, because at that point it starts behaving like a dependency rather than a one-off prompt.

How is a skill different from a prompt?

A prompt is often situational and tied to one interaction. A skill is meant to be reused across many interactions, projects, or contributors. Skills typically have clearer scope, stronger structure, and more operational intent. They may define activation conditions, approved tools, expected outputs, and boundaries. In practice, a prompt becomes skill-like once a team starts reusing it enough that correctness, maintenance, and collaboration matter.

Why do skills rot over time?

Skills rot because the environment around them changes. Models improve or change behavior, APIs evolve, frameworks update, repositories move, and team practices shift. A skill that once produced reliable outcomes can become inefficient, partially wrong, or actively misleading. The faster your agentic tooling changes, the faster this happens. That is why teams need a maintenance loop driven by evals, runtime observations, and periodic review rather than assuming published skills stay valid indefinitely.

How should teams test agent skills?

Teams should test skills with a mix of static checks and dynamic evals. Static checks inspect structure, safety patterns, required fields, and best-practice compliance without execution. Dynamic evals actually run the skill in a controlled task environment and score the result. Start small with isolated skill evals, then expand into project-level evaluations with multiple skills present. Like software testing, a few high-quality scenarios are usually more valuable than a large pile of shallow checks.

What security issues can skills introduce?

Skills can introduce malicious behavior, unsafe instructions, weak boundaries, and secret exposure risks. For example, a skill may encourage broad destructive actions, fail to warn against dangerous database operations, or normalize patterns that place API tokens into visible logs. Open skill ecosystems also create supply chain exposure, because teams may import instructions they did not write. That is why skill scanning, ownership, version tracking, and controlled distribution matter just as much here as they do in application security.

What is a harness in agentic development?

A harness is deterministic software that wraps a probabilistic model. It decides how the model is configured, which tools it can access, what rules are loaded, and what hooks or guardrails apply around prompts and actions. Harnesses matter because they let teams enforce repeatable behavior instead of hoping the model always chooses correctly. In practical terms, a harness is often where context loading, tool permissions, and action gating become operational rather than advisory.

How do skills compose with other skills and tools?

Skills compose by invoking tools, referencing related skills, or participating in larger workflows. A workflow skill might call another skill for log collection, another for root cause analysis, and another for issue creation. This composability is powerful because it allows layered behavior instead of rewriting instructions from scratch each time. It also increases risk, because defects in one skill can cascade through the chain. That is one reason versioning, eval coverage, and dependency visibility become essential at scale.

Why is dependency management important for skills?

Dependency management matters because shared skills eventually behave like packages. Teams need to know which version is installed, what changed between releases, who published it, and whether a specific outcome can be traced back to that version. Without that, debugging and governance become guesswork. Good dependency management also supports quality thresholds, safer upgrades, and broader compatibility across different coding agents, so teams do not have to rediscover the same problems on every project.

How can engineering managers govern skills across a team?

Engineering managers should treat skills as managed assets with ownership, quality gates, version history, and runtime visibility. At minimum, teams need a trusted registry or distribution method, a publish-review process, static security checks, some level of eval coverage, and observability tied to outcomes such as pull requests or production incidents. The goal is not bureaucracy. It is traceability. Once multiple developers and agents share the same skill base, unmanaged reuse becomes a reliability and security problem.

How do agent-first platforms help with skill management?

Agent-first platforms help by connecting skills to real delivery artifacts instead of leaving them as isolated text files. When skills run inside a control plane with projects, issues, tests, gates, and observability, teams can see whether the guidance actually improves delivery. Platforms with shared memory or routing layers also help when multiple coding agents coordinate over time. That does not replace skill quality work, but it gives teams the operational context needed to evaluate, govern, and improve skills systematically.

Key Takeaways

Skills deserve software-grade lifecycle management

Reusable context becomes infrastructure faster than most teams expect.

● Think in layers: Models provide capability, tools provide action, skills provide direction, and harnesses provide deterministic control.

● Treat reuse seriously: Once a skill is shared across tasks or teams, it needs ownership, testing, and version tracking.

● Use engineering controls: Static analysis, evals, security scanning, dependency management, and observability all apply directly to skills.

● Expect maintenance: Skills rot as models, APIs, repos, and team practices change.

● Build a context lifecycle: Create, test, package, observe, improve, and delete skills with the same discipline used for code.

The teams that win with coding agents will not be the ones with the most prompts, but the ones with the best-maintained context systems.