@soulcraft/kits 1.0.0

package/kits/product-requirements-doc/skills/acceptance-criteria/SKILL.md

@@ -0,0 +1,219 @@
+---
+id: acceptance-criteria
+name: acceptance-criteria
+description: Write clear, testable acceptance criteria for user stories
+version: "1.0.0"
+type: invocable
+requiresVision: false
+requiresData: false
+---
+
+## Acceptance Criteria Skill
+
+When the user invokes `/acceptance`, help them write clear, comprehensive acceptance criteria for user stories.
+
+### Invocation Patterns
+
+- `/acceptance` - Write criteria for current story
+- `/acceptance [story]` - Write criteria for specific story
+- `/acceptance review` - Review existing criteria
+- `/acceptance edge` - Generate edge case criteria
+
+### What Are Acceptance Criteria?
+
+**Definition**
+Conditions that must be met for a user story to be considered complete. They define the boundaries of a story and help verify correct implementation.
+
+**Purpose**
+- Define "done" clearly
+- Enable testing
+- Align team understanding
+- Prevent scope creep
+- Support estimation
+
+### Acceptance Criteria Formats
+
+**Given-When-Then (Gherkin)**
+```
+Given [precondition/context]
+When [action/trigger]
+Then [expected outcome]
+And [additional outcome]
+```
+
+**Checklist Format**
+```
+- [ ] [Condition 1 is met]
+- [ ] [Condition 2 is met]
+- [ ] [Behavior works as specified]
+```
+
+**Rule-Based Format**
+```
+Rule: [Business rule description]
+- Example: [Specific example of rule application]
+```
+
+### Output Format
+
+```markdown
+## Acceptance Criteria: [Story Title]
+
+### Story Reference
+**As a** [user],
+**I want to** [action],
+**So that** [benefit].
+
+---
+
+### Functional Criteria
+
+#### Scenario 1: [Happy Path - Primary Use Case]
+```gherkin
+Given [initial context]
+  And [additional context if needed]
+When [user action]
+Then [expected primary outcome]
+  And [expected secondary outcome]
+```
+
+#### Scenario 2: [Alternative Path]
+```gherkin
+Given [different context]
+When [user action]
+Then [different expected outcome]
+```
+
+#### Scenario 3: [Error Handling]
+```gherkin
+Given [context that leads to error]
+When [user action]
+Then [error handling behavior]
+  And [user sees appropriate message]
+```
+
+### Edge Cases
+
+#### Edge Case 1: [Description]
+```gherkin
+Given [edge case context]
+When [action]
+Then [expected behavior]
+```
+
+#### Edge Case 2: [Description]
+[Same format]
+
+### Business Rules
+| Rule | Description | Example |
+|------|-------------|---------|
+| [Rule 1] | [Description] | [Concrete example] |
+| [Rule 2] | [Description] | [Concrete example] |
+
+### Validation Rules
+| Field | Rule | Error Message |
+|-------|------|---------------|
+| [Field] | [Validation] | "[Message]" |
+| [Field] | [Validation] | "[Message]" |
+
+### Non-Functional Criteria
+- **Performance**: [Response time requirement]
+- **Accessibility**: [A11y requirements]
+- **Security**: [Security considerations]
+- **Compatibility**: [Browser/device requirements]
+
+### Out of Scope
+- [Explicitly excluded]
+- [Not covered in this story]
+
+### Test Coverage Checklist
+- [ ] Happy path tested
+- [ ] All validation rules tested
+- [ ] Error states tested
+- [ ] Edge cases tested
+- [ ] Boundary conditions tested
+```
+
+### Writing Effective Criteria
+
+**Be Specific**
+- Bad: "User sees error"
+- Good: "User sees 'Email already registered' message below email field"
+
+**Be Testable**
+- Bad: "Page loads quickly"
+- Good: "Page loads in under 2 seconds on 3G connection"
+
+**Be Complete**
+- Cover happy path
+- Cover error states
+- Cover edge cases
+- Define boundaries
+
+**Be Concise**
+- One behavior per criterion
+- No unnecessary words
+- Clear and direct
+
+### Types of Criteria to Include
+
+**Happy Path**
+- Primary successful flow
+- User achieves goal
+- Normal conditions
+
+**Alternative Paths**
+- Other valid ways to complete
+- Different user choices
+- Various input types
+
+**Error Paths**
+- Invalid input
+- System errors
+- Edge conditions
+
+**Boundary Conditions**
+- Minimum values
+- Maximum values
+- Empty states
+- Full states
+
+### Common Edge Cases
+
+**Input Validation**
+- Empty/blank input
+- Minimum length
+- Maximum length
+- Special characters
+- SQL injection attempts
+- XSS attempts
+
+**Data States**
+- First item
+- Last item
+- No items (empty state)
+- Many items (pagination)
+- Deleted items
+
+**User States**
+- Not logged in
+- Expired session
+- New user
+- Returning user
+- Admin vs. regular user
+
+**System States**
+- Slow connection
+- Offline
+- Server error
+- Concurrent users
+
+### Review Checklist
+
+- [ ] Every scenario is testable
+- [ ] Happy path is covered
+- [ ] Error handling is defined
+- [ ] Edge cases considered
+- [ ] Validation rules clear
+- [ ] No ambiguous language
+- [ ] Acceptance is binary (pass/fail)

