@comfanion/workflow 4.38.4-dev.0 → 4.39.0-dev.0

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

@@ -96,83 +96,196 @@ TaskFlow is a B2B platform for managing distributed teams. The system handles ta
 
 ---
 
-## Product Scope
+## AI-Specific Considerations (Optional)
+
+> **Note:** Only for AI/ML/RAG systems. Skip for traditional applications.
+
+### AI Quality Targets
+
+| Metric | MVP Target | Growth Target | Measurement |
+|--------|-----------|---------------|-------------|
+| Accuracy | {{percentage}} | {{percentage}} | {{method}} |
+| Hallucination Rate | < {{threshold}}% | < {{threshold}}% | {{method}} |
+| Response Latency | < {{time}}s (p95) | < {{time}}s (p95) | {{tool}} |
+| Context Relevance | {{percentage}} | {{percentage}} | {{method}} |
+
+<!-- Example for RAG system:
+| Metric | MVP Target | Growth Target | Measurement |
+|--------|-----------|---------------|-------------|
+| Accuracy | 85% | 95% | Gold dataset (100 Q&A pairs) |
+| Hallucination Rate | < 5% | < 1% | Manual review + TruLens |
+| Response Latency | < 3s (p95) | < 2s (p95) | APM monitoring |
+| Context Relevance | 80% | 90% | RAG Triad metrics |
+-->
 
-### MVP — Minimum Viable Product
+### System Boundaries
+
+**What the AI Should Do:**
+- {{capability_1}} — {{description}}
+- {{capability_2}} — {{description}}
+- {{capability_3}} — {{description}}
+
+**What the AI Should NOT Do:**
+- {{limitation_1}} — {{reason}}
+- {{limitation_2}} — {{reason}}
+- {{limitation_3}} — {{reason}}
+
+<!-- Example for RAG system:
+**What the AI Should Do:**
+- Answer questions about product documentation — Using only official docs as source
+- Provide code examples from docs — With proper attribution and links
+- Cite sources for every answer — Show which doc section was used
+- Admit when information is not available — "I don't have information about that"
+
+**What the AI Should NOT Do:**
+- Answer questions outside documentation scope — Redirect to support/community
+- Generate code not present in docs — Risk of hallucinations
+- Provide opinions or recommendations — Stick to factual information only
+- Make assumptions about user's context — Ask clarifying questions
+-->
 
-**{{Domain_1}}:**
-- {{capability}}
-- {{capability}}
+### Feedback & Improvement
 
-**{{Domain_2}}:**
-- {{capability}}
+**User Feedback Mechanisms:**
+- {{mechanism}} — {{purpose}} — {{how_used}}
+- {{mechanism}} — {{purpose}} — {{how_used}}
 
-### Growth Features (Post-MVP)
-- {{feature}}
+**Model Improvement Process:**
+- {{approach}} — {{frequency}} — {{who_responsible}}
+- {{approach}} — {{frequency}} — {{who_responsible}}
 
-### Out of Scope
-- {{item}}
+<!-- Example:
+**User Feedback Mechanisms:**
+- Thumbs up/down on answers — Track satisfaction, identify problem areas — Weekly review
+- "Report incorrect answer" button — Flag hallucinations — Immediate review queue
+- Copy answer to clipboard — Track which answers are most useful — Monthly analysis
+
+**Model Improvement Process:**
+- Weekly review of flagged answers — Update gold dataset — ML team
+- Monthly retraining on updated documentation — Improve accuracy — ML team
+- Quarterly review of system boundaries — Adjust scope — Product team
+-->
 
 ---
 
-## Functional Requirements
+## Product Scope
 
