@su-record/vibe 3.2.62 → 4.0.0

package/skills/vibe.design-review/rubrics/ai-slop-patterns.md

@@ -1,83 +0,0 @@
-# AI Slop Detection — Pattern Reference
-
-Patterns that indicate AI-generated defaults rather than deliberate design decisions. Each entry describes the visual signature and why it signals slop.
-
----
-
-## Pattern 1: Cyan/Neon-on-Dark Accent
-
-**Visual signature**: Electric cyan (`#00D8FF`, `#22D3EE`) or neon green/purple as the sole accent color on a dark gray or near-black background. Often applied to buttons, badges, and chart lines simultaneously.
-
-**Why it's slop**: This palette is the default "tech/SaaS" output for most AI image and code generators. It signals no brand research was done.
-
-**Legitimate exception**: Cyberpunk-themed games, developer tools with a deliberate retro-terminal aesthetic, or products with documented brand guidelines using these colors.
-
----
-
-## Pattern 2: Purple-to-Blue Gradient Hero
-
-**Visual signature**: A full-bleed hero section or page background using a diagonal or radial gradient from `#7C3AED` (purple) to `#2563EB` (blue). Often combined with white or light text and a "glow" effect.
-
-**Why it's slop**: The most overused AI-generated hero background across all categories and industries. Applied without regard for brand personality.
-
-**Legitimate exception**: Brand explicitly uses purple and blue as primary colors with documented rationale.
-
----
-
-## Pattern 3: Hero Metric Template
-
-**Visual signature**: An oversized number (60–80px font, often bold or gradient-colored) with a tiny label below it (`"Active Users"`, `"Revenue"`, `"Uptime"`). Three or four of these arranged in a row as the primary dashboard view.
-
-**Why it's slop**: It's a structural template, not a data visualization decision. Used regardless of whether the numbers are meaningful or whether the user needs them front and center.
-
-**Legitimate exception**: Real-time operational dashboards where these metrics are the primary user task.
-
----
-
-## Pattern 4: Identical 3-Up Card Grid
-
-**Visual signature**: Exactly three cards in a horizontal row, each containing an icon (top-left or centered), a short bold title, and 1–2 lines of description text. Repeated verbatim as a features section, benefits section, or team section.
-
-**Why it's slop**: The 3-up grid is the default content-filling pattern for every AI-generated landing page. It imposes a visual structure regardless of whether the content benefits from comparison.
-
-**Legitimate exception**: Content is genuinely comparative (pricing tiers, product variants), or the grid contains more than 3 genuinely distinct items.
-
----
-
-## Pattern 5: Default Glassmorphism
-
-**Visual signature**: Cards and panels with `backdrop-filter: blur(12px)`, a semi-transparent white or colored background (`rgba(255,255,255,0.1)`), and a subtle border (`rgba(255,255,255,0.2)`). Applied as the primary surface treatment across all cards.
-
-**Why it's slop**: Glassmorphism is a specific aesthetic that requires a layered background to function visually. AI applies it universally as a "modern" default, often on solid-color backgrounds where it produces no effect.
-
-**Legitimate exception**: OS-style UIs, media applications with rich background imagery, or products where glass surfaces are part of a coherent aesthetic system.
-
----
-
-## Pattern 6: Bounce/Elastic Functional Animation
-
-**Visual signature**: UI elements that overshoot their final position with `cubic-bezier` bounce or spring easing during state transitions — modals sliding in with elastic overshoot, buttons that wobble on hover, list items that bounce into view.
-
-**Why it's slop**: Bounce easing communicates playfulness. Applied to functional transitions (modals, form submissions, navigation) it creates a tonally inconsistent experience and feels unpolished in professional contexts.
-
-**Legitimate exception**: Mobile games, children's apps, or products with an explicitly playful brand personality where the animation reinforces brand voice.
-
----
-
-## Pattern 7: Inter/Roboto as Lazy Default
-
-**Visual signature**: Inter or Roboto used as both heading and body font across a product with no visible typography hierarchy differentiation. No font scale customization — using default weights and sizes from the framework.
-
-**Why it's slop**: These fonts are excellent but are chosen by AI because they are safe and system-default-adjacent. Font selection should reflect brand personality and audience expectations.
-
-**Legitimate exception**: Products that have explicitly evaluated their font options and chosen Inter/Roboto for legibility, neutrality, or performance reasons — with documented rationale.
-
----
-
-## Pattern 8: Gradient Text on Metrics/Statistics
-
-**Visual signature**: Key numbers, statistics, or headings rendered with a linear gradient applied to the text itself (`background-clip: text; -webkit-text-fill-color: transparent`), typically the same purple-to-blue or cyan-to-blue range.
-
-**Why it's slop**: Gradient text is visually noisy and reduces readability. It is applied wholesale by AI to make numbers "pop" without considering whether the visual effect serves the data's meaning.
-
-**Legitimate exception**: Brand wordmarks, decorative headings where legibility is secondary to visual impact, or hero statements where the gradient is part of a consistent typographic system.

