DevSpark v0.1.0: Agent-Agnostic, Multi-User, and Built for Teams

The Warning That Started Everything

During a routine /devspark.critic run on a feature specification, the framework's own adversarial analysis tool printed this:

MEDIUM: Single-developer workflow assumption. The specification does not address how multiple developers would coordinate when using different AI agents. Prompt divergence across platform-specific directories could produce inconsistent implementations from the same specification.

That was my tool — the one I built to catch architectural risks in other people's specifications — diagnosing a fundamental flaw in its own framework. I'd been so focused on individual developer productivity that I'd missed a scaling question that should have been obvious: what happens when the second developer shows up?

The peer review feedback that followed was even more direct: "I use Copilot. My colleague uses Claude. We work on the same repo. How does this not become a mess?"

When your own AI tool tells you your architecture won't scale for teams, you rebuild it. Here is how we solved the exact problems /devspark.critic found.

The Foundation: A Constitution That Doesn't Bend

Before talking about how developers work differently, it's worth establishing what stays the same.

Every DevSpark project has a constitution — a shared constitution.md that encodes the team's non-negotiable standards: security requirements, compliance constraints, architectural principles, coding conventions. The constitution is injected into every command execution universally. No developer can override it, personalize around it, or weaken it through local configuration. It's the floor that every piece of work must meet, regardless of who writes it or which AI agent they use.

This matters because of what it makes possible. When the standards are structurally enforced — not just documented, but wired into every prompt and validated by the CI/CD pipeline — you don't need to mandate how developers work. You only need to mandate what the work must deliver. The constitution handles the what. Everything else — the how — becomes a space where individual developers can operate freely.

The /devspark.pr-review command, when integrated into the CI/CD pipeline, drives directly off the shared constitution. It cannot be overridden by a developer's custom prompt. It doesn't check what the developer intended to follow — it checks what the code actually delivers against the constitutional standard. That's the enforcement mechanism that makes everything else in this article safe.

With that foundation in place, the question becomes: how do you give a team of developers — using different AI agents, thinking in different ways, producing their best work under different conditions — the flexibility to work the way that makes each of them most productive? That's what v0.1.0 was built to answer.

The Gap in Detail

Before v0.1.0, the prompts lived in agent-specific directories. If you used Claude Code, you worked with files under .claude/. If you switched to GitHub Copilot for a session, you needed a separate set of prompts under .github/. Two agents meant two copies of every prompt — diverging silently, accumulating drift, and making "consistent workflow" a polite fiction. I use both daily, and the drift was constant.

The personalization story was worse. There wasn't one. Every developer used the same prompts. If the default /devspark.specify template didn't match how you think about requirements — if you wanted more emphasis on failure modes, or less on user stories, or a different structure entirely — your options were to edit the shared file (affecting everyone) or maintain your own fork of the fork (affecting your sanity).

These weren't theoretical problems. They were the specific, repeated friction points that showed up in critique after critique. And they're what v0.1.0 was built to solve.

Three Decisions That Changed Everything

The solution wasn't a grand redesign. It was three reinforcing architectural decisions that, together, reframe how teams interact with the framework.

Decision 1: Canonical Prompts as the Single Source of Truth

Every command prompt now lives in exactly one place: .documentation/commands/. This is the canonical source. The /devspark.specify prompt, the /devspark.critic prompt, the /devspark.pr-review prompt — they all have one authoritative version, maintained once, reviewed once, and versioned in git like any other piece of shared infrastructure.

This sounds obvious in retrospect. But the prior model — where each AI agent platform had its own full copy of every prompt — created the same problem that copy-paste coding does. You'd fix a bug in the Claude version of a prompt and forget to propagate it to the Copilot version. The prompts diverged not because anyone wanted them to — but because duplication makes divergence inevitable.

Canonical prompts eliminate the class of bugs that comes from having multiple sources of truth for the same content.

Decision 2: Thin Shims Per Platform