-> **Traceability:** Each FR tracks Module, Unit, Architecture section, Epic, and Status.
-> **Maintained by:** @pm (Epic), @architect (Module/Unit/Arch §), @dev (Status).
+### MVP — Minimum Viable Product
+
+**{{Domain_1}}: {{domain_name}}**
+
+Core capabilities:
+- {{capability_1}} — {{brief_description}}
+- {{capability_2}} — {{brief_description}}
+- {{capability_3}} — {{brief_description}}
+
+Key user flows:
+1. **{{flow_name}}:** {{user_action}} → {{system_response}} → {{outcome}}
+2. **{{flow_name}}:** {{user_action}} → {{system_response}} → {{outcome}}
 
-### {{Domain_1}}
+**{{Domain_2}}: {{domain_name}}**
 
-| ID | Requirement | Priority | Module | Doc Section | Arch § | Epic | Status |
-|----|-------------|----------|--------|-------------|--------|------|--------|
-| FR-001 | {{requirement}} | P0 | {{module}} | → Unit: `{{name}}` | §{{N}} | → Epic: `{{file}}` | ⬜ |
-| FR-002 | {{requirement}} | P0 | {{module}} | → Module: `{{name}}` | §{{N}} | → Epic: `{{file}}` | ⬜ |
-| FR-003 | {{requirement}} | P1 | {{module}} | → Service: `{{name}}` | §{{N}} | → Epic: `{{file}}` | ⬜ |
+Core capabilities:
+- {{capability_1}} — {{brief_description}}
+- {{capability_2}} — {{brief_description}}
+
+Key user flows:
+1. **{{flow_name}}:** {{user_action}} → {{system_response}} → {{outcome}}
 
 <!-- Example:
-| FR-001 | User can create task with title, description, due date | P0 | Task | → Unit: `Task` | §3.1 | → Epic: `epic-01-task-crud.md` | ✅ |
-| FR-002 | User can assign task to team member | P0 | Task | → Unit: `Task` | §3.1 | → Epic: `epic-01-task-crud.md` | ⬜ |
-| FR-003 | System sends notification on assignment | P1 | Notification | → Service: `NotificationService` | §3.3 | → Epic: `epic-03-notifications.md` | ⬜ |
+**Task Management:**
+
+Core capabilities:
+- Task CRUD — Create, read, update, delete tasks with title, description, due date
+- Task Assignment — Assign tasks to team members, reassign, unassign
+- Status Workflow — Move tasks through todo → in_progress → done states
+
+Key user flows:
+1. **Create Task:** User fills form → System validates → Task created → Assignee notified → Task appears in list
+2. **Complete Task:** User clicks "Done" → System updates status → Team sees update → Analytics updated
 -->
 
-**Notes:**
-- {{important_business_rule}}
+### Growth Features (Post-MVP)
+
+**Phase 2:**
+- {{feature}} — {{why_important}} — {{business_value}}
+- {{feature}} — {{why_important}} — {{business_value}}
 
-### {{Domain_2}}
+**Phase 3:**
+- {{feature}} — {{why_important}} — {{business_value}}
 
-| ID | Requirement | Priority | Module | Doc Section | Arch § | Epic | Status |
-|----|-------------|----------|--------|-------------|--------|------|--------|
-| FR-010 | {{requirement}} | P0 | {{module}} | → Unit: `{{name}}` | §{{N}} | → Epic: `{{file}}` | ⬜ |
+<!-- Example:
+**Phase 2:**
+- Task Templates — Reduce repetitive task creation — Save 30% time for recurring workflows
+- Task Dependencies — Model complex workflows — Enable project management use cases
 
----
+**Phase 3:**
+- Recurring Tasks — Automate periodic work — Expand to operations teams
+- Time Tracking — Measure effort — Enable billing use cases
+-->
 
-## Non-Functional Requirements
+### Out of Scope
 
-> **Traceability:** NFRs also track Module (if specific), Architecture section, and Status.
+**Never:**
+- {{item}} — {{reason_why_never}}
+- {{item}} — {{reason_why_never}}
 
