Fetches sdd:add-task from neolabhq/context-engineering-kit and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/sdd:add-task
Restart Cursor to activate sdd:add-task. Access via /sdd:add-task in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
.specs/tasks/in-progress/ - Currently being worked on
.specs/tasks/done/ - Completed tasks
.specs/scratchpad/ - Temporary working files (gitignored)
2. Analyze Input
Parse the user's request:
Extract the core task objective
Identify implied type (bug, feature, task)
List of task files that this task depends on
Clarify if ambiguous (only if truly unclear):
Is this a bug fix or new feature?
Any related tasks or dependencies? (if not proided, then assume none)
3. Structure the Task
Create action-oriented title:
Start with verb: Add, Fix, Update, Implement, Remove, Refactor
Be specific but concise
Examples:
"Add validation to login form"
"Fix null pointer in user service"
"Implement caching for API responses"
Determine type:
Type
Use When
feature
New functionality or capability
bug
Something is broken or not working correctly
refactor
Code restructuring without changing behavior
test
Adding or updating tests
docs
Documentation changes only
chore
Maintenance tasks, dependency updates
ci
CI/CD configuration changes
4. Generate File Name
Create short name from the task title:
Lowercase the title
Replace spaces with hyphens
Remove special characters
Keep it concise (3-5 words max)
Example: "Add validation to login form" -> add-validation-login-form
Form file name: <short-name>.<issue-type>.md
Examples:
add-validation-login-form.feature.md
fix-null-pointer-user-service.bug.md
restructure-auth-module.refactor.md
add-unit-tests-api.test.md
update-readme.docs.md
upgrade-dependencies.chore.md
add-github-actions.ci.md
Verify uniqueness: Check .specs/tasks/draft/, .specs/tasks/todo/, .specs/tasks/in-progress/, and .specs/tasks/done/ for existing files with same name
5. Create Task File
Use Write tool to create .specs/tasks/todo/<short-name>.<issue-type>.md:
---title: <ACTION-ORIENTED TITLE>depends_on: <list of task files that this task depends on>---## Initial User Prompt{EXACT user input as provided}
## Description// Will be filled in future stages by business analyst
Constraints
Do NOT invoke the plan skill - the workflow handles subsequent phases
Do NOT create files outside .specs/tasks/draft/
Do NOT modify existing task files
Do NOT write description, only put // ... placeholder as specified in the task file.
Do NOT write depends_on section if no dependencies are provided.
Expected Output
Return to the orchestrator:
Task file path: Full path to created file (e.g., .specs/tasks/todo/add-validation-login-form.feature.md)
Generated title: The action-oriented title created
Issue type: task, bug, or feature
Format:
Created task file: .specs/tasks/draft/<name>.<type>.md
Title: <action-oriented title>
Type: <task|bug|feature>
Depends on: <list of task files that this task depends on>
Task file created in .specs/tasks/draft/ with correct naming convention (<name>.<type>.md)
File name is unique across all status folders (no overwriting existing files)
Depends on section is correct if dependencies are provided
Title starts with action verb (Add, Fix, Implement, Update, Remove, Refactor)
Type is correctly classified and reflected in file extension (.feature.md, .bug.md, .refactor.md, .test.md, .docs.md, .chore.md, .ci.md)
Original user input preserved in "Initial User Prompt" section
Description is empty placeholder // Will be filled in future stages by business analyst
Examples
Test task (.specs/tasks/draft/add-unit-tests-auth.test.md):
---title: Add unit tests for auth module---## Initial User Promptadd tests for auth
## Description// Will be filled in future stages by business analyst
Bug with context (.specs/tasks/draft/fix-login-timeout.bug.md):
---title: Fix login timeout on slow connections---## Initial User Promptusers getting 504 errors on slow wifi
## Description// Will be filled in future stages by business analyst
---title: Implement dark mode toggle---## Initial User Promptadd dark mode to settings page
## Description// Will be filled in future stages by business analyst
✓
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
