@comfanion/workflow 3.0.0

package/src/opencode/skills/prd-validation/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: prd-validation
+description: How to validate PRD for completeness, requirements coverage, and QA artifact presence
+license: MIT
+compatibility: opencode
+metadata:
+  domain: quality-assurance
+  artifacts: docs/validation/prd-validation-*.md
+---
+
+# PRD Validation Skill
+
+## When to Use
+
+Use this skill when you need to:
+- Validate PRD before creating architecture
+- Ensure all requirements are covered
+- Check QA artifact (prd-acceptance-criteria.md) exists
+
+## Prerequisites
+
+- Requirements validation must PASS first
+- File: `docs/requirements/requirements.md`
+
+## Validation Checklist
+
+### Structure Checks
+
+- [ ] File exists at `docs/prd.md`
+- [ ] Executive Summary section exists
+- [ ] Project Classification section exists
+- [ ] Success Criteria section exists
+- [ ] Product Scope section exists (MVP/Growth/Vision)
+- [ ] Functional Requirements section exists
+- [ ] Non-Functional Requirements section exists
+- [ ] Dependencies section exists
+- [ ] Risks section exists
+
+### Requirements Coverage
+
+- [ ] All FRs from requirements.md are addressed
+- [ ] All NFRs from requirements.md are addressed
+- [ ] No orphan requirements (in PRD but not in requirements.md)
+- [ ] FR IDs match between documents
+
+### Quality Checks
+
+- [ ] Executive summary explains the "why"
+- [ ] Success criteria are measurable
+- [ ] Scope boundaries are clear
+- [ ] MVP is minimal but viable
+- [ ] Growth features depend on MVP
+- [ ] Priorities are consistent with requirements.md
+
+### QA Artifact Check (MANDATORY)
+
+- [ ] File exists: `docs/prd-acceptance-criteria.md`
+- [ ] All FRs have acceptance criteria defined
+- [ ] AC uses Given/When/Then format
+- [ ] Coverage matrix is complete
+
+### Traceability Check
+
+For each FR in PRD:
+- [ ] Maps to requirement in requirements.md
+- [ ] Has clear scope (MVP/Growth/Vision)
+- [ ] Has priority (P0/P1/P2)
+
+## Validation Report Format
+
+```markdown
+# PRD Validation Report
+
+**Date:** YYYY-MM-DD
+**Status:** PASS | WARN | FAIL
+**File:** docs/prd.md
+
+## Prerequisites
+
+| Prerequisite | Status |
+|--------------|--------|
+| requirements.md validated | ✅ PASS |
+
+## Summary
+
+| Check Type | Total | Passed | Warnings | Failed |
+|------------|-------|--------|----------|--------|
+| Structure | 9 | 9 | 0 | 0 |
+| Coverage | 3 | 3 | 0 | 0 |
+| Quality | 6 | 5 | 1 | 0 |
+| QA Artifact | 4 | 4 | 0 | 0 |
+
+## QA Artifact Status
+
+| Artifact | Status |
+|----------|--------|
+| `docs/prd-acceptance-criteria.md` | ✅ Present |
+| FR Coverage | 100% (45/45) |
+| AC Format | Given/When/Then ✅ |
+
+## Requirements Coverage
+
+| Source | Total | Covered | Missing |
+|--------|-------|---------|---------|
+| Functional (FR) | 45 | 45 | 0 |
+| Non-Functional (NFR) | 12 | 12 | 0 |
+
+## Passed Checks
+
+- [x] All FRs from requirements.md covered
+- [x] All NFRs from requirements.md covered
+- [x] QA artifact present
+
+## Warnings
+
+- [ ] Success criteria for Growth phase could be more specific
+
+## Failures
+
+(None if PASS)
+
+## Recommendations
+
+1. Add specific metrics to Growth success criteria
+
+## Next Steps
+
+After fixing issues:
+- Re-run `/validate prd`
+- If PASS, proceed to `/architecture`
+```
+
+## If QA Artifact Missing
+
+```markdown
+## FAILURE: QA Artifact Missing
+
+**Required:** `docs/prd-acceptance-criteria.md`
+**Status:** ❌ NOT FOUND
+
+### Action Required
+
+Create the QA artifact using template:
+`@.opencode/templates/prd-acceptance-criteria-template.md`
+
+This artifact is MANDATORY before proceeding to architecture.
+
+### What It Should Contain
+
+1. Acceptance criteria for ALL FRs
+2. Given/When/Then format
+3. Edge cases and negative tests
+4. NFR test methods
+5. Coverage matrix
+```
+
+## Output
+
+Save to: `docs/validation/prd-validation-YYYY-MM-DD.md`
+
+## Related Skills
+
+- `prd-writing` - For fixing PRD issues
+- `acceptance-criteria` - For writing AC in QA artifact

