🌱 Spec Kit Spark

Build high-quality software faster.

An Adaptive System Life Cycle Development (ASLCD) Toolkit - combining specification-driven development with constitution-powered quality assurance and right-sized workflows for tasks of any complexity. Part of the WebSpark suite.

Note: Spec Kit Spark is a community extension, part of the WebSpark demonstration suite. Looking for the original? Visit github.com/github/spec-kit

• 🎯 The ASLCD Vision
• 🤔 What is Spec-Driven Development?
• ⚡ Get Started
• 📽️ Video Overview
• 🤖 Supported AI Agents
• 🔧 Specify CLI Reference
• 📚 Core Philosophy
• 🌟 Development Phases
• 🗺️ Roadmap
• 🔧 Prerequisites
• 📖 Learn More
• 📋 Detailed Process
• 🔍 Troubleshooting
• 👥 Maintainers
• 💬 Support
• 🙏 Acknowledgements
• 📄 License

Adaptive System Life Cycle Development extends traditional spec-driven development to address real-world challenges that the original approach doesn't fully cover:

1. Universality over Opinion - Core prompts that adapt rather than single-use commands
2. Right-Sized Rigor - Match process overhead to task complexity
3. Continuous Compliance - Constitution validation throughout the lifecycle
4. Adaptive Evolution - Systems and documentation evolve together

┌─────────────────────────────────────────┐
│           Task Arrives                   │
└─────────────────┬───────────────────────┘
                  │
    ┌─────────────┼─────────────┐
    ▼             ▼             ▼
┌────────┐  ┌──────────┐  ┌──────────┐
│Bug Fix │  │ Minor    │  │ Major    │
│Hotfix  │  │ Feature  │  │ Feature  │
└───┬────┘  └────┬─────┘  └────┬─────┘
    │            │             │
    ▼            ▼             ▼
┌────────┐  ┌──────────┐  ┌──────────┐
│quickfix│  │ quickfix │  │ specify  │
│        │  │   OR     │  │ plan     │
│        │  │ specify  │  │ tasks    │
└────────┘  └──────────┘  └──────────┘

Full ASLCD Documentation | Roadmap

Spec-Driven Development flips the script on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the "real work" of coding began. Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them.

Choose your preferred installation method:

Install once and use everywhere:

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

Then use the tool directly:

# Greenfield: Create new project from scratch
specify init <PROJECT_NAME>

# Brownfield: Add to existing project
cd /path/to/your-existing-project
specify init --here --ai claude

# Check installed tools
specify check

Brownfield Tip: Use /speckit.discover-constitution after initialization to analyze existing code patterns and draft a constitution.

To upgrade to the latest version:

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

# Upgrade project files (auto-detects your AI assistant)
specify upgrade

# Or with options
specify upgrade --dry-run          # Preview changes first
specify upgrade --backup           # Backup constitution
specify upgrade --ai claude        # Override detected agent

See the Upgrade Guide for detailed instructions.

Migrating from old version? If your project uses the old .specify/ directory or root-level memory/, scripts/, templates/ directories, see the Migration Guide for automated migration to the new .documentation/ structure.

Run directly without installing:

# Greenfield: New project
uvx --from git+https://github.com/MarkHazleton/spec-kit.git specify init <PROJECT_NAME>

# Brownfield: Existing project
cd /path/to/your-existing-project
uvx --from git+https://github.com/MarkHazleton/spec-kit.git specify init --here

Benefits of persistent installation:

• Tool stays installed and available in PATH
• No need to create shell aliases
• Better tool management with uv tool list, uv tool upgrade, uv tool uninstall
• Cleaner shell configuration

Launch your AI assistant in the project directory. The /speckit.* commands are available in the assistant.

Use the /speckit.constitution command to create your project's governing principles and development guidelines that will guide all subsequent development.

/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements

Use the /speckit.specify command to describe what you want to build. Focus on the what and why, not the tech stack.

/speckit.specify Build an application that can help me organize my photos in separate photo albums. Albums are grouped by date and can be re-organized by dragging and dropping on the main page. Albums are never in other nested albums. Within each album, photos are previewed in a tile-like interface.

Use the /speckit.plan command to provide your tech stack and architecture choices.

/speckit.plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local SQLite database.

Use /speckit.tasks to create an actionable task list from your implementation plan.