package/kits/product-requirements-doc/skills/create-user-story/SKILL.md

@@ -0,0 +1,43 @@
+---
+id: create-user-story
+name: Create User Story
+description: Write a complete user story with acceptance criteria
+version: "1.0.0"
+type: invocable
+parameters: [persona, goal]
+requiresVision: false
+requiresData: false
+---
+
+## Create User Story
+
+Write a complete user story with acceptance criteria
+
+### Steps
+
+1. Identify the target persona for this story
+2. Define the user goal - what action or capability do they want?
+3. Articulate the benefit - why does this matter to them?
+4. Write the story: "As a [persona], I want [goal], so that [benefit]"
+5. Add acceptance criteria as a checklist of testable conditions
+6. Estimate complexity (story points) and identify dependencies
+7. Link to related research, designs, or technical considerations
+8. Create the story file in user-stories/ directory
+
+### Inputs Required
+
+- **persona** (required): Which user persona is this for?
+- **goal** (required): What does the user want to accomplish?
+
+### Expected Outputs
+
+- New user story file in user-stories/
+- Updated PRD with story reference
+
+### When to Use
+
+This workflow is helpful when the user mentions:
+- "new story"
+- "add user story"
+- "write story"
+- "create requirement"

package/kits/product-requirements-doc/skills/define-success-metrics/SKILL.md

@@ -0,0 +1,41 @@
+---
+id: define-success-metrics
+name: Define Success Metrics
+description: Create measurable success criteria for a feature
+version: "1.0.0"
+type: invocable
+parameters: [feature]
+requiresVision: false
+requiresData: false
+---
+
+## Define Success Metrics
+
+Create measurable success criteria for a feature
+
+### Steps
+
+1. Identify the user outcome this feature enables
+2. Choose leading indicators (behavior changes) and lagging indicators (outcomes)
+3. Define specific metrics with current baseline and target
+4. Ensure metrics are measurable with existing/planned instrumentation
+5. Set timeframe for measurement (e.g., "within 30 days of launch")
+6. Document how metric will be tracked and reported
+7. Add metrics to the PRD success criteria section
+
+### Inputs Required
+
+- **feature** (required): Which feature needs success metrics?
+
+### Expected Outputs
+
+- Success metrics table in PRD
+- Measurement plan
+
+### When to Use
+
+This workflow is helpful when the user mentions:
+- "success metrics"
+- "how to measure"
+- "KPIs"
+- "define success"

package/kits/product-requirements-doc/skills/kit-expertise/SKILL.md

@@ -0,0 +1,81 @@
+---
+id: kit-expertise
+name: kit-expertise
+description: Domain expertise for Product Requirements (PRD) - applied automatically when working in this kit
+version: "1.0.0"
+type: background
+requiresVision: false
+requiresData: false
+---
+
+## Your Role
+
+Product Manager helping you create clear, comprehensive product requirements documents
+
+## Your Expertise
+
+- Product requirements writing
+- User story creation
+- Feature prioritization
+- Success metrics definition
+- Stakeholder alignment
+- Scope management
+- Risk identification
+- Acceptance criteria
+
+## Your Approach
+
+Work alongside the user as a creative partner
+
+## Things to Avoid
+
+- Vague or unmeasurable requirements
+- Implementation details in requirements
+- Scope creep encouragement
+- Ignoring edge cases
+
+## Domain Knowledge
+
+### Key Terms
+
+**user story**
+Feature description from user perspective
+
+**acceptance criteria**
+Conditions for story completion
+
+**epic**
+Large feature containing multiple stories
+
+**MVP**
+Minimum viable product
+
+**scope**
+Boundaries of what's included/excluded
+
+**stakeholder**
+Person with interest in the product
+
+**success metric**
+Measurable outcome indicating success
+
+**priority**
+Relative importance (P0, P1, P2)
+
+### Best Practices
+
+- Write from user perspective
+- Include acceptance criteria
+- Define success metrics
+- Prioritize ruthlessly
+- Document assumptions
+- Identify dependencies
+
+### Common Mistakes to Avoid
+
+- Solution-focused requirements
+- Missing edge cases
+- Undefined success criteria
+- Assuming shared understanding
+- No prioritization
+- Scope without boundaries

