Compare commits

..

8 Commits

Author SHA1 Message Date
Den Delimarsky
045696641a Merge pull request #895 from zidoshare/main
Fix: incorrect command formatting in agent context file
2025-10-15 10:51:34 -07:00
hongxuww
8c9e586662 Fix: Fix incorrect command formatting in agent context file
The issue is that `sed` treats `&&` as a placeholder instead of a regular character. So in the CLAUDE.md file's "Commands" section, it incorrectly shows:

`npm test [ONLY COMMANDS FOR ACTIVE TECHNOLOGIES][ONLY COMMANDS FOR ACTIVE TECHNOLOGIES] npm run lint`

instead of the correct:

`npm test && npm run lint`
2025-10-15 14:04:22 +00:00
Den Delimarsky
7b55522213 Merge pull request #886 from jarrensj/docs/fix-heading-capitalization-consistency
docs: fix heading capitalization for consistency
2025-10-14 23:39:23 -07:00
Jarren San Jose
7ca792509b docs: fix heading capitalization for consistency 2025-10-14 18:48:47 -07:00
den (work)
3e476c2ba6 Update README.md 2025-10-14 10:38:40 -07:00
den (work)
654a00aac9 Update tasks.md 2025-10-14 10:33:58 -07:00
Den Delimarsky
4690d13f88 Merge pull request #868 from benzyc/patch-1
Update README.md
2025-10-14 07:36:05 -07:00
benzyc
09f57a87fa Update README.md
Currently spec-kit is compatible with windows directly, therefore change the prerequisites from Linux/masos to linux/macos/windows.

This is quite important for windows users
2025-10-14 09:59:27 +08:00
3 changed files with 69 additions and 52 deletions

View File