If canonical prompts are the single source, the platform-specific directories — .claude/, .github/, and any others — become what they should have been all along: thin shims. Redirects. Each shim does exactly one thing: point the AI agent to the canonical prompt in .documentation/commands/.

This is how I work daily. I switch between Claude Code and GitHub Copilot constantly — Claude for deep architectural reasoning, Copilot for rapid iteration inside VS Code. With thin shims, switching costs nothing. Both agents use the same prompts, the same constitution, the same governance. The workflow stays the same because the canonical content doesn't change — only the shim that routes to it does. Adding support for another agent means writing a shim generator, not copying and maintaining an entire prompt library.

Decision 3: Per-User Personalization for Individual Work Styles

With the constitution handling standards and canonical prompts handling consistency, there's a clear space left: how each developer actually works. Different people think differently, structure problems differently, and produce their best work under different conditions. A framework that mandates what the work must deliver shouldn't also mandate how each person gets there.

That's the core philosophy behind per-user personalization. It's not a workaround or an escape hatch — it's a first-class design principle. The constitution ensures every developer meets the same standards. Personalization ensures they don't all have to think the same way to get there.

Run /devspark.personalize specify and DevSpark creates a user-scoped copy of the /devspark.specify prompt at .documentation/{your-git-username}/commands/specify.md. That override takes priority over the shared default — but only for you. Your teammate's runs still use the shared version. Your other teammate's custom version lives under their own git username directory.

Personalization doesn't touch the constitution. It can't. What it can change is how you approach the work that the constitution governs — the structure of your specifications, the emphasis of your critic runs, the level of detail in your plans. These are coding work style preferences, not standards decisions.

Some developers think in terms of failure modes and edge cases. Others lead with user stories. Some want the Critic to be aggressive about performance; others want it to focus on maintainability. These aren't right-or-wrong choices — they're reflections of how individual developers do their best work. Personalization makes space for all of them, inside the same governance model.

It's reversible. Delete your override file and you're back to the shared default. No migration, no cleanup, no side effects. The shared version was never touched.

It's yours. A personalized prompt reflects how you think and work. If you want /devspark.specify to emphasize failure modes because that's how your brain approaches requirements, that's not a suggestion for the team — it's your workflow, optimized for your productivity.

As an implementation detail, personalized prompts are stored in the repository itself — which means they follow you across worktrees, cloud environments, Codespaces, and any other machine where you clone or pull. No dotfile syncing, no per-machine setup. Your work style travels with the code.

What This Looks Like in Practice

Consider a team of three developers working on a .NET microservices project. They've established a constitution, they're using DevSpark for specifications and PR reviews, and they've agreed on coding standards. Before v0.1.0, they all had to use the same agent and the same prompt templates.

Now:

Developer A uses GitHub Copilot and prefers concise specifications. They run /devspark.personalize specify and trim the user story template to just acceptance criteria and failure modes. Their git username directory holds the override.

Developer B uses Claude Code and wants the Critic to be more aggressive about security analysis. They run /devspark.personalize critic and add additional security-focused evaluation criteria. Their override sits alongside Developer A's, each in their own namespace.

Developer C is new to the team. They clone the repo, run specify init --here --ai copilot, and immediately have access to the team's constitution, shared prompts, and — importantly — visibility into how their teammates have customized their workflows. It's an onboarding accelerator. Instead of asking "how does the team do specifications?", Developer C can look at two different answers and start developing their own style from day one.

The constitution stays shared. The governance stays consistent. But the way each developer interacts with that governance adapts to how they think and work. Consistency and individuality aren't in conflict — they operate at different layers, and that's the point.

The full file structure, resolution order, and shim architecture are documented on the DevSpark site. The short version: when a developer invokes a command, the framework checks for a user-scoped override first, falls back to the shared canonical default, and injects the constitution universally.

Governance and Work Style: Two Layers, One Framework

The two pillars — constitutional governance and per-user personalization — aren't in tension. They solve different problems at different layers. The constitution answers: what standards must the work meet? Personalization answers: how does each person do their best work within those standards?

