@su-record/vibe 3.2.6 → 3.2.7

package/skills/vibe.analyze/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vibe.analyze
-description: Analyze any target — code, document, website, or Figma design
+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
 ---
@@ -39,9 +39,9 @@ Determine analysis mode from the argument pattern:
 
 ## File Reading Policy (Mandatory)
 
-- **SPEC/Feature files**: Always use `Read` tool for the full file (never Grep for content)
+- **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)
-- **Grep restriction**: Use only for locating files, not for understanding content
+- **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
 
@@ -55,217 +55,19 @@ Determine analysis mode from the argument pattern:
 
 > **Timer**: Record start time at the beginning. Include elapsed time in the final report.
 
-## Mode 1: Feature/Module Analysis (`/vibe.analyze "feature-name"`)
+## 모드 라우팅 (하나만 로드)
 
-### Goal
+입력 판별 결과에 따라 **아래 reference 중 정확히 하나만** 읽는다. 한 번의 호출은 한 모드만 실행하므로,
+나머지 셋은 읽지 않는다 — 이것이 이 스킬에서 컨텍스트를 가장 크게 줄이는 지점이다.
 
-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
+| 모드 | 선택 조건 | 본문 |
+|---|---|---|
+| **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` |
 
-### 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: Always use native Explore sub-agents. Never explore in main session.**
-
-> Why: 3 Explore agents return ~600 tokens of summaries to main session.
-> Direct Glob/Grep/Read in main session would add 5-15K tokens of raw content.
-
-**Parallel exploration (ALL in ONE message):**
-
-```text
-Agent(subagent_type="Explore", model="haiku",
-  prompt="Find all [FEATURE] related API endpoints. List file paths, HTTP methods, routes, and auth requirements.")
-
-Agent(subagent_type="Explore", model="haiku",
-  prompt="Find all [FEATURE] related services, business logic, and utility functions. Map dependencies.")
-
-Agent(subagent_type="Explore", model="haiku",
-  prompt="Find all [FEATURE] related data models, schemas, and database queries. Document 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.
-
----
-
-## 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
-Agent(subagent_type="general-purpose", model="haiku",
-  prompt="Read the document at [PATH] and extract: 1) Section structure / table of contents 2) Key concepts and definitions 3) Main arguments or claims. Use the Read tool with pages parameter for PDFs.")
-
-Agent(subagent_type="general-purpose", model="haiku",
-  prompt="Read the document at [PATH] and extract: 1) Actionable recommendations 2) Data points, metrics, examples 3) References to external resources. Use the Read tool with pages parameter for PDFs.")
-```
-
-#### 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
-
----
-
-## 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 `WebFetch` tool to retrieve HTML
-- Fetch key pages (home, main feature pages, login, etc.)
-
-#### 2. Analyze (Parallel Sub-Agents)
-
-```text
-Agent(subagent_type="general-purpose", model="haiku",
-  prompt="Analyze the HTML from [URL] (use WebFetch). Extract: 1) Tech stack (framework, meta tags, scripts) 2) Page structure (header, nav, main sections, footer) 3) SEO elements (title, meta description, OG tags, structured data)")
-
-Agent(subagent_type="general-purpose", model="haiku",
-  prompt="Analyze the HTML from [URL] (use WebFetch). Extract: 1) Accessibility (ARIA labels, semantic HTML, alt texts, heading hierarchy) 2) Performance hints (script loading, image optimization) 3) Mobile responsiveness (viewport meta, media queries)")
-
-Agent(subagent_type="general-purpose", model="haiku",
-  prompt="Analyze the HTML from [URL] (use WebFetch). Extract: 1) UX patterns (navigation, CTA placement, form design) 2) Design system hints (CSS variables, component patterns) 3) Content strategy (copywriting tone, information hierarchy)")
-```
-
-#### 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 `WebFetch` 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`
-
----
-
-## Mode 4: Project Quality Analysis (--code/--deps/--arch)
-
-### Scope
-
-- **Default** (`/vibe.analyze`): Full analysis (code + dependencies + architecture)
-- `--code`: Code quality only
-- `--deps`: Dependency analysis only
-- `--arch`: Architecture analysis only
-
-### Code Quality (--code)
-
-- Cyclomatic complexity analysis
-- Code quality validation
-- Coupling/cohesion assessment
-
-### Dependencies (--deps)
-
-- Read `package.json` / `pyproject.toml` / `pubspec.yaml`
-- Detect version conflicts, security vulnerabilities, outdated packages
-
-### Architecture (--arch)
-
-- Identify core modules
-- Map module dependencies
-- Detect circular dependencies and layer violations
-
-### Report
-
-Save to `.vibe/reports/analysis-{date}.md`:
-
-> Read `references/output-templates.md` for the full Mode 4 report format.
+두 모드가 동시에 해당하면 사용자에게 어느 쪽인지 묻는다 — 임의로 고르지 않는다.
 
 ## Core Tools (Semantic Analysis)
 
@@ -294,3 +96,12 @@ Each mode has a weighted completeness checklist. Score = sum(checked items × we
 ---
 
 ARGUMENTS: $ARGUMENTS
+
+## 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

@@ -0,0 +1,81 @@
+# 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

@@ -0,0 +1,50 @@
+# 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

@@ -0,0 +1,47 @@
+# 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`
+
+---

package/skills/vibe.analyze/references/mode4-quality.md

@@ -0,0 +1,35 @@
+# Mode 4: Project Quality Analysis (--code/--deps/--arch)
+
+> vibe.analyze SKILL.md 의 모드 라우팅에서 **이 모드가 선택됐을 때만** 로드한다.
+
+## Mode 4: Project Quality Analysis (--code/--deps/--arch)
+
+### Scope
+
+- **Default** (`/vibe.analyze`): Full analysis (code + dependencies + architecture)
+- `--code`: Code quality only
+- `--deps`: Dependency analysis only
+- `--arch`: Architecture analysis only
+
+### Code Quality (--code)
+
+- Cyclomatic complexity analysis
+- Code quality validation
+- Coupling/cohesion assessment
+
+### Dependencies (--deps)
+
+- Read `package.json` / `pyproject.toml` / `pubspec.yaml`
+- Detect version conflicts, security vulnerabilities, outdated packages
+
+### Architecture (--arch)
+
+- Identify core modules
+- Map module dependencies
+- Detect circular dependencies and layer violations
+
+### Report
+
+Save to `.vibe/reports/analysis-{date}.md`:
+
+> Read `references/output-templates.md` for the full Mode 4 report format.

package/skills/vibe.brand-assets/SKILL.md

@@ -32,8 +32,8 @@ Auto-generate app icons and favicons based on SPEC brand information.
 - `android-chrome-512x512.png`
 
 ### Mobile (if applicable)
-- iOS: `AppIcon.appiconset/` with all sizes
-- Android: `mipmap-*/` adaptive icons
+
+For native iOS or Android targets only, read `references/mobile-assets.md`. Web-only favicon/OG calls do not load it.
 
 ## SPEC Brand Section
 

package/skills/vibe.brand-assets/references/mobile-assets.md

@@ -0,0 +1,6 @@
+# Native Mobile Brand Assets
+
+Load only when the target includes a native iOS or Android app.
+
+- iOS: `AppIcon.appiconset/` with all sizes
+- Android: `mipmap-*/` adaptive icons

package/skills/vibe.capability-loop/SKILL.md

@@ -3,7 +3,7 @@ name: vibe.capability-loop
 user-invocable: false
 invocation: [auto]
 tier: standard
-description: "When an agent fails, diagnose which capability is missing and build it into the repo. Activates after repeated agent failures, tool errors, or when a task keeps failing in the same way. Analyzes failure transcripts, identifies the missing guardrail/tool/abstraction/doc, and creates it permanently. Use this skill whenever you see 3+ similar failures, an agent hitting the same wall repeatedly, or the user asking 'why does this keep failing'."
+description: Use when the same agent or tool failure repeats, or a missing capability blocks progress, to reproduce the cause and build a permanent repository capability.
 triggers: [capability loop, failure loop, build capability, missing capability, agent failed, why did it fail]
 priority: 60
 ---
@@ -113,87 +113,13 @@ Based on classification, build the appropriate artifact:
 - ✅ **Capability prevents the failure** → Step 5 PERSIST
 - ❌ **Capability does NOT prevent the failure** → Step 4.5 ESCALATE (re-diagnose or ask user)
 
-### Step 4.5: ESCALATE — When VERIFY Fails
+### Step 4.5: ESCALATE — When VERIFY Fails (조건부)
 
-> **Problem**: The built capability didn't actually prevent the failure. This usually means the initial diagnosis was wrong (picked `Tool` when it needed `Guardrail`), or the failure has multiple missing capabilities.
->
-> **Do NOT silently proceed** — a sub-standard capability log pollutes `.vibe/capabilities-log.md` and the failure will recur.
+> **진입 조건**: Step 4 VERIFY 실패. 통과했으면 이 단계 전체를 건너뛴다.
+> **Problem**: 만든 capability 가 실제로 실패를 막지 못했다는 뜻 — 대개 초기 진단이 틀렸거나(Tool 로 골랐는데 Guardrail 이 필요했다) 누락 capability 가 여럿이다.
+> **조용히 진행 금지** — 미달 capability 로그는 `.vibe/capabilities-log.md` 를 오염시키고 실패는 재발한다.
 
-**Escalation loop:**
-
-```python
-tried = [current_diagnosis.category]  # e.g., ["Tool"]
-
-while True:
-    # Re-diagnose excluding already-tried categories
-    next_diagnosis = diagnose(failure, exclude=tried)
-
-    if next_diagnosis is None:
-        # All 5 categories (Tool/Guardrail/Abstraction/Documentation/Feedback) exhausted
-        escalate_to_user(failure, tried)
-        break
-
-    if next_diagnosis.category in tried:
-        # Stuck: diagnose keeps returning the same category
-        escalate_to_user(failure, tried)
-        break
-
-    tried.append(next_diagnosis.category)
-    capability = build(next_diagnosis)
-
-    if verify(capability, failure):
-        persist(capability)
-        return  # Success — go to Step 5
-
-    # Still failing — next iteration
-```
-
-**User escalation prompt (interactive mode):**
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⚠️ CAPABILITY LOOP STUCK
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Failure: {original failure description}
-
-Tried capabilities (all failed to prevent the failure):
-  ❌ Tool: {what was built, why it didn't work}
-  ❌ Guardrail: {what was built, why it didn't work}
-  ❌ Documentation: {what was built, why it didn't work}
-
-Automated diagnosis has run out of angles. This failure may require
-human judgment (process issue, cross-category solution, or external factor).
-
-How would you like to proceed?
-  1. Suggest a different angle (e.g., "this is a process issue", "needs Tool+Guardrail combination")
-     → Attempt custom approach per user instruction, then enter next verify
-  2. "manual" — resolve this failure via manual intervention, end capability loop
-     (record "escalated to manual" in capabilities-log.md)
-  3. "abort" — give up, record failure only
-     (record "diagnosis exhausted" in capabilities-log.md, do not halt the rest of the workflow)
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-**ultrawork mode exception:**
-
-```python
-if ultrawork_mode:
-    # Skip user prompt: try all 5 categories in sequence, record final state
-    all_tried_exhausted = exhaust_all_categories(failure, tried)
-    record_failure_to_log(
-        status="diagnosis_exhausted",
-        tried=all_tried_exhausted,
-        failure=failure
-    )
-    return  # Proceed without blocking downstream workflow
-```
-
-**Rollback of failed builds:**
-
-- Each failed capability build should be rolled back before trying the next category (unless it's non-destructive documentation).
-- For code additions (tool/guardrail/abstraction): `git checkout -- {files}` or delete created files.
-- For docs-only additions: leave in place (low risk) but note in escalation prompt.
+에스컬레이션 루프 전문(재진단·타입 재분류·롤백 판단): `references/escalate.md`
 
 ### Step 5: PERSIST — Record for Future Reference
 
@@ -272,3 +198,11 @@ VERIFY: Does the built capability actually prevent the failure?
 - After `/vibe.run` failure → auto-trigger capability-loop diagnosis
 - After `/vibe.review` findings → suggest capability-loop for recurring patterns
 - After manual agent correction → prompt "What capability would have prevented this?"
+
+## Done Criteria
+
+- [ ] The pre-change reproduction command and failing output are recorded.
+- [ ] The missing capability type and selection evidence are recorded.
+- [ ] The same reproduction command passes after the change.
+- [ ] The related deterministic test or guard passes.
+- [ ] The capability log contains status and verification evidence.