package/kits/product-requirements-doc/skills/prd-review/SKILL.md

@@ -0,0 +1,39 @@
+---
+id: prd-review
+name: PRD Review
+description: Comprehensive review of product requirements document
+version: "1.0.0"
+type: invocable
+requiresVision: false
+requiresData: false
+---
+
+## PRD Review
+
+Comprehensive review of product requirements document
+
+### Steps
+
+1. Check problem statement: Is the problem clearly defined and validated?
+2. Review personas: Are target users well-defined?
+3. Validate user stories: Do they follow proper format with acceptance criteria?
+4. Check prioritization: Is it clear what's MVP vs. future?
+5. Review success metrics: Are they SMART?
+6. Validate non-goals: Is scope clearly bounded?
+7. Check for gaps: Missing edge cases, error states, accessibility?
+8. Review dependencies: Are blockers and risks documented?
+9. Ensure stakeholder alignment section is complete
+10. Generate review summary with recommendations
+
+### Expected Outputs
+
+- PRD review checklist
+- Recommendations for improvement
+
+### When to Use
+
+This workflow is helpful when the user mentions:
+- "review PRD"
+- "check requirements"
+- "PRD complete?"
+- "ready for dev?"

package/kits/product-requirements-doc/skills/prd-structure/SKILL.md

@@ -0,0 +1,206 @@
+---
+id: prd-structure
+name: prd-structure
+description: Background expertise in PRD best practices and structure
+version: "1.0.0"
+type: background
+requiresVision: false
+requiresData: false
+---
+
+## PRD Structure Expertise
+
+You have expertise in writing Product Requirements Documents. Apply these principles when helping users create comprehensive, actionable PRDs.
+
+### PRD Purpose
+
+**A good PRD answers:**
+- Why are we building this?
+- What are we building?
+- Who is it for?
+- How will we know if it's successful?
+
+**A PRD is NOT:**
+- Technical specification
+- UI design document
+- Project plan
+- Test plan
+
+### Standard PRD Structure
+
+**1. Overview**
+- Product name
+- Document status
+- Author and stakeholders
+- Last updated
+- Executive summary
+
+**2. Problem Statement**
+- What problem are we solving?
+- Who has this problem?
+- How do we know it's a problem?
+- What happens if we don't solve it?
+
+**3. Goals & Success Metrics**
+- Business goals
+- User goals
+- Key metrics (OKRs/KPIs)
+- Definition of success
+
+**4. User Personas**
+- Who are the users?
+- Brief persona summaries
+- Link to full personas
+
+**5. User Stories / Requirements**
+- Prioritized list of requirements
+- User stories with acceptance criteria
+- MoSCoW or priority levels
+
+**6. Scope**
+- In scope
+- Out of scope
+- Future considerations
+
+**7. Solution Overview**
+- High-level approach
+- Key user flows
+- Wireframes/mockups (links)
+
+**8. Technical Considerations**
+- Known constraints
+- Integration requirements
+- Performance requirements
+- Security requirements
+
+**9. Dependencies & Risks**
+- External dependencies
+- Known risks
+- Assumptions
+
+**10. Timeline & Milestones**
+- Key dates
+- Phased rollout plan
+- Release criteria
+
+**11. Open Questions**
+- Unresolved decisions
+- Research needed
+- Stakeholder input required
+
+**12. Appendix**
+- Supporting research
+- Competitive analysis
+- Additional documentation
+
+### Writing Quality Standards
+
+**Problem Statement**
+- Specific and measurable
+- Backed by data
+- User-focused
+- Not solution-focused
+
+**Goals**
+- SMART format
+- Measurable outcomes
+- Timebound where possible
+- Aligned with strategy
+
+**Requirements**
+- User stories format
+- Prioritized
+- Testable
+- Independent where possible
+
+**Scope**
+- Crystal clear boundaries
+- Explicit about exclusions
+- Addresses obvious questions
+
+### Prioritization Methods
+
+**MoSCoW**
+- **Must Have**: Required for launch
+- **Should Have**: Important but not critical
+- **Could Have**: Nice to have
+- **Won't Have**: Explicitly excluded (for now)
+
+**RICE**
+- Reach: How many users affected
+- Impact: How much effect
+- Confidence: How sure are we
+- Effort: How much work
+
+**Value vs. Effort**
+- Plot on 2x2 matrix
+- Quick wins (high value, low effort) first
+- Big bets (high value, high effort) next
+- Avoid low value items
+
+### Common PRD Mistakes
+
+**Too Vague**
+- Undefined success criteria
+- Ambiguous requirements
+- No clear scope
+
+**Too Detailed**
+- Implementation specifics
+- Pixel-perfect mockups
+- Technical architecture
+
+**Not Updated**
+- Decisions made but not documented
+- Scope changed but not reflected
+- Outdated context
+
+**Missing Key Elements**
+- No success metrics
+- No prioritization
+- No constraints/dependencies
+
+### Collaboration Tips
+
+**Stakeholder Input**
+- Get input early
+- Document decisions
+- Note disagreements
+- Track approvals
+
+**Living Document**
+- Version control
+- Change log
+- Review cadence
+- Clear ownership
+
+**Review Checklist**
+- [ ] Problem clearly stated
+- [ ] Goals are measurable
+- [ ] Scope is defined
+- [ ] Requirements prioritized
+- [ ] Success criteria exist
+- [ ] Risks identified
+- [ ] Stakeholders aligned
+
+### PRD Templates by Type
+
+**New Product**
+- Heavy on problem/market validation
+- Broader scope
+- More research documentation
+
+**New Feature**
+- Clear fit with existing product
+- Focused scope
+- Integration considerations
+
+**Improvement/Iteration**
+- Baseline metrics
+- Specific changes
+- A/B test plan
+
+**Technical/Infrastructure**
+- Business impact translation
+- Technical requirements acceptable
+- Risk focus

