Delete prd-template directory

prd-template/SKILL.md

@@ -1,94 +0,0 @@
----
-name: prd-template
-description: Product Requirements Document creation following proven PM template structure. Use when the user asks to create, write, draft, or help with a PRD, product requirements document, product spec, feature specification, or product documentation for a new feature or product.
----
-
-# PRD Template Skill
-
-This skill helps create professional Product Requirements Documents following industry best practices.
-
-## Template Structure
-
-Every PRD should include these sections in order:
-
-### 1. Overview
-- **Problem Statement**: What problem are we solving? (2-3 sentences)
-- **Proposed Solution**: High-level description of what we're building (2-3 sentences)
-- **Success Metrics**: How we'll measure success (3-5 key metrics)
-
-### 2. Context & Background
-- **Why Now**: Why is this the right time?
-- **Strategic Alignment**: How does this align with company objectives?
-- **User Research Summary**: Key insights from research (if applicable)
-
-### 3. User Stories & Use Cases
-Format: "As a [user type], I want to [action] so that [benefit]"
-- Include 3-7 primary user stories
-- Add acceptance criteria for each
-
-### 4. Requirements
-**Functional Requirements:**
-- Must-have features (P0)
-- Should-have features (P1)
-- Nice-to-have features (P2)
-
-**Non-Functional Requirements:**
-- Performance expectations
-- Security considerations
-- Accessibility requirements
-
-### 5. Design & User Experience
-- Link to design mocks or wireframes
-- Key user flows
-- Edge cases and error states
-
-### 6. Technical Considerations
-- Architecture implications
-- Dependencies on other systems
-- Technical risks and mitigations
-
-### 7. Implementation Plan
-- **Phase 1 (MVP)**: What goes in first version
-- **Phase 2**: What comes next
-- **Phase 3**: Future enhancements
-
-### 8. Open Questions
-- Decisions that still need to be made
-- Stakeholders to consult
-- Research needed
-
-### 9. Appendix
-- Research links
-- Related documents
-- Competitive analysis
-
-## Writing Guidelines
-
-**Tone**: Clear, concise, actionable
-**Audience**: Engineers, designers, stakeholders
-**Length**: Aim for 3-6 pages for features, 8-12 for products
-
-**Best Practices:**
-- Use concrete examples over abstractions
-- Include "why" not just "what"
-- Make requirements testable
-- Link to supporting materials
-- Update as decisions are made
-
-## What Makes a Good PRD
-
-✅ **Do:**
-- Write from the user's perspective
-- Include specific success metrics
-- Address edge cases
-- Link to research and data
-- Make trade-offs explicit
-
-❌ **Don't:**
-- Write implementation details (that's tech spec)
-- Assume everyone has context
-- Leave requirements ambiguous
-- Skip the "why"
-- Forget about accessibility
-
-## Example PRD Opening