@su-record/vibe 3.2.64 → 4.0.0

package/skills/vibe.create-prd/agents/reviewer.md

@@ -1,54 +0,0 @@
----
-name: prd-reviewer
-role: Reviews PRD completeness and testability before sign-off
-tools: [Read]
----
-
-# Reviewer
-
-## Role
-Final quality gate for the PRD. Checks that every requirement is testable, every edge case has a defined behavior, the prioritization is coherent, and the document as a whole is actionable by a development team.
-
-## Responsibilities
-- Verify every acceptance criterion is binary pass/fail (no subjective language)
-- Check that every edge case has a defined expected behavior, not just a question
-- Confirm MoSCoW Must Haves are actually achievable (not wishlist items)
-- Flag any requirement that lacks acceptance criteria
-- Identify missing non-functional requirements: performance, security, accessibility
-
-## Input
-- Complete PRD draft assembled from all agents
-- Edge cases from prd-edge-case-finder
-- Prioritized backlog from prd-prioritizer
-
-## Output
-PRD review report:
-
-```markdown
-## PRD Review
-
-### Completeness Check
-- [x] All user stories have acceptance criteria
-- [x] All edge cases have defined expected behavior
-- [ ] MISSING: Performance requirement — search latency SLA not specified
-- [ ] MISSING: Accessibility requirement — WCAG level not stated
-- [x] Prioritization has clear MVP boundary
-
-### Testability Check
-- US-01 AC-3: "results appear quickly" — VAGUE, must specify ms target
-- US-02 AC-1: all criteria are binary pass/fail
-
-### Coherence Check
-- [x] Must Haves are a feasible MVP scope
-- [x] Dependencies between stories are noted
-
-### Verdict
-NEEDS REVISION — 3 items before this PRD can be used for sprint planning.
-```
-
-## Communication
-- Reports findings to: orchestrator (create-prd skill) / user
-- Receives instructions from: orchestrator
-
-## Domain Knowledge
-A PRD is testable if a QA engineer can write a test case for every acceptance criterion without asking the author for clarification. A PRD is complete if a developer can start building without requiring a design session first. Anything short of these standards requires revision.

package/skills/vibe.create-prd/frameworks/jobs-to-be-done.md

@@ -1,96 +0,0 @@
----
-name: jobs-to-be-done
-type: framework
-applies-to: [create-prd]
----
-
-# Jobs-to-Be-Done (JTBD) — Reference Card
-
-## Core Concept
-
-Users don't buy products — they **hire** them to do a job. Focus on the job, not the user persona.
-
-> "People don't want a quarter-inch drill. They want a quarter-inch hole." — Theodore Levitt
-
-## Job Statement Format
-
-```
-When [situation], I want to [motivation/goal], so I can [expected outcome].
-```
-
-**Example**:
-- When I finish a long meeting, I want to quickly capture action items, so I can follow up without forgetting anything.
-- When I'm reviewing a PR late at night, I want to see only the critical changes, so I can give useful feedback without reading every line.
-
-## Three Layers of Jobs
-
-| Layer | Description | Example |
-|-------|-------------|---------|
-| **Functional** | The practical task to be done | "Send a file to a colleague" |
-| **Emotional** | How the user wants to feel | "Feel confident I sent the right version" |
-| **Social** | How the user wants to be perceived | "Look organized and professional to my team" |
-
-All three layers matter. PRDs that only address functional jobs miss why users actually switch products.
-
-## Forces of Progress (Four Forces)
-
-| Force | Direction | Question to Ask |
-|-------|-----------|-----------------|
-| Push | Away from current solution | "What frustrates users about the current way?" |
-| Pull | Toward new solution | "What does the new solution promise?" |
-| Anxiety | Against switching | "What risks do users fear about changing?" |
-| Habit | Against switching | "What inertia keeps users in current behavior?" |
-
-Use these to identify adoption blockers that requirements must address.
-
-## Job Map (Stages)
-
-Every job has 8 universal stages:
-
-1. **Define** — Determine goals and plan the approach
-2. **Locate** — Gather needed inputs and information
-3. **Prepare** — Set up the environment for execution
-4. **Confirm** — Verify readiness before execution
-5. **Execute** — Carry out the core task
-6. **Monitor** — Track progress during execution
-7. **Modify** — Make adjustments as needed
-8. **Conclude** — Finish and wrap up the task
-
-Map each stage to identify where the current experience fails — those gaps become requirements.
-
-## Job Story vs. User Story
-
-| Format | Template | Focus |
-|--------|----------|-------|
-| User Story | As a [persona], I want [feature], so that [benefit] | Who the user is |
-| Job Story | When [situation], I want [motivation], so I can [outcome] | Context and causality |
-
-Job stories remove persona assumptions and focus on the triggering situation.
-
-```
-// User Story (persona-focused)
-As a project manager, I want to see task status, so I know project health.
-
-// Job Story (situation-focused)
-When a stakeholder asks for a status update unexpectedly,
-I want to pull up a project summary in under 10 seconds,
-so I can answer confidently without scrambling through notes.
-```
-
-## PRD Integration
-
-For each major requirement, document:
-
-1. **The Job**: What job does this feature help users complete?
-2. **Situation**: When does the need arise? (trigger context)
-3. **Success Metric**: How will we know the job is being done better?
-4. **Switch Moment**: What is the user currently hiring instead? (workaround)
-
-```markdown
-### Feature: Quick Status Summary
-
-**Job**: Get an instant project health snapshot when asked unexpectedly
-**Situation**: During ad-hoc stakeholder conversations or async check-ins
-**Currently Hired**: Scrolling through chat history + mental approximation
-**Success Metric**: Time-to-answer reduced from ~3min to <30s
-```

