@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.clone/references/scaffold-phases.md

@@ -1,59 +0,0 @@
-# Clone — Phase 3A/3B/3C Builder Contract
-
-> Loaded by vibe.clone SKILL.md Phase 3 (Scaffold) — full prep/dispatch/merge steps for MO/PC scaffold, the 150-line split rule, framework mapping, Phase 3C's import-switch/selector-review steps, and Claude's role checklist. Phase headers, Input lines, and script invocation commands stay in SKILL.md; this file covers the supporting detail only.
-
-```
-  Prep (sequential, once):
-    a. Step 0: clone-spec.js → emit _specs/mo/{Section}.spec.md for every section
-    b. Step A: clone-to-scss.js → SCSS draft in styles/{feature}/mo/ (computed values)
-    c. Orchestrator resolves every spec TODO BEFORE dispatch:
-       ├─ Confirm the interaction model (spec.interaction is a heuristic guess;
-       │  the spec's active-capture "Dynamic behaviors" block overrides it on conflict)
-       ├─ List the states to implement (spec.states + Dynamic behaviors)
-       ├─ Mark copyrighted text for placeholder replacement (skip with --real-content)
-       └─ Map component candidates against component-index.json (reuse vs create)
-    d. 150-line split rule (mechanical — wc -l, don't override with "but it's related"):
-       a completed spec over 150 lines means the section is too big for one builder →
-       split into sub-component specs (one per card variant / repeated pattern) + one
-       wrapper spec that imports them.
-  Dispatch (parallel):
-    ⛔ Every builder prompt embeds the FULL spec text INLINE — never "go read the file".
-       The spec file stays on disk as the audit trail; the prompt must be self-sufficient.
-    ⛔ Builders that write files in parallel run in worktree isolation; sub-component
-       builders complete before their wrapper builder starts.
-    Builder contract (each agent):
-      1. Build HTML structure + semantic tags + framework-specific component file
-         ⛔ No CSS in <style> blocks — only @import/@use of styles/{feature}/mo/
-         ⛔ Build for the CONFIRMED interaction model in the spec; wire every state
-         Framework mapping:
-           - React/Next → .tsx with CSS Modules or styled-components per stack
-           - Vue/Nuxt   → .vue with scoped <style lang="scss"> @import only
-           - Svelte     → .svelte with <style> @import only
-           - Vanilla    → .html + linked .scss
-      2. Asset references → public/images/{feature}/ (already populated in Phase 1)
-      3. SCSS edits per Immutable Rule 1 (evidence-cited only)
-      4. Verify compile (tsc --noEmit or stack equivalent) before finishing
-  Merge (orchestrator, as builders complete):
-    5. Merge worktrees; resolve conflicts (you have full context on every spec)
-    6. clone-validate.js per section — Step B
-       ├─ PASS → section done
-       └─ FAIL → fix discrepancies → re-run step 6 (loop until P1=0, no round cap)
-
-  2. Switch component style imports from styles/{feature}/{bp}/index.scss to the merged
-     styles/{feature}/index.scss
-  3. Review pc-only/mo-only selectors in the merge report — hide/show them with the
-     media query if the original does (evidence: the two sections.json trees)
-
-Claude's role:
-  ✅ Component candidates: decide which patterns become reusable components
-  ✅ HTML semantics: section/h1/p/button/nav tag selection
-  ✅ Text replacement: substitute copyrighted copy with placeholders or user-supplied text
-  ✅ Interaction model: confirm the spec's heuristic guess, then build for the real model
-  ✅ Interactions: implement every state in the spec (hover/focus/active/open), click handlers
-  ✅ SCSS value edits WITH cited evidence (computed.json/states.json/behaviors.json) —
-     clone-validate.js PASS is the judge
-  ❌ Do NOT invent CSS values without extraction evidence
-  ❌ Do NOT write CSS directly in <style> blocks
-  ❌ Do NOT hand-write vw/clamp/@media in Phase 3A/3B (responsive comes from Phase 3C merge)
-  ❌ Do NOT hotlink remote URLs — all assets must use local public/images/ paths
-```

package/skills/vibe.clone/references/setup-and-layout.md

