Strict test coverage ratio

.ai/README.md

@@ -0,0 +1,113 @@
+# AI Agent Documentation
+
+Documentation and context for AI agents working with Spec Kit.
+
+## Overview
+
+This directory contains information specifically for AI coding agents (Claude Code, GitHub Copilot, Gemini CLI, etc.) to help them understand and work effectively with the Spec-Driven Development workflow.
+
+## Contents
+
+- **[Library Gotchas](./library_gotchas.md)** - Common pitfalls and issues with various libraries and frameworks
+
+## For AI Agents
+
+When working with Spec Kit projects, AI agents should:
+
+1. **Understand the three-phase workflow**
+   - Phase 1: Specification (requirements and constraints)
+   - Phase 2: Planning (architecture and technical decisions)
+   - Phase 3: Implementation (coding and validation)
+
+2. **Respect the separation of concerns**
+   - Specifications define WHAT and WHY
+   - Plans define HOW
+   - Code implements according to plan
+
+3. **Follow the constitution**
+   - Projects may have `memory/constitution.md` with project-specific principles
+   - Respect established patterns and decisions
+   - Document rationale for architectural choices
+
+4. **Work atomically**
+   - For large features (>1000 LOC), decompose into capabilities
+   - Each capability should be 400-1000 LOC
+   - Create focused PRs for faster reviews
+
+5. **Validate against specifications**
+   - Implementation must satisfy acceptance criteria
+   - Plans must address all requirements
+   - Tests must prove correctness
+
+## Prompt Engineering Tips
+
+When working with Spec Kit:
+
+### For Specifications
+```
+Create a specification for [feature]. Include:
+- What the feature must do (functional requirements)
+- Performance and quality targets (non-functional requirements)
+- What exists that we must integrate with (technical constraints)
+- Testable acceptance criteria
+```
+
+### For Planning
+```
+Create an implementation plan for [feature] using [tech stack].
+Include:
+- Architecture decisions with rationale
+- Technology choices justified by requirements
+- Data models and schemas
+- API designs
+- Testing strategy
+```
+
+### For Implementation
+```
+Implement according to specs/[feature-id]/plan.md.
+Ensure:
+- All acceptance criteria are met
+- Tests validate requirements
+- Code follows established patterns
+- Clear commit messages reference spec
+```
+
+## Context Loading
+
+AI agents can load relevant context from:
+
+1. **Product Vision** (`docs/product-vision.md`) - Strategic direction
+2. **System Architecture** (`docs/system-architecture.md`) - Current architecture
+3. **Constitution** (`memory/constitution.md`) - Project principles
+4. **Specification** (`specs/[feature-id]/spec.md`) - Feature requirements
+5. **Implementation Plan** (`specs/[feature-id]/plan.md`) - Technical approach
+
+## Common Patterns
+
+### Feature Addition
+1. Read existing product vision and architecture
+2. Create specification with `/specify`
+3. Create implementation plan with `/plan`
+4. Generate tasks with `/tasks`
+5. Implement according to plan
+
+### Brownfield Changes
+1. Review existing architecture
+2. Understand constraints from current system
+3. Plan changes that respect existing patterns
+4. Implement with minimal disruption
+
+### Large Features
+1. Create full specification
+2. Use `/decompose` to break into capabilities
+3. For each capability:
+   - Create focused plan
+   - Implement atomically
+   - Submit PR and merge
+   - Move to next capability
+
+## Related
+
+- [User Documentation](../docs/) - For developers using Spec Kit
+- [Contributing](../contributing/) - For Spec Kit contributors

.ai/ai_docs/README.md