package/skills/vibe.create-prd/frameworks/rice-scoring.md

@@ -1,97 +0,0 @@
----
-name: rice-scoring
-type: framework
-applies-to: [create-prd]
----
-
-# RICE Scoring — Reference Card
-
-## Formula
-
-```
-RICE Score = (Reach × Impact × Confidence) / Effort
-```
-
-## Factor Definitions
-
-### Reach
-How many users affected per time period (e.g., per quarter)?
-
-| Scale | Example |
-|-------|---------|
-| 1,000 | Affects ~1,000 users/quarter |
-| 5,000 | Affects ~5,000 users/quarter |
-| 50,000 | Affects most of the user base |
-
-Use actual user counts when available. Use relative estimates otherwise.
-
-### Impact
-How much does this move the needle for each user?
-
-| Score | Meaning |
-|-------|---------|
-| 3 | Massive — core workflow improvement |
-| 2 | High — significant UX enhancement |
-| 1 | Medium — noticeable improvement |
-| 0.5 | Low — minor convenience |
-| 0.25 | Minimal — rarely noticed |
-
-### Confidence
-How confident are you in the Reach and Impact estimates?
-
-| Score | Meaning |
-|-------|---------|
-| 100% | Data-backed (user research, analytics) |
-| 80% | Some evidence (interviews, comparable features) |
-| 50% | Gut feeling, limited data |
-| 20% | Pure hypothesis, no data |
-
-### Effort
-Total person-weeks to design, build, and ship.
-
-| Score | Meaning |
-|-------|---------|
-| 0.5 | Half a week or less |
-| 1 | About 1 week |
-| 2 | ~2 weeks |
-| 5 | ~1 month |
-| 10 | Multi-month project |
-
-## Calculation Examples
-
-| Feature | Reach | Impact | Confidence | Effort | RICE Score |
-|---------|-------|--------|------------|--------|------------|
-| One-click checkout | 8,000 | 3 | 80% | 3 | **6,400** |
-| Dark mode toggle | 5,000 | 0.5 | 50% | 1 | **1,250** |
-| Export to CSV | 2,000 | 2 | 100% | 0.5 | **8,000** |
-| AI search | 10,000 | 2 | 50% | 10 | **1,000** |
-
-Higher score = higher priority.
-
-## Prioritization Tiers
-
-| RICE Score | Tier | Action |
-|------------|------|--------|
-| >5,000 | P0 — Must Ship | Schedule immediately |
-| 1,000–5,000 | P1 — High Priority | Include in next cycle |
-| 200–999 | P2 — Medium Priority | Backlog, revisit quarterly |
-| <200 | P3 — Low Priority | Won't do / nice to have |
-
-## When Data is Unavailable
-
-Use relative RICE (rank order, not absolute scores):
-- Assign all factors on 1–10 scale relative to each other
-- Note confidence as Low/Medium/High instead of percentages
-- Mark scores as estimates in PRD: `~2,400 (estimated)`
-
-## PRD Integration
-
-In the PRD, present RICE scores in the requirements table:
-
-```markdown
-| Story | Reach | Impact | Confidence | Effort | Score | Priority |
-|-------|-------|--------|------------|--------|-------|----------|
-| ...   | 5,000 | 2      | 80%        | 2      | 4,000 | P1       |
-```
-
-Always document assumptions used in scoring under the table.

