@su-record/vibe 3.2.64 → 4.0.0

package/skills/vibe/references/routing-examples.md

@@ -1,85 +0,0 @@
-# /vibe — Routing Examples & Output Format
-
-> vibe SKILL.md 에서 참조. 라우팅 예시 4종과 최종 출력 포맷.
-
-## Routing Examples
-
-### 예시 1: 신규 + figma
-
-```
-입력: /vibe "https://www.figma.com/design/abc/login 로 로그인 페이지"
-
-→ Intent: figma-driven UI
-→ Resume: 없음
-→ Pipeline:
-   1. /vibe.figma  (figma Extract + Convert Mode)
-   2. /vibe.spec   (생성된 SPEC 자동 보정)
-   3. /vibe.run
-   4. /vibe.verify
-   5. /vibe.trace
-```
-
-### 예시 2: Resume
-
-```
-입력: /vibe "이어서"  (혹은 빈 호출)
-
-→ Resume: .vibe/specs/login/ 발견 (3개 phase 파일)
-→ .vibe/features/login/ 없음
-→ Pipeline:
-   1. /vibe.run (구현부터)
-   2. /vibe.verify
-   3. /vibe.trace
-```
-
-### 예시 3: Review only
-
-```
-입력: /vibe "이 코드 리뷰만" + 📎 src/auth/login.ts
-
-→ Intent: review only
-→ Pipeline:
-   1. /vibe.review (단일 phase)
-```
-
-### 예시 4: automationLevel autonomous (ultrawork 별칭)
-
-```
-입력: /vibe "결제 API 만들어줘" ultrawork
-
-→ automationLevel: autonomous 설정 → SPEC 승인 게이트 skip
-→ 병렬 ACT 활성화
-→ ANCHOR→ACT→JUDGE→RECORD 루프 (게이트 통과까지 자동 반복)
-→ stuck 시 TODO 기록 후 루프 종료 (사용자 질문 없음)
-```
-
-
-## Output
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 /vibe Dynamic Dispatcher
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-[Phase 0: Input 분석]
-...
-
-[Phase 1: Intent 분류]
-→ new feature + figma-driven UI
-
-[Phase 2: Resume 감지]
-→ 진행 중인 작업 없음
-
-[Phase 3: 파이프라인 설계]
-...
-
-[Phase 4: 실행]
-... (SPEC 승인은 spec 단계 내부의 1회 게이트)
-
-[Phase 5: 종료 보고]
-...
-```
-
----
-
-ARGUMENTS: {자연어 요구사항 + 첨부}

package/skills/vibe.agents-md/SKILL.md

@@ -1,172 +0,0 @@
----
-name: vibe.agents-md
-user-invocable: false
-invocation: [auto, chain]
-tier: standard
-description: "Use when authoring or optimizing AGENTS.md or CLAUDE.md — create the context file or remove discoverable detail while preserving project-specific gotchas."
-triggers: [agents.md, claude.md, context file, optimize agents, optimize claude, write claude.md, create claude.md, project instructions]
-priority: 50
----
-
-# agents-md — Context File Author & Optimizer
-
-## Done Criteria
-
-- [ ] 요청된 AGENTS.md 또는 CLAUDE.md가 존재한다.
-- [ ] 저장소에서 탐색 가능한 일반 정보가 중복 서술되지 않는다.
-- [ ] 프로젝트 고유 제약과 검증 명령이 남아 있다.
-- [ ] 두 파일을 함께 관리하면 공통 규칙의 의미가 일치한다.
-
-Author and optimize AGENTS.md / CLAUDE.md files. They are the **same doctrine
-under different filenames** — everything below applies to both.
-Reference: https://addyosmani.com/blog/agents-md/
-
-## Core Principles
-
-**One-line test**: "Can the agent discover this by reading the code?" → Yes = delete.
-
-**Every line has a cost** (Curse of Instructions): LLM compliance drops
-exponentially with instruction count — roughly 90% at 1 instruction, ~59% at 5,
-~44% at 10, ~15% at 15+. A short, precise file beats a long, comprehensive one.
-
-**Lost in the Middle**: LLMs attend to the beginning and end of a document and
-under-weight the middle. Most important rules → top. Frequently violated rules
-→ bottom. Background context → middle (OK if ignored).
-
-## Step 1: Find Target Files
-
-Search project root for these files:
-
-Use the harness's file-pattern search capability for `AGENTS.md`, `CLAUDE.md`,
-`.cursorrules`, `.github/copilot-instructions.md`, and `.windsurfrules`.
-
-If a target exists → optimize it (Steps 2–3). If none exists and the user wants
-one → author it (Step 1b), then run the same optimization pass on the draft.
-
-## Step 1b: Authoring From Scratch
-
-Explore before writing: `package.json` (stack, scripts), `*.config.*`,
-`tsconfig.json`, `.env.example`, `Makefile`, `docker-compose.*`. Everything
-found this way is **discoverable — leave it out**.
-
-Then interview for what exploration cannot reveal (one question at a time,
-multiple-choice when possible):
-
-1. **Runtime traps** — differences invisible in code (Bun vs Node, ESM vs CJS)
-2. **Forbidden patterns** — libraries/approaches that burned the team before
-3. **Non-standard conventions** — naming/structure rules that differ from defaults
-4. **Architecture decisions** — business context the code can't explain
-5. **Boundaries** — files never to touch, changes requiring approval first
-
-Draft using `templates/claude-md.md`. Keep per-feature detail out — that
-belongs in SPEC files (`.vibe/specs/`), loaded only when relevant, not in the
-always-loaded context file. For large monorepos: one shared root file plus a
-small per-package file, instead of one giant root.
-
-Don't aim for perfect on day one: start minimal (30–50 lines), observe where
-the agent actually errs, add one line per *recurring* mistake. If the root
-cause is code structure, fix the code instead of adding a rule.
-
-## Step 2: Classify Current Content
-
-Classify each entry by the following criteria:
-
-### Delete (Discoverable)
-
-Information the agent can find by exploring the code:
-
-| Type | Example | Discovery Path |
-|------|---------|---------------|
-| Directory structure | "Components are in src/" | directory listing or file-pattern search |
-| Tech stack | "Uses React + TypeScript" | `package.json`, file extensions |
-| Phase/progress tables | "Phase 1 ✅, Phase 2 ✅..." | Just history, not actionable guidance |
-| Build/test commands | "Run tests with npm test" | `package.json` scripts |
-| API endpoint lists | "POST /api/users" | Router code |
-| Feature descriptions | "Phase 3 implements circuit breaker" | Readable from the code itself |
-| Architecture diagrams | ASCII box diagrams | Conceptual only, no mistake prevention |
-| Code style rules | Indentation, semicolons | Linter/formatter enforces them |
-
-### Keep (Non-discoverable)
-
-Traps and rules the agent cannot know from code alone:
-
-| Type | Example |
-|------|---------|
-| Runtime traps | "This is Bun, not Node" (not in package.json) |
-| Forbidden patterns | "Never use require()", "No React patterns" |
-| SSOT locations | "Only edit model-registry.ts, no hardcoding" |
-| Invariant ordering | "Priority: A → B → C, never change this order" |
-| Retry/fallback limits | "Max 2 retries, never 3+" |
-| Tool choices | "Use Zod only, no joi/yup" |
-| Naming conventions | Non-standard patterns only (if standard, delete) |
-| Project one-liner | Only when purpose is unclear from code |
-| Language/response directives | "Respond in Korean" etc. |
-
-### Anchoring Warning
-
-Mentioning a technology name anchors the agent toward it. "Don't use X" is
-useful, but "We use X" is unnecessary if already visible in code.
-
-### Emphasis Budget
-
-`**IMPORTANT**` / `**MUST**` / `**NEVER**` work only while rare. Reserve them
-for P1 rules; emphasis on every line nullifies all of it.
-
-## Step 3: Restructure
-
-Rewrite in this structure:
-
-```markdown
-# {Project Name} — {One-liner}
-
-{What the project does in 1-2 sentences. Only if purpose is unclear from code.}
-
-# Gotchas
-
-- **{Trap title}.** {Specific do/don't description}.
-- ...
-
-# Naming
-
-{Only if non-standard naming patterns exist. Omit if standard (camelCase etc.).}
-```
-
-Rules:
-- Maximum 3 sections (Intro, Gotchas, Naming)
-- Each gotcha has **bold title + specific do/don't**
-- "Don't use X" is more useful than "We use X"
-- Target under 50 lines total; 60–150 acceptable for complex projects; at 300+ the agent ignores half of it
-- Don't inline everything — point to `docs/FILE.md` and load it on demand (progressive disclosure)
-
-## Step 4: CLAUDE.md Separation (if applicable)
-
-If both files exist, put common rules in AGENTS.md and keep only
-Claude-specific directives (e.g., "Always respond in Korean") in CLAUDE.md.
-Claude Code reads both. If only one file exists, it carries everything —
-same content rules apply.
-
-## Step 5: Report Results
-
-```markdown
-## AGENTS.md Optimization Results
-
-| Metric | Before | After |
-|--------|--------|-------|
-| Lines | N | N |
-| Deleted items | - | N (discoverable) |
-| Kept items | - | N (gotchas) |
-
-### Deleted Items
-- {Item}: {Reason for deletion}
-
-### Kept/Added Items
-- {Item}: {Reason for keeping}
-```
-
-## Maintenance Signals
-
-| Signal | Meaning | Response |
-|--------|---------|----------|
-| Over 300 lines | Information overload | Split or trim |
-| Same mistake repeats | Rule is lost in noise | Emphasize or consolidate |
-| Adding rules has no effect | File is too long | Fix root cause |

package/skills/vibe.agents-md/rubrics/what-to-keep.md

@@ -1,49 +0,0 @@
-# What to Keep vs Remove in AGENTS.md
-
-## The One-Line Test
-
-> "Can the agent discover this by reading the code?" → Yes = delete.
-
-## Keep (Non-discoverable Gotchas)
-
-| Type | Example | Why Keep |
-|------|---------|----------|
-| Runtime trap | "Bun runtime, not Node" | Not visible in package.json |
-| Forbidden pattern | "Never use `require()` — ESM only" | Agent will default to CJS without this |
-| SSOT location | "Edit only `constants.ts` for stack mapping" | Agent will create duplicates |
-| Ordering invariant | "Build before test — always" | Violating silently breaks things |
-| Non-standard convention | "Exports need `.js` extension" | Counterintuitive in TS projects |
-| Tool choice | "Zod only — no joi or yup" | Agent picks any validation lib |
-| Boundary | "Never edit `dist/` directly" | Agent may "fix" generated files |
-| Response directive | "Respond in Korean" | Claude-specific, not in code |
-
-## Remove (Discoverable)
-
-| Type | Why Remove | Where to Find Instead |
-|------|------------|----------------------|
-| Directory structure | `ls` or Glob reveals it | The repo itself |
-| Tech stack list | Listed in `package.json` | `package.json` |
-| Build/test commands | Listed in `scripts` | `package.json` |
-| Phase progress tables | Historical record, not actionable | Git history |
-| API endpoint list | Readable from router code | Source files |
-| Architecture diagrams | Visual aid, no mistake prevention | Readme or separate doc |
-| Feature descriptions | Code speaks for itself | Source files |
-| General best practices | LLM already knows them | Unnecessary |
-
-## Anchoring Warning
-
-Mentioning any technology name biases the agent toward it:
-- "We use React" → unnecessary (visible in package.json) and creates anchoring
-- "Never use jQuery, even for legacy modules" → useful (prevents a specific mistake)
-
-Rule: Only name a technology when saying **don't use it** or when it's a **hidden runtime detail**.
-
-## Size Target
-
-| Outcome | Lines |
-|---------|-------|
-| Ideal | Under 50 |
-| Acceptable | 50-80 |
-| Warning | 80+ |
-
-If over 80 lines, almost certainly contains discoverable content. Audit again.

package/skills/vibe.agents-md/templates/agents-md.md

@@ -1,36 +0,0 @@
-# {{PROJECT_NAME}} — {{ONE_LINER}}
-
-{{OPTIONAL: What the project does in 1-2 sentences. Only include if purpose is unclear from code.}}
-
-## Gotchas
-
-- **{{TRAP_TITLE}}.** {{Specific do/don't — e.g., "Use Bun, not Node. `bun run dev`, not `node`."}}
-- **{{TRAP_TITLE}}.** {{Specific do/don't}}
-- **{{TRAP_TITLE}}.** {{Specific do/don't}}
-
-## Naming
-
-{{Only if non-standard naming patterns exist. Delete this section if standard conventions apply.}}
-
-- {{Pattern}}: {{Example}}
-
----
-
-<!--
-INSTRUCTIONS FOR FILLING THIS TEMPLATE
-
-1. Replace {{PROJECT_NAME}} and {{ONE_LINER}} with your project.
-2. For each Gotcha, ask: "Would an AI agent make this mistake without being told?"
-   - YES → keep it as a gotcha
-   - NO  → delete it (discoverable from code)
-3. Delete the Naming section if you use standard conventions (camelCase, PascalCase, etc.).
-4. Target: under 50 lines total.
-5. Delete this comment block before committing.
-
-WHAT NOT TO ADD:
-- Directory structure (use ls/Glob)
-- Tech stack list (see package.json)
-- Build/test commands (see package.json scripts)
-- Phase progress or history
-- General best practices the LLM already knows
--->

package/skills/vibe.agents-md/templates/claude-md.md

@@ -1,54 +0,0 @@
-# {{PROJECT_NAME}}
-
-{{OPTIONAL: 1-2 sentence description. Only if project purpose is unclear from reading the code.}}
-
-## Commands
-
-{{Only non-obvious commands. Delete commands already in package.json scripts.}}
-
-- `{{COMMAND}}` — {{WHY_ORDER_MATTERS_OR_SPECIAL_FLAGS}}
-
-## Conventions
-
-{{Only what linters/formatters don't enforce automatically.}}
-
-- {{CONVENTION}} — {{e.g., "ESM only — imports need .js extension"}}
-
-## Gotchas
-
-{{Non-discoverable traps an agent will hit without being told.}}
-
-- **{{TRAP_TITLE}}.** {{Specific do/don't description.}}
-- **{{TRAP_TITLE}}.** {{Specific do/don't description.}}
-
-## Boundaries
-
-{{What the agent should never touch or always ask about first.}}
-
-Always: {{ALWAYS_DO}}
-Ask first: {{ASK_BEFORE_DOING}}
-Never: {{ABSOLUTE_PROHIBITION}}
-
----
-
-<!--
-FILLING INSTRUCTIONS
-
-Size targets:
-- Small project (< 10 files): 20-30 lines
-- Medium project (10-50 files): 60-150 lines
-- Large project / monorepo: 100 lines root + 30 lines per package
-
-Placement priority (LLM attention is highest at top and bottom):
-- Top: most critical rules (security, never-do)
-- Middle: background context
-- Bottom: frequently violated rules
-
-For each line ask:
-1. Would the agent make a mistake without this? No → delete
-2. Does every session need this? No → move to SPEC or plan file
-3. Does a linter/hook enforce this? Yes → delete
-4. Is this discoverable from code? Yes → delete
-
-Delete this comment block before committing.
--->

package/skills/vibe.analyze/SKILL.md

@@ -1,105 +0,0 @@
----
-name: vibe.analyze
-description: Use when code, documents, websites, Figma, or project quality must be analyzed into an evidence-backed report.
-argument-hint: '"feature-name" or file.pdf or https://... or --code or --deps or --arch'
-user-invocable: true
----
-
-# /vibe.analyze
-
-Analyze any target: source code, documents, websites, or Figma designs.
-
-## Usage
-
-```
-/vibe.analyze                  # Full project quality analysis
-/vibe.analyze "login"          # Feature/module code exploration + context collection
-/vibe.analyze --code           # Code quality analysis only
-/vibe.analyze --deps           # Dependency analysis only
-/vibe.analyze --arch           # Architecture analysis only
-/vibe.analyze report.pdf       # Document analysis (PDF, markdown, slides)
-/vibe.analyze https://example.com  # Website analysis (UX, tech, SEO, accessibility)
-/vibe.analyze https://figma.com/design/...  # Figma design analysis
-```
-
-## Input Type Auto-Detection
-
-Determine analysis mode from the argument pattern:
-
-| Pattern | Mode | Description |
-|---------|------|-------------|
-| `*.pdf`, `*.docx`, `*.pptx`, `*.md` (file path) | **Document** | Structure, content, quality, applicability |
-| `http(s)://figma.com/*` | **Figma** | Design structure, components, tokens |
-| `http(s)://*` | **Website** | UX, tech stack, SEO, accessibility |
-| `--code`, `--deps`, `--arch` | **Project Quality** | Code quality, dependencies, architecture |
-| String (feature name) | **Feature/Module** | Source code exploration + flow analysis |
-| No argument | **Project Quality** | Full project analysis |
-
-**Detection order**: file extension → URL pattern → flag → string.
-
-## File Reading Policy (Mandatory)
-
-- **SPEC/Feature files**: Always use the harness's full-file reading capability (never text search for content)
-- **Source files**: Read the entire file before analyzing (no partial reads)
-- **Text-search restriction**: Use only for locating files, not for understanding content
-- **Agent prompts**: Always include "Read target files in full before analyzing"
-- **No partial analysis**: Never judge a file by a few lines around a Grep match
-
-## Context Reset
-
-**When this command runs, previous conversation is ignored.**
-- Explore and analyze from scratch like a new session
-- Base analysis only on newly collected information
-
----
-
-> **Timer**: Record start time at the beginning. Include elapsed time in the final report.
-
-## 모드 라우팅 (하나만 로드)
-
-입력 판별 결과에 따라 **아래 reference 중 정확히 하나만** 읽는다. 한 번의 호출은 한 모드만 실행하므로,
-나머지 셋은 읽지 않는다 — 이것이 이 스킬에서 컨텍스트를 가장 크게 줄이는 지점이다.
-
-| 모드 | 선택 조건 | 본문 |
-|---|---|---|
-| **1** Feature/Module | 인자가 기능·모듈 이름 (코드 분석) | `references/mode1-feature.md` |
-| **2** Document | 인자가 PDF·Markdown·슬라이드 파일 | `references/mode2-document.md` |
-| **3** Website | 인자가 http(s) URL | `references/mode3-website.md` |
-| **4** Project Quality | `--code` / `--deps` / `--arch` 플래그 | `references/mode4-quality.md` |
-
-두 모드가 동시에 해당하면 사용자에게 어느 쪽인지 묻는다 — 임의로 고르지 않는다.
-
-## Core Tools (Semantic Analysis)
-
-### Tool Invocation
-
-```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)))"
-```
-
-### Available Tools
-
-| Tool | Purpose | When to Use |
-|------|---------|-------------|
-| `analyzeComplexity` | Complexity analysis | Measure complexity metrics |
-| `validateCodeQuality` | Quality validation | Check code quality standards |
-| `saveMemory` | Save analysis results | Persist findings for future sessions |
-
----
-
-## Quality Gate (Mandatory)
-
-Each mode has a weighted completeness checklist. Score = sum(checked items × weight) / 100. **Minimum depth: L3 for feature analysis, L2 for project overview.**
-
-> Read `references/quality-gate.md` for the full mode-specific weighted checklists, score grades, depth-level table, forbidden-patterns table, and quality thresholds (code/deps).
-
----
-
-## Done Criteria
-
-- [ ] The report records the target and selected mode.
-- [ ] Every material finding has a file/line, URL, or source-location citation.
-- [ ] The selected mode's minimum depth and quality score pass.
-- [ ] The specified `.vibe/reports/` output exists.
-
-ARGUMENTS: $ARGUMENTS

package/skills/vibe.analyze/references/mode1-feature.md

@@ -1,81 +0,0 @@
-# Mode 1: Feature/Module Analysis
-
-> vibe.analyze SKILL.md 의 모드 라우팅에서 **이 모드가 선택됐을 때만** 로드한다.
-
-## Mode 1: Feature/Module Analysis (`/vibe.analyze "feature-name"`)
-
-### Goal
-
-Explore all source code related to the requested feature/module and analyze flow to:
-1. Understand current implementation status
-2. Map code structure and dependencies
-3. Build context for future development/modification requests
-
-### Process
-
-#### 1. Request Analysis
-
-Extract keywords from the user request:
-- Feature name (e.g., login, feed, payment)
-- Action (e.g., create, read, update, delete)
-- Scope (e.g., backend only, frontend only, full)
-
-#### 2. Understand Project Structure
-
-Read `CLAUDE.md`, `package.json`, `pyproject.toml`, etc. to identify tech stack.
-
-> Read `references/output-templates.md` for the full backend/frontend stack → directory mapping.
-
-#### 3. Explore Related Code (Parallel Sub-Agents)
-
-**MANDATORY: Delegate independent exploration through the harness's native collaboration capability. Never explore all branches in the coordinator session.**
-
-> Why: 3 Explore agents return ~600 tokens of summaries to main session.
-> Direct file-pattern search, text search, and full-file reading in the coordinator session would add 5-15K tokens of raw content.
-
-**Harness adapter:** Claude Code maps each worker to Task/Agent; Codex maps each
-worker to native collaboration. Inherit the session model by default. Dispatch
-the following independent workers concurrently when capacity permits:
-
-```text
-- Worker: find all [FEATURE] related API endpoints; list paths, methods, routes, and auth requirements.
-- Worker: find all [FEATURE] related services, business logic, utilities, and dependencies.
-- Worker: find all [FEATURE] related data models, schemas, queries, relationships, and key fields.
-```
-
-> Read `references/output-templates.md` for the additional "Scale for large projects (6+ related files)" agent prompts.
-
-**After all agents return:**
-- Synthesize results → proceed to Flow Analysis
-- Only Read specific files in main session when agent summaries need clarification
-
-#### 4. Flow Analysis
-
-**API Flow:**
-- Endpoint URL and HTTP method
-- Request/response schema
-- Authentication/authorization requirements
-
-**Business Logic:**
-- Core methods and their roles
-- Validation rules
-- External service integrations
-
-**Data Flow:**
-- Related tables/models
-- Relationships (1:N, N:M)
-- Key query patterns
-
-#### 5. Output
-
-> Read `references/output-templates.md` for the full Mode 1 output format.
-
-#### 6. Next Steps
-
-After analysis, suggest mode-specific follow-up actions.
-
-> Read `references/output-templates.md` for the full Next Steps decision tables (code/feature, document, website).
-
-Wait for user's choice before proceeding.
-
----

package/skills/vibe.analyze/references/mode2-document.md

@@ -1,50 +0,0 @@
-# Mode 2: Document Analysis (PDF, Markdown, Slides)
-
-> vibe.analyze SKILL.md 의 모드 라우팅에서 **이 모드가 선택됐을 때만** 로드한다.
-
-## Mode 2: Document Analysis (PDF, Markdown, Slides)
-
-### Goal
-
-Analyze document **structure, key content, quality, and applicability** to:
-1. Extract and organize information from the document
-2. Map relevance to the current project
-3. Suggest follow-up actions (development, improvement, application)
-
-### Process
-
-#### 1. Read Document
-
-- **PDF**: Use `Read` tool with `pages` parameter (split large documents into chunks of 20 pages)
-- **Markdown/Text**: Use `Read` tool for the full file
-- **Image-heavy documents**: Analyze visual elements (slides, diagrams) alongside text
-
-#### 2. Classify Document Type
-
-> Read `references/output-templates.md` for the full document-type → analysis-focus table.
-
-#### 3. Analyze Content (Parallel Sub-Agents)
-
-```text
-- Worker: read [PATH] in full (page ranges for PDFs) and extract section structure, key concepts, definitions, and claims.
-- Worker: read [PATH] in full (page ranges for PDFs) and extract recommendations, data points, examples, and references.
-```
-
-#### 4. Project Relevance Analysis
-
-- Map how document content applies to the current project
-- Check if patterns/tools/techniques mentioned are already implemented
-- Gap analysis: document recommendations vs current project state
-
-#### 5. Output
-
-> Read `references/output-templates.md` for the full Mode 2 output format.
-
-#### Fallback
-
-If `Read` fails for a document format:
-1. Check file extension and try alternative parsing
-2. If binary format is unsupported, inform user and suggest converting to PDF/markdown
-3. Never produce an analysis based on partial or failed reads
-
----

package/skills/vibe.analyze/references/mode3-website.md

@@ -1,47 +0,0 @@
-# Mode 3: Website Analysis (URL)
-
-> vibe.analyze SKILL.md 의 모드 라우팅에서 **이 모드가 선택됐을 때만** 로드한다.
-
-## Mode 3: Website Analysis (URL)
-
-### Goal
-
-Analyze website **tech stack, UX/UI, SEO, accessibility, and performance** to:
-1. Understand technical implementation
-2. Identify improvement opportunities
-3. Collect benchmarking insights
-
-### Process
-
-#### 1. Fetch Website
-
-- Use the harness's web-page retrieval capability to retrieve HTML
-- Fetch key pages (home, main feature pages, login, etc.)
-
-#### 2. Analyze (Parallel Sub-Agents)
-
-```text
-- Worker: retrieve and analyze [URL] for tech stack, page structure, and SEO elements.
-- Worker: retrieve and analyze [URL] for accessibility, performance hints, and responsiveness.
-- Worker: retrieve and analyze [URL] for UX patterns, design-system signals, and content strategy.
-```
-
-#### 3. Figma URL Handling
-
-If a Figma URL is detected, switch to **Figma-specific analysis**:
-- Use `get_design_context` or `get_screenshot` to collect design data
-- Analyze component structure, design tokens, layout patterns
-- Compare design intent with current project code
-
-#### 4. Output
-
-> Read `references/output-templates.md` for the full Mode 3 output format.
-
-#### Fallback
-
-If web-page retrieval fails:
-1. Retry once with a simplified URL (strip query params)
-2. If still failing, inform user of the error (timeout, DNS, etc.)
-3. Suggest user provide HTML file directly: `/vibe.analyze page.html`
-
----