package/skills/vibe.design-review/rubrics/scoring.md

@@ -1,63 +0,0 @@
-# Design Audit — Detailed Scoring Rubric
-
-Each dimension scored 0–4. Score the lowest applicable level that matches observed issues.
-
----
-
-## 1. Accessibility (a11y)
-
-| Score | Criteria |
-|-------|----------|
-| **4** | All interactive elements keyboard-reachable; ARIA roles correct; contrast ≥ 4.5:1 everywhere; all images have meaningful alt text; every form input has a label; focus indicators visible; `aria-live` on dynamic regions; skip-to-content present |
-| **3** | 1–2 minor issues: e.g., one icon missing `aria-label`, or skip link absent on a simple page |
-| **2** | Multiple issues but no complete blockers: e.g., some form inputs unlabeled, focus order inconsistent in one section |
-| **1** | Significant gaps: contrast failures on primary text, keyboard traps present, or no ARIA on custom widgets |
-| **0** | Critical failures: interactive elements unreachable by keyboard, no contrast at all on key text, or screen reader produces nonsense navigation |
-
----
-
-## 2. Performance
-
-| Score | Criteria |
-|-------|----------|
-| **4** | All below-fold images lazy-loaded with `srcset` and modern formats; ≤3 font files with `font-display: swap`; critical CSS inlined; JS code-split at routes; no layout shift on media; no duplicate deps |
-| **3** | 1–2 minor gaps: e.g., one non-critical image missing `loading="lazy"`, or a fourth font file loaded |
-| **2** | Several issues: missing lazy load on multiple images, no `font-display`, or a blocking script in `<head>` |
-| **1** | Major issues: no image optimization at all, large unneeded CSS framework fully loaded, or significant layout shifts |
-| **0** | Critical: blocking JS on `<head>` delays render, images 5× larger than necessary, LCP asset entirely unoptimized |
-
----
-
-## 3. Responsive
-
-| Score | Criteria |
-|-------|----------|
-| **4** | Mobile-first breakpoints; all touch targets ≥ 44×44px; no horizontal scroll at any viewport; typography scales cleanly; container queries used where appropriate; navigation adapts correctly |
-| **3** | 1–2 small gaps: e.g., one touch target slightly under 44px, or minor horizontal overflow on a niche breakpoint |
-| **2** | Several issues: some touch targets too small, typography doesn't scale, navigation doesn't adapt on mobile |
-| **1** | Layout broken at common breakpoints; horizontal scroll present; fixed-width elements causing overflow |
-| **0** | Completely non-responsive: desktop layout forced on mobile, content unreadable at 375px |
-
----
-
-## 4. Theming
-
-| Score | Criteria |
-|-------|----------|
-| **4** | All colors via CSS custom properties; dark mode supported or explicitly opted out with documentation; spacing, radius, and shadows all use design tokens; component variants use data attributes or classes only |
-| **3** | 1–3 hardcoded values in low-visibility areas; no inline styles on primary surfaces |
-| **2** | Multiple hardcoded values scattered through components; some spacing arbitrary; dark mode partial or inconsistent |
-| **1** | Most values hardcoded; design tokens exist but rarely used; inline styles prevalent |
-| **0** | No token system; all values inline or in scattered magic numbers; dark mode completely absent if required |
-
----
-
-## 5. AI Slop Detection
-
-| Score | Criteria |
-|-------|----------|
-| **4** | No AI template patterns; color scheme, typography, and layout reflect deliberate brand choices; animations serve function; design feels intentional and specific to this product |
-| **3** | 1 pattern present but with partial justification (e.g., gradient used sparingly, not as the dominant aesthetic) |
-| **2** | 2–3 patterns present; design leans on AI defaults without clear brand rationale |
-| **1** | 4–5 patterns present; the overall aesthetic is indistinguishable from generic AI-generated UI |
-| **0** | Full AI slop template: neon/cyan accents, purple-blue gradient hero, glassmorphism cards, 3-up icon grids, Inter font, gradient metric text — all present simultaneously |