@@ -1,64 +0,0 @@
-# Clone — Setup Steps & Output Layout
-
-> Loaded by vibe.clone SKILL.md Full Flow / Phase 0 (Setup) — working-directory + code-output layout and the full Phase 0 setup steps.
-
-```
-Working directory:
-  /tmp/{feature}/
-  ├── mo/ (375×812)  — rendered.html, computed.json, screenshot.png, assets/, sections.json
-  ├── pc/ (1440×900) — rendered.html, computed.json, screenshot.png, assets/, sections.json
-  └── tokens.json    — extracted design tokens (colors/fonts/spacing)
-
-Code output: placed directly in the project directory per detected stack
-  components/{feature}/, components/{feature}/_specs/{mo,pc}/,
-  styles/{feature}/{mo,pc}/ (per-BP drafts) → styles/{feature}/ (Phase 3C merged),
-  public/images/{feature}/, public/ (favicons/OG from assets/seo/)
-```
-
-```
-1. Stack detection:
-   - .vibe/config.json → stack (react/vue/next/svelte/vanilla, scss/tailwind/css-modules)
-   - Fallback: package.json deps
-2. Feature name: URL hostname → kebab-case (e.g. stripe.com → stripe-clone)
-   - User may override with --name=<custom>
-3. Directories:
-   - components/{feature}/, styles/{feature}/, public/images/{feature}/
-4. Component indexing → /tmp/{feature}/component-index.json
-   (scan up to 50 existing components, extract props/slots/classes, within 2 minutes)
-5. Design token scan → /tmp/{feature}/project-tokens.json
-   (SCSS > CSS Variables > Tailwind > CSS-in-JS)
-```
-
-## Full output locations
-
-```
-/tmp/{feature}/                  # 작업 디렉토리 (산출물 원본)
-  ├── menu-urls.json             # --sub URL 확장 결과
-  ├── mo/, pc/                   # rendered.html, computed.json, screenshot.png, states.json,
-  │                              #   behaviors.json, sections.json, assets/
-  └── project-tokens.json        # 기존 프로젝트 토큰 인덱스
-
-./components/{feature}/                  # 빌더가 작성한 컴포넌트 (.tsx/.vue/.svelte/.html)
-./components/{feature}/_specs/{mo,pc}/   # clone-spec.js가 생성한 섹션별 빌드 계약서 (*.spec.md)
-./styles/{feature}/                      # 최종 병합 SCSS (Phase 3C 산출 — mobile-first @media)
-  ├── mo/, pc/                   # BP별 SCSS 초안 (clone-to-scss.js + 근거 기반 수정)
-  ├── _tokens.scss               # CSS 변수 (병합)
-  ├── _base.scss                 # @font-face
-  ├── _shared.scss               # 유틸 + 글로벌 동작 (scroll-lib 등)
-  ├── sections/_<name>.scss      # 섹션별 partial (병합)
-  ├── index.scss                 # 마스터 orchestrator (병합)
-  └── class-plan.json            # 노드 id → BEM 클래스 (병합)
-./public/images/{feature}/       # 다운로드된 이미지/폰트
-./public/ (프로젝트 관례 경로)     # favicon·OG·manifest (assets/seo/ 에서 배선)
-```
-
-## Capture artifacts (Phase 1 output per breakpoint)
-
-`rendered.html`, `computed.json`, `screenshot.png`, `states.json`, `behaviors.json`,
-`asset-map.json`, `assets/` (images·fonts·seo).
-
-- `behaviors.json` = active interaction sweep, 4+ kinds (scroll header diff · tab-click content
-  swap · hover diff · in-view entrance animation · time-driven carousel candidates · smooth-scroll
-  library detection). It captures JS-set state that static CSS harvesting is blind to — the core of
-  clone accuracy. Disable with `--no-interact`.
-- `assets/seo/` = favicon · apple-touch-icon · og:image · webmanifest, wired during Phase 2.5.

package/skills/vibe.clone/references/verification-loops.md