/speckit.tasks

Use /speckit.implement to execute all tasks and build your feature according to the plan.

/speckit.implement

For detailed step-by-step instructions, see our comprehensive guide.

These commands leverage your project constitution but are independent of the Spec-Driven Development workflow. They don't require any spec, plan, or tasks—just a constitution. Use them on any codebase, anytime.

Use the /speckit.site-audit command to perform a comprehensive codebase audit against your project constitution and standards:

# Full audit (default - all checks)
/speckit.site-audit

# Constitution compliance only
/speckit.site-audit --scope=constitution

# Package/dependency analysis only
/speckit.site-audit --scope=packages

# Code quality metrics only
/speckit.site-audit --scope=quality

# Unused code/dependencies detection
/speckit.site-audit --scope=unused

# Duplicate code detection
/speckit.site-audit --scope=duplicate

Key Features:

• Constitution-Driven Analysis - Evaluates codebase against project principles
• Security Scanning - Detects hardcoded secrets, insecure patterns, missing validation
• Dependency Auditing - Identifies outdated, vulnerable, or unused packages
• Code Quality Metrics - Measures complexity, duplication, and maintainability
• Automated Reports - Saves detailed audit results to /.documentation/copilot/audit/YYYY-MM-DD_results.md
• Trend Tracking - Compares results against previous audits for improvement trends

Prerequisites:

• Project constitution at /.documentation/memory/constitution.md
• PowerShell 7+ (for script execution)
• pip-audit (optional, for Python security scanning)

For complete audit details, see the generated report in /.documentation/copilot/audit/.

Use the /speckit.critic command to perform adversarial risk analysis identifying technical flaws, implementation hazards, and failure modes:

# Run critic analysis after tasks are generated
/speckit.critic

# Focus on specific concerns
/speckit.critic Focus on scalability and security risks

Key Features:

• Pre-mortem Analysis - Imagines project failure in production and explains why
• Stack-Specific Risks - Detects framework-specific hazards (Python async, Node.js, Go, etc.)
• Showstopper Detection - Identifies issues that will cause production outages or security breaches
• Go/No-Go Recommendation - Provides clear verdict on whether to proceed with implementation
• Constitution Violations - Flags any deviations from project principles as showstoppers

Severity Levels:

• SHOWSTOPPER - Will cause production outage, data loss, or security breach (blocks implementation)
• CRITICAL - Will cause major user-facing issues or costly rework
• HIGH - Will cause technical debt or operational burden
• MEDIUM - Will slow development or cause minor issues

When to Use:

• After /speckit.tasks and before /speckit.implement
• When you want a skeptical review of your implementation plan
• To identify risks the team may have overlooked

Key Distinction from /speckit.analyze:

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

Prerequisites:

• Project constitution at /.documentation/memory/constitution.md
• Completed spec.md, plan.md, and tasks.md in the feature directory (this command is part of the spec workflow)

Use the /speckit.pr-review command to perform constitution-based code reviews on any GitHub Pull Request:

# Review current PR (auto-detect from branch)
/speckit.pr-review

# Review specific PR by number
/speckit.pr-review #123

# Re-review after changes
/speckit.pr-review #123

Key Features:

• Works for any PR - not limited to feature branches or spec-driven development
• Only requires constitution - no spec, plan, or tasks needed
• Branch-agnostic - review PRs targeting main, develop, or any branch
• Persistent reviews - saves reports to /.documentation/specs/pr-review/pr-{number}.md
• Tracks changes - monitors commit SHA and review timestamps
• Update handling - appends new reviews when PR changes, preserves history

Review Output:

• Constitution compliance evaluation (principle-by-principle)
• Security analysis and checklist
• Code quality assessment
• Testing coverage validation
• Categorized findings (Critical/High/Medium/Low)
• Actionable recommendations with file:line references
• Approval recommendation (Approve/Request Changes/Reject)

Prerequisites:

• Project constitution at /.documentation/memory/constitution.md
• GitHub CLI (gh) installed and authenticated
• GitHub repository with pull requests

For complete usage guide, see PR Review Documentation.

Use the /speckit.quickfix command for rapid bug fixes and small features without the overhead of full specification workflows:

# Bug fix with auto-classification
/speckit.quickfix fix null pointer exception in UserService.getProfile()

