Initial commit

2025-11-30 09:02:23 +08:00
commit 5f44d04a64
18 changed files with 1976 additions and 0 deletions
--- a/skills/spec-to-implementation/SKILL.md
+++ b/skills/spec-to-implementation/SKILL.md
@@ -0,0 +1,138 @@
+---
+name: spec-to-implementation
+description: Parse specifications and create implementation plans with task tracking in Notion
+---
+
+## Overview
+
+The Spec-to-Implementation skill transforms project specifications into detailed implementation plans with comprehensive task breakdowns, timeline estimates, and dependency tracking in Notion. It bridges the gap between requirements and execution.
+
+## When to Use
+
+Use this skill when you need to:
+- Convert project specifications into actionable implementation plans
+- Break down complex features into implementable tasks
+- Create detailed project timelines with estimates
+- Identify dependencies and critical path items
+- Generate task checklists with ownership and deadlines
+- Track implementation progress in Notion
+- Create architectural and technical specifications from requirements
+
+## Features
+
+- **Smart Requirement Parsing**: Automatically extracts requirements and acceptance criteria
+- **Task Decomposition**: Breaks specifications into atomic, implementable tasks
+- **Dependency Mapping**: Identifies and visualizes task dependencies
+- **Effort Estimation**: Provides time estimates for tasks and milestones
+- **Ownership Assignment**: Creates task assignments with clarity
+- **Progress Tracking**: Sets up Notion databases for implementation tracking
+- **Risk Identification**: Highlights potential implementation risks and blockers
+
+## Requirements
+
+- **Notion API Access**: For creating implementation plans and task databases
+- **Specification Format**: Clear specification documents (markdown, PDFs, or text)
+- **Team Database**: Directory of team members and skills (optional but recommended)
+- **Project Template**: Pre-configured Notion template for consistency
+
+## Implementation Details
+
+This skill transforms specifications through a systematic process:
+
+1. Parse specification document and extract requirements
+2. Break requirements into user stories and tasks
+3. Identify technical dependencies and blockers
+4. Create detailed implementation plan with phases
+5. Estimate effort for each task
+6. Assign ownership and set deadlines
+7. Create tracking structure in Notion
+8. Generate project dashboard and status reports
+
+### Spec-to-Implementation Workflow
+
+```
+Specification Document
+  ↓
+Extract Requirements
+  ↓
+Break into User Stories
+  ↓
+Decompose into Tasks
+  ↓
+Identify Dependencies
+  ↓
+Estimate Effort
+  ↓
+Assign Ownership
+  ↓
+Create Notion Plan
+  ↓
+Output: Implementation Roadmap
+```
+
+## Example Use Cases
+
+1. **Feature Implementation**
+   - Input: Feature specification with requirements
+   - Output: Task breakdown with timeline and ownership
+   - Tracks: Progress dashboard in Notion
+
+2. **Product Launch**
+   - Input: Product specification and launch requirements
+   - Output: Launch plan with phases, dependencies, and critical path
+   - Tracks: Multi-team coordination and milestones
+
+3. **System Migration**
+   - Input: Migration specification and technical requirements
+   - Output: Detailed migration plan with phases
+   - Tracks: Data mapping, system cutover, and rollback procedures
+
+4. **Infrastructure Project**
+   - Input: Infrastructure design specification
+   - Output: Implementation plan with testing and deployment phases
+   - Tracks: Build, test, and deployment checkpoints
+
+5. **API Development**
+   - Input: API specification and endpoint requirements
+   - Output: Development tasks with testing and documentation
+   - Tracks: Development progress and integration milestones
+
+## Task Hierarchy
+
+```
+Epic (Feature)
+  ├── User Story 1
+  │   ├── Task 1.1 (Backend)
+  │   ├── Task 1.2 (Frontend)
+  │   └── Task 1.3 (Testing)
+  ├── User Story 2
+  │   └── [Tasks...]
+  └── Acceptance Criteria
+```
+
+## Configuration
+
+```env
+NOTION_API_TOKEN=your_token_here
+PROJECT_DATABASE_ID=your_database_id
+TASK_DATABASE_ID=your_task_database_id
+TEAM_DATABASE_ID=your_team_database_id
+ESTIMATE_UNIT=hours
+```
+
+## Estimate Units
+
+Supported time estimate formats:
+- Hours
+- Story Points
+- Days
+- Weeks
+- Planning Poker values (1, 2, 3, 5, 8, 13, 21)
+
+## See Also
+
+- [Knowledge Capture](/skills/knowledge-capture) - For documenting design decisions
+- [Meeting Intelligence](/skills/meeting-intelligence) - For kickoff meeting preparation
+- [Research Documentation](/skills/research-documentation) - For technology research
+- [Notion Database Documentation](https://developers.notion.com)
+- [Agile Task Management Best Practices](https://developers.notion.com)
--- a/skills/spec-to-implementation/evaluations/README.md
+++ b/skills/spec-to-implementation/evaluations/README.md
@@ -0,0 +1,46 @@
+# Spec-to-Implementation - Evaluation Scenarios
+
+Test scenarios for validating specification parsing and implementation plan generation.
+
+## Evaluation Criteria
+
+**Requirement Extraction**
+- All functional requirements identified
+- Non-functional requirements documented
+- Acceptance criteria captured
+- Dependencies clearly stated
+
+**Task Breakdown**
+- Specifications decomposed into atomic tasks
+- Task sizing appropriate (1-2 days each)
+- Technical dependencies mapped
+- Parallel work opportunities identified
+
+**Estimation**
+- Effort estimates realistic
+- Timeline achieves project goals
+- Buffer time included for unknowns
+- Risk factors considered
+
+**Tracking**
+- Implementation plan is actionable
+- Progress metrics are trackable
+- Milestones clearly defined
+- Links to specification maintained
+
+## Test Scenario Types
+
+1. **Feature Implementation** - New feature specification to implementation plan
+2. **API Development** - API specification with endpoint breakdown
+3. **System Migration** - Migration specification with phased approach
+4. **Product Launch** - Multi-component launch planning
+5. **Infrastructure Project** - Technical infrastructure setup
+
+## Success Indicators
+
+✓ All requirements addressed in task list
+✓ Tasks are specific and actionable
+✓ Timeline is realistic
+✓ Dependencies are clear
+✓ Implementation is trackable
+✓ Risks identified and mitigation planned
--- a/skills/spec-to-implementation/reference/task-breakdown-guide.md
+++ b/skills/spec-to-implementation/reference/task-breakdown-guide.md
@@ -0,0 +1,240 @@
+# Spec to Implementation - Task Breakdown Guide
+
+How to decompose specifications into well-structured, implementable tasks.
+
+## Task Hierarchy
+
+```
+Specification Document
+├── Requirement 1
+│   ├── User Story 1.1
+│   │   ├── Task 1.1.1 (Backend)
+│   │   ├── Task 1.1.2 (Frontend)
+│   │   └── Task 1.1.3 (Testing)
+│   └── User Story 1.2
+│       └── [Tasks...]
+└── Requirement 2
+    └── [User Stories and Tasks...]
+```
+
+## Task Properties
+
+Each task should have:
+
+| Property | Purpose | Example |
+|----------|---------|---------|
+| **Title** | Clear, action-oriented | "Implement user authentication endpoint" |
+| **Description** | What, why, how | Details of implementation approach |
+| **Acceptance Criteria** | How to know it's done | "Users can log in with email/password" |
+| **Estimate** | Effort required | "5 story points" or "8 hours" |
+| **Owner** | Who's doing it | "Alex Chen" |
+| **Dependencies** | What must happen first | "Database schema finalized" |
+| **Priority** | Urgency | "P0 - Blocking", "P1 - Critical", etc. |
+
+## Task Sizing
+
+**Too Large (> 3 days)**
+- Hard to estimate accurately
+- Difficult to track progress
+- Risk of getting blocked
+
+**Right Size (1-2 days)**
+- Concrete and actionable
+- Progress visible daily
+- Easier to unblock
+
+**Too Small (< 2 hours)**
+- Overhead from task management
+- Discourages good estimates
+- Creates task clutter
+
+## Task Types
+
+### Backend Implementation
+```
+Task: Implement [feature] endpoint
+
+Acceptance Criteria:
+- [ ] Endpoint accepts [inputs]
+- [ ] Returns [format] with [fields]
+- [ ] Validates [constraints]
+- [ ] Handles [error cases]
+- [ ] Tests cover [coverage level]%
+```
+
+### Frontend Implementation
+```
+Task: Build [component/page]
+
+Acceptance Criteria:
+- [ ] Component renders [expected layout]
+- [ ] Responds to [user interactions]
+- [ ] Displays [content] from API
+- [ ] Works on [screen sizes]
+- [ ] Accessible (WCAG [level])
+```
+
+### Database/Data
+```
+Task: Create [schema/migration]
+
+Acceptance Criteria:
+- [ ] Schema supports [use cases]
+- [ ] Indexes created for [queries]
+- [ ] Migration handles [data]
+- [ ] Rollback plan documented
+- [ ] Performance tested
+```
+
+### Testing
+```
+Task: Test [feature/component]
+
+Acceptance Criteria:
+- [ ] Unit tests: [X]% coverage
+- [ ] Integration tests for [scenarios]
+- [ ] End-to-end tests for [flows]
+- [ ] Performance tests meet [targets]
+- [ ] Documented edge cases
+```
+
+### Documentation
+```
+Task: Document [feature/API]
+
+Acceptance Criteria:
+- [ ] API documentation complete
+- [ ] Usage examples included
+- [ ] Edge cases documented
+- [ ] Links to related docs added
+- [ ] Reviewed and approved
+```
+
+## Dependency Mapping
+
+**Identify blocking dependencies:**
+
+```
+Auth Implementation (5 days)
+├── Database schema (2 days) ← Must happen first
+├── API endpoint (3 days) ← Depends on schema
+├── Frontend UI (2 days) ← Depends on endpoint
+└── Testing (2 days) ← Depends on frontend
+```
+
+**Critical Path:** Schema → Endpoint → Frontend → Testing (11 days)
+
+**Parallel Work:** Multiple features can start once dependencies met
+
+## Effort Estimation
+
+**Estimation Techniques:**
+
+1. **Story Points** (Fibonacci: 1, 2, 3, 5, 8, 13)
+   - Relative sizing
+   - Good for iterative planning
+   - Accounts for uncertainty
+
+2. **Hours** (for precise tracking)
+   - 4-6 hours = Small task
+   - 8-16 hours = Medium task
+   - 16+ hours = Break down further
+
+3. **Days** (for roadmapping)
+   - 1 day = Sprint task
+   - 2-3 days = Normal task
+   - 4+ days = Risky, reconsider
+
+## Acceptance Criteria Format
+
+**Good Acceptance Criteria:**
+```
+Given [context]
+When [action happens]
+Then [expected result]
+```
+
+**Example:**
+```
+Given user is on the login page
+When they enter email and click submit without password
+Then they see error "Password is required"
+```
+
+## Common Decomposition Patterns
+
+### By Component
+- Task 1: Implement backend service
+- Task 2: Build UI component
+- Task 3: Integrate frontend to backend
+- Task 4: Test end-to-end
+
+### By Feature Slice
+- Task 1: Happy path implementation
+- Task 2: Error handling
+- Task 3: Edge cases
+- Task 4: Performance optimization
+
+### By Layer
+- Task 1: Database layer
+- Task 2: API layer
+- Task 3: Frontend layer
+- Task 4: Integration & testing
+
+### By Priority
+- Task 1: MVP features
+- Task 2: Core features
+- Task 3: Nice-to-haves
+- Task 4: Future enhancements
+
+## Red Flags
+
+⚠️ **Task is too vague**
+- "Fix authentication" → Break down to specific changes
+
+⚠️ **Task has unclear owner**
+- Ensure one person is clearly responsible
+
+⚠️ **Task has no acceptance criteria**
+- Add specific, measurable completion definition
+
+⚠️ **Task is estimated at 13+ points**
+- Break into smaller tasks
+
+⚠️ **Task has unidentified dependencies**
+- List all blockers explicitly
+
+⚠️ **Task depends on another task being done**
+- Create clear sequence or parallelize where possible
+
+## Task Lifecycle
+
+```
+Spec Analysis
+↓
+Task Identification
+↓
+Dependency Mapping
+↓
+Prioritization & Sequencing
+↓
+Estimation
+↓
+Assignment
+↓
+Implementation (with daily progress)
+↓
+Review & Testing
+↓
+Completion & Documentation
+```
+
+## Documentation in Task Manager
+
+Each task should link to:
+- [ ] Original specification
+- [ ] Related tasks
+- [ ] Design documentation
+- [ ] Test cases
+- [ ] Code review URL
+- [ ] Merged PR/commit