Initial commit: Claude Skills Factory with 8 refined custom skills
Custom Skills (ourdigital-custom-skills/): - 00-ourdigital-visual-storytelling: Blog featured image prompt generator - 01-ourdigital-research-publisher: Research-to-publication workflow - 02-notion-organizer: Notion workspace management - 03-research-to-presentation: Notion research to PPT/Figma - 04-seo-gateway-strategist: SEO gateway page strategy planning - 05-gateway-page-content-builder: Gateway page content generation - 20-jamie-brand-editor: Jamie Clinic branded content GENERATION - 21-jamie-brand-guardian: Jamie Clinic content REVIEW & evaluation Refinements applied: - All skills converted to SKILL.md format with YAML frontmatter - Added version fields to all skills - Flattened nested folder structures - Removed packaging artifacts (.zip, .skill files) - Reorganized file structures (scripts/, references/, etc.) - Differentiated Jamie skills with clear roles 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
# Milestone Summary Template
|
||||
|
||||
Use this when completing major phases or milestones.
|
||||
|
||||
```markdown
|
||||
## Phase [N] Complete: [Date]
|
||||
|
||||
### Accomplishments
|
||||
- [Major item delivered]
|
||||
- [Major item delivered]
|
||||
|
||||
### Deliverables
|
||||
- <mention-page url="...">Deliverable 1</mention-page>
|
||||
- [Link to PR/deployment]
|
||||
|
||||
### Metrics
|
||||
- [Relevant metric]
|
||||
- [Relevant metric]
|
||||
|
||||
### Learnings
|
||||
- [What went well]
|
||||
- [What to improve]
|
||||
|
||||
### Next Phase
|
||||
Starting [Phase name] on [Date]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,458 @@
|
||||
# Progress Tracking
|
||||
|
||||
## Update Frequency
|
||||
|
||||
### Daily Updates
|
||||
|
||||
For active implementation work:
|
||||
|
||||
**What to update**:
|
||||
- Task status if changed
|
||||
- Add progress note to task
|
||||
- Update blockers
|
||||
|
||||
**When**:
|
||||
- End of work day
|
||||
- After completing significant work
|
||||
- When encountering blockers
|
||||
|
||||
### Milestone Updates
|
||||
|
||||
For phase/milestone completion:
|
||||
|
||||
**What to update**:
|
||||
- Mark phase complete in plan
|
||||
- Add milestone summary
|
||||
- Update timeline if needed
|
||||
- Report to stakeholders
|
||||
|
||||
**When**:
|
||||
- Phase completion
|
||||
- Major deliverable ready
|
||||
- Sprint end
|
||||
- Release
|
||||
|
||||
### Status Change Updates
|
||||
|
||||
For task state transitions:
|
||||
|
||||
**What to update**:
|
||||
- Task status property
|
||||
- Add transition note
|
||||
- Notify relevant people
|
||||
|
||||
**When**:
|
||||
- Start work (To Do → In Progress)
|
||||
- Ready for review (In Progress → In Review)
|
||||
- Complete (In Review → Done)
|
||||
- Block (Any → Blocked)
|
||||
|
||||
## Progress Note Format
|
||||
|
||||
### Daily Progress Note
|
||||
|
||||
```markdown
|
||||
## Progress: [Date]
|
||||
|
||||
### Completed
|
||||
- [Specific accomplishment with details]
|
||||
- [Specific accomplishment with details]
|
||||
|
||||
### In Progress
|
||||
- [Current work item]
|
||||
- Current status: [Percentage or description]
|
||||
|
||||
### Next Steps
|
||||
1. [Next planned action]
|
||||
2. [Next planned action]
|
||||
|
||||
### Blockers
|
||||
- [Blocker description and who/what needed to unblock]
|
||||
- Or: None
|
||||
|
||||
### Decisions Made
|
||||
- [Any technical/product decisions]
|
||||
|
||||
### Notes
|
||||
[Additional context, learnings, issues encountered]
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
```markdown
|
||||
## Progress: Oct 14, 2025
|
||||
|
||||
### Completed
|
||||
- Implemented user authentication API endpoints (login, logout, refresh)
|
||||
- Added JWT token generation and validation
|
||||
- Wrote unit tests for auth service (95% coverage)
|
||||
|
||||
### In Progress
|
||||
- Frontend login form integration
|
||||
- Currently: Form submits but need to handle error states
|
||||
|
||||
### Next Steps
|
||||
1. Complete error handling in login form
|
||||
2. Add loading states
|
||||
3. Implement "remember me" functionality
|
||||
|
||||
### Blockers
|
||||
None
|
||||
|
||||
### Decisions Made
|
||||
- Using HttpOnly cookies for refresh tokens (more secure than localStorage)
|
||||
- Session timeout set to 24 hours based on security review
|
||||
|
||||
### Notes
|
||||
- Found edge case with concurrent login attempts, added to backlog
|
||||
- Performance of auth check is good (<10ms)
|
||||
```
|
||||
|
||||
### Milestone Summary
|
||||
|
||||
```markdown
|
||||
## Phase [N] Complete: [Date]
|
||||
|
||||
### Overview
|
||||
[Brief description of what was accomplished in this phase]
|
||||
|
||||
### Completed Tasks
|
||||
- <mention-page url="...">Task 1</mention-page> ✅
|
||||
- <mention-page url="...">Task 2</mention-page> ✅
|
||||
- <mention-page url="...">Task 3</mention-page> ✅
|
||||
|
||||
### Deliverables
|
||||
- [Deliverable 1]: [Link/description]
|
||||
- [Deliverable 2]: [Link/description]
|
||||
|
||||
### Key Accomplishments
|
||||
- [Major achievement]
|
||||
- [Major achievement]
|
||||
|
||||
### Metrics
|
||||
- [Relevant metric]: [Value]
|
||||
- [Relevant metric]: [Value]
|
||||
|
||||
### Challenges Overcome
|
||||
- [Challenge and how it was solved]
|
||||
|
||||
### Learnings
|
||||
**What went well**:
|
||||
- [Success factor]
|
||||
|
||||
**What to improve**:
|
||||
- [Area for improvement]
|
||||
|
||||
### Impact on Timeline
|
||||
- On schedule / [X days ahead/behind]
|
||||
- Reason: [If deviation, explain why]
|
||||
|
||||
### Next Phase
|
||||
- **Starting**: [Next phase name]
|
||||
- **Target start date**: [Date]
|
||||
- **Focus**: [Main objectives]
|
||||
```
|
||||
|
||||
## Updating Implementation Plan
|
||||
|
||||
### Progress Indicators
|
||||
|
||||
Update plan page regularly:
|
||||
|
||||
```markdown
|
||||
## Status Overview
|
||||
|
||||
**Overall Progress**: 45% complete
|
||||
|
||||
### Phase Status
|
||||
- ✅ Phase 1: Foundation - Complete
|
||||
- 🔄 Phase 2: Core Features - In Progress (60%)
|
||||
- ⏳ Phase 3: Integration - Not Started
|
||||
|
||||
### Task Summary
|
||||
- ✅ Completed: 12 tasks
|
||||
- 🔄 In Progress: 5 tasks
|
||||
- 🚧 Blocked: 1 task
|
||||
- ⏳ Not Started: 8 tasks
|
||||
|
||||
**Last Updated**: [Date]
|
||||
```
|
||||
|
||||
### Task Checklist Updates
|
||||
|
||||
Mark completed tasks:
|
||||
|
||||
```markdown
|
||||
## Implementation Phases
|
||||
|
||||
### Phase 1: Foundation
|
||||
- [x] <mention-page url="...">Database schema</mention-page>
|
||||
- [x] <mention-page url="...">API scaffolding</mention-page>
|
||||
- [x] <mention-page url="...">Auth setup</mention-page>
|
||||
|
||||
### Phase 2: Core Features
|
||||
- [x] <mention-page url="...">User management</mention-page>
|
||||
- [ ] <mention-page url="...">Dashboard</mention-page>
|
||||
- [ ] <mention-page url="...">Reporting</mention-page>
|
||||
```
|
||||
|
||||
### Timeline Updates
|
||||
|
||||
Update milestone dates:
|
||||
|
||||
```markdown
|
||||
## Timeline
|
||||
|
||||
| Milestone | Original | Current | Status |
|
||||
|-----------|----------|---------|--------|
|
||||
| Phase 1 | Oct 15 | Oct 14 | ✅ Complete (1 day early) |
|
||||
| Phase 2 | Oct 30 | Nov 2 | 🔄 In Progress (3 days delay) |
|
||||
| Phase 3 | Nov 15 | Nov 18 | ⏳ Planned (adjusted) |
|
||||
| Launch | Nov 20 | Nov 22 | ⏳ Planned (adjusted) |
|
||||
|
||||
**Timeline Status**: Slightly behind due to [reason]
|
||||
```
|
||||
|
||||
## Task Status Tracking
|
||||
|
||||
### Status Definitions
|
||||
|
||||
**To Do**: Not started
|
||||
- Task is ready to begin
|
||||
- Dependencies met
|
||||
- Assigned (or available)
|
||||
|
||||
**In Progress**: Actively being worked
|
||||
- Work has started
|
||||
- Assigned to someone
|
||||
- Regular updates expected
|
||||
|
||||
**Blocked**: Cannot proceed
|
||||
- Dependency not met
|
||||
- External blocker
|
||||
- Waiting on decision/resource
|
||||
|
||||
**In Review**: Awaiting review
|
||||
- Work complete from implementer perspective
|
||||
- Needs code review, QA, or approval
|
||||
- Reviewers identified
|
||||
|
||||
**Done**: Complete
|
||||
- All acceptance criteria met
|
||||
- Reviewed and approved
|
||||
- Deployed/delivered
|
||||
|
||||
### Updating Task Status
|
||||
|
||||
When updating:
|
||||
|
||||
```
|
||||
1. Update Status property
|
||||
2. Add progress note explaining change
|
||||
3. Update related tasks if needed
|
||||
4. Notify relevant people via comment
|
||||
|
||||
Example:
|
||||
properties: { "Status": "In Progress" }
|
||||
|
||||
Content update:
|
||||
## Progress: Oct 14, 2025
|
||||
Started implementation. Set up basic structure and wrote initial tests.
|
||||
```
|
||||
|
||||
## Blocker Tracking
|
||||
|
||||
### Recording Blockers
|
||||
|
||||
When encountering a blocker:
|
||||
|
||||
```markdown
|
||||
## Blockers
|
||||
|
||||
### [Date]: [Blocker Description]
|
||||
**Status**: 🚧 Active
|
||||
**Impact**: [What's blocked]
|
||||
**Needed to unblock**: [Action/person/decision needed]
|
||||
**Owner**: [Who's responsible for unblocking]
|
||||
**Target resolution**: [Date or timeframe]
|
||||
```
|
||||
|
||||
### Resolving Blockers
|
||||
|
||||
When unblocked:
|
||||
|
||||
```markdown
|
||||
## Blockers
|
||||
|
||||
### [Date]: [Blocker Description]
|
||||
**Status**: ✅ Resolved on [Date]
|
||||
**Resolution**: [How it was resolved]
|
||||
**Impact**: [Any timeline/scope impact]
|
||||
```
|
||||
|
||||
### Escalating Blockers
|
||||
|
||||
If blocker needs escalation:
|
||||
|
||||
```
|
||||
1. Update blocker status in task
|
||||
2. Add comment tagging stakeholder
|
||||
3. Update plan with blocker impact
|
||||
4. Propose mitigation if possible
|
||||
```
|
||||
|
||||
## Metrics Tracking
|
||||
|
||||
### Velocity Tracking
|
||||
|
||||
Track completion rate:
|
||||
|
||||
```markdown
|
||||
## Velocity
|
||||
|
||||
### Week 1
|
||||
- Tasks completed: 8
|
||||
- Story points: 21
|
||||
- Velocity: Strong
|
||||
|
||||
### Week 2
|
||||
- Tasks completed: 6
|
||||
- Story points: 18
|
||||
- Velocity: Moderate (1 blocker)
|
||||
|
||||
### Week 3
|
||||
- Tasks completed: 9
|
||||
- Story points: 24
|
||||
- Velocity: Strong (blocker resolved)
|
||||
```
|
||||
|
||||
### Quality Metrics
|
||||
|
||||
Track quality indicators:
|
||||
|
||||
```markdown
|
||||
## Quality Metrics
|
||||
|
||||
- Test coverage: 87%
|
||||
- Code review approval rate: 95%
|
||||
- Bug count: 3 (2 minor, 1 cosmetic)
|
||||
- Performance: All targets met
|
||||
- Security: No issues found
|
||||
```
|
||||
|
||||
### Progress Metrics
|
||||
|
||||
Quantitative progress:
|
||||
|
||||
```markdown
|
||||
## Progress Metrics
|
||||
|
||||
- Requirements implemented: 15/20 (75%)
|
||||
- Acceptance criteria met: 42/56 (75%)
|
||||
- Test cases passing: 128/135 (95%)
|
||||
- Code complete: 80%
|
||||
- Documentation: 60%
|
||||
```
|
||||
|
||||
## Stakeholder Communication
|
||||
|
||||
### Weekly Status Report
|
||||
|
||||
```markdown
|
||||
## Weekly Status: [Week of Date]
|
||||
|
||||
### Summary
|
||||
[One paragraph overview of progress and status]
|
||||
|
||||
### This Week's Accomplishments
|
||||
- [Key accomplishment]
|
||||
- [Key accomplishment]
|
||||
- [Key accomplishment]
|
||||
|
||||
### Next Week's Plan
|
||||
- [Planned work]
|
||||
- [Planned work]
|
||||
|
||||
### Status
|
||||
- On track / At risk / Behind schedule
|
||||
- [If at risk or behind, explain and provide mitigation plan]
|
||||
|
||||
### Blockers & Needs
|
||||
- [Active blocker or need for help]
|
||||
- Or: None
|
||||
|
||||
### Risks
|
||||
- [New or evolving risk]
|
||||
- Or: None currently identified
|
||||
```
|
||||
|
||||
### Executive Summary
|
||||
|
||||
For leadership updates:
|
||||
|
||||
```markdown
|
||||
## Implementation Status: [Feature Name]
|
||||
|
||||
**Overall Status**: 🟢 On Track / 🟡 At Risk / 🔴 Behind
|
||||
|
||||
**Progress**: [X]% complete
|
||||
|
||||
**Key Updates**:
|
||||
- [Most important update]
|
||||
- [Most important update]
|
||||
|
||||
**Timeline**: [Status vs original plan]
|
||||
|
||||
**Risks**: [Top 1-2 risks]
|
||||
|
||||
**Next Milestone**: [Upcoming milestone and date]
|
||||
```
|
||||
|
||||
## Automated Progress Tracking
|
||||
|
||||
### Query-Based Status
|
||||
|
||||
Generate status from task database:
|
||||
|
||||
```
|
||||
Query task database:
|
||||
SELECT
|
||||
"Status",
|
||||
COUNT(*) as count
|
||||
FROM "collection://tasks-uuid"
|
||||
WHERE "Related Tasks" CONTAINS 'plan-page-id'
|
||||
GROUP BY "Status"
|
||||
|
||||
Generate summary:
|
||||
- To Do: 8
|
||||
- In Progress: 5
|
||||
- Blocked: 1
|
||||
- In Review: 2
|
||||
- Done: 12
|
||||
|
||||
Overall: 44% complete (12/28 tasks)
|
||||
```
|
||||
|
||||
### Timeline Calculation
|
||||
|
||||
Calculate projected completion:
|
||||
|
||||
```
|
||||
Average velocity: 6 tasks/week
|
||||
Remaining tasks: 14
|
||||
Projected completion: 2.3 weeks from now
|
||||
|
||||
Compares to target: [On schedule/Behind/Ahead]
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Update regularly**: Don't let updates pile up
|
||||
2. **Be specific**: "Completed login" vs "Made progress"
|
||||
3. **Quantify progress**: Use percentages, counts, metrics
|
||||
4. **Note blockers immediately**: Don't wait to report blockers
|
||||
5. **Link to work**: Reference PRs, deployments, demos
|
||||
6. **Track decisions**: Document why, not just what
|
||||
7. **Be honest**: Report actual status, not optimistic status
|
||||
8. **Update in one place**: Keep implementation plan as source of truth
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
# Progress Update Template
|
||||
|
||||
Use this to update progress on implementation plans and tasks.
|
||||
|
||||
```markdown
|
||||
## Progress: [Date]
|
||||
|
||||
### Completed Today
|
||||
- [Specific item completed]
|
||||
- [Specific item completed]
|
||||
|
||||
### In Progress
|
||||
- [Current work item and status]
|
||||
|
||||
### Next Steps
|
||||
1. [Next action]
|
||||
2. [Next action]
|
||||
|
||||
### Blockers
|
||||
- [Blocker description] or None
|
||||
|
||||
### Notes
|
||||
[Additional context, decisions made, issues encountered]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
# Quick Implementation Plan Template
|
||||
|
||||
For simpler features or small changes.
|
||||
|
||||
```markdown
|
||||
# Implementation: [Feature Name]
|
||||
|
||||
## Spec
|
||||
<mention-page url="...">Specification</mention-page>
|
||||
|
||||
## Summary
|
||||
[Quick description]
|
||||
|
||||
## Tasks
|
||||
- [ ] <mention-page url="...">Task 1</mention-page>
|
||||
- [ ] <mention-page url="...">Task 2</mention-page>
|
||||
- [ ] <mention-page url="...">Task 3</mention-page>
|
||||
|
||||
## Timeline
|
||||
Start: [Date]
|
||||
Target completion: [Date]
|
||||
|
||||
## Status
|
||||
[Update as work progresses]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,383 @@
|
||||
# Specification Parsing
|
||||
|
||||
## Finding the Specification
|
||||
|
||||
Before parsing, locate the spec page:
|
||||
|
||||
```
|
||||
1. Search for spec:
|
||||
Notion:notion-search
|
||||
query: "[Feature Name] spec" or "[Feature Name] specification"
|
||||
|
||||
2. Handle results:
|
||||
- If found → use page URL/ID
|
||||
- If multiple → ask user which one
|
||||
- If not found → ask user for URL/ID
|
||||
|
||||
Example:
|
||||
Notion:notion-search
|
||||
query: "User Profile API spec"
|
||||
query_type: "internal"
|
||||
```
|
||||
|
||||
## Reading Specifications
|
||||
|
||||
After finding the spec, fetch it with `Notion:notion-fetch`:
|
||||
|
||||
1. Read the full content
|
||||
2. Identify key sections
|
||||
3. Extract structured information
|
||||
4. Note ambiguities or gaps
|
||||
|
||||
```
|
||||
Notion:notion-fetch
|
||||
id: "spec-page-id-from-search"
|
||||
```
|
||||
|
||||
## Common Spec Structures
|
||||
|
||||
### Requirements-Based Spec
|
||||
|
||||
```
|
||||
# Feature Spec
|
||||
## Overview
|
||||
[Feature description]
|
||||
|
||||
## Requirements
|
||||
### Functional
|
||||
- REQ-1: [Requirement]
|
||||
- REQ-2: [Requirement]
|
||||
|
||||
### Non-Functional
|
||||
- PERF-1: [Performance requirement]
|
||||
- SEC-1: [Security requirement]
|
||||
|
||||
## Acceptance Criteria
|
||||
- AC-1: [Criterion]
|
||||
- AC-2: [Criterion]
|
||||
```
|
||||
|
||||
Extract:
|
||||
- List of functional requirements
|
||||
- List of non-functional requirements
|
||||
- List of acceptance criteria
|
||||
|
||||
### User Story Based Spec
|
||||
|
||||
```
|
||||
# Feature Spec
|
||||
## User Stories
|
||||
### As a [user type]
|
||||
I want [goal]
|
||||
So that [benefit]
|
||||
|
||||
**Acceptance Criteria**:
|
||||
- [Criterion]
|
||||
- [Criterion]
|
||||
```
|
||||
|
||||
Extract:
|
||||
- User personas
|
||||
- Goals/capabilities needed
|
||||
- Acceptance criteria per story
|
||||
|
||||
### Technical Design Doc
|
||||
|
||||
```
|
||||
# Technical Design
|
||||
## Problem Statement
|
||||
[Problem description]
|
||||
|
||||
## Proposed Solution
|
||||
[Solution approach]
|
||||
|
||||
## Architecture
|
||||
[Architecture details]
|
||||
|
||||
## Implementation Plan
|
||||
[Implementation approach]
|
||||
```
|
||||
|
||||
Extract:
|
||||
- Problem being solved
|
||||
- Proposed solution approach
|
||||
- Architectural decisions
|
||||
- Implementation guidance
|
||||
|
||||
### Product Requirements Document (PRD)
|
||||
|
||||
```
|
||||
# PRD: [Feature]
|
||||
## Goals
|
||||
[Business goals]
|
||||
|
||||
## User Needs
|
||||
[User problems being solved]
|
||||
|
||||
## Features
|
||||
[Feature list]
|
||||
|
||||
## Success Metrics
|
||||
[How to measure success]
|
||||
```
|
||||
|
||||
Extract:
|
||||
- Business goals
|
||||
- User needs
|
||||
- Feature list
|
||||
- Success metrics
|
||||
|
||||
## Extraction Strategies
|
||||
|
||||
### Requirement Identification
|
||||
|
||||
Look for:
|
||||
- "Must", "Should", "Will" statements
|
||||
- Numbered requirements (REQ-1, etc.)
|
||||
- User stories (As a... I want...)
|
||||
- Acceptance criteria sections
|
||||
- Feature lists
|
||||
|
||||
### Categorization
|
||||
|
||||
Group requirements by:
|
||||
|
||||
**Functional**: What the system does
|
||||
- User capabilities
|
||||
- System behaviors
|
||||
- Data operations
|
||||
|
||||
**Non-Functional**: How the system performs
|
||||
- Performance targets
|
||||
- Security requirements
|
||||
- Scalability needs
|
||||
- Availability requirements
|
||||
- Compliance requirements
|
||||
|
||||
**Constraints**: Limitations
|
||||
- Technical constraints
|
||||
- Business constraints
|
||||
- Timeline constraints
|
||||
|
||||
### Priority Extraction
|
||||
|
||||
Identify priority indicators:
|
||||
- "Critical", "Must have", "P0"
|
||||
- "Important", "Should have", "P1"
|
||||
- "Nice to have", "Could have", "P2"
|
||||
- "Future", "Won't have", "P3"
|
||||
|
||||
Map to implementation phases based on priority.
|
||||
|
||||
## Handling Ambiguity
|
||||
|
||||
### Unclear Requirements
|
||||
|
||||
When requirement is ambiguous:
|
||||
|
||||
```markdown
|
||||
## Clarifications Needed
|
||||
|
||||
### [Requirement ID/Description]
|
||||
**Current text**: "[Ambiguous requirement]"
|
||||
**Question**: [What needs clarification]
|
||||
**Impact**: [Why this matters for implementation]
|
||||
**Assumed for now**: [Working assumption if any]
|
||||
```
|
||||
|
||||
Create clarification task or add comment to spec.
|
||||
|
||||
### Missing Information
|
||||
|
||||
When critical info is missing:
|
||||
|
||||
```markdown
|
||||
## Missing Information
|
||||
|
||||
- **[Topic]**: Spec doesn't specify [what's missing]
|
||||
- **Impact**: Blocks [affected tasks]
|
||||
- **Action**: Need to [how to resolve]
|
||||
```
|
||||
|
||||
### Conflicting Requirements
|
||||
|
||||
When requirements conflict:
|
||||
|
||||
```markdown
|
||||
## Conflicting Requirements
|
||||
|
||||
**Conflict**: REQ-1 says [X] but REQ-5 says [Y]
|
||||
**Impact**: [Implementation impact]
|
||||
**Resolution needed**: [Decision needed]
|
||||
```
|
||||
|
||||
## Acceptance Criteria Parsing
|
||||
|
||||
### Explicit Criteria
|
||||
|
||||
Direct acceptance criteria:
|
||||
|
||||
```
|
||||
## Acceptance Criteria
|
||||
- User can log in with email and password
|
||||
- System sends confirmation email
|
||||
- Session expires after 24 hours
|
||||
```
|
||||
|
||||
Convert to checklist:
|
||||
- [ ] User can log in with email and password
|
||||
- [ ] System sends confirmation email
|
||||
- [ ] Session expires after 24 hours
|
||||
|
||||
### Implicit Criteria
|
||||
|
||||
Derive from requirements:
|
||||
|
||||
```
|
||||
Requirement: "Users can upload files up to 100MB"
|
||||
|
||||
Implied acceptance criteria:
|
||||
- [ ] Files up to 100MB upload successfully
|
||||
- [ ] Files over 100MB are rejected with error message
|
||||
- [ ] Progress indicator shows during upload
|
||||
- [ ] Upload can be cancelled
|
||||
```
|
||||
|
||||
### Testable Criteria
|
||||
|
||||
Ensure criteria are testable:
|
||||
|
||||
❌ **Not testable**: "System is fast"
|
||||
✓ **Testable**: "Page loads in < 2 seconds"
|
||||
|
||||
❌ **Not testable**: "Users like the interface"
|
||||
✓ **Testable**: "90% of test users complete task successfully"
|
||||
|
||||
## Technical Detail Extraction
|
||||
|
||||
### Architecture Information
|
||||
|
||||
Extract:
|
||||
- System components
|
||||
- Data models
|
||||
- APIs/interfaces
|
||||
- Integration points
|
||||
- Technology choices
|
||||
|
||||
### Design Decisions
|
||||
|
||||
Note:
|
||||
- Technology selections
|
||||
- Architecture patterns
|
||||
- Trade-offs made
|
||||
- Rationale provided
|
||||
|
||||
### Implementation Guidance
|
||||
|
||||
Look for:
|
||||
- Suggested approach
|
||||
- Code examples
|
||||
- Library recommendations
|
||||
- Best practices mentioned
|
||||
|
||||
## Dependency Identification
|
||||
|
||||
### External Dependencies
|
||||
|
||||
From spec, identify:
|
||||
- Third-party services required
|
||||
- External APIs needed
|
||||
- Infrastructure requirements
|
||||
- Tool/library dependencies
|
||||
|
||||
### Internal Dependencies
|
||||
|
||||
Identify:
|
||||
- Other features needed first
|
||||
- Shared components required
|
||||
- Team dependencies
|
||||
- Data dependencies
|
||||
|
||||
### Timeline Dependencies
|
||||
|
||||
Note:
|
||||
- Hard deadlines
|
||||
- Milestone dependencies
|
||||
- Sequencing requirements
|
||||
|
||||
## Scope Extraction
|
||||
|
||||
### In Scope
|
||||
|
||||
What's explicitly included:
|
||||
- Features to build
|
||||
- Use cases to support
|
||||
- Users/personas to serve
|
||||
|
||||
### Out of Scope
|
||||
|
||||
What's explicitly excluded:
|
||||
- Features deferred
|
||||
- Use cases not supported
|
||||
- Edge cases not handled
|
||||
|
||||
### Assumptions
|
||||
|
||||
What's assumed:
|
||||
- Environment assumptions
|
||||
- User assumptions
|
||||
- System state assumptions
|
||||
|
||||
## Risk Identification
|
||||
|
||||
Extract risk information:
|
||||
|
||||
### Technical Risks
|
||||
- Unproven technology
|
||||
- Complex integration
|
||||
- Performance concerns
|
||||
- Scalability unknowns
|
||||
|
||||
### Business Risks
|
||||
- Market timing
|
||||
- Resource availability
|
||||
- Dependency on others
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
Note any mitigation approaches mentioned in spec.
|
||||
|
||||
## Spec Quality Assessment
|
||||
|
||||
Evaluate spec completeness:
|
||||
|
||||
✓ **Good spec**:
|
||||
- Clear requirements
|
||||
- Explicit acceptance criteria
|
||||
- Priorities defined
|
||||
- Risks identified
|
||||
- Technical approach outlined
|
||||
|
||||
⚠️ **Incomplete spec**:
|
||||
- Vague requirements
|
||||
- Missing acceptance criteria
|
||||
- Unclear priorities
|
||||
- No risk analysis
|
||||
- Technical details absent
|
||||
|
||||
Document gaps and create clarification tasks.
|
||||
|
||||
## Parsing Checklist
|
||||
|
||||
Before creating implementation plan:
|
||||
|
||||
☐ All functional requirements identified
|
||||
☐ Non-functional requirements noted
|
||||
☐ Acceptance criteria extracted
|
||||
☐ Dependencies identified
|
||||
☐ Risks noted
|
||||
☐ Ambiguities documented
|
||||
☐ Technical approach understood
|
||||
☐ Scope is clear
|
||||
☐ Priorities are defined
|
||||
|
||||
@@ -0,0 +1,146 @@
|
||||
# Standard Implementation Plan Template
|
||||
|
||||
Use this template for most feature implementations.
|
||||
|
||||
```markdown
|
||||
# Implementation Plan: [Feature Name]
|
||||
|
||||
## Overview
|
||||
[1-2 sentence feature description and business value]
|
||||
|
||||
## Linked Specification
|
||||
<mention-page url="...">Original Specification</mention-page>
|
||||
|
||||
## Requirements Summary
|
||||
|
||||
### Functional Requirements
|
||||
- [Requirement 1]
|
||||
- [Requirement 2]
|
||||
- [Requirement 3]
|
||||
|
||||
### Non-Functional Requirements
|
||||
- **Performance**: [Targets]
|
||||
- **Security**: [Requirements]
|
||||
- **Scalability**: [Needs]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] [Criterion 1]
|
||||
- [ ] [Criterion 2]
|
||||
- [ ] [Criterion 3]
|
||||
|
||||
## Technical Approach
|
||||
|
||||
### Architecture
|
||||
[High-level architectural decisions]
|
||||
|
||||
### Technology Stack
|
||||
- Backend: [Technologies]
|
||||
- Frontend: [Technologies]
|
||||
- Infrastructure: [Technologies]
|
||||
|
||||
### Key Design Decisions
|
||||
1. **[Decision]**: [Rationale]
|
||||
2. **[Decision]**: [Rationale]
|
||||
|
||||
## Implementation Phases
|
||||
|
||||
### Phase 1: Foundation (Week 1)
|
||||
**Goal**: Set up core infrastructure
|
||||
|
||||
**Tasks**:
|
||||
- [ ] <mention-page url="...">Database schema design</mention-page>
|
||||
- [ ] <mention-page url="...">API scaffolding</mention-page>
|
||||
- [ ] <mention-page url="...">Authentication setup</mention-page>
|
||||
|
||||
**Deliverables**: Working API skeleton
|
||||
**Estimated effort**: 3 days
|
||||
|
||||
### Phase 2: Core Features (Week 2-3)
|
||||
**Goal**: Implement main functionality
|
||||
|
||||
**Tasks**:
|
||||
- [ ] <mention-page url="...">Feature A implementation</mention-page>
|
||||
- [ ] <mention-page url="...">Feature B implementation</mention-page>
|
||||
|
||||
**Deliverables**: Core features working
|
||||
**Estimated effort**: 1 week
|
||||
|
||||
### Phase 3: Integration & Polish (Week 4)
|
||||
**Goal**: Complete integration and refinement
|
||||
|
||||
**Tasks**:
|
||||
- [ ] <mention-page url="...">Frontend integration</mention-page>
|
||||
- [ ] <mention-page url="...">Testing & QA</mention-page>
|
||||
|
||||
**Deliverables**: Production-ready feature
|
||||
**Estimated effort**: 1 week
|
||||
|
||||
## Dependencies
|
||||
|
||||
### External Dependencies
|
||||
- [Dependency 1]: [Status]
|
||||
- [Dependency 2]: [Status]
|
||||
|
||||
### Internal Dependencies
|
||||
- [Team/component dependency]
|
||||
|
||||
### Blockers
|
||||
- [Known blocker] or None currently
|
||||
|
||||
## Risks & Mitigation
|
||||
|
||||
### Risk 1: [Description]
|
||||
- **Probability**: High/Medium/Low
|
||||
- **Impact**: High/Medium/Low
|
||||
- **Mitigation**: [Strategy]
|
||||
|
||||
### Risk 2: [Description]
|
||||
- **Probability**: High/Medium/Low
|
||||
- **Impact**: High/Medium/Low
|
||||
- **Mitigation**: [Strategy]
|
||||
|
||||
## Timeline
|
||||
|
||||
| Milestone | Target Date | Status |
|
||||
|-----------|-------------|--------|
|
||||
| Phase 1 Complete | [Date] | ⏳ Planned |
|
||||
| Phase 2 Complete | [Date] | ⏳ Planned |
|
||||
| Phase 3 Complete | [Date] | ⏳ Planned |
|
||||
| Launch | [Date] | ⏳ Planned |
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Technical Success
|
||||
- [ ] All acceptance criteria met
|
||||
- [ ] Performance targets achieved
|
||||
- [ ] Security requirements satisfied
|
||||
- [ ] Test coverage > 80%
|
||||
|
||||
### Business Success
|
||||
- [ ] [Business metric 1]
|
||||
- [ ] [Business metric 2]
|
||||
|
||||
## Resources
|
||||
|
||||
### Documentation
|
||||
- <mention-page url="...">Design Doc</mention-page>
|
||||
- <mention-page url="...">API Spec</mention-page>
|
||||
|
||||
### Related Work
|
||||
- <mention-page url="...">Related Feature</mention-page>
|
||||
|
||||
## Progress Tracking
|
||||
|
||||
[This section updated regularly]
|
||||
|
||||
### Phase Status
|
||||
- Phase 1: ⏳ Not Started
|
||||
- Phase 2: ⏳ Not Started
|
||||
- Phase 3: ⏳ Not Started
|
||||
|
||||
**Overall Progress**: 0% complete
|
||||
|
||||
### Latest Update: [Date]
|
||||
[Brief status update]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
# Task Creation Template
|
||||
|
||||
When creating tasks from spec.
|
||||
|
||||
```markdown
|
||||
# [Task Name]
|
||||
|
||||
## Context
|
||||
Part of implementation for <mention-page url="...">Feature Spec</mention-page>
|
||||
|
||||
Implementation plan: <mention-page url="...">Implementation Plan</mention-page>
|
||||
|
||||
## Description
|
||||
[What needs to be done]
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] [Criterion 1]
|
||||
- [ ] [Criterion 2]
|
||||
|
||||
## Technical Details
|
||||
[Technical approach or notes]
|
||||
|
||||
## Dependencies
|
||||
- Blocked by: [Task] or None
|
||||
- Blocks: [Task] or None
|
||||
|
||||
## Resources
|
||||
- [Link to design]
|
||||
- [Link to related code]
|
||||
|
||||
## Progress
|
||||
[To be updated during implementation]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,441 @@
|
||||
# Task Creation from Specs
|
||||
|
||||
## Finding the Task Database
|
||||
|
||||
Before creating tasks, locate the task database:
|
||||
|
||||
```
|
||||
1. Search for task database:
|
||||
Notion:notion-search
|
||||
query: "Tasks" or "Task Management" or "[Project] Tasks"
|
||||
|
||||
2. Fetch database schema:
|
||||
Notion:notion-fetch
|
||||
id: "database-id-from-search"
|
||||
|
||||
3. Identify data source:
|
||||
- Look for <data-source url="collection://..."> tags
|
||||
- Extract collection ID for parent parameter
|
||||
|
||||
4. Note schema:
|
||||
- Required properties
|
||||
- Property types and options
|
||||
- Relation properties for linking
|
||||
|
||||
Example:
|
||||
Notion:notion-search
|
||||
query: "Engineering Tasks"
|
||||
query_type: "internal"
|
||||
|
||||
Notion:notion-fetch
|
||||
id: "tasks-database-id"
|
||||
```
|
||||
|
||||
Result: `collection://abc-123-def` for use as parent
|
||||
|
||||
## Task Breakdown Strategy
|
||||
|
||||
### Size Guidelines
|
||||
|
||||
**Good task size**:
|
||||
- Completable in 1-2 days
|
||||
- Single clear deliverable
|
||||
- Independently testable
|
||||
- Minimal dependencies
|
||||
|
||||
**Too large**:
|
||||
- Takes > 3 days
|
||||
- Multiple deliverables
|
||||
- Many dependencies
|
||||
- Break down further
|
||||
|
||||
**Too small**:
|
||||
- Takes < 2 hours
|
||||
- Too granular
|
||||
- Group with related work
|
||||
|
||||
### Granularity by Phase
|
||||
|
||||
**Early phases**: Larger tasks acceptable
|
||||
- "Design database schema"
|
||||
- "Set up API structure"
|
||||
|
||||
**Middle phases**: Medium-sized tasks
|
||||
- "Implement user authentication"
|
||||
- "Build dashboard UI"
|
||||
|
||||
**Late phases**: Smaller, precise tasks
|
||||
- "Fix validation bug in form"
|
||||
- "Add loading state to button"
|
||||
|
||||
## Task Creation Pattern
|
||||
|
||||
For each requirement or work item:
|
||||
|
||||
```
|
||||
1. Identify the work
|
||||
2. Determine task size
|
||||
3. Create task in database
|
||||
4. Set properties
|
||||
5. Write task description
|
||||
6. Link to spec/plan
|
||||
```
|
||||
|
||||
### Creating Task
|
||||
|
||||
```
|
||||
Use Notion:notion-create-pages:
|
||||
|
||||
parent: {
|
||||
type: "data_source_id",
|
||||
data_source_id: "collection://tasks-db-uuid"
|
||||
}
|
||||
|
||||
properties: {
|
||||
"[Title Property]": "Task: [Clear task name]",
|
||||
"Status": "To Do",
|
||||
"Priority": "[High/Medium/Low]",
|
||||
"[Project/Related]": ["spec-page-id", "plan-page-id"],
|
||||
"Assignee": "[Person]" (if known),
|
||||
"date:Due Date:start": "[Date]" (if applicable),
|
||||
"date:Due Date:is_datetime": 0
|
||||
}
|
||||
|
||||
content: "[Task description using template]"
|
||||
```
|
||||
|
||||
## Task Description Template
|
||||
|
||||
```markdown
|
||||
# [Task Name]
|
||||
|
||||
## Context
|
||||
Implementation task for <mention-page url="...">Feature Spec</mention-page>
|
||||
|
||||
Part of <mention-page url="...">Implementation Plan</mention-page> - Phase [N]
|
||||
|
||||
## Objective
|
||||
[What this task accomplishes]
|
||||
|
||||
## Requirements
|
||||
Based on spec requirements:
|
||||
- [Relevant requirement 1]
|
||||
- [Relevant requirement 2]
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] [Specific, testable criterion]
|
||||
- [ ] [Specific, testable criterion]
|
||||
- [ ] [Specific, testable criterion]
|
||||
|
||||
## Technical Approach
|
||||
[Suggested implementation approach]
|
||||
|
||||
### Components Affected
|
||||
- [Component 1]
|
||||
- [Component 2]
|
||||
|
||||
### Key Decisions
|
||||
- [Decision point 1]
|
||||
- [Decision point 2]
|
||||
|
||||
## Dependencies
|
||||
|
||||
### Blocked By
|
||||
- <mention-page url="...">Prerequisite Task</mention-page> or None
|
||||
|
||||
### Blocks
|
||||
- <mention-page url="...">Dependent Task</mention-page> or None
|
||||
|
||||
## Resources
|
||||
- [Link to design mockup]
|
||||
- [Link to API spec]
|
||||
- [Link to relevant code]
|
||||
|
||||
## Estimated Effort
|
||||
[Time estimate]
|
||||
|
||||
## Progress
|
||||
[To be updated during implementation]
|
||||
```
|
||||
|
||||
## Task Types
|
||||
|
||||
### Infrastructure/Setup Tasks
|
||||
|
||||
```
|
||||
Title: "Setup: [What's being set up]"
|
||||
Examples:
|
||||
- "Setup: Configure database connection pool"
|
||||
- "Setup: Initialize authentication middleware"
|
||||
- "Setup: Create CI/CD pipeline"
|
||||
|
||||
Focus: Getting environment/tooling ready
|
||||
```
|
||||
|
||||
### Feature Implementation Tasks
|
||||
|
||||
```
|
||||
Title: "Implement: [Feature name]"
|
||||
Examples:
|
||||
- "Implement: User login flow"
|
||||
- "Implement: File upload functionality"
|
||||
- "Implement: Dashboard widget"
|
||||
|
||||
Focus: Building specific functionality
|
||||
```
|
||||
|
||||
### Integration Tasks
|
||||
|
||||
```
|
||||
Title: "Integrate: [What's being integrated]"
|
||||
Examples:
|
||||
- "Integrate: Connect frontend to API"
|
||||
- "Integrate: Add payment provider"
|
||||
- "Integrate: Link user profile to dashboard"
|
||||
|
||||
Focus: Connecting components
|
||||
```
|
||||
|
||||
### Testing Tasks
|
||||
|
||||
```
|
||||
Title: "Test: [What's being tested]"
|
||||
Examples:
|
||||
- "Test: Write unit tests for auth service"
|
||||
- "Test: E2E testing for checkout flow"
|
||||
- "Test: Performance testing for API"
|
||||
|
||||
Focus: Validation and quality assurance
|
||||
```
|
||||
|
||||
### Documentation Tasks
|
||||
|
||||
```
|
||||
Title: "Document: [What's being documented]"
|
||||
Examples:
|
||||
- "Document: API endpoints"
|
||||
- "Document: Setup instructions"
|
||||
- "Document: Architecture decisions"
|
||||
|
||||
Focus: Creating documentation
|
||||
```
|
||||
|
||||
### Bug Fix Tasks
|
||||
|
||||
```
|
||||
Title: "Fix: [Bug description]"
|
||||
Examples:
|
||||
- "Fix: Login error on Safari"
|
||||
- "Fix: Memory leak in image processing"
|
||||
- "Fix: Race condition in payment flow"
|
||||
|
||||
Focus: Resolving issues
|
||||
```
|
||||
|
||||
### Refactoring Tasks
|
||||
|
||||
```
|
||||
Title: "Refactor: [What's being refactored]"
|
||||
Examples:
|
||||
- "Refactor: Extract auth logic to service"
|
||||
- "Refactor: Optimize database queries"
|
||||
- "Refactor: Simplify component hierarchy"
|
||||
|
||||
Focus: Code quality improvement
|
||||
```
|
||||
|
||||
## Sequencing Tasks
|
||||
|
||||
### Critical Path
|
||||
|
||||
Identify must-happen-first tasks:
|
||||
|
||||
```
|
||||
1. Database schema
|
||||
2. API foundation
|
||||
3. Core business logic
|
||||
4. Frontend integration
|
||||
5. Testing
|
||||
6. Deployment
|
||||
```
|
||||
|
||||
### Parallel Tracks
|
||||
|
||||
Tasks that can happen simultaneously:
|
||||
|
||||
```
|
||||
Track A: Backend development
|
||||
- API endpoints
|
||||
- Business logic
|
||||
- Database operations
|
||||
|
||||
Track B: Frontend development
|
||||
- UI components
|
||||
- State management
|
||||
- Routing
|
||||
|
||||
Track C: Infrastructure
|
||||
- CI/CD setup
|
||||
- Monitoring
|
||||
- Documentation
|
||||
```
|
||||
|
||||
### Phase-Based Sequencing
|
||||
|
||||
Group by implementation phase:
|
||||
|
||||
```
|
||||
Phase 1 (Foundation):
|
||||
- Setup tasks
|
||||
- Infrastructure tasks
|
||||
|
||||
Phase 2 (Core):
|
||||
- Feature implementation tasks
|
||||
- Integration tasks
|
||||
|
||||
Phase 3 (Polish):
|
||||
- Testing tasks
|
||||
- Documentation tasks
|
||||
- Optimization tasks
|
||||
```
|
||||
|
||||
## Priority Assignment
|
||||
|
||||
### P0/Critical
|
||||
- Blocks everything else
|
||||
- Core functionality
|
||||
- Security requirements
|
||||
- Data integrity
|
||||
|
||||
### P1/High
|
||||
- Important features
|
||||
- User-facing functionality
|
||||
- Performance requirements
|
||||
|
||||
### P2/Medium
|
||||
- Nice-to-have features
|
||||
- Optimizations
|
||||
- Minor improvements
|
||||
|
||||
### P3/Low
|
||||
- Future enhancements
|
||||
- Edge case handling
|
||||
- Cosmetic improvements
|
||||
|
||||
## Estimation
|
||||
|
||||
### Story Points
|
||||
|
||||
If using story points:
|
||||
- 1 point: Few hours
|
||||
- 2 points: Half day
|
||||
- 3 points: Full day
|
||||
- 5 points: 2 days
|
||||
- 8 points: 3-4 days (consider breaking down)
|
||||
|
||||
### Time Estimates
|
||||
|
||||
Direct time estimates:
|
||||
- 2-4 hours: Small task
|
||||
- 1 day: Medium task
|
||||
- 2 days: Large task
|
||||
- 3+ days: Break down further
|
||||
|
||||
### Estimation Factors
|
||||
|
||||
Consider:
|
||||
- Complexity
|
||||
- Unknowns
|
||||
- Dependencies
|
||||
- Testing requirements
|
||||
- Documentation needs
|
||||
|
||||
## Task Relationships
|
||||
|
||||
### Parent Task Pattern
|
||||
|
||||
For large features:
|
||||
|
||||
```
|
||||
Parent: "Feature: User Authentication"
|
||||
Children:
|
||||
- "Setup: Configure auth library"
|
||||
- "Implement: Login flow"
|
||||
- "Implement: Password reset"
|
||||
- "Test: Auth functionality"
|
||||
```
|
||||
|
||||
### Dependency Chain Pattern
|
||||
|
||||
For sequential work:
|
||||
|
||||
```
|
||||
Task A: "Design database schema"
|
||||
↓ (blocks)
|
||||
Task B: "Implement data models"
|
||||
↓ (blocks)
|
||||
Task C: "Create API endpoints"
|
||||
↓ (blocks)
|
||||
Task D: "Integrate with frontend"
|
||||
```
|
||||
|
||||
### Related Tasks Pattern
|
||||
|
||||
For parallel work:
|
||||
|
||||
```
|
||||
Central: "Feature: Dashboard"
|
||||
Related:
|
||||
- "Backend API for dashboard data"
|
||||
- "Frontend dashboard component"
|
||||
- "Dashboard data caching"
|
||||
```
|
||||
|
||||
## Bulk Task Creation
|
||||
|
||||
When creating many tasks:
|
||||
|
||||
```
|
||||
For each work item in breakdown:
|
||||
1. Determine task properties
|
||||
2. Create task page
|
||||
3. Link to spec/plan
|
||||
4. Set relationships
|
||||
|
||||
Then:
|
||||
1. Update plan with task links
|
||||
2. Review sequencing
|
||||
3. Assign tasks (if known)
|
||||
```
|
||||
|
||||
## Task Naming Conventions
|
||||
|
||||
**Be specific**:
|
||||
✓ "Implement user login with email/password"
|
||||
✗ "Add login"
|
||||
|
||||
**Include context**:
|
||||
✓ "Dashboard: Add revenue chart widget"
|
||||
✗ "Add chart"
|
||||
|
||||
**Use action verbs**:
|
||||
- Implement, Build, Create
|
||||
- Integrate, Connect, Link
|
||||
- Fix, Resolve, Debug
|
||||
- Test, Validate, Verify
|
||||
- Document, Write, Update
|
||||
- Refactor, Optimize, Improve
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
Before finalizing tasks:
|
||||
|
||||
☐ Each task has clear objective
|
||||
☐ Acceptance criteria are testable
|
||||
☐ Dependencies identified
|
||||
☐ Appropriate size (1-2 days)
|
||||
☐ Priority assigned
|
||||
☐ Linked to spec/plan
|
||||
☐ Proper sequencing
|
||||
☐ Resources noted
|
||||
|
||||
Reference in New Issue
Block a user