# Urgent hotfix
/speckit.quickfix urgent: payment processing timeout in checkout flow

# Mark as complete
/speckit.quickfix complete QF-2026-001

# List recent quickfixes
/speckit.quickfix list

Key Features:

• Auto-Classification - Detects bug-fix, hotfix, minor-feature, config-change, or docs-update
• Targeted Validation - Only checks constitution principles relevant to the task type
• Lightweight Records - Creates minimal documentation at /.documentation/quickfixes/QF-{YYYY}-{NNN}.md
• Scope Detection - Warns when work expands beyond classification limits
• Completion Tracking - Links to commits and PRs when marking complete

When to Use:

• Single file changes under 50 lines
• Bugs with clear root cause
• Production issues needing rapid response
• Configuration changes

When to Use Full Spec Instead:

• Multiple files with architectural impact
• New user-facing features
• Database schema or API contract changes

Use the /speckit.release command to archive development artifacts and prepare for the next development cycle:

# Auto-calculate version from completed work
/speckit.release

# Explicit version
/speckit.release 2.0.0

# Preview changes without writing
/speckit.release --dry-run

Key Features:

• Artifact Archival - Moves completed specs and quickfixes to /.documentation/releases/v{VERSION}/
• ADR Extraction - Distills key architectural decisions into permanent documentation
• CHANGELOG Generation - Auto-generates changelog entries from completed work
• Version Calculation - Determines MAJOR/MINOR/PATCH based on content
• Clean Slate - Resets specs directory for next development cycle

Output:

• /.documentation/releases/v{VERSION}/release-notes.md - Human-readable release summary
• /.documentation/releases/v{VERSION}/specs/ - Archived specifications
• /.documentation/releases/v{VERSION}/quickfixes/ - Archived quickfixes
• /.documentation/decisions/ADR-{NNN}.md - Architectural Decision Records
• Updated CHANGELOG.md

Use the /speckit.harvest command to clean stale docs, rewrite spec-linked code comments, and archive obsolete artifacts after preserving useful knowledge in living documentation:

# Full harvest
/speckit.harvest

# Documentation-only review and cleanup plan
/speckit.harvest --scope=docs

# Rewrite stale spec/task references in code comments only
/speckit.harvest --scope=comments

# Dry-run inventory and report only
/speckit.harvest --scope=scan

Key Features:

• Knowledge Preservation First - Updates living docs before archival
• Documentation Scoring - Assigns taxonomy, usefulness score, and disposition to scanned artifacts
• Comment Hygiene - Rewrites spec-linked comments into self-contained code documentation
• Safe Archival - Moves stale content to /.archive/ with preserved structure
• Approval Gate - Presents a harvest plan and requires explicit confirmation before changes

Output:

• Updated CHANGELOG.md or living docs where knowledge is harvested
• Harvest report at /.documentation/copilot/harvest-YYYY-MM-DD.md
• Archived stale docs and completed artifacts under /.archive/

When to Use:

• After several specs or quickfixes have accumulated supporting docs
• When AI-generated reviews, drafts, or session notes are cluttering the repo
• Before a release or documentation cleanup pass

Use the /speckit.evolve-constitution command to analyze PR reviews and propose constitution amendments:

# Full analysis of PR reviews and audits
/speckit.evolve-constitution

# Analyze specific PR findings
/speckit.evolve-constitution --from-pr #123

# Manual suggestion
/speckit.evolve-constitution suggest "Add principle for API versioning standards"

# Approve a proposal
/speckit.evolve-constitution approve CAP-2026-001

# Reject with reason
/speckit.evolve-constitution reject CAP-2026-002 "Too restrictive for current team"

Key Features:

• Pattern Analysis - Scans PR reviews for recurring violation patterns
• Gap Detection - Identifies issues not mapped to existing principles
• Proposal Generation - Creates CAP (Constitution Amendment Proposal) documents
• History Tracking - Maintains amendment log at /.documentation/memory/constitution-history.md
• Approval Workflow - Supports approve/reject actions with rationale

Amendment Types:

• ADD - New principle for uncovered area
• MODIFY - Update unclear or incomplete principle
• DEPRECATE - Remove or soften outdated principle
• CLARIFY - Add examples without changing rules

Prerequisites:

• Project constitution at /.documentation/memory/constitution.md
• PR review history (recommended for analysis mode)

Want to see Spec Kit in action? Watch our video overview!

The specify command supports the following options:

specify version reports a single local product version (pyproject.toml/installed package metadata). It does not compare against latest GitHub release to avoid confusing mismatches.

# Basic project initialization
specify init my-project

# Initialize with specific AI assistant
specify init my-project --ai claude

# Initialize with Cursor support
specify init my-project --ai cursor-agent

# Initialize with Qoder support
specify init my-project --ai qodercli

# Initialize with Windsurf support
specify init my-project --ai windsurf

# Initialize with Amp support
specify init my-project --ai amp

# Initialize with SHAI support
specify init my-project --ai shai

# Initialize with IBM Bob support
specify init my-project --ai bob

# Initialize with PowerShell scripts (Windows/cross-platform)
specify init my-project --ai copilot --script ps

# Initialize in current directory
specify init . --ai copilot
# or use the --here flag
specify init --here --ai copilot

# Force merge into current (non-empty) directory without confirmation
specify init . --force --ai copilot
# or
specify init --here --force --ai copilot

# Skip git initialization
specify init my-project --ai gemini --no-git

# Enable debug output for troubleshooting
specify init my-project --ai claude --debug

# Use GitHub token for API requests (helpful for corporate environments)
specify init my-project --ai claude --github-token ghp_your_token_here

# Check system requirements
specify check

After running specify init, your AI coding agent will have access to these slash commands for structured development:

Essential commands for the Spec-Driven Development workflow:

These commands only require a constitution and work independently of the spec workflow:

Additional commands for the spec-driven development workflow:

Note: /speckit.pr-review and /speckit.site-audit can be used at any time on any codebase—they only require a constitution and work independently of any spec workflow. /speckit.critic requires completed spec.md, plan.md, and tasks.md files.

Spec-Driven Development is a structured process that emphasizes:

• Intent-driven development where specifications define the "what" before the "how"
• Rich specification creation using guardrails and organizational principles
• Multi-step refinement rather than one-shot code generation from prompts
• Heavy reliance on advanced AI model capabilities for specification interpretation

Our research and experimentation focus on:

• Create applications using diverse technology stacks
• Validate the hypothesis that Spec-Driven Development is a process not tied to specific technologies, programming languages, or frameworks

• Demonstrate mission-critical application development
• Incorporate organizational constraints (cloud providers, tech stacks, engineering practices)
• Support enterprise design systems and compliance requirements

• Build applications for different user cohorts and preferences
• Support various development approaches (from vibe-coding to AI-native development)

• Validate the concept of parallel implementation exploration
• Provide robust iterative feature development workflows
• Extend processes to handle upgrades and modernization tasks

Spec Kit Spark is actively developed with a clear vision for the future:

• ✅ Full Spec-Driven Development workflow
• ✅ Constitution-based PR review (/speckit.pr-review)
• ✅ Comprehensive site auditing (/speckit.site-audit)
• ✅ Adversarial risk analysis (/speckit.critic)
• ✅ Lightweight quickfix workflow (/speckit.quickfix)
• ✅ Release documentation management (/speckit.release)
• ✅ Documentation harvest and cleanup workflow (/speckit.harvest)
• ✅ Constitution evolution (/speckit.evolve-constitution)
• ✅ Repository story generation (/speckit.repo-story)
• ✅ 17+ AI agent integrations

• 🔄 Enhanced technical debt tracking with metrics storage
• 🔄 Trend visualization for compliance scores
• 🔄 Improved quickfix-to-spec escalation workflow
• 🔄 Constitution template library

• 📋 CI/CD pipeline integration (GitHub Actions, Azure DevOps)
• 📋 Business value alignment documentation
• 📋 Cross-project governance for organizations
• 📋 Interactive constitution builder

• 🎯 Spec-to-test generation pipeline
• 🎯 Multi-repository constitution inheritance
• 🎯 AI model performance benchmarking
• 🎯 Enterprise compliance frameworks

Full Roadmap Details

• Linux/macOS/Windows
• Supported AI coding agent.
• uv for package management
• Python 3.11+
• Git

If you encounter issues with an agent, please open an issue so we can refine the integration.

• Complete Spec-Driven Development Methodology - Deep dive into the full process
• Detailed Walkthrough - Step-by-step implementation guide