package/src/opencode/skills/prd-writing/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: prd-writing
+description: How to write a Product Requirements Document with proper structure, sections, and traceability
+license: MIT
+compatibility: opencode
+metadata:
+  domain: product-management
+  artifacts: docs/prd.md
+---
+
+# PRD Writing Skill
+
+## When to Use
+
+Use this skill when you need to:
+- Create a new PRD from requirements
+- Structure product requirements into a coherent document
+- Define scope boundaries (MVP/Growth/Vision)
+
+## Template
+
+Use the template at: `@.opencode/templates/prd-template.md`
+
+## PRD Structure
+
+### Required Sections
+
+1. **Executive Summary** (2-3 paragraphs)
+   - What is being built
+   - Why it's being built (business value)
+   - Unique value proposition
+
+2. **Project Classification**
+   - Technical Type
+   - Domain
+   - Complexity
+   - Architecture style
+
+3. **Success Criteria** (measurable!)
+   - MVP Success metrics
+   - Growth Success metrics
+
+4. **Product Scope**
+   - MVP features (P0)
+   - Growth features (P1)
+   - Vision features (P2)
+
+5. **Functional Requirements**
+   - Organized by domain
+   - Each FR has: ID, Priority, Scope, Description, AC
+
+6. **Non-Functional Requirements**
+   - Performance (with metrics)
+   - Security
+   - Scalability
+   - Reliability
+
+7. **Dependencies & Integrations**
+8. **Risks & Mitigations**
+9. **Constraints**
+10. **Open Questions**
+
+## Writing Guidelines
+
+### Requirement IDs
+- Functional: `FR-001`, `FR-002`, ...
+- Non-Functional: `NFR-001`, `NFR-002`, ...
+
+### Priority Levels
+- **P0**: Must have for MVP
+- **P1**: Should have for growth
+- **P2**: Nice to have for vision
+
+### Scope Classification
+- **MVP**: Minimum viable product (v1.0)
+- **Growth**: Post-MVP enhancements (v1.x)
+- **Vision**: Future roadmap (v2.0+)
+
+### Language Rules
+- Use "must", "shall", "will" for mandatory items
+- Use "should", "may" for optional items
+- Avoid ambiguous terms without metrics
+
+## Validation Checklist
+
+Before completing PRD:
+- [ ] Executive summary explains the "why"
+- [ ] All FRs from requirements.md are addressed
+- [ ] All NFRs from requirements.md are addressed
+- [ ] Success criteria are measurable
+- [ ] Scope boundaries are clear
+- [ ] No conflicting requirements
+- [ ] Risks are documented with mitigations
+- [ ] Each FR has acceptance criteria
+
+## Output
+
+Save to: `docs/prd.md`
+
+## Related Skills
+
+- `acceptance-criteria` - For writing testable AC
+- `requirements-gathering` - For source requirements
+- `prd-validation` - For validating the PRD

