@su-record/vibe 3.2.64 → 4.0.0

package/skills/vibe.docs/templates/architecture.md

@@ -1,80 +0,0 @@
-# Architecture: {{PROJECT_NAME}}
-
-> Version: {{VERSION}} | Updated: {{DATE}}
-
-## Overview
-
-{{2-3 SENTENCES: WHAT THIS SYSTEM DOES AND ITS PRIMARY ARCHITECTURAL APPROACH.}}
-
-## System Diagram
-
-```mermaid
-graph TD
-    {{ENTRY_POINT}}[{{ENTRY_LABEL}}] --> {{MODULE_A}}[{{MODULE_A_LABEL}}]
-    {{MODULE_A}} --> {{MODULE_B}}[{{MODULE_B_LABEL}}]
-    {{MODULE_A}} --> {{MODULE_C}}[{{MODULE_C_LABEL}}]
-    {{MODULE_B}} --> {{STORE}}[({{STORE_LABEL}})]
-    {{MODULE_C}} --> {{EXTERNAL}}[{{EXTERNAL_SERVICE_LABEL}}]
-```
-
-> Replace nodes above based on actual `import` analysis. Run:
-> `grep -r "^import .* from" src/ | sed 's/.*from //' | sort | uniq` to get dependency edges.
-
-## Module Responsibilities
-
-| Module / Directory | Responsibility | Key Files |
-|--------------------|---------------|-----------|
-| `{{MODULE_1}}/` | {{RESPONSIBILITY}} | `{{KEY_FILE}}` |
-| `{{MODULE_2}}/` | {{RESPONSIBILITY}} | `{{KEY_FILE}}` |
-| `{{MODULE_3}}/` | {{RESPONSIBILITY}} | `{{KEY_FILE}}` |
-
-## Data Flow
-
-```
-{{INPUT_SOURCE}}
-  ↓ {{STEP_1_DESCRIPTION}}
-{{PROCESSING_MODULE}}
-  ↓ {{STEP_2_DESCRIPTION}}
-{{OUTPUT_TARGET}}
-```
-
-### Key Data Entities
-
-| Entity | Where Defined | Storage |
-|--------|--------------|---------|
-| `{{ENTITY_1}}` | `{{FILE_PATH}}` | {{DB / FILE / MEMORY}} |
-| `{{ENTITY_2}}` | `{{FILE_PATH}}` | {{DB / FILE / MEMORY}} |
-
-## External Dependencies
-
-| Service | Purpose | Auth Method |
-|---------|---------|-------------|
-| `{{SERVICE_1}}` | {{PURPOSE}} | {{API_KEY / OAUTH / NONE}} |
-| `{{SERVICE_2}}` | {{PURPOSE}} | {{AUTH_METHOD}} |
-
-## Key Decisions
-
-| Decision | Chosen Approach | Alternatives Considered | Rationale |
-|----------|----------------|------------------------|-----------|
-| {{DECISION_1}} | {{CHOICE}} | {{ALTERNATIVES}} | {{WHY}} |
-| {{DECISION_2}} | {{CHOICE}} | {{ALTERNATIVES}} | {{WHY}} |
-
-## Constraints & Non-Goals
-
-**Constraints:**
-- {{CONSTRAINT_1}} (e.g., "Must work offline")
-- {{CONSTRAINT_2}}
-
-**Non-goals (out of scope):**
-- {{NON_GOAL_1}}
-- {{NON_GOAL_2}}
-
-## Local Development Setup
-
-```bash
-{{SETUP_COMMANDS}}
-```
-
-## Further Reading
-
-- {{INTERNAL_LINK_OR_DOC}}

package/skills/vibe.docs/templates/behavioral-principles.md

