@su-record/vibe 2.9.4 → 2.9.5

package/skills/context7-usage/rubrics/when-to-use.md

@@ -1,50 +1,50 @@
-# Context7: When to Use vs Direct Docs
-
-## Use Context7 When
-
-| Situation | Signal |
-|-----------|--------|
-| Library version matters | "React 19", "Next.js 15", "Prisma 6" |
-| API changed recently | Migration guides, deprecated methods |
-| Official syntax needed | Schema definitions, config options |
-| Knowledge cutoff risk | Any library updated after Aug 2025 |
-| User asks "latest" or "current" | Explicit freshness requirement |
-
-**Examples where context7 is the right call:**
-- Next.js App Router file conventions
-- Prisma schema relation syntax
-- shadcn/ui component props
-- Tailwind v4 config format
-
-## Skip Context7 When
-
-| Situation | Better Alternative |
-|-----------|-------------------|
-| Stable, well-known API | Claude's built-in knowledge (useState, Array.map) |
-| Conceptual question | Reason directly — no docs needed |
-| Project-specific code | Read the actual source file |
-| Error message debugging | Grep codebase first |
-| You already have the docs open | Don't duplicate the search |
-
-**Examples where context7 is overkill:**
-- "How does useEffect work?" — stable React API
-- "What does Array.reduce do?" — JS standard lib
-- "Why is this TypeScript error appearing?" — analyze the code
-
-## Cost Awareness
-
-Context7 spawns a subagent, which adds latency (~2-5s) and consumes extra tokens. Only invoke when the freshness or official accuracy is worth that cost.
-
-## Decision Rule
-
-> Would a wrong answer here cause a bug or wasted time? If the API surface might have changed and accuracy matters — use context7. If it's general knowledge — answer directly.
-
-## Fallback
-
-If context7 is unavailable or returns no results:
-
-```
-1. /plugin install context7  ← if not installed
-2. Web Search for official docs
-3. Claude knowledge with explicit note: "verify against latest docs"
-```
+# Context7: When to Use vs Direct Docs
+
+## Use Context7 When
+
+| Situation | Signal |
+|-----------|--------|
+| Library version matters | "React 19", "Next.js 15", "Prisma 6" |
+| API changed recently | Migration guides, deprecated methods |
+| Official syntax needed | Schema definitions, config options |
+| Knowledge cutoff risk | Any library updated after Aug 2025 |
+| User asks "latest" or "current" | Explicit freshness requirement |
+
+**Examples where context7 is the right call:**
+- Next.js App Router file conventions
+- Prisma schema relation syntax
+- shadcn/ui component props
+- Tailwind v4 config format
+
+## Skip Context7 When
+
+| Situation | Better Alternative |
+|-----------|-------------------|
+| Stable, well-known API | Claude's built-in knowledge (useState, Array.map) |
+| Conceptual question | Reason directly — no docs needed |
+| Project-specific code | Read the actual source file |
+| Error message debugging | Grep codebase first |
+| You already have the docs open | Don't duplicate the search |
+
+**Examples where context7 is overkill:**
+- "How does useEffect work?" — stable React API
+- "What does Array.reduce do?" — JS standard lib
+- "Why is this TypeScript error appearing?" — analyze the code
+
+## Cost Awareness
+
+Context7 spawns a subagent, which adds latency (~2-5s) and consumes extra tokens. Only invoke when the freshness or official accuracy is worth that cost.
+
+## Decision Rule
+
+> Would a wrong answer here cause a bug or wasted time? If the API surface might have changed and accuracy matters — use context7. If it's general knowledge — answer directly.
+
+## Fallback
+
+If context7 is unavailable or returns no results:
+
+```
+1. /plugin install context7  ← if not installed
+2. Web Search for official docs
+3. Claude knowledge with explicit note: "verify against latest docs"
+```

package/skills/create-prd/SKILL.md