@@ -1,67 +0,0 @@
-# Clone — Phase 4 Compile Gate & Phase 5 Pixel Verification
-
-> Loaded by vibe.clone SKILL.md Phases 4–5. Both loops follow `vibe/rules/loop-contract.md`
-> (ANCHOR→ACT→JUDGE→RECORD); exit = gates pass │ stuck │ max-iter.
-
-## Phase 4: Compile Gate
-
-```
-No round cap. Loop until compile succeeds (or stuck → end loop; automationLevel decides
-whether the user is asked — see Termination below).
-
-0. Capture baseline (before Phase 3): record existing tsc + build errors
-   → Phase 4 only fixes NEW errors
-
-1. TypeScript: vue-tsc / svelte-check / tsc --noEmit
-2. Build: npm run build (120s timeout)
-3. Dev server: npm run dev → detect port → polling
-
-On error: parse → auto-fix → re-check
-Termination:
-  ✅ Success: all checks pass → enter Phase 5
-  ⚠️ Stuck: same errors as previous round → ask user
-     1. Direct fix instructions → retry
-     2. "proceed" — record remaining errors as TODO, proceed to Phase 5
-     3. "abort" — halt
-  automationLevel: autonomous → on stuck, record TODO without prompting and proceed
-
-⛔ Must enter Phase 5 after Phase 4 passes. Do NOT output a "completion summary".
-```
-
-## Phase 5: Pixel Verification Loop — MANDATORY
-
-**⛔ Phase 5 is mandatory, not optional. Enter automatically after Phase 4.**
-**⛔ Skipping Phase 5 makes the entire clone "incomplete".**
-
-```
-No round cap. Loop until P1=0 (or stuck → end loop; automationLevel decides whether the
-user is asked — see Termination below).
-Infrastructure: src/infra/lib/browser/ (Puppeteer + CDP) — same as figma Phase 6.
-
-1. Render scaffolded page in dev server at matching viewport
-2. Capture screenshot → pixelmatch comparison against /tmp/{feature}/{bp}/screenshot.png
-   diffRatio > 0.05 (clone target is tighter than figma) → P1
-3. CSS comparison: live computed CSS vs /tmp/{feature}/{bp}/computed.json
-   delta > 2px → P1, ≤ 2px → P2
-4. Asset audit: every <img>/background-image resolves to local public/images/ path → else P1
-5. Fix P1 first (refer to computed.json, no guessing) → revalidate compile → reload
-
-Narrowing scope:
-  Round 1: P1+P2+P3
-  Round 2: P1+P2
-  Round 3+: P1 only
-
-Termination:
-  ✅ P1=0 AND no new findings → complete
-  ⚠️ Stuck: same findings → ask user (resolve / proceed / abort)
-  automationLevel: autonomous → on stuck, record TODO without prompting and end the loop
-     as `stuck` — never record unresolved P1 as complete (SSOT: vibe/rules/loop-contract.md)
-
-Responsive: after MO verification → change viewport → repeat against PC screenshot
-Post-merge (Phase 3C): re-run at BOTH viewports (375×812 vs mo/screenshot.png,
-  1440×900 vs pc/screenshot.png) — either failing means the merge regressed; fix the
-  merged SCSS (evidence: the per-BP sections.json), never by re-guessing values
-Cleanup: shut down browser + dev server
-
-⛔ "Completion summary" output only allowed after Phase 5 completes.
-```

package/skills/vibe.commerce-patterns/SKILL.md