package/skills/vibe.design-review/rubrics/ux-heuristics.md

@@ -1,143 +0,0 @@
-# Nielsen's 10 Usability Heuristics — Code Review Adaptation
-
-Scoring per heuristic: 0 (violated) → 4 (excellent). Focus on what is observable in the code.
-
----
-
-## H1 — Visibility of System Status
-
-**What to look for in code**: Loading states on async actions, progress indicators, state-driven class/attribute changes, `aria-live` regions for dynamic content.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Every async action has a loading state; progress shown for multi-step ops; dynamic regions use `aria-live` |
-| **3** | Most async actions covered; 1 operation missing feedback |
-| **2** | Loading states on primary actions only; secondary actions have no feedback |
-| **1** | Only a spinner on page load; form submissions and mutations give no feedback |
-| **0** | No loading states anywhere; UI freezes silently on async calls |
-
----
-
-## H2 — Match Between System and Real World
-
-**What to look for**: Label copy, icon choices, terminology in component props and display text, logical grouping of related items.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | All labels use user-facing language (not internal field names); icons are universally understood; groupings match mental models |
-| **3** | Mostly natural language; 1–2 developer-facing terms exposed in UI |
-| **2** | Mixed: some labels match user expectations, others use internal/technical terminology |
-| **1** | Predominantly technical labels (`user_id`, `ts`, `ref_code`) in visible UI |
-| **0** | Raw API field names or database column names exposed directly to users |
-
----
-
-## H3 — User Control and Freedom
-
-**What to look for**: Cancel buttons on dialogs and forms, undo functionality, ability to navigate back, escape-to-close on modals.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Undo available for destructive actions; all modals closeable via Escape; cancel on all multi-step flows |
-| **3** | Most paths have exits; one flow lacks a clear back/cancel |
-| **2** | Cancel exists on modals but destructive actions (delete, submit) have no undo |
-| **1** | No undo; several flows trap the user until completion |
-| **0** | Irreversible destructive actions with no confirmation or recovery path |
-
----
-
-## H4 — Consistency and Standards
-
-**What to look for**: Reuse of shared components, consistent prop naming, same action always produces same UI response, platform conventions followed.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Shared component library used throughout; same action triggers same visual pattern; follows platform HIG |
-| **3** | 1–2 inconsistencies (e.g., one custom button not using Button component) |
-| **2** | Some shared components but several one-off implementations for identical patterns |
-| **1** | Each page re-implements its own UI patterns; no shared components |
-| **0** | Same action produces visually different results on different screens |
-
----
-
-## H5 — Error Prevention
-
-**What to look for**: Input validation (inline, not just on submit), confirmation dialogs on destructive actions, disabled states on invalid forms, input constraints (maxLength, type, pattern).
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Inline validation; destructive actions confirmed; submit disabled until valid; input types constrain input |
-| **3** | Confirmation dialogs present; validation on submit but not inline |
-| **2** | Some validation; destructive actions have confirmation but forms don't validate until submit |
-| **1** | No inline validation; destructive actions unconstrained |
-| **0** | No validation or confirmation; data loss possible without warning |
-
----
-
-## H6 — Recognition Rather Than Recall
-
-**What to look for**: Breadcrumbs, visible current state in navigation, contextual help text, search suggestions, recently used items.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Current location always visible; options surfaced in context; search includes suggestions |
-| **3** | Navigation shows current state; options visible on primary flows |
-| **2** | Some affordances; secondary flows require user to remember where they are |
-| **1** | No breadcrumbs; navigation doesn't indicate current section; users must recall paths |
-| **0** | Deep nested flows with no orientation cues |
-
----
-
-## H7 — Flexibility and Efficiency
-
-**What to look for**: Keyboard shortcuts, bulk actions, saved defaults, power-user paths that bypass multi-step flows.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Keyboard shortcuts for primary actions; bulk selection; smart defaults pre-populated |
-| **3** | Good defaults; 1–2 keyboard shortcuts on critical actions |
-| **2** | No shortcuts; forms have some defaults but key fields are always blank |
-| **1** | Every task requires the same number of steps regardless of user expertise |
-| **0** | Power users actively slowed down (e.g., forced onboarding on repeat visits) |
-
----
-
-## H8 — Aesthetic and Minimalist Design
-
-**What to look for**: Signal-to-noise ratio in rendered output; unnecessary decorative elements; information density relative to task complexity.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Every visible element serves a task or provides necessary context; no decorative noise |
-| **3** | Mostly clean; 1–2 decorative elements that could be removed without loss |
-| **2** | Several decorative elements that compete with primary content |
-| **1** | UI is visually busy; primary actions compete with decoration |
-| **0** | Information overload; users cannot identify primary action without significant scanning |
-
----
-
-## H9 — Help Users Recognize and Recover from Errors
-
-**What to look for**: Error message copy (specific, human-readable, with next steps), error placement (near the problem), error state styling.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Errors are specific, placed next to the problem, and suggest a fix; styled distinctly |
-| **3** | Clear error messages; placed correctly; fix suggestion sometimes missing |
-| **2** | Error messages exist but are generic ("Something went wrong") or placed in a toast far from the issue |
-| **1** | Raw error codes or API messages exposed to users |
-| **0** | No error states; failures silently ignored or produce white screens |
-
----
-
-## H10 — Help and Documentation
-
-**What to look for**: Tooltips on complex fields, onboarding flows for new users, empty states with guidance, contextual help links.
-
-| Score | Code Evidence |
-|-------|---------------|
-| **4** | Tooltips on non-obvious fields; empty states guide next action; onboarding present for new users |
-| **3** | Empty states with calls-to-action; tooltips on some complex fields |
-| **2** | Generic empty states ("No data found") without guidance |
-| **1** | No tooltips, empty state guidance, or onboarding |
-| **0** | Confusing UI with no help and no path to documentation |