-| ID | Requirement | Priority | Module | Doc Section | Arch § | Status |
-|----|-------------|----------|--------|-------------|--------|--------|
-| NFR-001 | {{requirement}} | P0 | — | — | §{{N}} | ⬜ |
-| NFR-002 | {{requirement}} | P0 | {{module}} | → Unit: `{{name}}` | §{{N}} | ⬜ |
+**Not Now (Future):**
+- {{item}} — {{why_later}}
+- {{item}} — {{why_later}}
 
 <!-- Example:
-| NFR-001 | API response time < 200ms (p95) | P0 | — | — | §5 Performance | ⬜ |
-| NFR-002 | Task data encrypted at rest | P0 | Task | → Unit: `Task` | §4 Security | ⬜ |
+**Never:**
+- Time tracking — Use external tools (Toggl, Harvest) - not core competency
+- Gantt charts — Too complex for target users (small teams)
+- Resource management — Out of product vision
+
+**Not Now (Future):**
+- Mobile app — Focus on web first, mobile in Phase 3 after PMF
+- Integrations — Wait for user demand, prioritize after MVP
+- Advanced reporting — Basic analytics in MVP, advanced in Phase 2
 -->
 
 ---
 
-## Non-Functional Requirements (Details)
+## Requirements
 
-> Optional: Add detailed notes for complex NFRs here.
+> **Source of Truth:** All detailed Functional and Non-Functional Requirements are maintained in `requirements.md`.
 
-### Performance
-- {{details_if_needed}}
+→ **Requirements Document:** `docs/requirements/requirements.md`
 
-### Security
-- {{details_if_needed}}
+### Requirements Summary
 
-### Scalability
-- {{details_if_needed}}
+**Functional Requirements:** {{total_fr_count}} requirements across {{domain_count}} domains
+- {{domain_1}}: {{fr_count}} requirements ({{p0_count}} P0, {{p1_count}} P1)
+- {{domain_2}}: {{fr_count}} requirements ({{p0_count}} P0, {{p1_count}} P1)
+
+**Non-Functional Requirements:** {{total_nfr_count}} requirements
+- Performance: {{nfr_count}} requirements
+- Security: {{nfr_count}} requirements
+- Scalability: {{nfr_count}} requirements
+
+**Priority Breakdown:**
+- P0 (Must Have - MVP): {{p0_count}} requirements
+- P1 (Should Have - Growth): {{p1_count}} requirements
+- P2 (Nice to Have - Vision): {{p2_count}} requirements
+
+<!-- Example:
+**Functional Requirements:** 23 requirements across 3 domains
+- Task Management: 12 requirements (8 P0, 4 P1)
+- User Management: 6 requirements (5 P0, 1 P1)
+- Notifications: 5 requirements (2 P0, 3 P1)
+
+**Non-Functional Requirements:** 8 requirements
+- Performance: 3 requirements
+- Security: 3 requirements
+- Scalability: 2 requirements
+
+**Priority Breakdown:**
+- P0 (Must Have - MVP): 15 requirements
+- P1 (Should Have - Growth): 8 requirements
+- P2 (Nice to Have - Vision): 0 requirements
+-->
 
 ---
 
@@ -198,5 +311,22 @@ TaskFlow is a B2B platform for managing distributed teams. The system handles ta
 
 ## References
 
-→ Architecture: `{{path}}`
-→ Requirements: `{{path}}`
+→ **Requirements (Source of Truth for FR/NFR):** `docs/requirements/requirements.md`  
+→ **Architecture:** `docs/architecture.md`  
+→ **Coding Standards:** `docs/coding-standards/README.md`
+
+---
+
+## Document Changelog
+
+| Version | Date | Author | Changes |
+|---------|------|--------|---------|
+| 1.0 | {{date}} | {{author}} | Initial PRD |
+
+<!-- Example:
+| Version | Date | Author | Changes |
+|---------|------|--------|---------|
+| 1.0 | 2026-01-15 | @pm | Initial PRD created from requirements |
+| 1.1 | 2026-01-20 | @pm | Added AI-specific considerations |
+| 1.2 | 2026-01-25 | @architect | Updated requirements summary after architecture |
+-->

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