specify init <project_name>

specify init .
# or use the --here flag
specify init --here
# Skip confirmation when the directory already has files
specify init . --force
# or
specify init --here --force

specify init <project_name> --ai claude
specify init <project_name> --ai gemini
specify init <project_name> --ai copilot

# Or in current directory:
specify init . --ai claude
specify init . --ai codex

# or use --here flag
specify init --here --ai claude
specify init --here --ai codex

# Force merge into a non-empty current directory
specify init . --force --ai claude

# or
specify init --here --force --ai claude

specify init <project_name> --ai claude --ignore-agent-tools

/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements. Include governance for how these principles should guide technical decisions and implementation choices.

Develop Taskify, a team productivity platform. It should allow users to create projects, add team members,
assign tasks, comment and move tasks between boards in Kanban style. In this initial phase for this feature,
let's call it "Create Taskify," let's have multiple users but the users will be declared ahead of time, predefined.
I want five users in two different categories, one product manager and four engineers. Let's create three
different sample projects. Let's have the standard Kanban columns for the status of each task, such as "To Do,"
"In Progress," "In Review," and "Done." There will be no login for this application as this is just the very
first testing thing to ensure that our basic features are set up. For each task in the UI for a task card,
you should be able to change the current status of the task between the different columns in the Kanban work board.
You should be able to leave an unlimited number of comments for a particular card. You should be able to, from that task
card, assign one of the valid users. When you first launch Taskify, it's going to give you a list of the five users to pick
from. There will be no password required. When you click on a user, you go into the main view, which displays the list of
projects. When you click on a project, you open the Kanban board for that project. You're going to see the columns.
You'll be able to drag and drop cards back and forth between different columns. You will see any cards that are
assigned to you, the currently logged in user, in a different color from all the other ones, so you can quickly
see yours. You can edit any comments that you make, but you can't edit comments that other people made. You can
delete any comments that you made, but you can't delete comments anybody else made.

└── .documentation
    ├── memory
    │   └── constitution.md
    ├── scripts
    │   ├── check-prerequisites.sh
    │   ├── common.sh
    │   ├── create-new-feature.sh
    │   ├── setup-plan.sh
    │   └── update-claude-md.sh
    ├── specs
    │   └── 001-create-taskify
    │       └── spec.md
    └── templates
        ├── plan-template.md
        ├── spec-template.md
        └── tasks-template.md

For each sample project or project that you create there should be a variable number of tasks between 5 and 15
tasks for each one randomly distributed into different states of completion. Make sure that there's at least
one task in each stage of completion.

Read the review and acceptance checklist, and check off each item in the checklist if the feature spec meets the criteria. Leave it empty if it does not.

We are going to generate this using .NET Aspire, using Postgres as the database. The frontend should use
Blazor server with drag-and-drop task boards, real-time updates. There should be a REST API created with a projects API,
tasks API, and a notifications API.

.
├── CLAUDE.md
└── .documentation
    ├── memory
    │   └── constitution.md
    ├── scripts
    │   ├── check-prerequisites.sh
    │   ├── common.sh
    │   ├── create-new-feature.sh
    │   ├── setup-plan.sh
    │   └── update-claude-md.sh
    ├── specs
    │   └── 001-create-taskify
    │       ├── contracts
    │       │   ├── api-spec.json
    │       │   └── signalr-spec.md
    │       ├── data-model.md
    │       ├── plan.md
    │       ├── quickstart.md
    │       ├── research.md
    │       └── spec.md
    └── templates
        ├── CLAUDE-template.md
        ├── plan-template.md
        ├── spec-template.md
        └── tasks-template.md

I want you to go through the implementation plan and implementation details, looking for areas that could
benefit from additional research as .NET Aspire is a rapidly changing library. For those areas that you identify that
require further research, I want you to update the research document with additional details about the specific
versions that we are going to be using in this Taskify application and spawn parallel research tasks to clarify
any details using research from the web.

I think we need to break this down into a series of steps. First, identify a list of tasks
that you would need to do during implementation that you're not sure of or would benefit
from further research. Write down a list of those tasks. And then for each one of these tasks,
I want you to spin up a separate research task so that the net results is we are researching
all of those very specific tasks in parallel. What I saw you doing was it looks like you were
researching .NET Aspire in general and I don't think that's gonna do much for us in this case.
That's way too untargeted research. The research needs to help you solve a specific targeted question.

