@su-record/vibe 3.2.62 → 4.0.0

package/skills/vibe.contract/SKILL.md

@@ -1,232 +0,0 @@
----
-name: vibe.contract
-description: Use when a SPEC API contract may differ from implementation or endpoint and schema drift must be detected.
-argument-hint: "extract | check | diff [feature-name]"
-user-invocable: true
----
-
-# /vibe.contract
-
-**API Contract Drift Detection** — when implementation diverges from the SPEC's API contract, catch it immediately.
-
-> The SPEC is the source of truth. If the implementation silently leaves the SPEC, tests can pass while the contract breaks.
-
-## Usage
-
-```
-/vibe.contract extract <feature>       # SPEC → contract record at .vibe/contracts/<feature>.md
-/vibe.contract check <feature>         # contract vs implementation, drift report
-/vibe.contract diff <feature>          # changed fields since last check
-```
-
-## What counts as an "API contract"
-
-A contract = any **interface shape** that external consumers (clients, other services) depend on:
-
-- HTTP endpoint: method + path + request schema + response schema + status codes
-- GraphQL: query/mutation name + args + return shape
-- Event/message: topic + payload schema
-- Exported TypeScript function signature (when explicitly marked as public API)
-
-## Process
-
-Execute the bundled implementation below with subcommand: `$ARGUMENTS`
-
-**Core steps**:
-
-1. **extract**: parse SPEC sections like `## API` / `## Endpoints` / `## Interface` and persist as a structured contract record
-2. **check**: locate matching endpoints in the implementation, compare signature/schema, report drift as P1 findings
-3. **diff**: compare against the previous snapshot, surface only **changed fields** (noise minimized)
-
-## Drift severity
-
-| Drift type | Severity | Example |
-|---|---|---|
-| Missing endpoint | P1 | SPEC says `GET /users/:id`, implementation has none |
-| Missing required field in response | P1 | SPEC response includes `email`, implementation drops it |
-| Type change (breaking) | P1 | `userId: number` → `userId: string` |
-| Added required request field | P1 | breaks existing clients |
-| Added optional field | P3 | extension is allowed |
-| Status code added | P2 | client must handle a new case |
-| Status code removed | P1 | expected response disappeared |
-
-**On any P1 drift**: treat as failure regardless of `/vibe.verify` outcome — tests can pass while the contract breaks.
-
-## Storage Format
-
-계약 파일의 저장 위치와 frontmatter 스키마는 아래 **Storage Contract** 절이 SSOT다.
-이 문서 안에서 스키마를 두 번 정의하지 않는다 — 과거 이 자리에 있던 축약본은 `id`·`kind`·
-`source-spec-hash` 가 빠진 손실 버전이었다.
-
-## Integration
-
-`/vibe.spec` 직후 `extract`, `/vibe.verify` 시나리오 통과 후 `check` 로 자동 연결된다.
-호출 계약과 drift 등급별 처리(P1 강등 / P2·P3 경고)는 아래 **Integration Points** 절이 SSOT다 —
-이 자리에 있던 요약본은 P1/P2/P3 구분이 빠진 손실 버전이었다.
-
-## Done Criteria
-
-아래 **Done Criteria** 절(Bundled implementation 안)이 SSOT다 — 이 자리에 있던 축약본은
-`source-spec-hash` 재추출 no-op, drift 위치(file:line), 프레임워크 감지 실패 처리가 빠진
-손실 버전이었다.
-
----
-
-ARGUMENTS: $ARGUMENTS
-
-## Bundled implementation
-
-
-# vibe.contract — API Contract Drift Detection
-
-**Purpose**: catch divergence between the SPEC's external contract and the actual implementation. Passing tests ≠ contract preserved.
-
-## Why this exists
-
-Hidden vibe-coding weakness: as the implementation grows, response shapes drift away from what the SPEC documents. Scenario tests still pass — but **external consumers break**. Manual SPEC-vs-code review is high-friction, so mechanize it.
-
-## Storage Contract
-
-```
-.vibe/contracts/
-  <feature>.md             # contract SSOT (extracted from SPEC)
-  <feature>.snapshot.md    # implementation snapshot (last check)
-```
-
-### Contract frontmatter schema
-
-```yaml
----
-feature: string
-extracted-from: .vibe/specs/<feature>.md
-extracted-at: ISO-8601
-source-spec-hash: sha256  # for change detection
-endpoints:
-  - id: unique-kebab-id         # e.g. get-user-by-id
-    kind: http | graphql | event | function
-    # http
-    method: GET | POST | PUT | DELETE | PATCH
-    path: /users/:id
-    request:
-      params: { name: type, ... }
-      query: { name: type, ... }
-      body: { field: type, ... } | null
-      required: [field, ...]
-    response:
-      statusCodes:
-        200: { schema }
-        404: { error: string }
-      required-fields:
-        200: [id, email]
-    # graphql
-    operation: query | mutation
-    name: string
-    args: { ... }
-    returns: { ... }
-    # event
-    topic: string
-    payload: { ... }
-    # function
-    signature: "(a: string, b: number) => Promise<User>"
-    module: path/to/file.ts
----
-```
-
-## Subcommands
-
-### 1. `extract <feature>` — pull contract out of the SPEC
-
-**Steps**:
-1. Load SPEC file (single file or split folder)
-2. Search sections in this order:
-   - `## API` / `## Endpoints` / `## Interface` / `## Contract`
-   - Markdown tables (method/path/request/response headers)
-   - OpenAPI/JSON Schema snippets inside code blocks
-3. Extraction failure (no such section) → **exit cleanly with `no-contract` state**. Not every feature has an API.
-4. Success → convert to the frontmatter structure
-5. `source-spec-hash`: sha256 of SPEC content (for next extract to detect change)
-6. Save to `.vibe/contracts/<feature>.md` (no-op if file exists with the same hash)
-
-**Caveat**: extraction is LLM-driven. Mark low-confidence fields with `# unconfirmed` so the user can review.
-
-### 2. `check <feature>` — contract vs implementation
-
-**Steps**:
-1. Load `.vibe/contracts/<feature>.md`. If missing → **suggest extract first**.
-2. For each endpoint, find implementation:
-   - http: detect framework (Express, Fastify, Next.js API routes, Hono, ...)
-   - graphql: locate resolver files
-   - event: producer/consumer code
-   - function: module export
-3. Extract implementation signature/schema → compare against contract
-4. Classify drift (severity table in command file)
-5. Persist snapshot at `.vibe/contracts/<feature>.snapshot.md` (current implementation state)
-
-### 3. `diff <feature>` — changes since last snapshot
-
-**Steps**:
-1. If `.snapshot.md` does not exist → say "first run" and exit
-2. Re-extract current implementation; compare to existing snapshot
-3. Output **only changed fields** in ASCII diff form:
-   ```
-   endpoints/get-user-by-id/response/200:
-     - email: string
-     + email: string | null   ← nullability added (P1 breaking)
-     + phoneNumber: string    ← new field (P3 safe)
-   ```
-4. On any drift, auto-call `/vibe.regress register --from-contract`
-
-## Integration Points
-
-### From /vibe.spec
-
-Auto-invoke right after the SPEC is written:
-```
-Load skill `vibe.contract` with: extract <feature>
-```
-Failure does not stop `/vibe.spec` (extraction is optional). On success, `/vibe.run` references this contract.
-
-### From /vibe.verify
-
-After all scenarios pass:
-```
-Load skill `vibe.contract` with: check <feature>
-```
-- no drift → verify still passes
-- P1 drift → demote verify to fail; auto-register
-- P2 / P3 drift → warning only; verify still passes
-
-### To /vibe.regress
-
-On P1 drift:
-```
-Load skill `vibe.regress` with:
-  subcommand: register --from-contract
-  feature: <feature>
-  symptom: "Contract drift: <endpoint-id> <drift-type>"
-  root-cause-tag: integration
-```
-
-## Framework Detection Rules
-
-HTTP framework detection order:
-1. `package.json` dependencies: `next` → Next.js API routes
-2. `fastify` → Fastify
-3. `express` → Express
-4. `hono` → Hono
-5. `@nestjs/core` → NestJS
-6. None detected → ask user for manual mapping
-
-After detection, grep for each framework's **route definition pattern** to map endpoints:
-- Next.js: `pages/api/**` or `app/api/**/route.ts`
-- Express: `app.get|post|put|delete|patch\(`
-- Fastify: `fastify.get|post|...` or route configuration
-- Hono: `app.get|post|...`
-
-## Done Criteria
-
-- [ ] `extract` does not error on SPEC without an API section
-- [ ] `source-spec-hash`-based re-extract is a no-op when unchanged
-- [ ] `check` reports each drift with severity + location (file:line)
-- [ ] P1 drift always invokes `/vibe.regress`
-- [ ] On framework detection failure, ask the user — do not silently skip

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