package/skills/vibe.design-review/templates/critique-report.md

@@ -1,86 +0,0 @@
-# Design Critique: {{TARGET}}
-
-**Date**: {{DATE}}
-**Scope**: {{SCOPE_DESCRIPTION}}
-**Design Context**: {{CONTEXT_SOURCE}} (design-context.json / defaults)
-**Audience**: {{AUDIENCE_PRIMARY}} — {{AUDIENCE_EXPERTISE}}
-
----
-
-## Heuristic Scores
-
-| # | Heuristic | Score | Key Issue |
-|---|-----------|-------|-----------|
-| H1 | Visibility of system status | {{H1_SCORE}}/4 | {{H1_ISSUE}} |
-| H2 | Match between system and real world | {{H2_SCORE}}/4 | {{H2_ISSUE}} |
-| H3 | User control and freedom | {{H3_SCORE}}/4 | {{H3_ISSUE}} |
-| H4 | Consistency and standards | {{H4_SCORE}}/4 | {{H4_ISSUE}} |
-| H5 | Error prevention | {{H5_SCORE}}/4 | {{H5_ISSUE}} |
-| H6 | Recognition rather than recall | {{H6_SCORE}}/4 | {{H6_ISSUE}} |
-| H7 | Flexibility and efficiency | {{H7_SCORE}}/4 | {{H7_ISSUE}} |
-| H8 | Aesthetic and minimalist design | {{H8_SCORE}}/4 | {{H8_ISSUE}} |
-| H9 | Help recognize and recover from errors | {{H9_SCORE}}/4 | {{H9_ISSUE}} |
-| H10 | Help and documentation | {{H10_SCORE}}/4 | {{H10_ISSUE}} |
-| **Total** | | **{{TOTAL_SCORE}}/40** | **{{TOTAL_PCT}}%** |
-
----
-
-## Persona Red Flags
-
-### Power User — {{POWER_STATUS}}
-{{#POWER_ISSUES}}
-- {{ISSUE}}
-{{/POWER_ISSUES}}
-{{#POWER_CLEAR}}
-- No red flags
-{{/POWER_CLEAR}}
-
-### First-Time User — {{FIRST_TIME_STATUS}}
-{{#FIRST_TIME_ISSUES}}
-- {{ISSUE}}
-{{/FIRST_TIME_ISSUES}}
-{{#FIRST_TIME_CLEAR}}
-- No red flags
-{{/FIRST_TIME_CLEAR}}
-
-### Accessibility-Dependent User — {{A11Y_STATUS}}
-{{#A11Y_ISSUES}}
-- {{ISSUE}}
-{{/A11Y_ISSUES}}
-{{#A11Y_CLEAR}}
-- No red flags
-{{/A11Y_CLEAR}}
-
-### Stressed / Distracted User — {{STRESSED_STATUS}}
-{{#STRESSED_ISSUES}}
-- {{ISSUE}}
-{{/STRESSED_ISSUES}}
-{{#STRESSED_CLEAR}}
-- No red flags
-{{/STRESSED_CLEAR}}
-
-### Mobile-Only User — {{MOBILE_STATUS}}
-{{#MOBILE_ISSUES}}
-- {{ISSUE}}
-{{/MOBILE_ISSUES}}
-{{#MOBILE_CLEAR}}
-- No red flags
-{{/MOBILE_CLEAR}}
-
----
-
-## Top Recommendations
-
-{{#RECOMMENDATIONS}}
-{{INDEX}}. **[{{HEURISTIC}}]** {{RECOMMENDATION}}
-{{/RECOMMENDATIONS}}
-
----
-
-## Next Steps
-
-| Condition | Recommended Skill |
-|-----------|-------------------|
-| Visual complexity / clutter noted | `/design-refine distill` |
-| Token inconsistencies noted | `/design-refine normalize` |
-| Good overall, minor polish needed | `/design-refine polish` |

package/skills/vibe.design-review/templates/report.md

@@ -1,88 +0,0 @@
-# Design Audit Report: {{TARGET}}
-
-**Date**: {{DATE}}
-**Auditor**: {{AUDITOR}}
-**Scope**: {{SCOPE_DESCRIPTION}}
-**Design Context**: {{CONTEXT_SOURCE}} (design-context.json / defaults)
-
----
-
-## Scores
-
-| Dimension | Score | Grade | Key Issues |
-|-----------|-------|-------|------------|
-| Accessibility | {{A11Y_SCORE}}/4 | {{A11Y_GRADE}} | {{A11Y_SUMMARY}} |
-| Performance | {{PERF_SCORE}}/4 | {{PERF_GRADE}} | {{PERF_SUMMARY}} |
-| Responsive | {{RESP_SCORE}}/4 | {{RESP_GRADE}} | {{RESP_SUMMARY}} |
-| Theming | {{THEME_SCORE}}/4 | {{THEME_GRADE}} | {{THEME_SUMMARY}} |
-| AI Slop | {{SLOP_SCORE}}/4 | {{SLOP_GRADE}} | {{SLOP_SUMMARY}} |
-| **Overall** | **{{TOTAL_SCORE}}/20** | **{{TOTAL_PCT}}%** | |
-
-Grade scale: 4=Excellent, 3=Good, 2=Moderate, 1=Major Issues, 0=Critical
-
----
-
-## Findings
-
-### P0 — Blocker (breaks functionality)
-
-{{#P0_FINDINGS}}
-- [{{DIMENSION}}] {{DESCRIPTION}} — `{{FILE}}:{{LINE}}`
-{{/P0_FINDINGS}}
-{{#NO_P0}}
-- None
-{{/NO_P0}}
-
-### P1 — Critical (significant UX impact)
-
-{{#P1_FINDINGS}}
-- [{{DIMENSION}}] {{DESCRIPTION}} — `{{FILE}}:{{LINE}}`
-{{/P1_FINDINGS}}
-{{#NO_P1}}
-- None
-{{/NO_P1}}
-
-### P2 — Important (noticeable quality gap)
-
-{{#P2_FINDINGS}}
-- [{{DIMENSION}}] {{DESCRIPTION}} — `{{FILE}}:{{LINE}}`
-{{/P2_FINDINGS}}
-{{#NO_P2}}
-- None
-{{/NO_P2}}
-
-### P3 — Minor (polish opportunity)
-
-{{#P3_FINDINGS}}
-- [{{DIMENSION}}] {{DESCRIPTION}} — `{{FILE}}:{{LINE}}`
-{{/P3_FINDINGS}}
-{{#NO_P3}}
-- None
-{{/NO_P3}}
-
----
-
-## Recommendations
-
-{{#RECOMMENDATIONS}}
-{{INDEX}}. {{RECOMMENDATION}}
-{{/RECOMMENDATIONS}}
-
----
-
-## Next Steps
-
-| Condition | Recommended Skill |
-|-----------|-------------------|
-| Design system inconsistencies found | `/design-refine normalize` |
-| UX/usability concerns noted | `/design-review critique` |
-| Score ≥ 16/20, minor polish only | `/design-refine polish` |
-
----
-
-## Audit Metadata
-
-- Files scanned: {{FILE_COUNT}}
-- Total findings: {{TOTAL_FINDINGS}} (P0: {{P0_COUNT}}, P1: {{P1_COUNT}}, P2: {{P2_COUNT}}, P3: {{P3_COUNT}})
-- Platform: {{PLATFORM}}
-- Stack: {{STACK}}

package/skills/vibe.design-teach/SKILL.md

@@ -1,11 +0,0 @@
----
-name: vibe.design-teach
-description: Compatibility alias for gathering project design context. Use for design-teach, design-setup, or design-context requests.
-user-invocable: false
-invocation: [auto]
-tier: standard
-triggers: [design-teach, design-setup, design-context]
-priority: 50
----
-
-Load `vibe.design` with `init --from=interview`, preserving update intent and all supplied context.

package/skills/vibe.devlog/SKILL.md

@@ -1,147 +0,0 @@
----
-name: vibe.devlog
-invocation: [auto]
-tier: standard
-description: "Use when accumulated git commits must be turned into a devlog post or the configured N-commit publication threshold is reached."
-triggers: [devlog, 개발일지, dev log, devlog 작성, 개발일지 작성]
-priority: 60
----
-# Devlog Auto-Generator
-
-## Done Criteria
-
-- [ ] 처리한 commit 범위가 산출물에 기록되어 있다.
-- [ ] devlog Markdown이 설정된 대상 경로에 존재한다.
-- [ ] 이미 처리한 commit이 중복 포함되지 않았다.
-- [ ] 설정된 frontmatter 필드가 모두 채워져 있다.
-
-Analyzes git commit history to automatically generate development logs and saves them as posts to the configured blog repository.
-
-## Config
-
-`devlog` section in `.vibe/config.json`:
-
-```json
-{
-  "devlog": {
-    "enabled": true,
-    "targetRepo": "/absolute/path/to/blog-repo",
-    "targetDir": "posts",
-    "prefix": "devlog",
-    "interval": 10,
-    "autoPush": false,
-    "lang": "ko",
-    "author": "Su",
-    "category": "dev-log",
-    "tags": []
-  }
-}
-```
-
-| Key | Required | Default | Description |
-|-----|----------|---------|-------------|
-| `enabled` | Y | `false` | Whether to enable |
-| `targetRepo` | Y | — | Absolute path to the blog repository |
-| `targetDir` | N | `"posts"` | Directory to save posts |
-| `prefix` | N | `"devlog"` | Filename prefix (`{prefix}-{NNNN}.md`) |
-| `interval` | N | `10` | How many commits trigger a generation |
-| `autoPush` | N | `false` | Auto commit+push to targetRepo |
-| `lang` | N | `"ko"` | Writing language |
-| `author` | N | git user.name | Author name |
-| `category` | N | `"dev-log"` | frontmatter category |
-| `tags` | N | `[]` | Default tags (project name etc. auto-added) |
-
-## Trigger Modes
-
-### 1. Auto (lifecycle acceleration)
-
-When lifecycle hooks are available, `devlog-gen.js` may check the counter after
-each commit and invoke `llm-orchestrate.js`. Hooks are acceleration only: before
-declaring the devlog workflow complete, explicitly count commits since the last
-devlog and run the same generation step when the count reaches `interval`.
-
-### 2. Manual
-
-User manually triggers via `/devlog` or the `개발일지 작성` keyword. Collects commits since the last devlog and generates immediately.
-
-## Generation Process
-
-### Step 1: Collect Commits
-
-Collects commits after the date of the last devlog:
-
-```bash
-# Extract date from last devlog file
-# frontmatter date of targetRepo/targetDir/{prefix}-NNNN.md
-git log --oneline --after="{last_date}" --reverse
-```
-
-### Step 2: Analyze & Group
-
-- Identify version bump commits (X.Y.Z pattern)
-- Classify by feat/fix/refactor/docs
-- Select notable commits (meaningful changes)
-
-### Step 3: Generate Markdown
-
-Generated with the following frontmatter format:
-
-```markdown
----
-title: "{project_name} Devlog #{next_number} - {summary_title} ({interval} commits)"
-date: "{today}"
-category: "{category}"
-description: "{one_line_description}"
-tags: [{project_tags}, {auto_detected_tags}]
-author: "{author}"
-lang: "{lang}"
----
-
-# {title}
-
-**Work period**: {start_date} ~ {end_date}
-
-## Work done this period
-
-### {theme} ({interval} commits)
-
-{overview_paragraph}
-
-| Commit | Description |
-|--------|-------------|
-| `{meaningful_commit_message}` | **{highlight}** |
-...
-
-## Work highlights
-
-{2-3 highlights with code blocks or diagrams}
-
-## Development status
-
-- **Version**: {start_version} → {end_version}
-- **Key changes**: {key_changes}
-
----
-
-**Next devlog**: {prefix}-{next+1} (after next {interval} commits)
-```
-
-### Step 4: Write File
-
-```
-{targetRepo}/{targetDir}/{prefix}-{NNNN}.md
-```
-
-The number is automatically determined as the last existing file number + 1.
-
-### Step 5: (Optional) Auto Push
-
-If `autoPush: true`, read `references/auto-push.md` and require normal external-state confirmation. Calls with `autoPush: false` do not load it.
-
-## Rules
-
-- **Preserve original commit messages** — Quote commit messages verbatim, no arbitrary changes
-- **Include version bump commits** — Include in the table but exclude from highlights
-- **Maximum 3 highlights** — Select only the most impactful changes
-- **Use code blocks** — Before/After comparisons and architecture diagrams are recommended
-- **Emphasize numbers** — Line count changes (-N lines), version ranges, file counts, etc.

package/skills/vibe.devlog/references/auto-push.md

@@ -1,10 +0,0 @@
-# Optional Devlog Auto-Push
-
-Load only when `devlog.autoPush` is `true`. External push still requires confirmation.
-
-```bash
-cd {targetRepo}
-git add {targetDir}/{prefix}-{NNNN}.md
-git commit -m "post: Add {prefix} #{NNNN}"
-git push
-```