@@ -1,47 +0,0 @@
-<!-- VIBE-BEHAVIORAL:START -->
-## Behavioral Principles (Karpathy-Inspired)
-
-Derived from Andrej Karpathy's observations on LLM coding pitfalls.
-Source: https://github.com/forrestchang/andrej-karpathy-skills
-
-### Think Before Coding
-
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
-
-- State assumptions explicitly. If uncertain, ask rather than guess.
-- Present multiple interpretations — don't pick silently when ambiguity exists.
-- Push back when a simpler approach exists.
-- Stop when confused. Name what's unclear. Ask.
-
-### Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No flexibility or configurability that wasn't requested.
-- No error handling for impossible scenarios.
-- If 200 lines could be 50, rewrite it.
-
-### Surgical Changes
-
-**Touch only what you must. Clean up only your own mess.**
-
-- Don't improve adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- Match existing style, even if you'd do it differently.
-- Remove orphans YOUR changes created — leave pre-existing dead code alone.
-- Every changed line should trace to the user's request.
-
-### Goal-Driven Execution
-
-**Define success criteria. Loop until verified.**
-
-| Instead of | Transform to |
-|------------|--------------|
-| "Add validation" | "Write tests for invalid inputs, then make them pass" |
-| "Fix the bug" | "Write a test that reproduces it, then make it pass" |
-| "Refactor X" | "Ensure tests pass before and after" |
-
-Strong success criteria enable independent looping. Weak criteria ("make it work") require constant clarification.
-<!-- VIBE-BEHAVIORAL:END -->

package/skills/vibe.docs/templates/readme.md

@@ -1,84 +0,0 @@
-# {{PROJECT_NAME}}
-
-> {{ONE_LINE_DESCRIPTION_FROM_PACKAGE_JSON}}
-
-## What is this?
-
-{{2-3 SENTENCES: THE PROBLEM THIS PROJECT SOLVES AND HOW IT SOLVES IT.}}
-
-## Quick Start
-
-```bash
-# Install
-{{PACKAGE_MANAGER}} install {{PACKAGE_NAME}}
-
-# Minimal usage example
-{{USAGE_EXAMPLE}}
-```
-
-## Features
-
-- **{{FEATURE_1}}** — {{BRIEF_DESCRIPTION}}
-- **{{FEATURE_2}}** — {{BRIEF_DESCRIPTION}}
-- **{{FEATURE_3}}** — {{BRIEF_DESCRIPTION}}
-
-## Architecture
-
-> Include this section if the project has 5+ source directories.
-
-```
-{{PROJECT_NAME}}/
-├── {{DIR_1}}/      # {{RESPONSIBILITY_1}}
-├── {{DIR_2}}/      # {{RESPONSIBILITY_2}}
-└── {{DIR_3}}/      # {{RESPONSIBILITY_3}}
-```
-
-## Configuration
-
-| File | Purpose |
-|------|---------|
-| `{{CONFIG_FILE_1}}` | {{PURPOSE}} |
-| `{{CONFIG_FILE_2}}` | {{PURPOSE}} |
-
-**Key environment variables:**
-
-| Variable | Required | Default | Description |
-|----------|----------|---------|-------------|
-| `{{ENV_VAR_1}}` | Yes / No | `{{DEFAULT}}` | {{DESCRIPTION}} |
-
-## Development
-
-```bash
-# Install dependencies
-{{INSTALL_COMMAND}}
-
-# Build
-{{BUILD_COMMAND}}
-
-# Test
-{{TEST_COMMAND}}
-
-# Lint
-{{LINT_COMMAND}}
-```
-
-## API Reference
-
-> Include if the project exposes a public API.
-
-### `{{FUNCTION_OR_CLASS_NAME}}`
-
-```typescript
-{{FUNCTION_SIGNATURE}}
-```
-
-{{DESCRIPTION}}
-
-**Parameters:**
-- `{{PARAM_1}}` — {{TYPE}}: {{DESCRIPTION}}
-
-**Returns:** `{{RETURN_TYPE}}` — {{DESCRIPTION}}
-
-## License
-
-{{LICENSE}} — see [LICENSE](./LICENSE)

package/skills/vibe.docs/templates/release-notes.md