@@ -1,98 +0,0 @@
----
-name: vibe.create-prd
-invocation: [auto, chain]
-tier: standard
-description: "Use when a product idea or research input must become an implementation-ready PRD covering the problem, objectives, segments, value propositions, solution, and release plan."
-triggers: [prd, product requirements, feature spec, requirements document]
-priority: 60
-chain-next: [vibe.user-personas, vibe.prioritization]
----
-
-# Create a Product Requirements Document
-
-## Done Criteria
-
-- [ ] PRD 파일이 요청된 출력 경로에 존재한다.
-- [ ] 8개 필수 섹션이 모두 비어 있지 않다.
-- [ ] 목표마다 측정 가능한 성공 지표가 있다.
-- [ ] release 범위와 제외 범위가 명시되어 있다.
-
-> 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/vibe.create-prd/agents/edge-case-finder.md

@@ -1,48 +0,0 @@
----
-name: prd-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 prd-requirements-writer
-- Research brief from prd-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: prd-prioritizer, prd-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/vibe.create-prd/agents/prioritizer.md

@@ -1,60 +0,0 @@
----
-name: prd-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 prd-requirements-writer
-- Edge cases from prd-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: prd-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/vibe.create-prd/agents/requirements-writer.md

@@ -1,48 +0,0 @@
----
-name: prd-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 prd-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: prd-edge-case-finder, prd-prioritizer, prd-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).

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

