@su-record/vibe 3.2.64 → 4.0.0

package/skills/vibe.prioritization/SKILL.md

@@ -1,95 +0,0 @@
----
-name: vibe.prioritization
-invocation: [auto, chain]
-tier: standard
-description: "Reference guide to 9 prioritization frameworks with formulas, when-to-use guidance, and templates — RICE, ICE, Kano, MoSCoW, Opportunity Score, and more."
-triggers: [prioritize, prioritization, rice, ice, kano, moscow, opportunity score]
-priority: 50
-chain-next: [vibe.create-prd]
----
-
-# Prioritization Frameworks Reference
-
-## Done Criteria
-
-- [ ] 선택한 framework와 선택 근거가 기록되어 있다.
-- [ ] 모든 평가 대상에 framework의 필수 입력값이 있다.
-- [ ] 정의된 산식으로 점수가 계산되어 있다.
-- [ ] 최종 정렬 순서와 동점 처리 기준이 명시되어 있다.
-
-> Based on the Product Frameworks Compendium from [Product Compass](https://www.productcompass.pm/p/the-product-frameworks-compendium) by Pawel Huryn (MIT License).
-
-A reference guide to help you select and apply the right prioritization framework for your context.
-
-## Core Principle
-
-Never allow customers to design solutions. Prioritize **problems (opportunities)**, not features.
-
-## Opportunity Score (Dan Olsen, *The Lean Product Playbook*)
-
-The recommended framework for prioritizing customer problems.
-
-Survey customers on **Importance** and **Satisfaction** for each need (normalize to 0-1 scale).
-
-Three related formulas:
-- **Current value** = Importance x Satisfaction
-- **Opportunity Score** = Importance x (1 - Satisfaction)
-- **Customer value created** = Importance x (S2 - S1), where S1 = satisfaction before, S2 = satisfaction after
-
-High Importance + low Satisfaction = highest Opportunity Score = best opportunities. Plot on an Importance vs Satisfaction chart — upper-left quadrant is the sweet spot.
-
-## ICE Framework
-
-Useful for prioritizing initiatives and ideas. Considers not only value but also risk and economic factors.
-
-- **I** (Impact) = Opportunity Score x Number of Customers affected
-- **C** (Confidence) = How confident are we? (1-10). Accounts for risk.
-- **E** (Ease) = How easy is it to implement? (1-10). Accounts for economic factors.
-
-**Score** = I x C x E. Higher = prioritize first.
-
-## RICE Framework
-
-Splits ICE's Impact into two separate factors. Useful for larger teams that need more granularity.
-
-- **R** (Reach) = Number of customers affected
-- **I** (Impact) = Opportunity Score (value per customer)
-- **C** (Confidence) = How confident are we? (0-100%)
-- **E** (Effort) = How much effort to implement? (person-months)
-
-**Score** = (R x I x C) / E
-
-## 9 Frameworks Overview
-
-| Framework | Best For | Key Insight |
-|-----------|----------|-------------|
-| Eisenhower Matrix | Personal tasks | Urgent vs Important — for individual PM task management |
-| Impact vs Effort | Tasks/initiatives | Simple 2x2 — quick triage, not rigorous for strategic decisions |
-| Risk vs Reward | Initiatives | Like Impact vs Effort but accounts for uncertainty |
-| **Opportunity Score** | Customer problems | **Recommended.** Importance x (1 - Satisfaction). Normalize to 0-1. |
-| Kano Model | Understanding expectations | Must-be, Performance, Attractive, Indifferent, Reverse. For understanding, not prioritizing. |
-| Weighted Decision Matrix | Multi-factor decisions | Assign weights to criteria, score each option. Useful for stakeholder buy-in. |
-| **ICE** | Ideas/initiatives | Impact x Confidence x Ease. Recommended for quick prioritization. |
-| **RICE** | Ideas at scale | (Reach x Impact x Confidence) / Effort. Adds Reach to ICE. |
-| MoSCoW | Requirements | Must/Should/Could/Won't. Caution: project management origin. |
-
-## How to Choose
-
-1. **Prioritizing customer problems?** → Opportunity Score
-2. **Quick initiative ranking?** → ICE
-3. **Large team with data?** → RICE
-4. **Understanding user expectations?** → Kano Model
-5. **Stakeholder alignment needed?** → Weighted Decision Matrix
-6. **Requirements scoping?** → MoSCoW (with caution)
-
-## Templates
-
-- [Opportunity Score intro (PDF)](https://drive.google.com/file/d/1ENbYPmk1i1AKO7UnfyTuULL5GucTVufW/view)
-- [Importance vs Satisfaction Template (Google Slides)](https://docs.google.com/presentation/d/1jg-LuF_3QHsf6f1nE1f98i4C0aulnRNMOO1jftgti8M/edit#slide=id.g796641d975_0_3)
-- [ICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1LUfnsPolhZgm7X2oij-7EUe0CJT-Dwr-/edit?usp=share_link)
-- [RICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1S-6QpyOz5MCrV7B67LUWdZkAzn38Eahv/edit?usp=sharing)
-
-## Further Reading
-
-- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium)
-- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers)

package/skills/vibe.prioritization/rubrics/frameworks.md

@@ -1,79 +0,0 @@
-# Prioritization Frameworks Rubric
-
-## RICE
-
-**Formula**: `(Reach × Impact × Confidence) / Effort`
-
-| Factor | Scale | Example |
-|--------|-------|---------|
-| Reach | Users/month (absolute) | 5,000 users |
-| Impact | Opportunity Score 0.0–1.0 | 0.7 |
-| Confidence | 0–100% | 80% = 0.8 |
-| Effort | Person-months | 2 |
-
-**Example**: `(5000 × 0.7 × 0.8) / 2 = 1400` — higher score = prioritize first.
-
-**When to use**: Large teams with data. Separates audience size (Reach) from value per user (Impact).
-
-**Watch out for**: Effort estimates are often optimistic — apply a 1.5x buffer.
-
----
-
-## ICE
-
-**Formula**: `Impact × Confidence × Ease`
-
-| Factor | Scale | Example |
-|--------|-------|---------|
-| Impact | 1–10 (or Opportunity Score × Users) | 8 |
-| Confidence | 1–10 | 7 |
-| Ease | 1–10 (inverse of effort) | 5 |
-
-**Example**: `8 × 7 × 5 = 280` — higher score = prioritize first.
-
-**When to use**: Quick ranking of ideas/initiatives. Faster than RICE, good for early-stage decisions.
-
-**Watch out for**: "Ease" is subjective — calibrate across team before scoring.
-
----
-
-## MoSCoW
-
-**Categories**:
-
-| Category | Meaning | Guideline |
-|----------|---------|-----------|
-| **Must** | Cannot launch without | Max 60% of scope |
-| **Should** | High value, not critical | Next priority after Must |
-| **Could** | Nice to have | Include only if capacity allows |
-| **Won't** | Explicitly deferred | Documents what is NOT in scope |
-
-**When to use**: Scoping a release. Good for stakeholder alignment conversations.
-
-**Watch out for**: Stakeholders inflate "Must" — challenge each Must with "What happens if we skip this for V1?". MoSCoW is a scoping tool, not a discovery tool.
-
----
-
-## Opportunity Score
-
-**Formula**: `Importance × (1 − Satisfaction)` (normalize both to 0–1 scale)
-
-**Example**:
-- Importance: 0.9, Satisfaction: 0.3 → Score: `0.9 × 0.7 = 0.63` (high opportunity)
-- Importance: 0.9, Satisfaction: 0.9 → Score: `0.9 × 0.1 = 0.09` (already solved)
-
-**When to use**: Prioritizing customer problems before deciding on solutions. Prevents building features customers already find satisfactory.
-
-**Watch out for**: Survey sample must be representative. Low sample size inflates confidence.
-
----
-
-## Choosing the Right Framework
-
-| Situation | Recommended Framework |
-|-----------|----------------------|
-| "Which customer problems matter most?" | Opportunity Score |
-| "Which features should we build this sprint?" | ICE |
-| "How do we rank initiatives across a large team?" | RICE |
-| "What goes into V1 vs. later?" | MoSCoW |
-| "Stakeholders disagree on priorities?" | Weighted Decision Matrix |

package/skills/vibe.prioritization/templates/scoring-matrix.md

@@ -1,69 +0,0 @@
-# Prioritization Scoring Matrix Template
-
-## Project / Sprint: {{PROJECT_OR_SPRINT_NAME}}
-
-**Framework selected**: {{FRAMEWORK}} (RICE / ICE / MoSCoW / Opportunity Score)
-**Date**: {{DATE}}
-**Scored by**: {{SCORER_NAMES}}
-
----
-
-## RICE Scoring Matrix
-
-| Item | Reach (users/mo) | Impact (0–1) | Confidence (%) | Effort (person-mo) | RICE Score | Priority |
-|------|-----------------|--------------|----------------|--------------------|------------|----------|
-| {{ITEM_1}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
-| {{ITEM_2}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
-| {{ITEM_3}} | {{R}} | {{I}} | {{C}} | {{E}} | `=(R×I×C)/E` | — |
-
----
-
-## ICE Scoring Matrix
-
-| Item | Impact (1–10) | Confidence (1–10) | Ease (1–10) | ICE Score | Priority |
-|------|---------------|-------------------|-------------|-----------|----------|
-| {{ITEM_1}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
-| {{ITEM_2}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
-| {{ITEM_3}} | {{I}} | {{C}} | {{E}} | `=I×C×E` | — |
-
----
-
-## MoSCoW Categorization
-
-| Item | Category | Rationale | Owner |
-|------|----------|-----------|-------|
-| {{ITEM_1}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
-| {{ITEM_2}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
-| {{ITEM_3}} | Must / Should / Could / Won't | {{REASON}} | {{OWNER}} |
-
-**Must count**: {{X}} / {{TOTAL}} — keep Must ≤ 60% of total scope.
-
----
-
-## Opportunity Score Matrix
-
-| Customer Need | Importance (0–1) | Satisfaction (0–1) | Opportunity Score | Action |
-|--------------|------------------|---------------------|-------------------|--------|
-| {{NEED_1}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
-| {{NEED_2}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
-| {{NEED_3}} | {{I}} | {{S}} | `=I×(1-S)` | Invest / Monitor / Maintain |
-
-Score > 0.5 = strong opportunity. Score < 0.1 = already solved.
-
----
-
-## Final Ranked Backlog
-
-| Rank | Item | Framework Score | Decision | Notes |
-|------|------|-----------------|----------|-------|
-| 1 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
-| 2 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
-| 3 | {{ITEM}} | {{SCORE}} | Build / Defer / Drop | {{NOTES}} |
-
----
-
-## Scoring Notes
-
-- {{ASSUMPTION_OR_CAVEAT_1}}
-- {{ASSUMPTION_OR_CAVEAT_2}}
-- Next review date: {{REVIEW_DATE}}

package/skills/vibe.priority-todos/SKILL.md

@@ -1,11 +0,0 @@
----
-name: vibe.priority-todos
-description: Use when TODOs or review findings must be organized by P1/P2/P3; compatibility alias for vibe.review priority-todos mode.
-user-invocable: false
-invocation: [auto]
-tier: standard
-triggers: [todo list, task management, P1, P2, P3, priority todos, organize tasks]
-priority: 60
----
-
-Load `vibe.review` in priority-todos mode and preserve all arguments.

package/skills/vibe.react-best-practices/SKILL.md

@@ -1,61 +0,0 @@
----
-name: vibe.react-best-practices
-invocation: [auto]
-tier: core
-description: "Use when implementing or reviewing React/Next.js code where Vercel performance pitfalls, rendering behavior, or bundle efficiency must be checked."
-triggers: [react, next.js, vercel, react performance, re-render, rendering waterfall]
-priority: 60
----
-
-# Vercel React Best Practices
-
-## Pre-check (K1)
-
-> Is this a React/Next.js performance issue? Standard React patterns (useState, useEffect, components) don't need this skill. Activate only for performance optimization or code review.
-
-## CRITICAL Gotchas
-
-### Waterfall Elimination
-
-| Gotcha | Why Non-obvious |
-|--------|----------------|
-| **Sequential awaits** | `const a = await f1(); const b = await f2();` creates waterfall. Use `Promise.all([f1(), f2()])` for independent ops |
-| **Await placement** | Move `await` to the branch where value is actually used, not at declaration |
-| **Missing Suspense** | Wrap slow server components in `<Suspense>` to stream — don't block entire page |
-
-### Bundle Size
-
-| Gotcha | Why Non-obvious |
-|--------|----------------|
-| **Barrel imports** | `import { Button } from "@/components"` pulls entire barrel. Use `import { Button } from "@/components/Button"` |
-| **Third-party in initial bundle** | Load analytics/logging AFTER hydration with `next/dynamic` or lazy `useEffect` |
-| **Heavy components** | Charts, editors, maps → `next/dynamic` with `{ ssr: false }` |
-
-## HIGH Gotchas
-
-### Server-side
-
-| Gotcha | Fix |
-|--------|-----|
-| Duplicate DB calls across server components | Wrap with `React.cache()` for per-request dedup |
-| Large data serialized to client | Pick only needed fields before passing to client components |
-| Blocking post-processing (logging, analytics) | Use `after()` for non-blocking tasks |
-
-## MEDIUM Gotchas
-
-| Gotcha | Fix |
-|--------|-----|
-| Expensive computation re-runs on parent re-render | Isolate in `memo()` wrapped component |
-| Static JSX recreated every render | Hoist outside component: `const HEADER = <header>...</header>` |
-| Long lists render all items | `content-visibility: auto; contain-intrinsic-size: 0 80px;` on list items |
-| `{count && <Item />}` renders `0` | Use ternary: `{count > 0 ? <Item /> : null}` |
-| Event handler changes every render → effect re-runs | Store handlers in `useRef` for stable effects |
-| Object in useEffect deps | Use primitive values (id, not entire object) as dependencies |
-
-## Done Criteria (K4)
-
-- [ ] No sequential awaits for independent operations
-- [ ] No barrel imports for tree-shakeable modules
-- [ ] Server component data is `React.cache()`-wrapped where reused
-- [ ] Heavy third-party loaded after hydration
-- [ ] Long lists use `content-visibility: auto`

package/skills/vibe.react-best-practices/rubrics/performance.md

@@ -1,82 +0,0 @@
-# React Performance Patterns
-
-## memo — Skip Re-render
-
-Wrap components that receive stable props but re-render from parent updates.
-
-```typescript
-const ItemRow = memo(function ItemRow({ item }: { item: Item }) {
-  return <tr>{item.name}</tr>;
-});
-```
-
-**When to use**: Pure display components in long lists, or children of frequently-updating parents.
-**When NOT to use**: Components that almost always re-render anyway (memo check costs CPU too).
-
-## useMemo — Cache Expensive Computation
-
-```typescript
-// Expensive filter/sort that depends on list + query
-const filtered = useMemo(
-  () => items.filter(i => i.name.includes(query)).sort(byDate),
-  [items, query]
-);
-```
-
-**Rule**: Only memoize when the computation is genuinely expensive (> 1ms). Measuring before adding is best practice.
-
-**Gotcha**: Object/array deps break memoization — use primitive values:
-
-```typescript
-// Bad: new object reference every render breaks memo
-useMemo(() => compute(config), [config]);
-
-// Good: primitive values stay stable
-useMemo(() => compute(config), [config.id, config.mode]);
-```
-
-## useCallback — Stable Function References
-
-```typescript
-// Without useCallback: new function ref → effect re-runs every render
-const handleSubmit = useCallback(
-  (e: FormEvent) => { submitForm(formData); },
-  [formData]
-);
-```
-
-**Use when**: passing callbacks to memo-wrapped children, or as useEffect dependencies.
-**Skip when**: the component receiving it is not memoized (no benefit).
-
-## Suspense — Stream Slow Components
-
-```tsx
-// Without Suspense: entire page waits for slowComponent
-// With Suspense: page streams, slot renders when ready
-<Suspense fallback={<Skeleton />}>
-  <SlowDataComponent />   {/* server component with slow fetch */}
-</Suspense>
-```
-
-**Gotcha**: Suspense boundaries must be placed at the **component that fetches**, not a parent.
-
-## useTransition — Keep UI Responsive
-
-```typescript
-const [isPending, startTransition] = useTransition();
-
-// Mark state update as non-urgent — keeps input responsive
-startTransition(() => setSearchQuery(inputValue));
-```
-
-Use for filtering, sorting, navigation — updates that can briefly lag without hurting UX.
-
-## Quick Reference
-
-| Pattern | Use Case | Skip When |
-|---------|----------|-----------|
-| `memo` | Pure component in updating tree | Almost always re-renders anyway |
-| `useMemo` | Expensive calculation | Fast computation (< 1ms) |
-| `useCallback` | Stable dep for memo/effect | Recipient is not memoized |
-| `Suspense` | Slow async data in subtree | Synchronous rendering |
-| `useTransition` | Non-urgent state updates | Critical/immediate feedback |

package/skills/vibe.react-best-practices/rubrics/server-components.md

@@ -1,86 +0,0 @@
-# Server vs Client Component Decision Guide
-
-## Decision Tree
-
-```
-Does this component need any of the following?
-    │
-    ├─ useState / useReducer         → Client
-    ├─ useEffect / lifecycle hooks   → Client
-    ├─ Browser APIs (window, document, localStorage) → Client
-    ├─ Event handlers (onClick, onChange, onSubmit)  → Client
-    ├─ Third-party hooks (useRouter, useForm, etc.)  → Client
-    │
-    └─ None of the above?            → Server (default)
-```
-
-## Default: Server Component
-
-Next.js App Router defaults all components to Server. Only add `"use client"` when required.
-
-**Server components can:**
-- Fetch data directly (no useEffect needed)
-- Access backend resources (DB, filesystem, env secrets)
-- Reduce client bundle size (zero JS shipped)
-- Use `async/await` at the component level
-
-```tsx
-// Server component — no directive needed
-async function UserProfile({ id }: { id: string }) {
-  const user = await db.user.findUnique({ where: { id } });
-  return <div>{user?.name}</div>;
-}
-```
-
-## Client Component
-
-Add `"use client"` at the top of the file.
-
-```tsx
-"use client";
-import { useState } from "react";
-
-export function Counter() {
-  const [count, setCount] = useState(0);
-  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
-}
-```
-
-## Composition Pattern: Push Client Down
-
-Keep client boundary as low as possible. Wrap only the interactive slice, not the whole page.
-
-```tsx
-// Bad: entire section becomes client
-"use client";
-async function ProductPage({ id }: { id: string }) { ... }
-
-// Good: server fetches, client handles interaction
-async function ProductPage({ id }: { id: string }) {
-  const product = await getProduct(id);
-  return (
-    <div>
-      <ProductDetails product={product} />   {/* server */}
-      <AddToCartButton productId={id} />     {/* client — small, isolated */}
-    </div>
-  );
-}
-```
-
-## Gotchas
-
-| Mistake | Effect | Fix |
-|---------|--------|-----|
-| Importing a Client component into a Server component that passes a non-serializable prop | Runtime error | Only pass serializable data (string, number, plain object) |
-| `"use client"` on a file that only uses server features | Unnecessary client bundle | Remove directive |
-| `async` component without Suspense wrapper | Blocks entire parent render | Wrap in `<Suspense fallback={...}>` |
-| Calling `React.cache()` in a Client component | No effect — cache is server-only | Move data fetching to Server component |
-| Secrets in Client component | Exposed to browser | Move fetch to Server component or API route |
-
-## Data Fetching Boundary
-
-| Where | Pattern |
-|-------|---------|
-| Server component | `await fetch()` / direct DB call |
-| Client component | `useEffect` + fetch, or SWR/React Query |
-| Shared across server components | Wrap with `React.cache()` for per-request dedup |

package/skills/vibe.reason/SKILL.md

@@ -1,160 +0,0 @@
----
-name: vibe.reason
-description: 복잡한 문제에서 가설·근거·트레이드오프를 구조화해 결론을 내려야 할 때 체계적 reasoning framework를 적용한다.
-argument-hint: "problem description"
-user-invocable: true
----
-
-# /vibe.reason
-
-## 완료 기준
-
-- [ ] 문제, 제약, 판단 기준이 명시되어 있다.
-- [ ] 각 핵심 주장에 근거 또는 명시된 가정이 연결되어 있다.
-- [ ] 검토한 대안과 탈락 이유가 기록되어 있다.
-- [ ] 결론이 판단 기준에 따라 재현 가능하게 도출되어 있다.
-
-Apply 9-step reasoning framework to complex problems.
-
-## Usage
-
-```
-/vibe.reason "problem description"
-```
-
-> **⏱️ Timer**: Query the system clock at START and record the result as `{start_time}`.
-
-## When to Use
-
-1. **Complex bug debugging** - Root cause unclear, need systematic hypothesis verification
-2. **Architecture design decisions** - Choose optimal option among several
-3. **Performance optimization** - Bottleneck may be in multiple places
-4. **Refactoring planning** - Systematically analyze legacy code complexity
-5. **Requirements analysis** - Reconcile conflicting requirements
-
-## 9-Step Reasoning Framework
-
-### 1. Logical Dependencies and Constraints
-- Check policies, rules, prerequisites
-- Optimize task order (identify dependencies)
-- Apply user constraints first
-
-### 2. Risk Assessment
-- Analyze action consequences
-- Check rollback possibility
-- Review compatibility, security, performance risks
-
-### 3. Inductive Reasoning and Hypothesis Exploration
-- Generate hypotheses about root cause
-- Prioritize by likelihood
-- Present verification method for each hypothesis
-
-### 4. Result Evaluation and Adaptability
-- Modify plan based on observations
-- Generate new hypothesis when disproved
-- Determine backtracking need
-
-### 5. Information Availability
-- Identify all available tools
-- Reference relevant policy/rule documents
-- Restore previous context
-- Distinguish items needing user confirmation
-
-### 6. Precision and Evidence
-- Cite exact source when referencing policies
-- Include filename:line when referencing code
-- Provide exact metric numbers
-
-### 7. Completeness
-- Integrate all requirements, options, preferences
-- Avoid premature conclusions
-- Explore multiple alternatives
-
-### 8. Persistence and Patience
-- Intelligently retry temporary errors
-- Solve problems through strategy changes
-- Continue until all reasoning steps complete
-
-### 9. Response Suppression
-- Act only after reasoning complete
-- Document reasoning process for complex decisions
-- Ensure safety through step-by-step execution
-
-> Read `references/output-format-template.md` for the full markdown report template.
-
-> Read `references/worked-example.md` for a full worked example applying the 9-step framework to a debugging scenario.
-
-## Best Practices
-
-1. **Describe problem specifically**
-   - Bad: "There's a bug"
-   - Good: "After login, profile page intermittently returns 500 error"
-
-2. **Include context**
-   - Occurrence conditions (always? intermittent?)
-   - Relevant tech stack
-   - Solutions already tried
-
-3. **Verify step by step**
-   - Verify hypotheses in order of likelihood
-   - Feedback each verification result
-
-## Core Tools (Reasoning Support)
-
-### Tool Invocation
-
-All tools are called via:
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => t.TOOL_NAME({...args}).then(r => console.log(r.content[0].text)))"
-```
-
-### Recommended Tools for Reasoning
-
-| Tool | Purpose | When to Use |
-|------|---------|-------------|
-| `analyzeComplexity` | Complexity analysis | Identify high-risk complex code |
-| `saveMemory` | Save reasoning progress | Store hypothesis verification results |
-| `recallMemory` | Recall saved memory | Retrieve previous reasoning context |
-
-### Example Tool Usage in Reasoning
-
-**1. Find potential problem source:**
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => t.findSymbol({symbolName: 'getProfile', searchPath: 'src/'}).then(r => console.log(r.content[0].text)))"
-```
-
-**2. Trace references to understand flow:**
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => t.findReferences({symbolName: 'sessionData', searchPath: 'src/'}).then(r => console.log(r.content[0].text)))"
-```
-
-**3. Save hypothesis verification result:**
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => t.saveMemory({key: 'hypothesis-1-result', value: 'Session save timing issue confirmed - race condition in auth middleware', category: 'reasoning', projectPath: process.cwd()}).then(r => console.log(r.content[0].text)))"
-```
-
----
-
-## Quality Gate (Mandatory)
-
-> Read `references/quality-rubrics.md` for the full reasoning quality checklist, hypothesis quality standards, minimum hypothesis count, evidence standards, risk assessment matrix, forbidden reasoning patterns, and reasoning output requirements.
-
-### Reasoning Score Calculation
-
-```
-Score = (completed_steps / 9) × 100
-
-Grades:
-- 9/9 (100%): ✅ THOROUGH - Ready to act
-- 7-8/9 (78-89%): ⚠️ ADEQUATE - Minor gaps
-- 5-6/9 (56-67%): ❌ INCOMPLETE - More analysis needed
-- <5/9 (<56%): ❌ INSUFFICIENT - Start over
-```
-
----
-
-ARGUMENTS: $ARGUMENTS