@@ -1,74 +0,0 @@
-# Release Notes: {{PROJECT_NAME}}
-
----
-
-## [{{VERSION}}] — {{RELEASE_DATE}}
-
-> {{ONE_SENTENCE_SUMMARY_OF_THIS_RELEASE}}
-
-### Breaking Changes
-
-> If none, remove this section.
-
-- **{{CHANGE_DESCRIPTION}}** — {{MIGRATION_GUIDE}}
-  - Before: `{{OLD_USAGE}}`
-  - After: `{{NEW_USAGE}}`
-
-### Features
-
-- `feat`: {{FEATURE_DESCRIPTION}} ([#{{PR_NUMBER}}]({{PR_URL}}))
-- `feat`: {{FEATURE_DESCRIPTION}} ([#{{PR_NUMBER}}]({{PR_URL}}))
-
-### Bug Fixes
-
-- `fix`: {{BUG_DESCRIPTION}} — {{WHAT_WAS_WRONG_AND_HOW_FIXED}} ([#{{PR_NUMBER}}]({{PR_URL}}))
-
-### Performance
-
-- `perf`: {{IMPROVEMENT_DESCRIPTION}} — {{BEFORE}} → {{AFTER}}
-
-### Other
-
-- `refactor`: {{DESCRIPTION}}
-- `docs`: {{DESCRIPTION}}
-- `chore`: {{DESCRIPTION}}
-
----
-
-## Upgrade Guide
-
-### From {{PREVIOUS_VERSION}} to {{VERSION}}
-
-```bash
-{{UPGRADE_COMMAND}}
-```
-
-**Required config changes:**
-1. {{CONFIG_CHANGE_1}}
-2. {{CONFIG_CHANGE_2}}
-
----
-
-## [{{PREVIOUS_VERSION}}] — {{PREVIOUS_DATE}}
-
-> Past release notes continue below in reverse chronological order.
-
----
-
-<!-- GENERATION NOTES (remove before publishing)
-
-Run to generate draft:
-  git log {{PREVIOUS_TAG}}..HEAD --oneline --no-merges
-
-Classify commits:
-  feat:     → Features
-  fix:      → Bug Fixes
-  perf:     → Performance
-  refactor/docs/chore/test: → Other
-  BREAKING CHANGE in footer: → Breaking Changes
-
-Version bump guidance:
-  Breaking changes → major (x.0.0)
-  New features      → minor (0.x.0)
-  Bug fixes only    → patch (0.0.x)
--->

package/skills/vibe.documentation-provider/SKILL.md

@@ -1,22 +0,0 @@
----
-name: vibe.documentation-provider
-description: Fetch current, authoritative library and API documentation through the best available provider. Use for external API/SDK implementation, migrations, version differences, official references, or deprecated API checks; routes between chub, Context7, and official web documentation.
-user-invocable: true
----
-
-# Documentation Provider
-
-## Done Criteria
-
-- [ ] 사용한 provider와 조회 대상 package/API가 기록되어 있다.
-- [ ] 답변 또는 구현 근거에 문서 버전이나 조회 날짜가 포함되어 있다.
-- [ ] fallback을 사용하면 앞선 provider 실패 이유가 기록되어 있다.
-
-Select one provider and return only the documentation needed by the caller.
-
-1. Prefer chub when curated API docs or reusable annotations are available. Read `references/chub.md`.
-2. Otherwise use Context7 when its library documentation provider is available. Read `references/context7.md`.
-3. Otherwise research the official vendor documentation on the web and cite the source.
-4. Delegate retrieval through native collaboration when the result would bloat the coordinator context. Claude Code maps the worker to Task/Agent; Codex maps it to native collaboration. Inherit the session model.
-
-Never implement from training data when current documentation is required. Preserve the caller's requested library, topic, language, and output shape.

package/skills/vibe.documentation-provider/references/chub.md

@@ -1,141 +0,0 @@
----
-name: documentation-provider-chub-reference
-invocation: [auto]
-tier: optional
-description: "Context Hub (chub) — fetch vetted, up-to-date API documentation. Write accurate code based on the latest docs instead of training data when working with external APIs/SDKs."
-triggers: [chub, context hub, API docs, latest API, deprecated API, SDK documentation, api reference, 최신 문서]
-priority: 60
----
-
-# Context Hub (chub) Usage
-
-A skill for fetching vetted, up-to-date documentation before writing external API/SDK code.
-Solves the knowledge cutoff problem inherent in training data.
-
-## Why?
-
-| Problem | Solution |
-|---------|----------|
-| Relying on training data → using deprecated APIs | chub get → code based on vetted latest docs |
-| Web search → noisy results | chub search → curated docs only |
-| Repeating the same mistakes every session | chub annotate → accumulated learnings |
-
-## When to Use
-
-| Situation | Example |
-|-----------|---------|
-| Writing external API code | "Integrate Stripe payments" |
-| Checking latest SDK version | "Call the latest OpenAI model" |
-| Need official documentation | "Set up Supabase auth" |
-| Preventing deprecated patterns | "Firebase v10 migration" |
-
-## Workflow
-
-```
-Request to write external API/SDK code
-    ↓
-Step 0: Check if chub is installed (auto-install if not)
-    ↓
-Step 1: chub search "<library name>"
-    ↓
-Step 2: chub get <id> --lang ts
-    ↓
-Step 3: Write code based on the docs
-    ↓
-Step 4: chub annotate when a gotcha is discovered
-```
-
-## Step 0 — Auto-install
-
-**Always perform this step before running the skill.**
-
-```bash
-# 1. Check if chub exists
-which chub || command -v chub
-```
-
-If chub is not found, attempt automatic installation:
-
-```bash
-npm install -g @aisuite/chub
-```
-
-If installation fails, fall back to running via `npx @aisuite/chub`:
-
-```bash
-# search example
-npx @aisuite/chub search "stripe"
-# get example
-npx @aisuite/chub get stripe/api --lang ts
-```
-
-If `npx` also fails, fall back to context7 or Web Search (see Fallback Chain).
-
-## Usage
-
-### Step 1 — Search for docs
-
-```bash
-chub search "stripe"
-chub search "openai"
-chub search ""           # View full list
-```
-
-### Step 2 — Fetch latest docs
-
-```bash
-chub get stripe/api --lang ts
-chub get openai/chat --lang py
-chub get supabase/auth --lang js
-```
-
-### Step 3 — Write code based on the docs
-
-Write accurate code based on the fetched documentation.
-**Never rely on training data. Docs first, code second.**
-
-### Step 4 — Record learnings
-
-Gotchas, workarounds, and version issues discovered during work:
-
-```bash
-chub annotate stripe/api "pg parameter is required for Korean payments"
-chub annotate openai/chat "tool_calls in streaming comes as delta"
-chub annotate firebase/auth "getAuth() import path changed in v10"
-```
-
-Annotations are stored locally and automatically included the next time you run `chub get`.
-
-## Implementation Pattern (Delegated Worker)
-
-Delegate through the harness's native collaboration capability to prevent
-context bloat. Claude Code maps the worker to Task/Agent; Codex maps it to
-native collaboration. Inherit the session model by default:
-
-```
-Worker goal: Run `chub search <library>` then `chub get <id> --lang <lang>` to
-fetch current API documentation for [topic]. Return only relevant usage
-examples, key changes, and annotations.
-```
-
-The worker handles the chub calls and returns only a summary — keeping the coordinator context clean.
-
-## Supported APIs (1,000+)
-
-OpenAI, Anthropic, Stripe, Firebase, Supabase, Vercel, AWS S3, Cloudflare Workers, Auth0, Clerk, and more.
-
-```bash
-chub search    # Run without arguments to view the full list
-```
-
-## Fallback Chain
-
-```
-which chub fails
-    ↓
-npm install -g @aisuite/chub (auto attempt)
-    ↓
-On failure: npx @aisuite/chub <command> (temporary execution)
-    ↓
-If npx also fails: context7 or Web Search fallback
-```

package/skills/vibe.documentation-provider/references/context7-when-to-use.md

@@ -1,50 +0,0 @@
-# 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/vibe.documentation-provider/references/context7.md

@@ -1,107 +0,0 @@
----
-name: documentation-provider-context7-reference
-invocation: [auto]
-tier: optional
-description: "Context7 plugin for latest library documentation. Auto-activates when docs, documentation, latest version, official docs, API reference, or library help is needed."
-triggers: [latest version, official docs, API reference, library help, context7]
-priority: 60
----
-
-# Context7 Usage
-
-Guide for searching latest library/framework documentation using Context7 plugin with subagent isolation.
-
-## Why Subagent Approach?
-
-| Approach | Problem |
-|----------|---------|
-| Direct plugin call | Docs content fills main context, causing bloat |
-| Subagent isolation | Docs queried in separate context, only results returned |
-
-**Benefits:**
-
-- Prevents context bloat during long coding sessions
-- Solves knowledge cutoff problem with latest docs
-- Main context stays focused on implementation
-
-## When to Use
-
-| Situation | Example |
-|-----------|---------|
-| Latest API check | "React 19 use() hook usage" |
-| Version differences | "Next.js 15 changes" |
-| Official docs needed | "Prisma schema syntax" |
-| Migration guide | "Vue 2 → Vue 3 migration" |
-
-## How It Works
-
-```
-User asks library question
-    ↓
-Skill detects docs need
-    ↓
-Delegate an isolated docs-researcher worker using the inherited session model
-    ↓
-Worker calls context7 in isolated context
-    ↓
-Returns only relevant info to main context
-```
-
-## Usage
-
-### Automatic (Recommended)
-
-Just ask library/API questions naturally:
-
-```
-"How do I use React 19 use() hook?"
-"What's new in Next.js 15?"
-"Prisma many-to-many relation syntax"
-```
-
-The skill auto-detects and delegates a docs-researcher worker.
-
-### Manual Command
-
-```
-/context7:docs <library> [query]
-```
-
-Examples:
-
-```
-/context7:docs react hooks
-/context7:docs next.js app router
-/context7:docs prisma relations
-```
-
-## Implementation Pattern
-
-When you detect a library/API documentation need, delegate through the
-harness's native collaboration capability. Claude Code maps the worker to
-Task/Agent; Codex maps it to native collaboration. Inherit the session model:
-
-```
-Worker goal: Use context7 to find [library] documentation about [topic]. Return
-only the relevant API usage examples and key points.
-```
-
-The worker handles the context7 calls and returns a summary, keeping the coordinator context clean.
-
-## Fallback Chain
-
-```
-context7 plugin not installed
-    ↓
-Prompt user: /plugin install context7
-    ↓
-If still unavailable: Web Search for official docs
-```
-
-## Installation
-
-If context7 is not installed, guide user:
-
-```bash
-/plugin install context7
-```

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

@@ -1,63 +0,0 @@
----
-name: vibe.e2e-commerce
-invocation: [auto]
-tier: core
-description: "E2E test scenarios for commerce checkout and payment flows. Provides ready-made Playwright test templates for cart→checkout→payment→confirmation flows, including PG sandbox testing (Toss/Stripe), error scenarios (payment failure, timeout, stock exhaustion), and idempotency verification. Use when writing E2E tests for any e-commerce feature — checkout, payment, order status, or refund flows."
-triggers: [e2e commerce, checkout test, payment test, order flow test]
-priority: 60
----
-
-# E2E Commerce Test Scenarios
-
-## Pre-check (K1)
-
-> Are you testing a checkout/payment/order flow? If testing simple CRUD or non-transactional features, standard E2E patterns suffice — this skill is not needed.
-
-## Must-Test Scenarios
-
-### P0 — Blocks Deployment
-
-| Scenario | What to Verify | Gotcha |
-|----------|---------------|--------|
-| **Happy path checkout** | Cart → Shipping → Payment → Order confirmation | Verify order status text, not just URL change |
-| **Payment failure** | Error message shown, stock released | Check stock is RELEASED after failure, not just error displayed |
-| **Duplicate payment** | Only 1 order created on double-click | `Promise.all([click(), click()])` then verify order count via API |
-| **Out of stock** | Blocks checkout with clear message | Simulate stock depletion mid-checkout via test API |
-
-### P1 — Should Pass
-
-| Scenario | What to Verify | Gotcha |
-|----------|---------------|--------|
-| **Coupon calculation** | Discount amount and total correct | Test percentage AND fixed amount coupons separately |
-| **Webhook resilience** | Order completes even with delayed webhook | Configure 5s delay, verify processing→complete transition |
-| **Cart merge on login** | Guest cart merged into user cart | User cart takes priority for duplicate items |
-| **Partial refund** | Refunded amount correct, order updated | Verify remaining amount, not just refund event |
-
-### P2 — Nice to Have
-
-| Scenario | What to Verify |
-|----------|---------------|
-| Multiple payment methods | Each method completes checkout |
-| Guest checkout | Full flow without login |
-| Order cancellation | Refund triggered, stock restored |
-
-## Test Environment Gotchas
-
-| Gotcha | Fix |
-|--------|-----|
-| Using real PG sandbox in CI | Use MSW (`setupServer`) for mock PG responses |
-| Flaky tests from timing | Use `waitForSelector`/`waitForURL`, never `sleep` |
-| Test data leaks between tests | Seed in `beforeAll`, clean in `afterAll` |
-| Hardcoded test card numbers | Document: `4000000000000002` = decline |
-
-## Related
-
-See `commerce-patterns` skill for implementation gotchas (idempotency, atomic stock, payment state machine) that these tests verify.
-
-## Done Criteria (K4)
-
-- [ ] All P0 scenarios pass in CI
-- [ ] P1 scenarios written and tracked
-- [ ] Test data seeded/cleaned per suite
-- [ ] No flaky tests (no arbitrary waits)
-- [ ] Mock PG server configured for CI