Neither is optional. Without governance, personalization becomes chaos — each developer drifting toward their own interpretation of quality. Without personalization, governance becomes a straitjacket — every developer forced into the same workflow regardless of how they think. You need both.

Here's what that looks like in practice:

I run /devspark.personalize critic and remove the static analysis emphasis from my local Critic workflow — I find it noisy during rapid prototyping in Claude Code. My iterations move faster. But when I open a pull request, the pipeline-integrated /devspark.pr-review runs against the unmodified constitution. If the code violates a static analysis rule that the constitution mandates, the PR is flagged. My work style shortcut didn't weaken the formal quality gate — because it can't. Personalization operates in a different layer than governance.

That's the design. Developers aren't personalizing despite the governance model; they're personalizing because the governance model makes it safe to do so. The constitution guarantees consistency. Personalization guarantees that achieving consistency doesn't require everyone to think and work the same way.

What This Means for the Framework's Future

Agent-agnostic architecture and multi-user personalization aren't just features — they're structural decisions that change what's possible going forward.

Individual productivity compounds over time. As each developer refines their personalized prompts — tuning emphasis, adjusting structure, adapting to their evolving thinking style — the framework gets better for them with every iteration. This isn't a collective optimization exercise. It's each person making their own tools sharper.

Agent evaluation becomes low-risk. A team can experiment with a new AI agent on a subset of tasks without committing to a migration. The canonical prompts don't change; only a new shim needs to be written.

Onboarding accelerates. New team members don't just get the code and the constitution. They get visibility into how experienced developers have shaped their workflows — a form of institutional knowledge that's usually invisible. And they're free to develop their own style from day one.

Cross-team prompt libraries become feasible. Organizations can maintain a shared set of canonical prompts as a baseline, with individual developers customizing from that foundation. The personalization layer provides the adaptation mechanism — not to standardize how people work, but to give everyone a starting point they can make their own.

The Three Pillars, Reinforced

v0.1.0 crystallized what I now think of as three reinforcing pillars — not as a marketing exercise, but as the architectural principles that every design decision gets evaluated against: constitutionally enforced governance (immutable standards that CI/CD pipelines apply regardless of local customization), agent-agnostic by default (canonical prompts, thin shims, no privileged agent), and multi-user personalization (user-scoped overrides committed to git for individual work style adaptation).

The constitution came first in the design for a reason. Once the non-negotiable standards are structurally enforced, everything else falls into place. Agent-agnostic architecture makes multi-user possible — you can't personalize per-user if each user is locked into a different prompt ecosystem. And personalization makes the whole framework worth using day after day — because it respects that different developers do their best work in different ways, without ever compromising what that work must deliver.

v0.1.0 didn't set out to solve team collaboration from scratch. It set out to solve the specific problem that /devspark.critic and peer reviewers kept surfacing: the framework assumed a single developer using a single agent. Real teams don't work that way. The fix wasn't a grand redesign — it was three reinforcing decisions: canonical prompts, thin shims, and personalized overrides committed to git, with an immutable constitution backing the formal review process.

Sometimes the best architecture is the one that gets out of the way.

For the complete command reference, installation guide, getting-started walkthrough, and compatibility matrix, visit the DevSpark repository and documentation site.

Explore More

• Bring Your Own AI: DevSpark Unlocks Multi-Agent Collaboration -- The new Centralized Agent Registry lets your team mix GitHub Copilot, Cl
• DevSpark: Constitution-Driven AI for Software Development -- DevSpark aligns AI coding agents with project architecture and governanc
• From Oracle CASE to Spec-Driven AI Development -- A 40-Year Journey Through Model-Driven Engineering
• DevSpark: The Evolution of AI-Assisted Software Development -- From requirements discipline to continuous governance — a complete frame
• DevSpark in Practice: A NuGet Package Case Study -- Four consecutive specifications on a production .NET package — what spec