@@ -1,65 +0,0 @@
----
-name: vibe.commerce-patterns
-invocation: [auto]
-tier: core
-description: "E-commerce domain patterns — cart management, payment processing (Toss/Stripe/PG), inventory tracking, and order state machines with transaction safety. Use when implementing any shopping cart, checkout flow, payment integration, stock management, or order lifecycle. Covers idempotency keys, double-charge prevention, stock reservation, and refund flows. Must use this skill when the codebase involves e-commerce — even for seemingly simple 'add to cart' features."
-triggers: [commerce, ecommerce, cart, payment, checkout, inventory, toss, stripe, order flow]
-priority: 60
----
-
-# Commerce Patterns
-
-## Pre-check (K1)
-
-> Is this an e-commerce transaction flow? If building simple CRUD without payment/stock management, this skill is not needed.
-
-## Gotchas & Traps
-
-These are the non-obvious failure modes LLMs typically miss:
-
-### Payment
-
-| Trap | Consequence | Prevention |
-|------|-------------|------------|
-| No idempotency key | User double-clicks → charged twice | `idempotencyKey: order_${orderId}_${timestamp}` on every payment request |
-| Webhook not idempotent | Retry delivers duplicate events | Check `eventId` before processing, store processed events |
-| Missing webhook signature verification | Attacker forges payment confirmation | Always verify HMAC signature before processing |
-| No payment state machine | Order stuck in limbo | `PENDING → PROCESSING → AUTHORIZED → CAPTURED → COMPLETED` (+ FAILED, CANCELED, REFUNDED) |
-
-### Inventory
-
-| Trap | Consequence | Prevention |
-|------|-------------|------------|
-| Non-atomic stock decrement | Race condition → negative stock | `UPDATE SET stock = stock - $1 WHERE stock >= $1` (atomic with check) |
-| No reservation TTL | Stock locked forever on abandoned checkout | 15-min reservation + scheduled cleanup job |
-| Commit without reservation | Stock sold twice | Two-phase: RESERVE (checkout start) → COMMIT (payment success) / RELEASE (failure) |
-| Optimistic lock without retry | Fails silently under contention | Use `version` column or `FOR UPDATE` for high-contention products |
-
-### Cart & Pricing
-
-| Trap | Consequence | Prevention |
-|------|-------------|------------|
-| No price snapshot | Price changes between add and checkout | Store `price` at add time, revalidate at checkout entry |
-| No guest→user cart merge | Guest loses cart on login | Merge by `sessionId` on login, user cart takes priority for duplicates |
-| No cart expiration | Abandoned carts accumulate forever | TTL-based cleanup (e.g., 7 days) |
-
-## Checkout Flow (Reference)
-
-```
-Cart Validation → Order Creation (PENDING) → Stock Reservation (15min) → Payment
-  ├─ Success → Order PAID, Stock COMMIT, Send Confirmation
-  └─ Failure → Order FAILED, Stock RELEASE
-```
-
-## Related
-
-See `e2e-commerce` skill for test scenarios covering these patterns (P0 duplicate payment, stock release on failure, etc.).
-
-## Done Criteria (K4)
-
-- [ ] Idempotency key on all payment requests
-- [ ] Webhook handler is idempotent (dedup by eventId)
-- [ ] Stock updates are atomic (SQL-level check)
-- [ ] Two-phase reservation implemented with TTL
-- [ ] Prices snapshot at cart add, revalidated at checkout
-- [ ] Payment state machine covers all transitions

package/skills/vibe.commerce-patterns/rubrics/checkout-flow.md

@@ -1,48 +0,0 @@
-# Checkout UX Best Practices Checklist
-
-## Cart Review Step
-
-- [ ] Cart items show current price, quantity, and subtotal per line
-- [ ] Price change warning shown if item price changed since add-to-cart
-- [ ] Out-of-stock items flagged before user proceeds
-- [ ] Clear "Continue to Checkout" CTA — one primary action per step
-- [ ] Guest checkout option visible (no forced registration)
-
-## Shipping & Address Step
-
-- [ ] Address autocomplete reduces input friction
-- [ ] Saved addresses surfaced first for logged-in users
-- [ ] Shipping cost displayed before payment (no surprise at confirmation)
-- [ ] Estimated delivery date shown per shipping method
-- [ ] Address validation feedback inline, not on submit
-
-## Payment Step
-
-- [ ] Supported payment methods visible upfront (icons, labels)
-- [ ] Payment form uses browser autofill attributes (`autocomplete`)
-- [ ] Idempotency key bound to order ID — double-click safe
-- [ ] Loading state on submit button prevents double submission
-- [ ] Clear error messages distinguish user error from system error
-- [ ] PG redirect handles back-button recovery gracefully
-
-## Order Confirmation Step
-
-- [ ] Order ID prominently displayed (user can reference for support)
-- [ ] Confirmation email sent within 30 seconds of payment success
-- [ ] Summary includes: items, total, shipping address, estimated delivery
-- [ ] Clear next step (track order / continue shopping)
-- [ ] No personal payment data displayed (mask card number)
-
-## Error & Edge Cases
-
-- [ ] Stock exhausted mid-checkout: clear message, return to cart
-- [ ] Payment timeout: inform user, preserve order state for retry
-- [ ] Session expiry during checkout: preserve cart, redirect to login
-- [ ] Network failure on submit: prevent duplicate submission, show retry CTA
-
-## Accessibility & Performance
-
-- [ ] Checkout steps announced to screen readers (step X of Y)
-- [ ] Tab order logical through form fields
-- [ ] Core checkout flow works without JavaScript (progressive enhancement)
-- [ ] Page weight under 200 KB per step (no unnecessary third-party scripts)