@@ -1,6 +1,6 @@
 ---
 name: requirements-gathering
-description: Use when gathering FR/NFR through stakeholder interviews and elicitation techniques
+description: Gather functional and non-functional requirements through stakeholder interviews, user research, and elicitation techniques. Use when starting a new project, collecting requirements, interviewing stakeholders, or when user mentions "requirements", "FR", "NFR", "stakeholder needs", or "user research".
 license: MIT
 compatibility: opencode
 metadata:
@@ -10,69 +10,85 @@ metadata:
 
 # Requirements Gathering Skill
 
-## When to Use
-
-Use this skill when you need to:
-- Gather requirements from stakeholders
-- Document functional and non-functional requirements
-- Create the foundation for PRD
-
-## Template
-
-Use template at: `@.opencode/skills/requirements-gathering/template.md`
-
-## Requirements Document Structure (v2)
-
-### 1. Header
-
-```yaml
-id: REQ-001
-version: 1.0
-status: draft | approved
-date: {{date}}
-author: {{author}}
+```xml
+<requirements_gathering>
+  <definition>Gather FR/NFR through stakeholder interviews</definition>
+  
+  <output>docs/requirements/requirements.md</output>
+  
+  <structure>
+    <header>id, version, status, date, author</header>
+    <summary>Problem, users, outcomes</summary>
+    <stakeholders>Table: Role | Representative | Interest | Influence</stakeholders>
+    <functional_requirements>
+      <grouped_by>Domain</grouped_by>
+      <table>ID | Requirement | Priority | Source | Module | Doc Section | Arch § | Epic | Status</table>
+      <traceability>
+        <module>Filled by @architect</module>
+        <arch_section>Filled by @architect</arch_section>
+        <epic>Filled by @pm</epic>
+        <status>Updated by @dev (⬜ → ✅)</status>
+      </traceability>
+    </functional_requirements>
+    <nfr>
+      <categories>Performance, Security, Scalability, Usability, Reliability, Maintainability</categories>
+      <table>ID | Requirement | Priority | Metric | Arch § | Status</table>
+    </nfr>
+    <ai_requirements optional="true">For RAG/AI systems</ai_requirements>
+    <constraints>Table: Type | Description | Impact</constraints>
+    <assumptions>Bullet list</assumptions>
+    <dependencies>Table: Item | Owner | Status | Risk</dependencies>
+    <open_questions>Checklist</open_questions>
+    <glossary>Table: Term | Definition</glossary>
+    <references>Links to PRD, Architecture</references>
+  </structure>
+  
+  <requirement_rules>
+    <atomic>One requirement = one thing</atomic>
+    <measurable>Use numbers, not "quickly"</measurable>
+    <testable>Can verify with test</testable>
+    <unambiguous>Clear, no interpretation needed</unambiguous>
+  </requirement_rules>
+  
+  <ids>
+    <functional>FR-001, FR-002, ...</functional>
+    <nfr>NFR-001, NFR-002, ...</nfr>
+  </ids>
+  
+  <priority>
+    <P0>Must have (MVP)</P0>
+    <P1>Should have (Growth)</P1>
+    <P2>Nice to have (Vision)</P2>
+  </priority>
+  
+  <interview_questions>
+    <functional>
+      <q>What do you need to accomplish?</q>
+      <q>What information do you need to see?</q>
+      <q>What actions do you need to take?</q>
+      <q>What happens when X fails?</q>
+    </functional>
+    <nfr>
+      <q>How many users concurrently?</q>
+      <q>What response time is acceptable?</q>
+      <q>What's the data retention policy?</q>
+      <q>What security standards apply?</q>
+    </nfr>
+  </interview_questions>
+  
+  <reference_format>
+    <unit>→ Unit: `Task`</unit>
+    <fr>→ FR: `FR-001`</fr>
+    <prd>→ PRD: `docs/prd.md`</prd>
+  </reference_format>
+</requirements_gathering>
 ```
 
-### 2. Summary
-
-Brief prose explaining:
-- What problem is being solved
-- Who the primary users are
-- Key outcomes expected
-
-### 3. Stakeholders
-
-| Role | Representative | Interest | Influence |
-|------|---------------|----------|-----------|
-| Product Owner | Name | Feature delivery | High |
-| End Users | Segment | Daily usage | High |
-
-### 4. Functional Requirements
-
-**Grouped by domain:**
-
-```markdown
-### Task Management
-
-Core task lifecycle operations.
-
-| ID | Requirement | Priority | Source |
-|----|-------------|----------|--------|
-| FR-001 | User can create task | P0 | Team Lead |
-
-**Business Rules:**
-- One task = one assignee
-
-**Notes:**
-- Notifications in separate domain
-```
-
-### 5. Non-Functional Requirements
-
-Separate tables by category:
-- Performance (with metrics)
-- Security
-- Scalability
+**When to include:**
+- System uses LLM/ML models
+- System has probabilistic outputs (not deterministic)
+- Accuracy/hallucination metrics are critical
+- System needs clear boundaries (what it should/shouldn't do)
 
 ### 6. Constraints
 
@@ -112,71 +128,40 @@ Separate tables by category:
 → Stakeholder Interviews: `docs/interviews/`
 ```
 