@@ -0,0 +1,47 @@
+# AI Documentation Repository
+
+This directory contains critical documentation and patterns that are frequently referenced during AI-assisted development. These files provide essential context that helps AI agents understand codebase-specific patterns, library quirks, and implementation guidelines.
+
+## Purpose
+
+When creating specifications and plans, AI agents need access to:
+- Library-specific implementation patterns
+- Codebase conventions and gotchas
+- Custom utility documentation
+- Framework-specific best practices
+
+Files in this directory should be referenced in specifications using the `docfile` YAML format:
+
+```yaml
+- docfile: ai_docs/framework_patterns.md
+  why: Custom authentication patterns for this project
+  section: OAuth Implementation
+```
+
+## Organization
+
+- **framework_patterns.md**: Patterns specific to the main framework/language
+- **library_gotchas.md**: Known issues and workarounds for dependencies
+- **custom_utils.md**: Documentation for project-specific utilities
+- **integration_patterns.md**: Common integration patterns and examples
+
+## Guidelines
+
+1. **Keep focused**: Each file should address specific implementation needs
+2. **Include examples**: Provide concrete code examples, not just descriptions
+3. **Update regularly**: Keep documentation current with codebase changes
+4. **Reference context**: Explain why patterns exist and when to use them
+
+## Usage in Specifications
+
+Reference these files in your specifications' "All Needed Context" section:
+
+```yaml
+Documentation & References:
+- docfile: ai_docs/authentication_patterns.md
+  why: Custom JWT implementation with refresh token handling
+  section: Refresh Token Flow
+  gotcha: Tokens expire after 15 minutes, not the standard 1 hour
+```
+
+This ensures AI agents have the necessary context for successful implementation without needing to discover patterns throdos ugh trial and error.

.ai/ai_docs/library_gotchas.md

@@ -0,0 +1,53 @@
+# Library Gotchas and Workarounds
+
+This file documents known issues, quirks, and workarounds for libraries used in this project. Include specific version numbers and examples.
+
+## Template Format
+
+```markdown
+## [Library Name] v[Version]
+
+**Issue**: Brief description of the problem
+**Gotcha**: What to watch out for
+**Workaround**: How to handle it correctly
+**Example**: Code snippet showing the right way
+
+### Critical Issues
+- List any breaking changes or major issues
+
+### Common Mistakes
+- List frequent errors developers encounter
+```
+
+## Example Entry
+
+## FastAPI v0.104.1
+
+**Issue**: Async functions required for database operations
+**Gotcha**: Using sync database calls in async endpoints causes blocking
+**Workaround**: Always use async database client methods
+**Example**:
+```python
+# Wrong - blocks the event loop
+@app.get("/users")
+def get_users():
+    return db.query(User).all()
+
+# Correct - non-blocking
+@app.get("/users")
+async def get_users():
+    return await db.execute(select(User))
+```
+
+### Critical Issues
+- Pydantic v2 migration requires model_dump() instead of dict()
+- Background tasks must be async if they access the database
+
+### Common Mistakes
+- Forgetting `await` with database operations
+- Using sync functions in async contexts
+- Not handling database connection cleanup
+
+---
+
+*Note: Add your library-specific gotchas below using the template format*

.env.template

@@ -0,0 +1,18 @@
+# Specify CLI Environment Variables Template
+# Copy this file to .env and customize the values as needed
+
+# Repository Configuration
+# Override the default GitHub repository for template downloads
+SPECIFY_REPO_OWNER=github
+SPECIFY_REPO_NAME=spec-kit
+SPECIFY_REPO_BRANCH=
+
+# Repository Settings:
+# - SPECIFY_REPO_OWNER: GitHub username/organization that owns the spec-kit repository
+# - SPECIFY_REPO_NAME: Name of the repository containing the templates
+# - SPECIFY_REPO_BRANCH: Specific branch to download from (uses latest release if empty)
+
+# Examples:
+# SPECIFY_REPO_OWNER=mycompany
+# SPECIFY_REPO_NAME=custom-spec-kit
+# SPECIFY_REPO_BRANCH=development

.github/workflows/scripts/create-release-packages.sh

@@ -124,8 +124,8 @@ build_variant() {
   fi
   case $agent in
     claude)