package/skills/vibe.commerce-patterns/templates/product-schema.md

@@ -1,85 +0,0 @@
-# Product Data Schema Template
-
-## Core Product
-
-```typescript
-interface Product {
-  id: string;                        // UUID or slug — immutable after creation
-  sku: string;                       // Unique stock keeping unit
-  name: string;
-  description: string;
-  status: "ACTIVE" | "ARCHIVED" | "DRAFT";
-
-  pricing: ProductPricing;
-  inventory: ProductInventory;
-  media: ProductMedia[];
-  attributes: ProductAttribute[];    // color, size, material, etc.
-  variants: ProductVariant[];        // if applicable
-
-  createdAt: Date;
-  updatedAt: Date;
-}
-```
-
-## Pricing
-
-```typescript
-interface ProductPricing {
-  currency: string;                  // ISO 4217 — "KRW", "USD"
-  basePrice: number;                 // In smallest currency unit (cents/원)
-  salePrice?: number;                // null = no active sale
-  salePeriod?: { from: Date; to: Date };
-  taxRate: number;                   // 0.1 = 10%
-  taxIncluded: boolean;              // Is tax included in basePrice?
-}
-```
-
-## Inventory
-
-```typescript
-interface ProductInventory {
-  trackInventory: boolean;           // false = always in stock (digital goods)
-  stock: number;                     // Current available quantity
-  reservedStock: number;             // Locked in active checkouts
-  lowStockThreshold: number;        // Alert when stock <= this value
-  backorderAllowed: boolean;
-  reservationTtlMinutes: number;    // How long to hold reserved stock (default: 15)
-}
-```
-
-## Variant
-
-```typescript
-interface ProductVariant {
-  id: string;
-  sku: string;
-  attributes: Record<string, string>; // { color: "red", size: "M" }
-  pricing?: Partial<ProductPricing>;  // Override base pricing
-  inventory: ProductInventory;
-  active: boolean;
-}
-```
-
-## Cart Line Item (Price Snapshot)
-
-```typescript
-interface CartLineItem {
-  productId: string;
-  variantId?: string;
-  quantity: number;
-  // Snapshot at add-to-cart time — do not read live price from DB during checkout
-  snapshotPrice: number;
-  snapshotCurrency: string;
-  snapshotName: string;
-  addedAt: Date;
-}
-```
-
-## Usage Notes
-
-- Store `snapshotPrice` in cart to survive price changes — revalidate at checkout entry only
-- `reservedStock + stock` = total physical stock on hand
-- Use `FOR UPDATE` or atomic SQL when decrementing `stock`
-- Archive products instead of deleting — orders reference them
-- `{{CURRENCY}}` — replace with project's primary currency code
-- `{{TAX_RATE}}` — replace with applicable tax rate (e.g., `0.1` for 10% VAT)

package/skills/vibe.commit-push-pr/SKILL.md