@@ -1,90 +1,90 @@
----
-name: create-prd
-tier: standard
-description: "Create a Product Requirements Document using a comprehensive 8-section template covering problem, objectives, segments, value propositions, solution, and release planning."
-triggers: [prd, product requirements, feature spec, requirements document]
-priority: 60
-chain-next: [user-personas, prioritization-frameworks]
----
-
-# Create a Product Requirements Document
-
-> Based on the PRD template from [Product Compass](https://www.productcompass.pm/p/prd-template) by Pawel Huryn (MIT License).
-
-## Purpose
-
-You are an experienced product manager responsible for creating a comprehensive Product Requirements Document (PRD) for $ARGUMENTS. This document will serve as the authoritative specification for your product or feature, aligning stakeholders and guiding development.
-
-## Context
-
-A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill uses an 8-section template proven to communicate product vision effectively to engineers, designers, leadership, and stakeholders.
-
-## Instructions
-
-1. **Gather Information**: If the user provides files, read them carefully. If they mention research, URLs, or customer data, use web search to gather additional context and market insights.
-
-2. **Think Step by Step**: Before writing, analyze:
-   - What problem are we solving?
-   - Who are we solving it for?
-   - How will we measure success?
-   - What are our constraints and assumptions?
-
-3. **Apply the PRD Template**: Create a document with these 8 sections:
-
-   **1. Summary** (2-3 sentences)
-   - What is this document about?
-
-   **2. Contacts**
-   - Name, role, and comment for key stakeholders
-
-   **3. Background**
-   - Context: What is this initiative about?
-   - Why now? Has something changed?
-   - Is this something that just recently became possible?
-
-   **4. Objective**
-   - What's the objective? Why does it matter?
-   - How will it benefit the company and customers?
-   - How does it align with vision and strategy?
-   - Key Results: How will you measure success? (Use SMART OKR format)
-
-   **5. Market Segment(s)**
-   - For whom are we building this?
-   - What constraints exist?
-   - Note: Markets are defined by people's problems/jobs, not demographics
-
-   **6. Value Proposition(s)**
-   - What customer jobs/needs are we addressing?
-   - What will customers gain?
-   - Which pains will they avoid?
-   - Which problems do we solve better than competitors?
-   - Consider the Value Curve framework
-
-   **7. Solution**
-   - 7.1 UX/Prototypes (wireframes, user flows)
-   - 7.2 Key Features (detailed feature descriptions)
-   - 7.3 Technology (optional, only if relevant)
-   - 7.4 Assumptions (what we believe but haven't proven)
-
-   **8. Release**
-   - How long could it take?
-   - What goes in the first version vs. future versions?
-   - Avoid exact dates; use relative timeframes
-
-4. **Use Accessible Language**: Write for a primary school graduate. Avoid jargon. Use clear, short sentences.
-
-5. **Structure Output**: Present the PRD as a well-formatted markdown document with clear headings and sections.
-
-6. **Save the Output**: Save the PRD as `PRD-[product-name].md` in the project root or docs directory.
-
-## Notes
-
-- Be specific and data-driven where possible
-- Link each section back to the overall strategy
-- Flag assumptions clearly so the team can validate them
-- Keep the document concise but complete
-
-## Further Reading
-
-- [How to Write a Product Requirements Document? The Best PRD Template.](https://www.productcompass.pm/p/prd-template)
-- [A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)](https://www.productcompass.pm/p/ai-prd-template)
+---
+name: create-prd
+tier: standard
+description: "Create a Product Requirements Document using a comprehensive 8-section template covering problem, objectives, segments, value propositions, solution, and release planning."
+triggers: [prd, product requirements, feature spec, requirements document]
+priority: 60
+chain-next: [user-personas, prioritization-frameworks]
+---
+
+# Create a Product Requirements Document
+
+> Based on the PRD template from [Product Compass](https://www.productcompass.pm/p/prd-template) by Pawel Huryn (MIT License).
+
+## Purpose
+
+You are an experienced product manager responsible for creating a comprehensive Product Requirements Document (PRD) for $ARGUMENTS. This document will serve as the authoritative specification for your product or feature, aligning stakeholders and guiding development.
+
+## Context
+
+A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill uses an 8-section template proven to communicate product vision effectively to engineers, designers, leadership, and stakeholders.
+
+## Instructions
+
+1. **Gather Information**: If the user provides files, read them carefully. If they mention research, URLs, or customer data, use web search to gather additional context and market insights.
+
+2. **Think Step by Step**: Before writing, analyze:
+   - What problem are we solving?
+   - Who are we solving it for?
+   - How will we measure success?
+   - What are our constraints and assumptions?
+
+3. **Apply the PRD Template**: Create a document with these 8 sections:
+
+   **1. Summary** (2-3 sentences)
+   - What is this document about?
+
+   **2. Contacts**
+   - Name, role, and comment for key stakeholders
+
+   **3. Background**
+   - Context: What is this initiative about?
+   - Why now? Has something changed?
+   - Is this something that just recently became possible?
+
+   **4. Objective**
+   - What's the objective? Why does it matter?
+   - How will it benefit the company and customers?
+   - How does it align with vision and strategy?
+   - Key Results: How will you measure success? (Use SMART OKR format)
+
+   **5. Market Segment(s)**
+   - For whom are we building this?
+   - What constraints exist?
+   - Note: Markets are defined by people's problems/jobs, not demographics
+
+   **6. Value Proposition(s)**
+   - What customer jobs/needs are we addressing?
+   - What will customers gain?
+   - Which pains will they avoid?
+   - Which problems do we solve better than competitors?
+   - Consider the Value Curve framework
+
+   **7. Solution**
+   - 7.1 UX/Prototypes (wireframes, user flows)
+   - 7.2 Key Features (detailed feature descriptions)
+   - 7.3 Technology (optional, only if relevant)
+   - 7.4 Assumptions (what we believe but haven't proven)
+
+   **8. Release**
+   - How long could it take?
+   - What goes in the first version vs. future versions?
+   - Avoid exact dates; use relative timeframes
+
+4. **Use Accessible Language**: Write for a primary school graduate. Avoid jargon. Use clear, short sentences.
+
+5. **Structure Output**: Present the PRD as a well-formatted markdown document with clear headings and sections.
+
+6. **Save the Output**: Save the PRD as `PRD-[product-name].md` in the project root or docs directory.
+
+## Notes
+
+- Be specific and data-driven where possible
+- Link each section back to the overall strategy
+- Flag assumptions clearly so the team can validate them
+- Keep the document concise but complete
+
+## Further Reading
+
+- [How to Write a Product Requirements Document? The Best PRD Template.](https://www.productcompass.pm/p/prd-template)
+- [A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)](https://www.productcompass.pm/p/ai-prd-template)

package/skills/create-prd/agents/edge-case-finder.md

@@ -1,48 +1,48 @@
----
-name: edge-case-finder
-role: Identifies edge cases, constraints, and risks for each requirement
-tools: [Read, WebSearch]
----
-
-# Edge Case Finder
-
-## Role
-Stress-tests the requirements by systematically exploring what happens at boundaries, under failure conditions, and with unexpected inputs. Produces edge cases and risks that must be addressed before implementation begins.
-
-## Responsibilities
-- Apply boundary value analysis to each acceptance criterion
-- Identify concurrent access and race condition risks
-- Surface failure mode questions: what happens when the network is down, the DB is slow, or the API returns an error
-- Check for internationalization, localization, and character encoding edge cases
-- Flag security concerns: injection, over-fetching, authorization bypass
-
-## Input
-- User stories and acceptance criteria from requirements-writer
-- Research brief from researcher (constraints section)
-
-## Output
-Edge cases and risks appended to each user story, plus a global risks section:
-
-```markdown
-## Edge Cases: US-01 (Search by keyword)
-
-- Empty query string → must return graceful empty state, not 500
-- Query with only whitespace → treat as empty, not a search
-- Query > 500 characters → truncate or reject with clear message
-- Special characters (&, <, >) → must be sanitized to prevent XSS
-- Concurrent searches (user types fast) → debounce, cancel previous request
-
-## Global Risks
-
-| Risk | Likelihood | Impact | Mitigation |
-|------|-----------|--------|-----------|
-| Search index out of sync | Medium | High | Stale-while-revalidate + staleness indicator |
-| Response > 300ms on slow network | High | Medium | Skeleton loader + timeout fallback |
-```
-
-## Communication
-- Reports findings to: prioritizer, reviewer
-- Receives instructions from: orchestrator (create-prd skill)
-
-## Domain Knowledge
-Edge case categories: boundary values, null/empty inputs, concurrent operations, network failures, authorization bypass, i18n/l10n, performance degradation, data volume extremes. Each edge case must have a defined expected behavior — "undefined" is not acceptable.
+---
+name: edge-case-finder
+role: Identifies edge cases, constraints, and risks for each requirement
+tools: [Read, WebSearch]
+---
+
+# Edge Case Finder
+
+## Role
+Stress-tests the requirements by systematically exploring what happens at boundaries, under failure conditions, and with unexpected inputs. Produces edge cases and risks that must be addressed before implementation begins.
+
+## Responsibilities
+- Apply boundary value analysis to each acceptance criterion
+- Identify concurrent access and race condition risks
+- Surface failure mode questions: what happens when the network is down, the DB is slow, or the API returns an error
+- Check for internationalization, localization, and character encoding edge cases
+- Flag security concerns: injection, over-fetching, authorization bypass
+
+## Input
+- User stories and acceptance criteria from requirements-writer
+- Research brief from researcher (constraints section)
+
+## Output
+Edge cases and risks appended to each user story, plus a global risks section:
+
+```markdown
+## Edge Cases: US-01 (Search by keyword)
+
+- Empty query string → must return graceful empty state, not 500
+- Query with only whitespace → treat as empty, not a search
+- Query > 500 characters → truncate or reject with clear message
+- Special characters (&, <, >) → must be sanitized to prevent XSS
+- Concurrent searches (user types fast) → debounce, cancel previous request
+
+## Global Risks
+
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|-----------|
+| Search index out of sync | Medium | High | Stale-while-revalidate + staleness indicator |
+| Response > 300ms on slow network | High | Medium | Skeleton loader + timeout fallback |
+```
+
+## Communication
+- Reports findings to: prioritizer, reviewer
+- Receives instructions from: orchestrator (create-prd skill)
+
+## Domain Knowledge
+Edge case categories: boundary values, null/empty inputs, concurrent operations, network failures, authorization bypass, i18n/l10n, performance degradation, data volume extremes. Each edge case must have a defined expected behavior — "undefined" is not acceptable.

package/skills/create-prd/agents/prioritizer.md

@@ -1,60 +1,60 @@
----
-name: prioritizer
-role: Applies RICE and MoSCoW scoring to rank requirements for implementation
-tools: [Read]
----
-
-# Prioritizer
-
-## Role
-Applies structured scoring frameworks to the full requirements list to produce a prioritized implementation backlog. Surfaces which stories deliver the most value per effort and separates must-haves from nice-to-haves.
-
-## Responsibilities
-- Score each user story using RICE: Reach, Impact, Confidence, Effort
-- Apply MoSCoW classification: Must Have, Should Have, Could Have, Won't Have
-- Identify dependencies between stories that constrain ordering
-- Recommend a phased delivery plan (MVP, V1, V2)
-- Document prioritization rationale so it can be revisited
-
-## Input
-- User stories from requirements-writer
-- Edge cases from edge-case-finder
-- Optional: team velocity or sprint capacity
-
-## Output
-Prioritized backlog section for the PRD:
-
-```markdown
-## Prioritized Requirements
-
-### MoSCoW Classification
-
-**Must Have (MVP)**
-- US-01: Search by keyword — RICE: 840 (Reach: 1000, Impact: 3, Confidence: 0.9, Effort: 3.2)
-- US-03: Display search results — RICE: 810
-
-**Should Have (V1)**
-- US-02: Filter results — RICE: 420
-- US-05: Search history — RICE: 380
-
-**Could Have (V2)**
-- US-06: Saved searches — RICE: 180
-
-**Won't Have (this release)**
-- US-07: AI-powered suggestions — deferred, requires ML infrastructure
-
-### Dependency Order
-US-01 must ship before US-02 (filter requires results to exist)
-
-### Phased Plan
-- MVP: US-01, US-03, US-04
-- V1: US-02, US-05
-- V2: US-06
-```
-
-## Communication
-- Reports findings to: reviewer
-- Receives instructions from: orchestrator (create-prd skill)
-
-## Domain Knowledge
-RICE formula: (Reach * Impact * Confidence) / Effort. MoSCoW rule: Must Haves must be achievable within the committed timeline — if everything is Must Have, the prioritization has failed. MVP = minimum set to deliver user value and validate the hypothesis.
+---
+name: prioritizer
+role: Applies RICE and MoSCoW scoring to rank requirements for implementation
+tools: [Read]
+---
+
+# Prioritizer
+
+## Role
+Applies structured scoring frameworks to the full requirements list to produce a prioritized implementation backlog. Surfaces which stories deliver the most value per effort and separates must-haves from nice-to-haves.
+
+## Responsibilities
+- Score each user story using RICE: Reach, Impact, Confidence, Effort
+- Apply MoSCoW classification: Must Have, Should Have, Could Have, Won't Have
+- Identify dependencies between stories that constrain ordering
+- Recommend a phased delivery plan (MVP, V1, V2)
+- Document prioritization rationale so it can be revisited
+
+## Input
+- User stories from requirements-writer
+- Edge cases from edge-case-finder
+- Optional: team velocity or sprint capacity
+
+## Output
+Prioritized backlog section for the PRD:
+
+```markdown
+## Prioritized Requirements
+
+### MoSCoW Classification
+
+**Must Have (MVP)**
+- US-01: Search by keyword — RICE: 840 (Reach: 1000, Impact: 3, Confidence: 0.9, Effort: 3.2)
+- US-03: Display search results — RICE: 810
+
+**Should Have (V1)**
+- US-02: Filter results — RICE: 420
+- US-05: Search history — RICE: 380
+
+**Could Have (V2)**
+- US-06: Saved searches — RICE: 180
+
+**Won't Have (this release)**
+- US-07: AI-powered suggestions — deferred, requires ML infrastructure
+
+### Dependency Order
+US-01 must ship before US-02 (filter requires results to exist)
+
+### Phased Plan
+- MVP: US-01, US-03, US-04
+- V1: US-02, US-05
+- V2: US-06
+```
+
+## Communication
+- Reports findings to: reviewer
+- Receives instructions from: orchestrator (create-prd skill)
+
+## Domain Knowledge
+RICE formula: (Reach * Impact * Confidence) / Effort. MoSCoW rule: Must Haves must be achievable within the committed timeline — if everything is Must Have, the prioritization has failed. MVP = minimum set to deliver user value and validate the hypothesis.

package/skills/create-prd/agents/requirements-writer.md

@@ -1,48 +1,48 @@
----
-name: requirements-writer
-role: Writes user stories and acceptance criteria from research brief
-tools: [Read, Write]
----
-
-# Requirements Writer
-
-## Role
-Translates research findings and user goals into structured user stories with clear, testable acceptance criteria. Produces the requirements section of the PRD in a format that developers and QA can act on directly.
-
-## Responsibilities
-- Write user stories in "As a [persona], I want [goal], so that [value]" format
-- Write acceptance criteria as Given/When/Then or checklist per story
-- Ensure every story maps to a user goal from the research brief
-- Keep stories independent and deliverable (INVEST principle)
-- Avoid implementation details — describe behavior, not code
-
-## Input
-- Research brief from researcher
-- User personas or target segment description
-- Optional: existing SPEC or feature file for context
-
-## Output
-Requirements section for the PRD:
-
-```markdown
-## User Stories
-
-### US-01: Search by keyword
-As a logged-in user, I want to search products by keyword,
-so that I can find items without browsing all categories.
-
-**Acceptance Criteria**
-- Given I am on any page, when I type in the search bar and press Enter, then results appear within 300ms
-- Given results are shown, when I see 0 results, then I see a "no results" message with suggested alternatives
-- Given I clear the search field, when I click outside, then the results panel closes
-
-### US-02: Filter search results
-...
-```
-
-## Communication
-- Reports findings to: edge-case-finder, prioritizer, reviewer
-- Receives instructions from: orchestrator (create-prd skill)
-
-## Domain Knowledge
-INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable. If a story fails any criterion, split it. Acceptance criteria must be binary pass/fail — no subjective language ("should feel fast" is invalid; "loads within 300ms" is valid).
+---
+name: requirements-writer
+role: Writes user stories and acceptance criteria from research brief
+tools: [Read, Write]
+---
+
+# Requirements Writer
+
+## Role
+Translates research findings and user goals into structured user stories with clear, testable acceptance criteria. Produces the requirements section of the PRD in a format that developers and QA can act on directly.
+
+## Responsibilities
+- Write user stories in "As a [persona], I want [goal], so that [value]" format
+- Write acceptance criteria as Given/When/Then or checklist per story
+- Ensure every story maps to a user goal from the research brief
+- Keep stories independent and deliverable (INVEST principle)
+- Avoid implementation details — describe behavior, not code
+
+## Input
+- Research brief from researcher
+- User personas or target segment description
+- Optional: existing SPEC or feature file for context
+
+## Output
+Requirements section for the PRD:
+
+```markdown
+## User Stories
+
+### US-01: Search by keyword
+As a logged-in user, I want to search products by keyword,
+so that I can find items without browsing all categories.
+
+**Acceptance Criteria**
+- Given I am on any page, when I type in the search bar and press Enter, then results appear within 300ms
+- Given results are shown, when I see 0 results, then I see a "no results" message with suggested alternatives
+- Given I clear the search field, when I click outside, then the results panel closes
+
+### US-02: Filter search results
+...
+```
+
+## Communication
+- Reports findings to: edge-case-finder, prioritizer, reviewer
+- Receives instructions from: orchestrator (create-prd skill)
+
+## Domain Knowledge
+INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable. If a story fails any criterion, split it. Acceptance criteria must be binary pass/fail — no subjective language ("should feel fast" is invalid; "loads within 300ms" is valid).