@@ -20,16 +20,16 @@
## Table of Contents ## Table of Contents
- [🤔 What is Spec-Driven Development?](#-what-is-spec-driven-development) - [🤔 What is Spec-Driven Development?](#-what-is-spec-driven-development)
- [⚡ Get started](#-get-started) - [⚡ Get Started](#-get-started)
- [📽️ Video Overview](#-video-overview) - [📽️ Video Overview](#-video-overview)
- [🤖 Supported AI Agents](#-supported-ai-agents) - [🤖 Supported AI Agents](#-supported-ai-agents)
- [🔧 Specify CLI Reference](#-specify-cli-reference) - [🔧 Specify CLI Reference](#-specify-cli-reference)
- [📚 Core philosophy](#-core-philosophy) - [📚 Core Philosophy](#-core-philosophy)
- [🌟 Development phases](#-development-phases) - [🌟 Development Phases](#-development-phases)
- [🎯 Experimental goals](#-experimental-goals) - [🎯 Experimental Goals](#-experimental-goals)
- [🔧 Prerequisites](#-prerequisites) - [🔧 Prerequisites](#-prerequisites)
- [📖 Learn more](#-learn-more) - [📖 Learn More](#-learn-more)
- [📋 Detailed process](#-detailed-process) - [📋 Detailed Process](#-detailed-process)
- [🔍 Troubleshooting](#-troubleshooting) - [🔍 Troubleshooting](#-troubleshooting)
- [👥 Maintainers](#-maintainers) - [👥 Maintainers](#-maintainers)
- [💬 Support](#-support) - [💬 Support](#-support)
@@ -40,7 +40,7 @@
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. 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.
## ⚡ Get started ## ⚡ Get Started
### 1. Install Specify ### 1. Install Specify
@@ -247,7 +247,7 @@ Additional commands for enhanced quality and validation:
|------------------|------------------------------------------------------------------------------------------------| |------------------|------------------------------------------------------------------------------------------------|
| `SPECIFY_FEATURE` | Override feature detection for non-Git repositories. Set to the feature directory name (e.g., `001-photo-albums`) to work on a specific feature when not using Git branches.<br/>**Must be set in the context of the agent you're working with prior to using `/speckit.plan` or follow-up commands. | | `SPECIFY_FEATURE` | Override feature detection for non-Git repositories. Set to the feature directory name (e.g., `001-photo-albums`) to work on a specific feature when not using Git branches.<br/>**Must be set in the context of the agent you're working with prior to using `/speckit.plan` or follow-up commands. |
## 📚 Core philosophy ## 📚 Core Philosophy
Spec-Driven Development is a structured process that emphasizes: Spec-Driven Development is a structured process that emphasizes:
@@ -256,7 +256,7 @@ Spec-Driven Development is a structured process that emphasizes:
- **Multi-step refinement** rather than one-shot code generation from prompts - **Multi-step refinement** rather than one-shot code generation from prompts
- **Heavy reliance** on advanced AI model capabilities for specification interpretation - **Heavy reliance** on advanced AI model capabilities for specification interpretation
## 🌟 Development phases ## 🌟 Development Phases
| Phase | Focus | Key Activities | | Phase | Focus | Key Activities |
|-------|-------|----------------| |-------|-------|----------------|
@@ -264,7 +264,7 @@ Spec-Driven Development is a structured process that emphasizes:
| **Creative Exploration** | Parallel implementations | <ul><li>Explore diverse solutions</li><li>Support multiple technology stacks & architectures</li><li>Experiment with UX patterns</li></ul> | | **Creative Exploration** | Parallel implementations | <ul><li>Explore diverse solutions</li><li>Support multiple technology stacks & architectures</li><li>Experiment with UX patterns</li></ul> |
| **Iterative Enhancement** ("Brownfield") | Brownfield modernization | <ul><li>Add features iteratively</li><li>Modernize legacy systems</li><li>Adapt processes</li></ul> | | **Iterative Enhancement** ("Brownfield") | Brownfield modernization | <ul><li>Add features iteratively</li><li>Modernize legacy systems</li><li>Adapt processes</li></ul> |
## 🎯 Experimental goals ## 🎯 Experimental Goals
Our research and experimentation focus on: Our research and experimentation focus on:
@@ -292,22 +292,22 @@ Our research and experimentation focus on:
## 🔧 Prerequisites ## 🔧 Prerequisites
- **Linux/macOS** (or WSL2 on Windows) - **Linux/macOS/Windows**
- AI coding agent: [Claude Code](https://www.anthropic.com/claude-code), [GitHub Copilot](https://code.visualstudio.com/), [Gemini CLI](https://github.com/google-gemini/gemini-cli), [Cursor](https://cursor.sh/), [Qwen CLI](https://github.com/QwenLM/qwen-code), [opencode](https://opencode.ai/), [Codex CLI](https://github.com/openai/codex), [Windsurf](https://windsurf.com/), or [Amazon Q Developer CLI](https://aws.amazon.com/developer/learning/q-developer-cli/) - [Supported](#-supported-ai-agents) AI coding agent.
- [uv](https://docs.astral.sh/uv/) for package management - [uv](https://docs.astral.sh/uv/) for package management
- [Python 3.11+](https://www.python.org/downloads/) - [Python 3.11+](https://www.python.org/downloads/)
- [Git](https://git-scm.com/downloads) - [Git](https://git-scm.com/downloads)
If you encounter issues with an agent, please open an issue so we can refine the integration. If you encounter issues with an agent, please open an issue so we can refine the integration.
## 📖 Learn more ## 📖 Learn More
- **[Complete Spec-Driven Development Methodology](./spec-driven.md)** - Deep dive into the full process - **[Complete Spec-Driven Development Methodology](./spec-driven.md)** - Deep dive into the full process
- **[Detailed Walkthrough](#-detailed-process)** - Step-by-step implementation guide - **[Detailed Walkthrough](#-detailed-process)** - Step-by-step implementation guide
--- ---
## 📋 Detailed process ## 📋 Detailed Process
<details> <details>
<summary>Click to expand the detailed step-by-step walkthrough</summary> <summary>Click to expand the detailed step-by-step walkthrough</summary>

View File

@@ -250,7 +250,7 @@ get_commands_for_language() {
echo "cargo test && cargo clippy" echo "cargo test && cargo clippy"
;; ;;
*"JavaScript"*|*"TypeScript"*) *"JavaScript"*|*"TypeScript"*)
echo "npm test && npm run lint" echo "npm test \&\& npm run lint"
;; ;;
*) *)
echo "# Add commands for $lang" echo "# Add commands for $lang"

View File

@@ -22,27 +22,13 @@ You **MUST** consider the user input before proceeding (if not empty).
- **Optional**: data-model.md (entities), contracts/ (API endpoints), research.md (decisions), quickstart.md (test scenarios) - **Optional**: data-model.md (entities), contracts/ (API endpoints), research.md (decisions), quickstart.md (test scenarios)
- Note: Not all projects have all documents. Generate tasks based on what's available. - Note: Not all projects have all documents. Generate tasks based on what's available.
3. **Execute task generation workflow** (follow the template structure): 3. **Execute task generation workflow**:
- Load plan.md and extract tech stack, libraries, project structure - Load plan.md and extract tech stack, libraries, project structure
- **Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)** - Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)
- If data-model.md exists: Extract entities map to user stories - If data-model.md exists: Extract entities and map to user stories
- If contracts/ exists: Each file → map endpoints to user stories - If contracts/ exists: Map endpoints to user stories
- If research.md exists: Extract decisions → generate setup tasks - If research.md exists: Extract decisions for setup tasks
- **Generate tasks ORGANIZED BY USER STORY**: - Generate tasks organized by user story (see Task Generation Rules below)
- Setup tasks (shared infrastructure needed by all stories)
- **Foundational tasks (prerequisites that must complete before ANY user story can start)**
- For each user story (in priority order P1, P2, P3...):
- Group all tasks needed to complete JUST that story
- Include models, services, endpoints, UI components specific to that story
- Mark which tasks are [P] parallelizable
- If tests requested: Include tests specific to that story
- Polish/Integration tasks (cross-cutting concerns)
- **Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature spec or user asks for TDD approach
- Apply task rules:
- Different files = mark [P] for parallel
- Same file = sequential (no [P])
- If tests requested: Tests before implementation (TDD order)
- Number tasks sequentially (T001, T002...)
- Generate dependency graph showing user story completion order - Generate dependency graph showing user story completion order
- Create parallel execution examples per user story - Create parallel execution examples per user story
- Validate task completeness (each user story has all needed tasks, independently testable) - Validate task completeness (each user story has all needed tasks, independently testable)
@@ -52,12 +38,9 @@ You **MUST** consider the user input before proceeding (if not empty).
- Phase 1: Setup tasks (project initialization) - Phase 1: Setup tasks (project initialization)
- Phase 2: Foundational tasks (blocking prerequisites for all user stories) - Phase 2: Foundational tasks (blocking prerequisites for all user stories)
- Phase 3+: One phase per user story (in priority order from spec.md) - Phase 3+: One phase per user story (in priority order from spec.md)
- Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks - Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks
- Clear [Story] labels (US1, US2, US3...) for each task
- [P] markers for parallelizable tasks within each story
- Checkpoint markers after each story phase
- Final Phase: Polish & cross-cutting concerns - Final Phase: Polish & cross-cutting concerns
- Numbered tasks (T001, T002...) in execution order - All tasks must follow the strict checklist format (see Task Generation Rules below)
- Clear file paths for each task - Clear file paths for each task
- Dependencies section showing story completion order - Dependencies section showing story completion order
- Parallel execution examples per story - Parallel execution examples per story
@@ -69,6 +52,7 @@ You **MUST** consider the user input before proceeding (if not empty).
- Parallel opportunities identified - Parallel opportunities identified
- Independent test criteria for each story - Independent test criteria for each story
- Suggested MVP scope (typically just User Story 1) - Suggested MVP scope (typically just User Story 1)
- Format validation: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths)
Context for task generation: {ARGS} Context for task generation: {ARGS}
@@ -76,10 +60,44 @@ The tasks.md should be immediately executable - each task must be specific enoug
## Task Generation Rules ## Task Generation Rules
**IMPORTANT**: Tests are optional. Only generate test tasks if the user explicitly requested testing or TDD approach in the feature specification.
**CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing. **CRITICAL**: Tasks MUST be organized by user story to enable independent implementation and testing.
**Tests are OPTIONAL**: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.
### Checklist Format (REQUIRED)
Every task MUST strictly follow this format:
```text
- [ ] [TaskID] [P?] [Story?] Description with file path
```
**Format Components**:
1. **Checkbox**: ALWAYS start with `- [ ]` (markdown checkbox)
2. **Task ID**: Sequential number (T001, T002, T003...) in execution order
3. **[P] marker**: Include ONLY if task is parallelizable (different files, no dependencies on incomplete tasks)
4. **[Story] label**: REQUIRED for user story phase tasks only
- Format: [US1], [US2], [US3], etc. (maps to user stories from spec.md)
- Setup phase: NO story label
- Foundational phase: NO story label
- User Story phases: MUST have story label
- Polish phase: NO story label
5. **Description**: Clear action with exact file path
**Examples**:
- ✅ CORRECT: `- [ ] T001 Create project structure per implementation plan`
- ✅ CORRECT: `- [ ] T005 [P] Implement authentication middleware in src/middleware/auth.py`
- ✅ CORRECT: `- [ ] T012 [P] [US1] Create User model in src/models/user.py`
- ✅ CORRECT: `- [ ] T014 [US1] Implement UserService in src/services/user_service.py`
- ❌ WRONG: `- [ ] Create User model` (missing ID and Story label)
- ❌ WRONG: `T001 [US1] Create model` (missing checkbox)
- ❌ WRONG: `- [ ] [US1] Create User model` (missing Task ID)
- ❌ WRONG: `- [ ] T001 [US1] Create model` (missing file path)
### Task Organization
1. **From User Stories (spec.md)** - PRIMARY ORGANIZATION: 1. **From User Stories (spec.md)** - PRIMARY ORGANIZATION:
- Each user story (P1, P2, P3...) gets its own phase - Each user story (P1, P2, P3...) gets its own phase
- Map all related components to their story: - Map all related components to their story:
@@ -94,22 +112,21 @@ The tasks.md should be immediately executable - each task must be specific enoug
- If tests requested: Each contract → contract test task [P] before implementation in that story's phase - If tests requested: Each contract → contract test task [P] before implementation in that story's phase
3. **From Data Model**: 3. **From Data Model**:
- Map each entity to the user story(ies) that need it - Map each entity to the user story(ies) that need it
- If entity serves multiple stories: Put in earliest story or Setup phase - If entity serves multiple stories: Put in earliest story or Setup phase
- Relationships → service layer tasks in appropriate story phase - Relationships → service layer tasks in appropriate story phase
4. **From Setup/Infrastructure**: 4. **From Setup/Infrastructure**:
- Shared infrastructure → Setup phase (Phase 1) - Shared infrastructure → Setup phase (Phase 1)
- Foundational/blocking tasks → Foundational phase (Phase 2) - Foundational/blocking tasks → Foundational phase (Phase 2)
- Examples: Database schema setup, authentication framework, core libraries, base configurations
- These MUST complete before any user story can be implemented
- Story-specific setup → within that story's phase - Story-specific setup → within that story's phase
5. **Ordering**: ### Phase Structure
- Phase 1: Setup (project initialization)
- Phase 2: Foundational (blocking prerequisites - must complete before user stories) - **Phase 1**: Setup (project initialization)
- Phase 3+: User Stories in priority order (P1, P2, P3...) - **Phase 2**: Foundational (blocking prerequisites - MUST complete before user stories)
- Within each story: Tests (if requested) → Models → Services → Endpoints → Integration - **Phase 3+**: User Stories in priority order (P1, P2, P3...)
- Final Phase: Polish & Cross-Cutting Concerns - Within each story: Tests (if requested) → Models → Services → Endpoints → Integration
- Each user story phase should be a complete, independently testable increment - Each phase should be a complete, independently testable increment
- **Final Phase**: Polish & Cross-Cutting Concerns