package/src/opencode/skills/requirements-gathering/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: requirements-gathering
+description: How to conduct stakeholder interviews and extract functional/non-functional requirements
+license: MIT
+compatibility: opencode
+metadata:
+  domain: business-analysis
+  artifacts: docs/requirements/requirements.md
+---
+
+# Requirements Gathering Skill
+
+## When to Use
+
+Use this skill when you need to:
+- Conduct stakeholder interviews
+- Extract functional requirements (FR)
+- Extract non-functional requirements (NFR)
+- Discover hidden requirements through questions
+
+## Interview Technique
+
+### Phase 1: Context Discovery
+
+Ask these questions first:
+1. What problem are we solving?
+2. Who are the users/stakeholders?
+3. What existing systems does this integrate with?
+4. What's the timeline and budget?
+5. What happens if we don't build this?
+
+### Phase 2: Functional Discovery
+
+For each user type:
+1. What actions should they be able to perform?
+2. What are the main workflows?
+3. What data do they need to see/edit?
+4. What are the edge cases?
+5. What errors might occur?
+
+### Phase 3: Quality Attributes (NFR)
+
+Ask about:
+- **Performance**: Expected response times? Concurrent users?
+- **Security**: Authentication? Data sensitivity? Compliance?
+- **Scalability**: Data volume growth? User growth?
+- **Reliability**: Uptime requirements? Recovery time?
+- **Usability**: User expertise level? Accessibility?
+
+### Phase 4: Constraints & Assumptions
+
+Document:
+- Technical constraints (existing systems, languages, platforms)
+- Business constraints (budget, timeline, regulations)
+- Assumptions being made
+
+## Output Format
+
+### Functional Requirements
+
+```markdown
+### FR-001: [Requirement Title]
+
+**Priority:** P0 | P1 | P2
+**Source:** [Stakeholder / Document / Interview]
+**Category:** [Domain area]
+
+**Description:**
+[Clear, unambiguous description of what the system must do]
+
+**Acceptance Criteria:**
+- [ ] [Testable criterion 1]
+- [ ] [Testable criterion 2]
+
+**Dependencies:** [FR-XXX, NFR-XXX]
+**Notes:** [Additional context]
+```
+
+### Non-Functional Requirements
+
+```markdown
+### NFR-001: [Requirement Title]
+
+**Priority:** P0 | P1 | P2
+**Category:** Performance | Security | Scalability | Reliability | Usability
+
+**Requirement:**
+[Specific, measurable requirement]
+
+**Metric:** [How to measure]
+**Target:** [Specific target value]
+
+**Verification Method:** [How to verify compliance]
+```
+
+## Requirement Quality Checklist
+
+Each requirement must be:
+- [ ] **Specific** - Clear, unambiguous
+- [ ] **Measurable** - Has acceptance criteria or metrics
+- [ ] **Achievable** - Technically feasible
+- [ ] **Relevant** - Tied to business value
+- [ ] **Traceable** - Has unique ID and source
+
+## Common Anti-patterns to Avoid
+
+1. **Vague language**: "The system should be fast" → "API response < 200ms p95"
+2. **Missing metrics**: "High availability" → "99.9% uptime"
+3. **Solution masquerading as requirement**: "Use Redis" → "Cache frequently accessed data"
+4. **Missing acceptance criteria**: Always include testable criteria
+
+## Discovery Questions Bank
+
+### For Hidden Requirements
+- "What would make this a failure even if it works correctly?"
+- "Who else needs to be involved that we haven't talked to?"
+- "What reports or dashboards do you need?"
+- "How do you handle this process today?"
+
+### For Prioritization
+- "If you could only have 3 features, which would they be?"
+- "What's the minimum needed to go live?"
+- "What's the cost of NOT having this feature?"
+
+## Output
+
+Save to: `docs/requirements/requirements.md`
+
+## Related Skills
+
+- `prd-writing` - For turning requirements into PRD
+- `requirements-validation` - For validating requirements

package/src/opencode/skills/requirements-validation/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: requirements-validation
+description: How to validate requirements for completeness, clarity, and quality (SMART criteria)
+license: MIT
+compatibility: opencode
+metadata:
+  domain: quality-assurance
+  artifacts: docs/validation/requirements-validation-*.md
+---
+
+# Requirements Validation Skill
+
+## When to Use
+
+Use this skill when you need to:
+- Validate requirements.md before creating PRD
+- Check for missing or conflicting requirements
+- Ensure requirements meet SMART criteria
+
+## Validation Checklist
+
+### Structure Checks
+
+- [ ] File exists at `docs/requirements/requirements.md`
+- [ ] File is not empty
+- [ ] Functional Requirements section exists
+- [ ] Non-Functional Requirements section exists
+
+### ID Checks
+
+- [ ] All requirements have unique IDs
+- [ ] FR IDs follow format: `FR-XXX` (e.g., FR-001)
+- [ ] NFR IDs follow format: `NFR-XXX` (e.g., NFR-001)
+- [ ] No duplicate IDs
+- [ ] IDs are sequential (no gaps)
+
+### Priority Checks
+
+- [ ] All requirements have priorities
+- [ ] Priorities use P0/P1/P2 format
+- [ ] P0 requirements are truly critical
+
+### Quality Checks (SMART)
+
+For each requirement:
+- [ ] **Specific** - Clear, unambiguous description
+- [ ] **Measurable** - Has acceptance criteria or metrics
+- [ ] **Achievable** - Technically feasible
+- [ ] **Relevant** - Tied to business value
+- [ ] **Traceable** - Has source documented
+
+### FR-Specific Checks
+
+- [ ] Each FR has acceptance criteria
+- [ ] AC is testable (can be verified as pass/fail)
+- [ ] No implementation details in requirements
+- [ ] Dependencies are identified
+
+### NFR-Specific Checks
+
+- [ ] Each NFR has measurable metric
+- [ ] Target values are specified
+- [ ] Verification method is defined
+- [ ] Categories are valid (Performance/Security/Scalability/Reliability)
+
+### Language Checks
+
+Scan for ambiguous language:
+- [ ] No "should" without "must" clarification
+- [ ] No "might", "could", "possibly"
+- [ ] No "fast", "quick", "responsive" without metrics
+- [ ] No "user-friendly" without specific criteria
+- [ ] No "etc.", "and so on", "..."
+
+### Conflict Checks
+
+- [ ] No conflicting requirements
+- [ ] No circular dependencies
+- [ ] Priorities don't conflict with dependencies
+
+## Validation Report Format
+
+```markdown
+# Requirements Validation Report
+
+**Date:** YYYY-MM-DD
+**Status:** PASS | WARN | FAIL
+**File:** docs/requirements/requirements.md
+
+## Summary
+
+| Check Type | Total | Passed | Warnings | Failed |
+|------------|-------|--------|----------|--------|
+| Structure | 4 | 4 | 0 | 0 |
+| IDs | 5 | 5 | 0 | 0 |
+| Priorities | 3 | 3 | 0 | 0 |
+| Quality | N | X | Y | Z |
+| Language | 5 | 4 | 1 | 0 |
+
+## Passed Checks
+
+- [x] All requirements have unique IDs
+- [x] All requirements have priorities
+
+## Warnings
+
+- [ ] FR-015: Acceptance criteria could be more specific
+  - Current: "User can search products"
+  - Suggestion: Add search criteria, expected results
+
+## Failures
+
+- [ ] FR-023: Missing acceptance criteria
+  - Impact: Cannot verify implementation
+  - Action: Add testable AC
+
+- [ ] NFR-005: No measurable metric
+  - Current: "System should be fast"
+  - Action: Define response time target (e.g., < 200ms p95)
+
+## Recommendations
+
+1. Add AC to FR-023
+2. Define metric for NFR-005
+3. Clarify ambiguous terms in FR-015
+
+## Next Steps
+
+After fixing issues:
+- Re-run `/validate requirements`
+- If PASS, proceed to `/prd`
+```
+
+## Output
+
+Save to: `docs/validation/requirements-validation-YYYY-MM-DD.md`
+
+## Related Skills
+
+- `requirements-gathering` - For fixing missing requirements
+- `acceptance-criteria` - For writing better AC