-## Reference Format
-
-Use `→` for all references:
-```markdown
-→ PRD: `docs/prd.md`
-→ FR: `FR-001`
-```
-
-## Requirement Writing Rules
-
-### Good Requirements
-
-| Rule | Good | Bad |
-|------|------|-----|
-| Atomic | User can create task | User can create and edit task |
-| Measurable | Load in < 2s | Load quickly |
-| Testable | Title max 200 chars | Title reasonable length |
-| Unambiguous | Required field | Important field |
-
-### Requirement IDs
-
-- Functional: `FR-001`, `FR-002`, ...
-- Non-Functional: `NFR-001`, `NFR-002`, ...
+---
 
-### Priority
+## Example: Task Management Requirements
 
-| Level | Meaning | Scope |
-|-------|---------|-------|
-| P0 | Must have | MVP |
-| P1 | Should have | Growth |
-| P2 | Nice to have | Vision |
+```yaml
+id: REQ-001
+version: 1.0
+status: draft
+```
 
-## Interview Questions
+# Requirements Document
 
-### Functional Discovery
+## Summary
 
-1. What do you need to accomplish?
-2. What information do you need to see?
-3. What actions do you need to take?
-4. What happens when X fails?
+Team collaboration tool for managing tasks and assignments.
 
-### NFR Discovery
+## Functional Requirements
 
-1. How many users concurrently?
-2. What response time is acceptable?
-3. What's the data retention policy?
-4. What security standards apply?
+### Task Management
 
-## Validation Checklist
+| ID | Requirement | Priority | Source | Module | Doc Section | Arch § | Epic | Status |
+|----|-------------|----------|--------|--------|-------------|--------|------|--------|
+| FR-001 | User can create task | P0 | Team Lead | Task | → Unit: `Task` | §3.1 | → Epic: `epic-01-task-crud.md` | ⬜ |
+| FR-002 | User can assign task | P0 | Team Lead | Task | → Unit: `Task` | §3.1 | → Epic: `epic-01-task-crud.md` | ⬜ |
 
-- [ ] All stakeholders identified
-- [ ] Requirements grouped by domain
-- [ ] Each requirement is atomic and testable
-- [ ] NFRs have measurable metrics
-- [ ] Constraints documented
-- [ ] Assumptions validated
-- [ ] Dependencies identified with owners
-- [ ] Uses `→` reference format
+**Business Rules:**
+- One task = one assignee
 
-## Output
+## Non-Functional Requirements
 
-Save to: `docs/requirements/requirements.md`
+### Performance
 
-## Related Skills
+| ID | Requirement | Priority | Metric | Arch § | Status |
+|----|-------------|----------|--------|--------|--------|
+| NFR-001 | Page load < 2s | P0 | 95th percentile | §4.2 | ⬜ |
 