@@ -1,83 +0,0 @@
----
-name: vibe.commit-push-pr
-invocation: [auto]
-tier: optional
-description: "Use when the user asks to commit completed changes, push the branch, and open a pull request in one workflow."
-triggers: [commit, push, PR, pull request, merge]
-priority: 70
----
-
-# Commit-Push-PR
-
-## Pre-checks
-
-```bash
-git status            # What's changed
-git diff --stat       # Review changes
-git log --oneline -5  # Recent commits for style
-```
-
-## Workflow
-
-1. Review and stage changed files
-2. Write commit message (Conventional Commits)
-3. Push to remote branch
-4. Create PR with `gh pr create`
-
-## Commit Message Format
-
-```
-[type] title (under 50 chars)
-
-body (optional, 72 char wrap)
-
-Co-Authored-By: Claude <noreply@anthropic.com>
-```
-
-Types: `feat` | `fix` | `docs` | `style` | `refactor` | `test` | `chore` | `perf`
-
-## Security Checks (CRITICAL)
-
-```bash
-# Before committing — detect sensitive files
-git diff --cached --name-only | grep -E '\.(env|pem|key)$|credentials|secret'
-```
-
-**Never commit:** `.env`, `.env.local`, `*.pem`, `*.key`, `credentials.json`, `service-account.json`
-
-> If sensitive files are staged, **immediately warn and abort**.
-
-## Branch Protection
-
-**보호 브랜치 규칙 (항상 적용 — 조건부 로드 금지):**
-
-- **`main`/`master` 에 직접 커밋·푸시하지 않는다.**
-- 현재 브랜치가 `main`/`master` 면 **먼저 새 브랜치를 만든다.**
-- `main`/`master` 에 **force-push 는 절대 하지 않는다.**
-
-> 이 규칙은 reference 로 내리지 않는다. "브랜치가 보호돼 있을 때만 읽어라" 는 순환이다 —
-> 무엇이 보호 브랜치인지 판단하려면 이미 이 규칙을 알고 있어야 한다.
-> 안전·정확성 규칙은 조건부 로드 대상이 아니다.
-
-## PR Format
-
-```bash
-gh pr create \
-  --title "[type] title" \
-  --body "## Changes
-- Key changes
-
-## Related Issues
-- Closes #issue-number
-
-## Testing
-- Test methods and results"
-```
-
-## Done Criteria (K4)
-
-- [ ] No sensitive files in commit
-- [ ] Commit message follows Conventional Commits
-- [ ] Co-Authored-By line included
-- [ ] Not pushing directly to main/master
-- [ ] PR created with clear description

package/skills/vibe.commit-push-pr/agents/change-analyzer.md

@@ -1,55 +0,0 @@
----
-name: change-analyzer
-role: Analyzes git diff to understand what changed and why
-tools: [Bash, Read, Grep]
----
-
-# Change Analyzer
-
-## Role
-Reads the full git diff and related source files to produce a structured change summary. Distinguishes between what was changed, why it was changed, and what the impact surface is — so message-writer and pr-writer have accurate material.
-
-## Responsibilities
-- Run `git diff --staged` and `git diff` to capture all pending changes
-- Categorize changes: new feature, bug fix, refactor, config, docs, test
-- Identify the primary motivation for the change (what problem does it solve)
-- List files changed grouped by concern (e.g., business logic, tests, config)
-- Flag any risky changes: deleted files, public API modifications, schema changes
-
-## Input
-- Project root path
-- Optional: SPEC or issue reference to cross-check intent
-
-## Output
-Change analysis report:
-
-```markdown
-## Change Analysis
-
-### Category
-bug-fix (primary) + refactor (secondary)
-
-### What Changed
-- src/auth.ts: added null check before JWT decode call
-- src/auth.ts: extracted `decodeToken` into standalone function
-- tests/auth.test.ts: added 2 tests for null token edge case
-
-### Why It Changed
-JWT decode was called without checking for null token, causing unhandled
-TypeError on unauthenticated requests to protected routes.
-
-### Risk Surface
-- Public API: `validateToken()` signature unchanged — safe
-- Behavior change: now returns `null` instead of throwing on invalid token
-
-### Files Changed
-- src/auth.ts (logic)
-- tests/auth.test.ts (tests)
-```
-
-## Communication
-- Reports findings to: message-writer, pr-writer
-- Receives instructions from: orchestrator (commit-push-pr skill)
-
-## Domain Knowledge
-Conventional commit categories: feat, fix, refactor, test, docs, chore, perf, ci. A change is a "fix" only if it corrects incorrect behavior. Categorize by primary intent — a bug fix with refactoring is still "fix".