@@ -1,55 +0,0 @@
----
-name: prd-researcher
-role: Gathers market context and user needs using web search and codebase analysis
-tools: [WebSearch, Read, Glob, Grep, Bash]
----
-
-# Researcher
-
-## Role
-Gathers external context — competitor patterns, industry standards, user expectations — and internal context — existing codebase conventions, current pain points — to ground the PRD in evidence rather than assumption.
-
-## Responsibilities
-- Search for how competitors and industry leaders solve this problem
-- Identify common user expectations and mental models for this feature type
-- Review existing codebase for related patterns, conventions, or prior art
-- Surface relevant regulatory, accessibility, or compliance constraints
-- Compile source references so prd-requirements-writer can cite evidence
-
-## Input
-- Feature or problem description from the user
-- Optional: competitor URLs, target persona, or market segment
-
-## Output
-Research brief:
-
-```markdown
-## Research Brief: {Feature Name}
-
-### Market Context
-- Competitor A solves this with [approach] — key pattern: [detail]
-- Industry standard: [convention with source URL]
-
-### User Expectations
-- Users expect [behavior] based on [evidence]
-- Common mental model: [description]
-
-### Internal Context
-- Existing related code: src/modules/billing/ uses [pattern]
-- Prior art: feature X (PR #42) solved a similar problem with [approach]
-
-### Constraints Identified
-- WCAG 2.1 AA applies to any user-facing form
-- GDPR: consent required before storing search history
-
-### Sources
-- [URL 1]: description
-- [URL 2]: description
-```
-
-## Communication
-- Reports findings to: prd-requirements-writer, prd-edge-case-finder
-- Receives instructions from: orchestrator (create-prd skill)
-
-## Domain Knowledge
-Evidence hierarchy: user research > competitor analysis > industry convention > engineering preference. Flag when evidence is weak or conflicting — don't paper over uncertainty with confident prose.

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
-```