-      mkdir -p "$base_dir/.claude/commands"
-      generate_commands claude md "\$ARGUMENTS" "$base_dir/.claude/commands" "$script" ;;
+      mkdir -p "$base_dir/.claude/commands/spec-kit"
+      generate_commands claude md "\$ARGUMENTS" "$base_dir/.claude/commands/spec-kit" "$script" ;;
     gemini)
       mkdir -p "$base_dir/.gemini/commands"
       generate_commands gemini toml "{{args}}" "$base_dir/.gemini/commands" "$script"

.gitignore

@@ -38,3 +38,9 @@ env/
 .env
 .env.local
 *.lock
+
+.claude
+.serena
+CLAUDE.md
+.specify
+specs

ATTRIBUTION.md

@@ -0,0 +1,40 @@
+# Attribution
+
+## Original Source
+
+This project is a fork of **[GitHub's spec-kit](https://github.com/github/spec-kit)**, created by:
+- **Den Delimarsky** ([@localden](https://github.com/localden))
+- **John Lam** ([@jflam](https://github.com/jflam))
+
+The original spec-kit project introduced the foundational concepts of Spec-Driven Development and remains under MIT License with copyright held by GitHub, Inc.
+
+## Fork Maintainer
+
+**Current Fork:** [hcnimi/spec-kit](https://github.com/hcnimi/spec-kit)
+**Maintained by:** Hubert Nimitanakit ([@hcnimi](https://github.com/hcnimi))
+
+This fork has evolved with additional features including multi-repo workspace support, adaptive workflow modes, and capability-based atomic PRs.
+
+## Influences & Inspirations
+
+### PRPs (Prompt-Response Pairs)
+- **Repository:** https://github.com/Wirasm/PRPs-agentic-eng
+- **Author:** Wirasm
+- **Influence:** Informed our approach to agentic engineering patterns and workflow structure
+
+### OpenSpec
+- **Repository:** https://github.com/Fission-AI/OpenSpec
+- **Author:** Fission-AI
+- **Influence:** Inspired the adaptive specification depth system (quick/lightweight/full modes) introduced in v0.4.0
+
+## Methodology Attribution
+
+The **Spec-Driven Development** methodology and core philosophy originate from research and work by John Lam at GitHub. This fork builds upon and extends that foundation while maintaining the original MIT License terms.
+
+## License
+
+This project maintains the MIT License from the original work. See [LICENSE](./LICENSE) for full terms.
+
+---
+
+**Last Updated:** 2025-11-01 (v0.4.0)

CODE_OF_CONDUCT.md

@@ -55,8 +55,8 @@ further defined and clarified by project maintainers.
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at <opensource@github.com>. All
-complaints will be reviewed and investigated and will result in a response that
+reported by opening a confidential issue at https://github.com/hcnimi/spec-kit/issues/new.
+All complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is
 obligated to maintain confidentiality with regard to the reporter of an incident.
 Further details of specific enforcement policies may be posted separately.

CONTRIBUTING.md

@@ -31,7 +31,7 @@ Here are a few things you can do that will increase the likelihood of your pull
 
 - Follow the project's coding conventions.
 - Write tests for new functionality.
-- Update documentation (`README.md,` `spec-driven.md`) if your changes affect user-facing features.
+- Update documentation (`README.md` and relevant files in `docs/`) if your changes affect user-facing features.
 - Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
 - Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
 - Test your changes with the Spec-Driven Development workflow to ensure compatibility.
@@ -47,7 +47,8 @@ When working on spec-kit:
 
 ## Resources
 
-- [Spec-Driven Development Methodology](./spec-driven.md)
+- [Spec-Driven Development Documentation](./docs/)
+- [Contributing Guide (detailed)](./contributing/)
 - [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
 - [Using Pull Requests](https://help.github.com/articles/about-pull-requests/)
 - [GitHub Help](https://help.github.com)

LICENSE

@@ -1,6 +1,7 @@
 MIT License
 
-Copyright GitHub, Inc.
+Copyright (c) 2024-2025 Hubert Nimitanakit (hcnimi)
+Based on original work Copyright GitHub, Inc.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

MANIFEST.in

@@ -0,0 +1,2 @@
+include templates/commands/*.md
+recursive-include templates *