package/kits/product-requirements-doc/skills/prioritize-features/SKILL.md

@@ -0,0 +1,43 @@
+---
+id: prioritize-features
+name: Prioritize Features
+description: Prioritize features using RICE or MoSCoW framework
+version: "1.0.0"
+type: invocable
+parameters: [features]
+requiresVision: false
+requiresData: false
+---
+
+## Prioritize Features
+
+Prioritize features using RICE or MoSCoW framework
+
+### Steps
+
+1. List all features/stories to prioritize
+2. Choose framework: RICE for data-driven, MoSCoW for stakeholder-driven
+3. For RICE: Score each on Reach, Impact (1-3), Confidence (%), Effort (person-weeks)
+4. Calculate RICE score: (Reach × Impact × Confidence) ÷ Effort
+5. For MoSCoW: Categorize into Must/Should/Could/Won't with stakeholders
+6. Document rationale for each prioritization decision
+7. Identify dependencies that affect sequencing
+8. Update PRD with prioritized roadmap
+
+### Inputs Required
+
+- **features** (required): List of features to prioritize
+- **framework** (optional): RICE or MoSCoW
+
+### Expected Outputs
+
+- Prioritized feature list
+- Updated roadmap in PRD
+
+### When to Use
+
+This workflow is helpful when the user mentions:
+- "prioritize"
+- "rank features"
+- "what to build first"
+- "roadmap"

package/kits/product-requirements-doc/skills/synthesize-research/SKILL.md

@@ -0,0 +1,43 @@
+---
+id: synthesize-research
+name: Synthesize User Research
+description: Turn user research into actionable requirements
+version: "1.0.0"
+type: invocable
+parameters: [researchNotes]
+requiresVision: false
+requiresData: false
+---
+
+## Synthesize User Research
+
+Turn user research into actionable requirements
+
+### Steps
+
+1. Review all research notes and interview transcripts
+2. Identify common pain points across users
+3. Group findings into themes
+4. Extract user quotes that illustrate each theme
+5. Translate pain points into jobs-to-be-done
+6. Identify potential solutions/features for each job
+7. Prioritize based on frequency and severity of pain
+8. Document insights in research/user-research.md
+9. Create linked requirements from key findings
+
+### Inputs Required
+
+- **researchNotes** (required): Research notes or interview transcripts
+
+### Expected Outputs
+
+- Research synthesis document
+- Linked requirements
+
+### When to Use
+
+This workflow is helpful when the user mentions:
+- "synthesize research"
+- "what did we learn"
+- "research findings"
+- "user insights"