Why I Forked GitHub Spec Kit

Part Three: Building Spec Kit Spark

Series: Part 1 | Part 2 | Part 3 | Part 4

The previous articles established two capabilities: requirements-driven development (Part 1) and constitution-based PR reviews (Part 2). Both assume you're building something new.

But most teams aren't starting fresh. They have existing codebases with implicit patterns, undocumented conventions, and years of accumulated decisions. This article introduces Spec Kit Spark—a fork that adds the brownfield capabilities I previewed in Part 1: discovering constitutions from existing code, auditing codebase-wide compliance, and analyzing risk before implementation.

The Gaps in Original Spec Kit

GitHub's Spec Kit introduced Spec-Driven Development with a powerful concept: the project constitution. But the original toolkit uses the constitution primarily during the spec workflow:

1. /speckit.specify → Define requirements
2. /speckit.plan → Create implementation plan
3. /speckit.tasks → Break down into actionable tasks
4. /speckit.implement → Execute the plan

Three opportunities emerged:

What Spec Kit Spark Adds

I created Spec Kit Spark as a community extension that keeps the original SDD workflow intact while adding four constitution-powered capabilities:

/speckit.pr-review — Constitution-Based Pull Request Reviews

This capability evolved from the custom extension I documented in Part 2, now integrated as a core Spec Kit Spark feature.

The problem: Traditional PR reviews depend on individual reviewer knowledge. Different reviewers catch different issues based on their experience and focus.

The solution: Use the constitution as an objective standard. Every PR gets evaluated against the same principles.

Key design decisions:

• Works for any PR in any branch—not limited to feature branches
• Only requires a constitution—no spec, plan, or tasks needed
• Saves review history to /specs/pr-review/pr-{number}.md
• Tracks commit SHAs so you can re-review after changes

This means constitution-powered reviews work for hotfixes to main, documentation updates to develop, and any contribution, regardless of whether it followed the SDD workflow.

/speckit.site-audit — Codebase-Wide Compliance Auditing

The problem: Constitution principles mean nothing if they're not enforced consistently across the entire codebase.

The solution: A comprehensive audit command that evaluates your entire codebase against constitution principles.

What it checks:

• Constitution compliance (principle-by-principle)
• Security vulnerabilities and patterns
• Dependency health (outdated, unused, vulnerable packages)
• Code quality metrics (complexity, duplication)
• Unused code detection

Key design decisions:

• Supports scoped audits (--scope=constitution, --scope=packages, etc.)
• Produces trend-trackable reports in /docs/copilot/audit/
• Compares against previous audits to show improvement or regression

/speckit.critic — Adversarial Risk Analysis

The problem: Plans and task lists can look perfect on paper but fail spectacularly in production. Teams with limited experience in a new tech stack often miss edge cases.

The solution: A skeptical reviewer that identifies showstoppers before implementation begins.

How it differs from /speckit.analyze:

• /speckit.analyze = Consistency checking (are artifacts aligned?)
• /speckit.critic = Adversarial analysis (what will fail in production?)

Severity levels include showstopper (production outage, data loss, security breach), critical (major user-facing issues), high (technical debt), and medium (development slowdown).

Key design decisions:

• Constitution violations are automatically showstopper severity
• Provides a clear Go/No-Go recommendation
• Runs after /speckit.tasks but before /speckit.implement

/speckit.discover-constitution — Brownfield Constitution Discovery

The problem: Existing codebases have implicit patterns and conventions baked into the code. Teams adopting SDD need a way to extract these patterns into a constitution.

The solution: Analyze the codebase, discover patterns, and guide teams through interactive questions to formalize a constitution.

How it works:

1. Scans for patterns (testing frameworks, security practices, architecture conventions)
2. Reports high-confidence patterns (>80% consistent) vs. inconsistent areas
3. Asks 8-10 targeted questions to validate findings
4. Generates a draft constitution at /memory/constitution-draft.md

Key design decisions:

• Discovery-first: analyze code before asking questions
• Draft output: produces a starting point for team review, not a final document
• Respects existing work: treats discovered patterns as valuable

Additional Improvements

Beyond the four major features, Spec Kit Spark includes:

PowerShell Parity

Every bash script has a corresponding PowerShell script. Windows developers get first-class support.

Repository Health Analysis

Integrated Git Spark reports provide insights into contributor activity and bus factor, file hotspots (high churn, many authors), governance scores (commit message quality, traceability), and risk analysis based on code churn patterns.

Enhanced Documentation

The toolkit includes constitutional governance guides with examples, PR review usage documentation, site audit usage guides, critic command documentation, and local development instructions.

The Philosophy: Continuous Constitution Value

The core philosophy of Spec Kit Spark is straightforward:

A project constitution should provide value continuously, not just during feature development.

If you write a constitution that says "All public APIs must have input validation," that principle should guide new feature development (original Spec Kit), catch violations in pull requests (/speckit.pr-review), identify existing violations in the codebase (/speckit.site-audit), and flag missing validation as a risk before implementation (/speckit.critic).

This creates a closed loop where constitution principles are enforced at every stage of the development lifecycle.

Attribution

Full credit goes to the GitHub team—particularly Den Delimarsky and John Lam—for creating Spec-Driven Development and the original Spec Kit.

Spec Kit Spark is an extension, not a replacement. The original SDD workflow remains unchanged. All additions maintain backward compatibility.

Try It Yourself

Install Spec Kit Spark:

uv tool install specify-cli --from git+https://github.com/MarkHazleton/spec-kit.git

Initialize in your existing project (brownfield):

cd /path/to/your-project
specify init --here --ai copilot

# Discover patterns and draft a constitution
# (use /speckit.discover-constitution in your AI agent)

Or start fresh (greenfield):

specify init my-project --ai claude

Then try the constitution-powered commands:

• /speckit.discover-constitution — Draft a constitution from existing code
• /speckit.pr-review #123 — Review a PR against your constitution
• /speckit.site-audit — Audit your entire codebase
• /speckit.critic — Identify risks before implementation

What This Means for Development Teams

The extension addresses a common challenge: how do you maintain consistency in a codebase as it grows and evolves? Traditional approaches rely on documentation that becomes stale, tribal knowledge that lives in senior developers' heads, or inconsistent code reviews that vary by reviewer.

Constitution-driven development offers an alternative. By codifying principles once and enforcing them continuously, teams can maintain consistency without constant vigilance. The constitution becomes a shared reference point that scales beyond individual knowledge.

Worth examining whether this approach fits your team's workflow. For projects with high governance requirements, regulatory compliance needs, or distributed teams where consistency is challenging, the investment in crafting a constitution may pay dividends throughout the development lifecycle.

Summary

The goal: maximize the return on investment for crafting a thoughtful project constitution—across the entire development lifecycle.

Continue: Part 4: The Adaptive SDLC Toolkit →