DevSpark series
AI-assisted development needs a memory.
DevSpark is my constitution-driven toolkit for keeping AI coding agents aligned with a project's architecture, quality standards, and decision history across the full software lifecycle.
DevSpark is how I build the software: one part of how I solve business problems, alongside Project Mechanics for managing the work.
A project that remembers
60-second journey · silent, with on-screen text
Read the journey
New session. Same explanations.
Your project's context should survive the conversation. AI sessions lose the context that makes code fit a project. DevSpark began with the practical challenge of governing change in existing software.
Give your project a memory.
Principles. Current knowledge. Reasons behind decisions. A versioned constitution, current knowledge, and decision rationale give agents a shared foundation. Layered prompts and reusable skills bring that context into daily work.
Start with a real need.
Carry intent from the first question to verified change. Requirements, planning, implementation, quality gates, and constitution-based pull request reviews connect a real need to verified delivery.
Different agents. One project.
Work together across teams, tools, and applications. Agent-independent workflows, personalization, CLI entry points, and monorepo support help teams share governance while choosing their tools.
Real work teaches the framework.
Case studies, visible workflows, and deliberate guardrails. Explore the NuGet case study, blogging workflow, observability, bounded autonomy, contributions, and lessons from dogfooding. The series also examines adoption friction and the cost of methodology.
The work ends. Knowledge stays.
Verify the change in code and knowledge before clearing the spec. The v4 model treats specifications as temporary change instructions. Verified code, current knowledge, and current decisions remain after the work is complete.
Find your starting point.
Understand the idea. Try the workflow. Explore the evidence. Start with why DevSpark exists, follow the getting-started guide, or explore a practical case study. The complete collection is below.
Why it exists
AI-assisted development changed the speed of writing code, not the cost of getting it wrong. An agent can produce a feature in minutes and quietly drift from the architecture, the tests and the decisions that came before it. The discipline matters more now, not less.
DevSpark keeps intent, code, tests and knowledge in sync: a written constitution and specs that every plan, review and audit checks against, whether the change is a planned feature or a late hotfix.
It's the engineering half of how I work. Project Mechanics is how I manage the work: people, decisions and accountability. DevSpark is how I build the software. The Sparks are the proof: working systems built this way, including API Test Spark and WebSpark.HttpClientUtility.
A working constitution
Project principles become versioned context that agents can use during specification, planning, implementation, review, and release.
Governance with reach
The framework carries architectural intent beyond greenfield setup into brownfield discovery, pull requests, audits, and production change.
Built in public
These articles document the decisions, experiments, trade-offs, and lessons behind the evolving open-source toolkit.
The archive
All DevSpark articles
DevSpark Dogfooding: Escaping the Scope-Creep Spiral
I used DevSpark on real development and watched a system built to control complexity start to generate its own. This essay follows the scope-creep spiral, the rules that broke it, the ideas I wrote down instead of building, and a second project that tested whether the rules held.
QA Was Always My Last Battle Front
I used to throw releases over the wall and let QA reconstruct what I meant. This essay follows how DevSpark connected acceptance criteria at the start of a change to independent validation at the end, without adding a single command, agent, or gate.
I'm Not a Game Developer. I Built a Game Anyway.
After one ad too many in a mobile puzzle game, I built my own in a week with Godot and DevSpark, despite never having written a game. The most useful moment was when the code passed every test and the puzzles still weren't fun. I'm asking readers to play it, read the code, and tell me whether shipping makes me a game developer.
DevSpark: Change Must Start With a Real Need
DevSpark grew from a career lesson about building what people actually need rather than what happens to be exciting. This essay connects that discipline to the framework's lifecycle and explains why an agent needs the same product process made explicit.
DevSpark v4: The Spec Was Never the Record
The last DevSpark article left assimilation unsolved: how does a completed spec's knowledge merge back into a project without the destination becoming the same kind of pile the spec used to be? Working through v4, the fix turned out to be a reframe, not a new mechanism — the spec was never a record to begin with, and the prompts that check it were already asking the wrong question.
DevSpark's Next Evolution: Rethinking Where Knowledge Lives
DevSpark already solved what happens to a completed spec — release archives it, harvest extracts what's worth keeping. The problem I'm working on now is harder: how do you give a project durable knowledge that works at build time and at runtime, stays accurate, costs fewer tokens, and stays portable and transparent? That's the design problem I'm working through, and I've started turning the constraints into an actual requirements document.
The Methodology Tax: Why Grassroots Innovation Gets Rejected
Enterprises often reject the AI development tools best equipped to solve their governance problems, not because the tools fail technically but because of how they arrive. Using DevSpark as a case study, I trace why this happens and what it would take to fix it.
DevSpark and Agent Skills: Beyond Portable AI Capabilities
The Agent Skills specification is a welcome step toward portable, reusable AI capabilities. But enterprise software delivery needs more than portable skills — it needs orchestration, governance, and lifecycle continuity. This article traces where DevSpark sits in that emerging landscape and why the distinction matters.
DevSpark Blogging Workflow: How I Built Better Articles
Writing the Cloudflare and IIS article made me realize I needed the same kind of governed workflow for content that I expect from code. This is how I layered write-article, critique, editorial, and SEO prompts on top of DevSpark so a rough idea could become a stronger, more publishable article through deliberate iteration.
DevSpark: Constitution-Driven AI for Software Development
DevSpark aligns AI coding agents with project architecture and governance through a constitution-driven toolkit for the full software development lifecycle.
The DevSpark Tiered Prompt Model: Resolving Context at Scale
How DevSpark's cascading prompt hierarchy — framework defaults, project overrides, user personalization — injects the right context without repetition.
Workflows as First-Class Artifacts: Defining Operations for AI
How DevSpark's Harness Runtime turns ad-hoc AI interactions into version-controlled, validated, reproducible workflow specs — and what changed.
Closing the Loop: Automating Feedback with Suggest-Improvement
How the suggest-improvement workflow alias captures developer friction in context and closes the loop between daily use and framework evolution.
Observability in AI Workflows: Exposing the Black Box
How DevSpark run artifacts, JSONL event logs, and telemetry make AI workflow debugging tractable — turning non-deterministic failures into diagnosable events.
Autonomy Guardrails: Bounding Agent Action Safely
How DevSpark's act/plan execution modes and per-step tool scoping let me expand agent autonomy incrementally — starting with review, earning toward execution.
Designing the DevSpark CLI UX: Commands vs Prompts
How DevSpark's CLI evolved from slash commands to a full subcommand tree — and what those design choices reveal about structure vs. flexibility in AI tooling.
A Governed Contribution Model for DevSpark Prompts
How DevSpark's tiered ownership model lets improvements flow from individual discovery to shared framework — without bottlenecks, without chaos.
The Alias Layer: Masking Complexity in Agent Invocations
How DevSpark's shim architecture and workflow aliases reduce cognitive overhead — from agent-specific boilerplate to a single semantic command.
Prompt Metadata: Enforcing the DevSpark Constitution
How frontmatter-driven contracts and spec lifecycle enforcement keep the DevSpark constitution non-negotiable — from initial specification through PR review.
Dogfooding DevSpark: Building the Plane While Flying It
A first-person look at what it's actually like to dogfood DevSpark — using a prompt tool to refine a prompt tool — anchored in an old EDS Super Bowl commercial about building a plane mid-flight.
Bring Your Own AI: DevSpark Unlocks Multi-Agent Collaboration
DevSpark's latest release rebuilds the framework's core to be completely AI-agnostic. The new Centralized Agent Registry — a single agents-registry.json file — strips every hardcoded 'if Copilot do this, if Claude do that' decision out of the framework scripts and replaces it with dynamic configuration. Adding support for tomorrow's newest AI tool is now a one-line registry entry. More practically: the same Markdown spec that one developer refines with Copilot in VS Code can be picked up and implemented by a colleague using Claude Code in the terminal, then reviewed by a tech lead in Cursor — without the framework skipping a beat.
DevSpark Monorepo Support: Governing Multiple Apps in One Repository
Monorepos give teams atomic commits and unified history, but they introduce governance problems: mixed review rules, scope ambiguity, and AI agents that can't tell one app from another. DevSpark's multi-app support solves this with an explicit application registry, layered governance that can't weaken repo-wide rules, and dependency-aware scope analysis — all backward-compatible and opt-in.
Why I Built DevSpark
An exploration of why I built DevSpark — driven by the personal struggle of keeping existing codebases aligned with architectural standards long after the initial specification phase.
Getting Started with DevSpark: Requirements Quality Matters
Bad requirements produce bad code—this was true with humans and is exponentially worse with AI. Vague prompts force AI to guess at thousands of unstated constraints, generating code that looks right but fails under real-world conditions. DevSpark addresses this through structured phases: Constitution guardrails, mandatory clarification loops, discrete pipeline gates, and human verification. Requirements quality matters more than coding speed.
DevSpark: Constitution-Based Pull Request Reviews
Every mature codebase accumulates institutional knowledge that lives in scattered places. This article explores how to use DevSpark to perform AI-powered pull request reviews that validate changes against a project constitution—a living document capturing architectural principles, anti-patterns, and non-negotiable standards.
DevSpark: The Evolution of AI-Assisted Software Development
DevSpark evolved from a greenfield planning tool into a governance framework for AI-assisted development. This overview tracks the progression from requirements-first principles through constitution-based PR reviews, brownfield discovery, adaptive lifecycle management, and automated upstream sync.
DevSpark: Months Later, Lessons Learned
After months of using DevSpark across real projects, the theory met reality. This article is a practitioner's check-up — what survived contact with production, what surprised me, and the lessons I didn't expect about AI confidence, adversarial review, and the economics of doing it right.
DevSpark in Practice: A NuGet Package Case Study
The DevSpark series describes the methodology. This article shows it. Four consecutive feature specifications on WebSpark.HttpClientUtility — a production .NET NuGet package — covering a documentation site, compiler warning cleanup, a package split, and a new batch execution feature. Each spec illuminated something different about what spec-driven development costs, what it saves, and what it preserves.
DevSpark: From Fork to Framework — What the Commits Reveal
Writing about building something and actually building it are two different activities. This article uses the DevSpark commit history as primary source material — tracking what got built, when, and why from the first fork through the many iterations that produced DevSpark v0.1.0. The result is a practitioner's record of how an idea becomes a tool through persistence, iteration, and a willingness to throw things out and start again.
DevSpark v0.1.0: Agent-Agnostic, Multi-User, and Built for Teams
DevSpark v0.1.0 introduces two reinforcing design pillars — agent-agnostic architecture and multi-user personalization — that solve a tension every team with AI coding agents faces: how to share standards without forcing uniformity. Canonical prompts live in one place, thin shims adapt them per platform, and /devspark.personalize lets each developer tailor commands without affecting anyone else. The result is a model where teams commit personalized prompts to git, making individual workflow choices visible, reviewable, and shareable.
Fork Management: Automating Upstream Integration
When you fork an open-source project to add significant enhancements, staying synchronized with upstream improvements while preserving your innovations is a classic dilemma. DevSpark solves this with automated upstream synchronization using intelligent scripts, decision criteria frameworks, and AI-assisted integration planning.
From Oracle CASE to Spec-Driven AI Development
From Oracle CASE repositories in the 90s to AI-powered DevSpark today, this is a personal journey through four decades of model-driven development. Learn how the industry cycled from structure to speed and back to synthesis, and what Monday-morning practices you can adopt now.
Taking DevSpark to the Next Level
From EDS mainframes to AI coding agents—introducing the Adaptive System Lifecycle Development Toolkit that bridges rigorous enterprise methodology with modern AI-assisted development. Learn how to balance structure with innovation, maintain quality without rigidity, and make your project constitution valuable throughout the entire development lifecycle.