package/skills/vibe.commit-push-pr/agents/message-writer.md

@@ -1,50 +0,0 @@
----
-name: message-writer
-role: Drafts a conventional commit message from the change analysis
-tools: [Read, Bash]
----
-
-# Message Writer
-
-## Role
-Produces a well-formed conventional commit message from the change analysis. Follows the Conventional Commits specification. Focuses on communicating the "why" in the body, not repeating the diff in the subject line.
-
-## Responsibilities
-- Write a subject line: `<type>(<scope>): <imperative summary>` under 72 characters
-- Write a body paragraph explaining motivation and context (not just what changed)
-- Add BREAKING CHANGE footer if public API or behavior changed incompatibly
-- Reference issue/ticket numbers if provided
-- Avoid generic filler ("update code", "fix stuff", "various changes")
-
-## Input
-- Change analysis report from change-analyzer
-- Optional: issue number, ticket ID, or SPEC reference
-
-## Output
-Ready-to-use commit message:
-
-```
-fix(auth): handle null token in validateToken to prevent TypeError
-
-JWT decode was called without a null guard, causing unhandled TypeErrors
-on unauthenticated requests to protected routes. Now returns null for
-invalid or missing tokens instead of throwing.
-
-Closes #142
-```
-
-Also outputs the git command to apply it:
-```bash
-git commit -m "$(cat <<'EOF'
-fix(auth): handle null token in validateToken to prevent TypeError
-...
-EOF
-)"
-```
-
-## Communication
-- Reports findings to: reviewer
-- Receives instructions from: orchestrator (commit-push-pr skill)
-
-## Domain Knowledge
-Conventional Commits spec: type(scope): subject. Types: feat, fix, refactor, test, docs, chore, perf, ci, build. Scope is the module or area affected. Subject uses imperative mood ("add" not "added"). Body wraps at 72 chars. Breaking changes go in footer as `BREAKING CHANGE: description`.

package/skills/vibe.commit-push-pr/agents/pr-writer.md

@@ -1,58 +0,0 @@
----
-name: pr-writer
-role: Drafts PR title and body with summary and test plan
-tools: [Read, Bash]
----
-
-# PR Writer
-
-## Role
-Produces a complete pull request title and body from the change analysis. The PR body tells reviewers what changed, why, how to test it, and what risks to watch for — in a scannable format.
-
-## Responsibilities
-- Write a concise PR title under 70 characters
-- Write a Summary section with 2-4 bullet points of key changes
-- Write a Motivation section explaining the problem being solved
-- Write a Test Plan checklist reviewers can follow to validate the change
-- Add a Risk/Notes section for any breaking changes, migration steps, or caveats
-
-## Input
-- Change analysis report from change-analyzer
-- Commit message from message-writer
-- Optional: SPEC file or issue reference for additional context
-
-## Output
-PR title and body ready for `gh pr create`:
-
-```markdown
-## Title
-fix(auth): handle null token to prevent unhandled TypeError
-
-## Body
-
-## Summary
-- Added null guard in `validateToken` before JWT decode
-- Extracted `decodeToken` as a testable pure function
-- Added 2 edge case tests for null and malformed tokens
-
-## Motivation
-Unauthenticated requests to protected routes were crashing with
-`TypeError: Cannot read properties of null` because `validateToken`
-called `jwt.decode()` without checking for a null token value.
-
-## Test Plan
-- [ ] `npm test` passes with no failures
-- [ ] Manually test: send request with no `Authorization` header → expect 401, no 500
-- [ ] Manually test: send request with `Authorization: Bearer null` → expect 401
-
-## Notes
-- `validateToken` now returns `null` instead of throwing for invalid tokens
-- Callers that expected a throw must be updated (none found in this repo)
-```
-
-## Communication
-- Reports findings to: reviewer
-- Receives instructions from: orchestrator (commit-push-pr skill)
-
-## Domain Knowledge
-A good PR body answers: What changed? Why? How do I verify it works? What could break? Keep Summary bullets to actions taken, not descriptions of files. Test Plan must include at least one manual verification step.