-- `prd-writing` - Uses requirements as input
-- `requirements-validation` - Validates requirements
-- `acceptance-criteria` - For testable AC
+See `template.md` for full format.

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

@@ -38,15 +38,34 @@ TaskFlow addresses the need for lightweight task management for small remote tea
 
 ## Functional Requirements
 
+> **Traceability:** Each FR tracks Module, Unit, Architecture section, Epic, and Status.
+> **Maintained by:** 
+> - @analyst — Gathers requirements from stakeholders (fills ID, Requirement, Priority, Source)
+> - @architect — Fills Module, Doc Section, Arch § after architecture design
+> - @pm — Fills Epic after epic creation
+> - @dev — Updates Status during implementation
+
+> **Workflow:**
+> 1. @analyst creates requirements.md with FR/NFR (Module/Arch § empty)
+> 2. @architect designs architecture.md, updates requirements.md (fills Module, Arch §)
+> 3. @pm creates epics, updates requirements.md (fills Epic column)
+> 4. @dev implements stories, updates requirements.md (Status: ⬜ → ✅)
+
 ### {{Domain_1}}: {{domain_name}}
 
 {{brief_context_for_this_group_of_requirements}}
 
-| ID | Requirement | Priority | Source |
-|----|-------------|----------|--------|
-| FR-001 | {{user_can_action}} | P0 | {{stakeholder}} |
-| FR-002 | {{user_can_action}} | P0 | {{stakeholder}} |
-| FR-003 | {{system_does_action}} | P1 | {{stakeholder}} |
+| ID | Requirement | Priority | Source | Module | Doc Section | Arch § | Epic | Status |
+|----|-------------|----------|--------|--------|-------------|--------|------|--------|
+| FR-001 | {{user_can_action}} | P0 | {{stakeholder}} | {{module}} | → Unit: `{{name}}` | §{{N}} | → Epic: `{{file}}` | ⬜ |
+| FR-002 | {{user_can_action}} | P0 | {{stakeholder}} | {{module}} | → Unit: `{{name}}` | §{{N}} | → Epic: `{{file}}` | ⬜ |
+| FR-003 | {{system_does_action}} | P1 | {{stakeholder}} | {{module}} | → Unit: `{{name}}` | §{{N}} | → Epic: `{{file}}` | ⬜ |
+
+<!-- Example:
+| FR-001 | User can create task with title, description, due date | P0 | Team Lead | Task | → Unit: `Task` | §3.1 | → Epic: `epic-01-task-crud.md` | ✅ |
+| FR-002 | User can assign task to team member | P0 | Team Lead | Task | → Unit: `Task` | §3.1 | → Epic: `epic-01-task-crud.md` | ⬜ |
+| FR-003 | System sends notification on assignment | P1 | Team Lead | Notification | → Service: `NotificationService` | §3.3 | → Epic: `epic-03-notifications.md` | ⬜ |
+-->
 
 **Business Rules:**
 - {{rule}}
@@ -77,31 +96,92 @@ Core task lifecycle operations that all users need.
 
 {{brief_context}}
 
-| ID | Requirement | Priority | Source |
-|----|-------------|----------|--------|
-| FR-010 | {{requirement}} | P1 | {{stakeholder}} |
+| ID | Requirement | Priority | Source | Module | Doc Section | Arch § | Epic | Status |
+|----|-------------|----------|--------|--------|-------------|--------|------|--------|
+| FR-010 | {{requirement}} | P1 | {{stakeholder}} | {{module}} | → Unit: `{{name}}` | §{{N}} | → Epic: `{{file}}` | ⬜ |
 
 ---
 
 ## Non-Functional Requirements
 
+> **Traceability:** NFRs also track Module (if specific), Architecture section, and Status.
+
 ### Performance
 