Now I want you to go and audit the implementation plan and the implementation detail files.
Read through it with an eye on determining whether or not there is a sequence of tasks that you need
to be doing that are obvious from reading this. Because I don't know if there's enough here. For example,
when I look at the core implementation, it would be useful to reference the appropriate places in the implementation
details where it can find the information as it walks through each step in the core implementation or in the refinement.

/speckit.tasks

/speckit.implement

/speckit.pr-review

/speckit.pr-review #123

# Full audit covering all categories
/speckit.site-audit

# Focus on specific areas
/speckit.site-audit --scope=constitution  # Constitution compliance
/speckit.site-audit --scope=packages      # Dependency analysis
/speckit.site-audit --scope=quality       # Code quality metrics

# Run after /speckit.tasks, before /speckit.implement
/speckit.critic

# Focus on specific concerns
/speckit.critic Focus on scalability and security

If you're having issues with Git authentication on Linux, you can install Git Credential Manager:

#!/usr/bin/env bash
set -e
echo "Downloading Git Credential Manager v2.6.1..."
wget https://github.com/git-ecosystem/git-credential-manager/releases/download/v2.6.1/gcm-linux_amd64.2.6.1.deb
echo "Installing Git Credential Manager..."
sudo dpkg -i gcm-linux_amd64.2.6.1.deb
echo "Configuring Git to use GCM..."
git config --global credential.helper manager
echo "Cleaning up..."
rm gcm-linux_amd64.2.6.1.deb

• Den Delimarsky (@localden)
• John Lam (@jflam)

For support, please open a GitHub issue. We welcome bug reports, feature requests, and questions about using Spec-Driven Development.

This project is heavily influenced by and based on the work and research of John Lam.

Spec Kit Spark is a maintained fork of github.com/github/spec-kit with significant enhancements for Adaptive System Life Cycle Development. We actively track and selectively incorporate valuable improvements from upstream.

We maintain this fork using documented decision criteria to:

• Auto-apply bug fixes and security patches
• Adapt template and documentation improvements
• Evaluate major features for integration
• Ignore changes incompatible with our structure

See FORK_DIVERGENCE.md for:

• Complete divergence history
• Decision criteria framework
• Absorbed changes log
• Integration opportunities

For Contributors: Run the sync script to review and apply upstream changes.

Interactive Mode (Recommended): Review each commit with detailed implications:

# PowerShell
.\scripts\powershell\sync-upstream.ps1 -Mode interactive

# Bash
./.documentation/scripts/bash/sync-upstream.sh --mode interactive

This mode:

• Shows full commit details and file changes
• Explains implications for Spark architecture
• Detects potential conflicts with Spark-specific files
• Prompts for action: Apply, Skip, Defer, or View diff
• Creates checkpoint branches for safe rollback

Quick Review: See categorized commits:

# PowerShell
.\scripts\powershell\sync-upstream.ps1 -Mode review

# Bash
./.documentation/scripts/bash/sync-upstream.sh --mode review

Automated Cherry-Picks: Apply safe bug fixes automatically:

# PowerShell
.\scripts\powershell\sync-upstream.ps1 -Mode auto

# Bash
./.documentation/scripts/bash/sync-upstream.sh --mode auto

Generate Report: Create detailed analysis for team review:

# PowerShell
.\scripts\powershell\sync-upstream.ps1 --mode report > sync-report.md

# Bash
./.documentation/scripts/bash/sync-upstream.sh --mode report > sync-report.md

The sync script automatically:

• Categories upstream commits by our decision criteria
• Identifies safe auto-applicable changes
• Generates reports for manual review
• Updates FORK_DIVERGENCE.md with applied changes
• Creates checkpoint branches for safe rollback

We believe in contributing valuable innovations back to the community. If you've developed a feature that could benefit the upstream project:

1. Create an upstream-compatible branch (adjust paths: .documentation/ → docs/)
2. Remove Spark-specific dependencies
3. Submit PR to github.com/github/spec-kit
4. Document in FORK_DIVERGENCE.md under "Contributed to Upstream"

This project is licensed under the terms of the MIT open source license. Please refer to the LICENSE file for the full terms.