package/src/opencode/skills/research-methodology/SKILL.md

@@ -0,0 +1,140 @@
+# Research Methodology Skill
+
+How to conduct thorough technical, market, domain, and competitive research.
+
+## Purpose
+
+Provide structured research methodology to gather insights before requirements gathering.
+
+## Research Types
+
+### 1. Market Research
+
+**Goal:** Understand market landscape, trends, and opportunities.
+
+**Process:**
+1. Define research scope and questions
+2. Identify target market segments
+3. Research market size and growth
+4. Analyze market trends
+5. Identify opportunities and gaps
+
+**Output Sections:**
+- Market Overview
+- Target Segments
+- Market Size & Growth
+- Key Trends
+- Opportunities
+
+### 2. Technical Research
+
+**Goal:** Evaluate technologies, patterns, and approaches.
+
+**Process:**
+1. Define technical questions to answer
+2. Research available technologies
+3. Evaluate pros/cons of each
+4. Review case studies and implementations
+5. Provide recommendations
+
+**Output Sections:**
+- Technology Options
+- Comparison Matrix
+- Case Studies
+- Recommendations
+- Risks & Considerations
+
+### 3. Domain Research
+
+**Goal:** Deep understanding of business domain.
+
+**Process:**
+1. Identify domain concepts and terminology
+2. Research industry standards
+3. Understand regulatory requirements
+4. Study domain patterns
+5. Document domain model
+
+**Output Sections:**
+- Domain Glossary
+- Industry Standards
+- Regulatory Requirements
+- Domain Patterns
+- Domain Model
+
+### 4. Competitive Research
+
+**Goal:** Understand competitive landscape.
+
+**Process:**
+1. Identify competitors (direct and indirect)
+2. Analyze competitor products/features
+3. Evaluate strengths/weaknesses
+4. Identify differentiation opportunities
+5. Benchmark best practices
+
+**Output Sections:**
+- Competitor Overview
+- Feature Comparison
+- SWOT Analysis
+- Differentiation Opportunities
+- Best Practices
+
+## Research Template
+
+```markdown
+# {{topic}} Research Report
+
+**Type:** Market / Technical / Domain / Competitive
+**Date:** {{date}}
+**Author:** {{user_name}}
+
+## Executive Summary
+
+[2-3 paragraphs summarizing key findings]
+
+## Research Questions
+
+1. [Question 1]
+2. [Question 2]
+3. [Question 3]
+
+## Methodology
+
+[How research was conducted]
+
+## Findings
+
+### [Finding 1]
+[Details]
+
+### [Finding 2]
+[Details]
+
+## Recommendations
+
+1. [Recommendation 1]
+2. [Recommendation 2]
+
+## References
+
+- [Source 1]
+- [Source 2]
+
+## Appendix
+
+[Supporting data, charts, etc.]
+```
+
+## Quality Criteria
+
+- [ ] Clear research questions defined
+- [ ] Methodology documented
+- [ ] Sources cited
+- [ ] Findings are actionable
+- [ ] Recommendations provided
+- [ ] Limitations acknowledged
+
+## Output Location
+
+`docs/research/[type]/[topic]-research.md`