-| ID | Requirement | Metric | Priority |
-|----|-------------|--------|----------|
-| NFR-001 | {{what}} | {{measurable_target}} | P0 |
+| ID | Requirement | Metric | Priority | Module | Arch § | Status |
+|----|-------------|--------|----------|--------|--------|--------|
+| NFR-001 | {{what}} | {{measurable_target}} | P0 | {{module}} | §{{N}} | ⬜ |
+
+<!-- Example:
+| NFR-001 | API response time < 200ms (p95) | p95 < 200ms | P0 | — | §5 Performance | ⬜ |
+| NFR-002 | Task data encrypted at rest | AES-256 | P0 | Task | §4 Security | ⬜ |
+-->
 
 ### Security
 
-| ID | Requirement | Standard/Approach | Priority |
-|----|-------------|-------------------|----------|
-| NFR-010 | {{what}} | {{how}} | P0 |
+| ID | Requirement | Standard/Approach | Priority | Module | Arch § | Status |
+|----|-------------|-------------------|----------|--------|--------|--------|
+| NFR-010 | {{what}} | {{how}} | P0 | {{module}} | §{{N}} | ⬜ |
 
 ### Scalability
 
-| ID | Requirement | Target | Priority |
-|----|-------------|--------|----------|
-| NFR-020 | {{what}} | {{number}} | P1 |
+| ID | Requirement | Target | Priority | Module | Arch § | Status |
+|----|-------------|--------|----------|--------|--------|--------|
+| NFR-020 | {{what}} | {{number}} | P1 | {{module}} | §{{N}} | ⬜ |
+
+---
+
+## AI-Specific Requirements (Optional)
+
+> **Note:** Only for AI/ML/RAG systems. Skip for traditional applications.
+
+### AI Quality Metrics
+
+| ID | Metric | Target | Measurement Method | Priority | Arch § | Status |
+|----|--------|--------|-------------------|----------|--------|--------|
+| AI-001 | Accuracy | {{target_percentage}} | {{how_to_measure}} | P0 | §{{N}} | ⬜ |
+| AI-002 | Hallucination Rate | < {{threshold}}% | {{validation_method}} | P0 | §{{N}} | ⬜ |
+| AI-003 | Response Latency | < {{time}}s (p95) | {{monitoring_tool}} | P1 | §{{N}} | ⬜ |
+
+<!-- Example for RAG system:
+| AI-001 | Accuracy | 85% on gold dataset | 100 Q&A pairs validated by experts | P0 | §6 AI Quality | ⬜ |
+| AI-002 | Hallucination Rate | < 5% | Manual review + TruLens framework | P0 | §6 AI Quality | ⬜ |
+| AI-003 | Response Latency | < 3s (p95) | APM monitoring (Datadog) | P1 | §5 Performance | ⬜ |
+-->
+
+### System Boundaries
+
+**In Scope:**
+- {{what_system_should_answer}}
+- {{capability_2}}
+
+**Out of Scope:**
+- {{what_system_should_NOT_answer}} — {{reason}}
+- {{limitation_2}} — {{reason}}
+
+<!-- Example:
+**In Scope:**
+- Answer questions about product documentation
+- Provide code examples from official docs
+- Cite sources for every answer
+
+**Out of Scope:**
+- Answer questions outside documentation scope — "I don't have information about that"
+- Generate code not present in docs — "I can only show examples from our docs"
+- Provide opinions or recommendations — Stick to factual information
+-->
+
+### Feedback Mechanisms
+
+| ID | Mechanism | Purpose | Priority | Status |
+|----|-----------|---------|----------|--------|
+| FB-001 | {{feedback_type}} | {{why_needed}} | P0 | ⬜ |
+
+<!-- Example:
+| FB-001 | Thumbs up/down on answers | Track satisfaction, identify problem areas | P0 | ⬜ |
+| FB-002 | "Report incorrect answer" button | Flag hallucinations for manual review | P0 | ⬜ |
+| FB-003 | Copy answer to clipboard | Track which answers are most useful | P2 | ⬜ |
+-->
 
 ---