DevSpark and Agent Skills: Beyond Portable AI Capabilities

I Almost Made DevSpark Smaller

When the Agent Skills specification started gaining traction, my first instinct was to comply. Break every DevSpark command into an atomic skill. One skill for clarification, one for specification generation, one for task decomposition, one for planning. Modular, composable, interoperable with Claude Code, GitHub Copilot, Cursor — the full ecosystem.

I spent a few days mapping it out. And the further I got, the more I could see what I was actually doing: dissolving the thing that makes DevSpark useful. Fragmenting a governed workflow into atomic pieces that reassemble themselves is just the same fragmentation problem at a different level. I was about to make DevSpark smaller in order to make it more compliant.

That's the moment this article is about. Not DevSpark's architecture in the abstract — the specific decision that clarified what the framework is actually for.

A Skill Is a Capability, Not a System

Before explaining what I decided, it's worth being precise about what the Agent Skills specification does well — because it does solve a real problem.

The industry is producing hundreds of standalone prompts, agent-specific hacks, and one-off automation scripts, and nobody has a clean way to share them. Agent Skills is a genuine attempt to fix that. Simple packaging conventions, agent-neutral definitions, markdown metadata, supporting scripts, composable and portable across ecosystems.

A skill is self-contained, portable, and agent-neutral. That's exactly what you want when sharing capabilities across reasoning environments.

What a skill doesn't provide is orchestration. It doesn't know what came before it in the delivery pipeline, doesn't integrate with governance processes, doesn't coordinate across agents, and doesn't maintain architectural continuity across the lifecycle of a feature.

DevSpark commands such as /devspark.specify operate in a fundamentally different context. They participate in governed workflows — they know the state of the project, integrate with review and validation processes, and can invoke multiple agents in sequence. Commands are orchestration-aware. Skills are interoperability artifacts.

The distinction felt academic to me until I started mapping DevSpark against the skills spec. Then it became architectural.

Scripts Are Where Context Comes From

Here's the part of the Agent Skills model I find most interesting, and the part most tooling ecosystems get wrong: script support.

I've spent more time getting DevSpark's pre-reasoning scripts right than I've spent on the prompts they feed — and that ratio has held across every project where the framework has mattered. Most AI tooling ecosystems invest heavily in prompts and almost nothing in structured context gathering.

Enterprise delivery is rarely an isolated task.

Before an agent reasons about a specification, it needs to know: what files are in scope, what APIs changed, what existing specs overlap, what tests are missing, what architectural boundaries are involved. On a recent refactor, a pre-reasoning script flagged that three modified files touched a service boundary documented only in an architecture decision record from 2022 — a boundary the prompt had no way to know existed. Without that script, the agent would have reasoned confidently in the wrong direction.

That's the gap. Currently, most workflows push the discovery burden onto the model through extended prompts — or worse, onto the developer through manual copy-paste.

DevSpark scripts run before the agent begins reasoning. They identify impacted service boundaries, extract modified public APIs, locate existing specifications, gather work item references, and summarize what changed architecturally — all before the model sees its first token. The result isn't prompt engineering. It's structured context engineering, and the difference shows up in smaller context windows, more relevant reasoning, and substantially reduced hallucination risk.

Where DevSpark Sits

I've been thinking about how to describe DevSpark's position relative to the emerging skill ecosystem. The layer model I keep returning to is:

ASLCD — Adaptive Software Lifecycle and Continuous Delivery — is the operating model above any single framework or tool. It's the set of organizational practices, governance structures, and delivery commitments that make AI-assisted development trustworthy at scale, not just functional in a demo.

DevSpark was never intended to be a prompt collection or a skill library. It evolved from a specific frustration: AI-assisted development tools work great in demos and fall apart in brownfield enterprise systems where the codebase has fifteen years of decisions embedded in it, governance is non-negotiable, and "just ship it" means something very specific.

Two of the principles that shaped DevSpark are the ones most invisible to the skills model: Spec-Driven Development and Brownfield Awareness. The Agent Skills specification has no concept of either. A skill doesn't know that the system it's operating in has an existing specification it must align with, or that the codebase it's touching carries architectural constraints from decisions made years before the skill existed. A governed workflow does.

None of the principles conflict with skills. But they operate at a scope that skills alone don't address — which is exactly why the fragmentation instinct was wrong.

The Decision: Outcome-Oriented Skills

What I landed on instead of fragmentation: outcome-oriented orchestration skills.

Rather than many small atomic pieces, a smaller number of skills each delivering a complete business outcome. The first flagship skill is write-spec — not specify, clarify, plan, and tasks as separate units, but a single skill that orchestrates the entire outcome of producing a working specification: clarify ambiguities, analyze the repository, gather architectural context, inspect existing specifications, generate the implementation plan, produce task breakdowns, set up validation criteria.

One invocation. One outcome. One governance boundary.

The phased approach to getting there matters as much as the decision itself. I'm not refactoring existing DevSpark commands immediately — that way lies instability. Instead:

Phase 1 — Design First. Establish the taxonomy, metadata standards, invocation patterns, and governance model for skills within the DevSpark ecosystem before touching any existing commands. This avoids premature coupling.

Phase 2 — Standalone Skill. Build skills/write-spec as a self-contained, interoperable implementation that runs independently of DevSpark. It proves out the script-driven context engineering model without destabilizing existing workflows.

Phase 3 — Internal Refactor. Once the standalone skill is validated, /devspark.specify becomes a thin orchestration wrapper around skills/write-spec. Backward compatibility preserved. Governance maintained. Lifecycle continuity unbroken.

The refactor only happens after validation. Slower than just reorganizing files — but the only approach that preserves the reliability teams actually depend on.

What's Still Not Settled

There's a version of this story where the conclusion is: "skills are great, DevSpark will support them, everything is fine." That conclusion is technically accurate and misses what's actually interesting.

The deeper question is what governance means in an AI-assisted delivery context. A skill is portable. Portability is valuable. But portability without governance is just another form of chaos — capable components with no principle organizing them into something trustworthy.

The distinction matters most in regulated industries, healthcare, large enterprise SDLC, brownfield modernization — anywhere the question isn't "can the AI do this?" but "can I trust what the AI did, can I audit it, and can my team build on it reliably?"

What I've worked out is the position. What I haven't worked out is whether the broader ecosystem builds toward that kind of governed interoperability, or routes around it by treating skills as the complete answer. The Agent Skills spec is a layer in what trustworthy AI delivery requires. Whether the industry treats it as a layer or as a destination is the question still open.

Explore More

Related articles that extend the thinking here:

• Why I Built DevSpark — The original frustration that shaped DevSpark's architecture
• The DevSpark Tiered Prompt Model — How context is resolved at scale across users and projects
• Workflows as First-Class Artifacts — Why multi-step orchestration needs explicit definition
• Designing the DevSpark CLI UX — The distinction between commands and prompts in practice
• DevSpark: The Evolution of AI-Assisted Software Development — How the framework has changed as AI tooling has matured