Initial commit
This commit is contained in:
Zhongwei Li
73
commands/implement.md
Normal file
73
commands/implement.md
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
argument-hint: "[--all]"
|
||||
description: Implement features from tasks document with optional batch mode
|
||||
---
|
||||
|
||||
# Implementation Executor
|
||||
|
||||
Execute implementation tasks from the task breakdown document, with support for batch or incremental implementation.
|
||||
|
||||
## Arguments
|
||||
|
||||
`--all` (optional, batch implementation flag)
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Read Required Documents**:
|
||||
- Read `docs/tasks-init.md` to understand all tasks and their organization
|
||||
- Read `docs/spec-init.md` to understand requirements and success criteria
|
||||
- Read `docs/plan-init.md` to understand technical decisions and architecture
|
||||
|
||||
2. **Implementation Strategy**:
|
||||
- If `--all` flag is provided: Implement all tasks in batch mode
|
||||
- If `--all` flag is NOT provided: Implement tasks by group, then wait for user approval before proceeding to next group
|
||||
|
||||
3. **For Each Task**:
|
||||
- Mark task as in_progress using TodoWrite
|
||||
- Implement the feature following:
|
||||
- Existing code patterns and conventions
|
||||
- Technical decisions from plan-init.md
|
||||
- Specification requirements from spec-init.md
|
||||
- Write clean, maintainable code
|
||||
- Test functionality to ensure it works correctly
|
||||
- Mark task as completed using TodoWrite immediately after successful completion
|
||||
|
||||
4. **Code Quality Standards**:
|
||||
- Follow existing code style and patterns in the codebase
|
||||
- Use consistent naming conventions
|
||||
- Write clear, self-documenting code
|
||||
- Handle edge cases appropriately
|
||||
- Ensure no breaking changes to existing functionality
|
||||
|
||||
5. **Testing During Implementation**:
|
||||
- Manual testing: Verify each feature works as specified
|
||||
- Test normal use cases first, then edge cases
|
||||
- Ensure error handling works correctly
|
||||
- Document any test steps performed
|
||||
|
||||
6. **Completion Report**:
|
||||
After all tasks (or all groups if using incremental mode) are complete, provide:
|
||||
- Summary of implemented features
|
||||
- List of created or modified files
|
||||
- Detailed testing methodology:
|
||||
* Manual test steps with expected results
|
||||
* Test command examples (if applicable)
|
||||
* Edge cases covered
|
||||
- Next steps guidance (for --all: done; for incremental: ready for next group)
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- **Code Quality**: Clean, readable code following project conventions
|
||||
- **Specification Alignment**: All implementations match requirements from spec-init.md
|
||||
- **Technical Adherence**: Solutions follow architecture and decisions from plan-init.md
|
||||
- **Testing Coverage**: Manual testing validates all requirements and edge cases
|
||||
- **Error Handling**: Proper error handling and edge case management
|
||||
- **Documentation**: Clear test procedures and expected results
|
||||
|
||||
## Task
|
||||
|
||||
Read the tasks from `docs/tasks-init.md`, specification from `docs/spec-init.md`, and technical plan from `docs/plan-init.md`. Then implement all tasks following the instructions above.
|
||||
|
||||
The implementation should result in a fully functional feature set that meets all specification requirements, passes all manual testing, and maintains code quality standards. Each task must be atomic, testable, and contribute to achieving the specification goals.
|
||||
|
||||
If implementing incrementally (without --all), wait for user approval after completing each task group before proceeding to the next group.
|
||||
60
commands/plan.md
Normal file
60
commands/plan.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
argument-hint: "[tech-stack]"
|
||||
description: Create comprehensive technical implementation plan from specification
|
||||
---
|
||||
|
||||
# Implementation Plan Generator
|
||||
|
||||
Generate a detailed technical implementation plan from a specification document and create or analyze technology stack.
|
||||
|
||||
## Arguments
|
||||
|
||||
$1 (Optional: specific technology stack in Korean or English format)
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Read `docs/spec-init.md`**: Understand feature requirements and success criteria
|
||||
2. **Determine Technology Stack**:
|
||||
- If user provides $1: Use specified technology stack
|
||||
- If not provided: Analyze project structure and recommend appropriate technologies
|
||||
3. **Create `docs/plan-init.md`** with the following structure:
|
||||
- Original Tech Stack Request (record user input if provided)
|
||||
- Technology Stack (frameworks, libraries, versions for implementation)
|
||||
- Architecture Overview (high-level system design, component interactions)
|
||||
- Data Models (database schema, data structures, relationships)
|
||||
- API Design (endpoints, request/response formats if applicable)
|
||||
- Component Structure (component hierarchy, organization, folder structure)
|
||||
- State Management (data flow, store architecture)
|
||||
- Security Considerations (authentication, authorization, data protection)
|
||||
- Testing Strategy (unit, integration, E2E test approach)
|
||||
- Deployment Plan (build process, environment configuration, CI/CD)
|
||||
- Dependencies (packages, versions, compatibility notes)
|
||||
|
||||
4. **Generate Report**:
|
||||
- Summarize technology selection rationale
|
||||
- Explain key architectural decisions
|
||||
- Guide user to next step: run `/simple-sdd/tasks` to generate implementation tasks
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- **Technical Feasibility**: All proposed solutions must be practically implementable
|
||||
- **Specification Alignment**: Plan must precisely match requirements from spec-init.md
|
||||
- **Implementation Detail**: Sufficiently detailed for developers to begin coding
|
||||
- **Best Practices**: Incorporates industry standards and proven patterns
|
||||
- **Scalability**: Considers future growth and maintenance
|
||||
|
||||
## Output Format
|
||||
|
||||
### Report Structure
|
||||
1. **Selected Technology Stack** - List of frameworks and key libraries
|
||||
2. **Architecture Highlights** - 3-5 key design decisions and their rationale
|
||||
3. **Key Components** - Major components and their responsibilities
|
||||
4. **Next Steps** - Instructions to run `/simple-sdd/tasks`
|
||||
|
||||
## Task
|
||||
|
||||
Based on the specification in `docs/spec-init.md` and optional technology preference in $1, create a comprehensive implementation plan. The plan should provide sufficient technical detail for experienced developers to begin implementation immediately.
|
||||
|
||||
Generate the plan following the Structure outline and ensure each section provides actionable guidance with specific technologies, patterns, and architectural decisions.
|
||||
|
||||
Write all content in the same language as the original specification document (Korean or English).
|
||||
39
commands/spec.md
Normal file
39
commands/spec.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
argument-hint: "[requirements]"
|
||||
description: "Generate a comprehensive software specification document from requirements"
|
||||
---
|
||||
|
||||
# Specification Generator
|
||||
|
||||
Generate a detailed, structured software specification document from user-provided requirements.
|
||||
|
||||
## Arguments
|
||||
|
||||
$1 (Korean/English supported)
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **분석**: 제공된 요구 사항을 세밀하게 분석하고 명확히 이해
|
||||
2. **문서 생성**: 다음 구조로 `docs/spec-init.md` 생성:
|
||||
- Original Requirements (사용자 입력 그대로)
|
||||
- Overview (간단한 요약)
|
||||
- Goals (명확한 목표)
|
||||
- User Stories (사용자 관점 시나리오)
|
||||
- Functional Requirements (해야 할 일)
|
||||
- Non-Functional Requirements (성능, 보안, 접근성)
|
||||
- Constraints & Assumptions (제약사항과 가정)
|
||||
- Success Criteria (성공 기준)
|
||||
|
||||
3. **보고**: 핵심 내용을 요약해서 사용자에게 제시하고, `/simple-sdd/plan [tech-stack]` 명령 사용 안내
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- **명확성**: 명확하고 모호하지 않으며 완전한 명세
|
||||
- **검증성**: 테스트 가능하고 측정 가능한 요구 사항
|
||||
- **정합성**: 사용자 요구 사항과 완벽하게 일치
|
||||
|
||||
## Task
|
||||
|
||||
Based on the requirements provided in $1, create a comprehensive specification document that meets the quality standards above. The document should be written in the same language as the input (Korean or English).
|
||||
|
||||
Generate the specification following the Structure outline and ensure each section is detailed and actionable.
|
||||
57
commands/tasks.md
Normal file
57
commands/tasks.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
argument-hint: "[context]"
|
||||
description: Generate implementation tasks from specification and plan
|
||||
---
|
||||
|
||||
# Tasks Generator
|
||||
|
||||
Generate detailed, atomic implementation tasks from specification and technical plan documents.
|
||||
|
||||
## Arguments
|
||||
|
||||
$1 (Optional: additional context or task filtering in Korean/English)
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Read Documents**:
|
||||
- Read `docs/spec-init.md` to understand all requirements and success criteria
|
||||
- Read `docs/plan-init.md` to understand technical architecture and implementation strategy
|
||||
|
||||
2. **Generate `docs/tasks-init.md`** with the following structure:
|
||||
- **Task Groups**: Organize tasks by logical categories (e.g., Setup & Configuration, Database & Data Models, API Endpoints, Frontend Components, Integration & Testing)
|
||||
- **Task Format**: Each task must include:
|
||||
- ID: **T-001**, **T-002** format (sequential numbering)
|
||||
- Title: Clear, concise task name
|
||||
- Purpose: Why this task is needed
|
||||
- Description: What needs to be implemented
|
||||
- Dependencies: Reference other task IDs if applicable
|
||||
- Required: Yes/No (critical for MVP vs. enhancements)
|
||||
- **Task Characteristics**:
|
||||
- Atomic: Each task should be completable in 1-3 hours
|
||||
- Testable: Clear acceptance criteria
|
||||
- Ordered: Tasks sorted by dependencies and logical flow
|
||||
- **Report Section**: Include summary statistics
|
||||
|
||||
3. **Generate Report**:
|
||||
- Total number of tasks and groups
|
||||
- Each group name with complexity rating (Low/Medium/High)
|
||||
- Summary table: Task ID, Title, Purpose (brief), Required (Yes/No)
|
||||
- Key insights about task distribution
|
||||
- Next steps: Guide user to run `/implement [--all]` to begin implementation
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- **Specification Alignment**: All tasks derived from spec-init.md requirements
|
||||
- **Plan Adherence**: Tasks follow technical architecture from plan-init.md
|
||||
- **Atomic & Testable**: Each task is small and has clear acceptance criteria
|
||||
- **Dependency Management**: Tasks ordered correctly with dependencies documented
|
||||
- **Realistic Scope**: Tasks are achievable and well-scoped
|
||||
- **Complete Coverage**: All aspects of spec and plan are covered
|
||||
|
||||
## Task
|
||||
|
||||
Based on the specification in `docs/spec-init.md` and technical plan in `docs/plan-init.md`, create a comprehensive task breakdown that developers can immediately begin implementing.
|
||||
|
||||
Generate the tasks following the Structure outline with proper grouping, sequencing, and detailed descriptions. Ensure every task is atomic, testable, and clearly linked to specification requirements.
|
||||
|
||||
Write all content in English and follow the exact formatting specified above.
|
||||
Reference in New Issue
Block a user