package/skills/vibe.create-prd/orchestrator.md

@@ -1,72 +0,0 @@
----
-name: create-prd-orchestrator
-type: orchestrator
-agents: [researcher, edge-case-finder, requirements-writer, prioritizer, reviewer]
----
-
-# Create-PRD Orchestrator
-
-> 구조·섹션·네이밍은 vibe/rules/orchestrator-contract.md (SSOT) 를 따른다.
-
-## Workflow
-
-### Phase 1: Gather Context
-- **Agent**: researcher, edge-case-finder
-- **Input**: Feature idea or problem statement + codebase context
-- **Output**: researcher → existing patterns, prior art, constraints; edge-case-finder → edge cases, failure modes, user scenarios
-- **Parallel**: yes — researcher and edge-case-finder run simultaneously
-
-### Phase 2: Draft User Stories
-- **Agent**: requirements-writer
-- **Input**: Context and edge cases from Phase 1
-- **Output**: User stories in `As a / I want / So that` format with acceptance criteria
-- **Parallel**: no — sequential synthesis of Phase 1 outputs
-
-### Phase 3: Prioritize
-- **Agent**: prioritizer
-- **Input**: User stories from Phase 2
-- **Output**: RICE-scored stories with recommended MoSCoW classification (Must/Should/Could/Won't)
-- **Parallel**: no — requires full story set for relative scoring
-
-### Phase 4: Review
-- **Agent**: reviewer
-- **Input**: Prioritized stories + RICE scores from Phase 3
-- **Output**: Completeness verdict — missing sections, ambiguous requirements, scope concerns
-- **Parallel**: no
-
-### Phase 5: Output PRD
-- **Agent**: orchestrator (self)
-- **Input**: All phase outputs
-- **Output**: Structured PRD document using `templates/prd.md` format
-- **Parallel**: no
-
-## DAG (Dependency Graph)
-
-```mermaid
-graph TD
-    A[Phase 1a: Researcher] --> C[Phase 2: Requirements-Writer]
-    B[Phase 1b: Edge-Case-Finder] --> C
-    C --> D[Phase 3: Prioritizer]
-    D --> E[Phase 4: Reviewer]
-    E --> F[Phase 5: PRD Output]
-```
-
-## Error Handling
-
-| Phase | Failure Mode | Strategy |
-|-------|-------------|----------|
-| Phase 1 | researcher returns no prior art | Proceed — note "greenfield feature" in PRD |
-| Phase 1 | edge-case-finder times out | Continue with researcher output only, flag limited edge-case coverage |
-| Phase 2 | Problem statement too vague | Pause, prompt user with clarifying questions before continuing |
-| Phase 3 | RICE data unavailable (no metrics) | Use relative scoring (High/Medium/Low), note data gaps |
-| Phase 4 | Reviewer finds critical gaps | Return to Phase 2 with gap list (max 1 retry) |
-| Phase 4 | Retry still incomplete after 1 pass | Flag gaps as `needs-clarification`, output partial PRD |
-| Phase 5 | PRD template missing | Output raw structured markdown without template |
-
-## Scalability Modes
-
-| Mode | When | Agents Used |
-|------|------|-------------|
-| Full | Normal operation | All 5 agents |
-| Reduced | Time pressure | researcher + requirements-writer + reviewer only |
-| Single | Quick story draft | requirements-writer only — draft without research or scoring |

package/skills/vibe.create-prd/rubrics/completeness.md

@@ -1,58 +0,0 @@
-# PRD Completeness Checklist
-
-## Section 1 — Summary
-
-- [ ] Describes what the document is about in 2-3 sentences
-- [ ] Readable by a non-technical stakeholder
-- [ ] Status clearly marked (Draft / Review / Approved)
-
-## Section 2 — Contacts
-
-- [ ] Product Manager named as owner
-- [ ] Engineering Lead included
-- [ ] Designer included (if UI/UX involved)
-- [ ] Key decision-maker or sponsor listed
-
-## Section 3 — Background
-
-- [ ] "Why this?" answered — clear context given
-- [ ] "Why now?" answered — trigger or change identified
-- [ ] No assumed knowledge — first-time reader can understand
-
-## Section 4 — Objective
-
-- [ ] Goal statement is outcome-oriented (not feature-oriented)
-- [ ] At least one measurable Key Result with baseline, target, and timeframe
-- [ ] Linked to company strategy or OKR (even briefly)
-
-## Section 5 — Market Segments
-
-- [ ] Primary audience defined by problem or job-to-be-done (not just demographics)
-- [ ] Constraints explicitly stated (who this is NOT for)
-
-## Section 6 — Value Propositions
-
-- [ ] Customer jobs listed (what users are trying to accomplish)
-- [ ] Gains (benefits) distinguished from pains (problems removed)
-- [ ] Competitive differentiation stated — why us, why better
-
-## Section 7 — Solution
-
-- [ ] 7.1: Prototype link or key screen descriptions included
-- [ ] 7.2: Features table includes priority (Must / Should / Could)
-- [ ] 7.4: At least 2 assumptions listed with validation method
-- [ ] No feature described without a corresponding user job or pain from Section 6
-
-## Section 8 — Release
-
-- [ ] MVP scope defined — what is in V1 vs. later
-- [ ] Out-of-scope items explicitly listed (prevents scope creep)
-- [ ] Relative timeframes used — no hard dates in V1 unless confirmed
-
-## Overall Quality
-
-- [ ] Jargon-free — a new team member can understand without asking
-- [ ] No sections left as placeholder ("TBD" without owner + due date)
-- [ ] Assumptions are flagged, not buried as facts
-- [ ] Document length proportional to initiative size (not bloated)
-- [ ] Open questions have owners and due dates

package/skills/vibe.create-prd/templates/prd.md

@@ -1,139 +0,0 @@
-# PRD: {{PRODUCT_OR_FEATURE_NAME}}
-
-> Version: {{VERSION}} | Status: {{STATUS}} (Draft / Review / Approved)
-> Last updated: {{DATE}}
-
----
-
-## 1. Summary
-
-{{2-3 SENTENCES DESCRIBING WHAT THIS DOCUMENT COVERS AND WHY IT EXISTS}}
-
----
-
-## 2. Contacts
-
-| Name | Role | Responsibility |
-|------|------|----------------|
-| {{PM_NAME}} | Product Manager | Owner, final decisions |
-| {{LEAD_ENG_NAME}} | Engineering Lead | Technical feasibility |
-| {{DESIGN_NAME}} | Designer | UX/UI |
-| {{STAKEHOLDER_NAME}} | {{STAKEHOLDER_ROLE}} | {{COMMENT}} |
-
----
-
-## 3. Background
-
-**Context**
-{{WHAT IS THIS INITIATIVE ABOUT? WHAT LED TO IT?}}
-
-**Why now?**
-{{HAS SOMETHING CHANGED? NEW DATA, MARKET SHIFT, REGULATORY REQUIREMENT?}}
-
-**Is this newly possible?**
-{{HAS NEW TECHNOLOGY OR CAPABILITY MADE THIS FEASIBLE NOW?}}
-
----
-
-## 4. Objective
-
-**Goal**
-{{WHAT ARE WE TRYING TO ACHIEVE AND WHY DOES IT MATTER?}}
-
-**Strategic alignment**
-{{HOW DOES THIS ALIGN WITH COMPANY VISION AND CURRENT STRATEGY?}}
-
-**Key Results (SMART OKRs)**
-
-| Metric | Baseline | Target | Timeframe |
-|--------|----------|--------|-----------|
-| {{METRIC_1}} | {{BASELINE}} | {{TARGET}} | {{TIMEFRAME}} |
-| {{METRIC_2}} | {{BASELINE}} | {{TARGET}} | {{TIMEFRAME}} |
-
----
-
-## 5. Market Segments
-
-**Primary segment**
-{{WHO ARE WE BUILDING THIS FOR? DESCRIBE BY PROBLEM/JOB, NOT DEMOGRAPHICS.}}
-
-**Secondary segment (if any)**
-{{OPTIONAL}}
-
-**Constraints**
-- {{CONSTRAINT_1}} (e.g., "Users must be logged in")
-- {{CONSTRAINT_2}}
-
----
-
-## 6. Value Propositions
-
-**Customer jobs we address**
-- {{JOB_1}}: {{CONTEXT}}
-- {{JOB_2}}: {{CONTEXT}}
-
-**Gains (what customers get)**
-- {{GAIN_1}}
-- {{GAIN_2}}
-
-**Pains we eliminate**
-- {{PAIN_1}}
-- {{PAIN_2}}
-
-**Competitive advantage**
-{{HOW DO WE SOLVE THIS BETTER THAN ALTERNATIVES? WHAT IS OUR UNIQUE EDGE?}}
-
----
-
-## 7. Solution
-
-### 7.1 UX / Prototypes
-
-{{LINK TO FIGMA OR WIREFRAMES, OR DESCRIBE KEY SCREENS/FLOWS}}
-
-Key user flows:
-1. {{FLOW_1_NAME}}: {{BRIEF DESCRIPTION}}
-2. {{FLOW_2_NAME}}: {{BRIEF DESCRIPTION}}
-
-### 7.2 Key Features
-
-| Feature | Description | Priority |
-|---------|-------------|----------|
-| {{FEATURE_1}} | {{DESCRIPTION}} | Must |
-| {{FEATURE_2}} | {{DESCRIPTION}} | Should |
-| {{FEATURE_3}} | {{DESCRIPTION}} | Could |
-
-### 7.3 Technology (optional)
-
-{{ONLY INCLUDE IF TECH CHOICES HAVE PRODUCT IMPLICATIONS — e.g., real-time, offline support}}
-
-### 7.4 Assumptions
-
-| # | Assumption | How to Validate | Risk if Wrong |
-|---|-----------|-----------------|---------------|
-| 1 | {{ASSUMPTION_1}} | {{VALIDATION_METHOD}} | {{RISK}} |
-| 2 | {{ASSUMPTION_2}} | {{VALIDATION_METHOD}} | {{RISK}} |
-
----
-
-## 8. Release Plan
-
-**Scope approach**: {{PHASED / BIG BANG / GRADUAL ROLLOUT}}
-
-| Phase | What's Included | Estimated Timeline |
-|-------|----------------|-------------------|
-| V1 (MVP) | {{MVP_SCOPE}} | {{RELATIVE_TIME}} |
-| V2 | {{V2_SCOPE}} | {{RELATIVE_TIME}} |
-| Future | {{FUTURE_ITEMS}} | TBD |
-
-**Out of scope (V1)**
-- {{OUT_OF_SCOPE_1}}
-- {{OUT_OF_SCOPE_2}}
-
----
-
-## Open Questions
-
-| # | Question | Owner | Due |
-|---|----------|-------|-----|
-| 1 | {{QUESTION_1}} | {{OWNER}} | {{DATE}} |