opencodekit 0.18.1 → 0.18.3

package/dist/template/.opencode/skill/swiftui-expert-skill/SKILL.md

@@ -1,16 +1,29 @@
 ---
 name: swiftui-expert-skill
 description: Write, review, or improve SwiftUI code following best practices for state management, view composition, performance, modern APIs, Swift concurrency, and iOS 26+ Liquid Glass adoption. Use when building new SwiftUI features, refactoring existing views, reviewing code quality, or adopting modern SwiftUI patterns.
+version: 1.0.0
+tags: [apple, ui]
+dependencies: []
 ---
 
 # SwiftUI Expert Skill
 
+## When to Use
+
+- When building, reviewing, or refactoring SwiftUI code with modern APIs and best practices.
+
+## When NOT to Use
+
+- When the task does not involve SwiftUI (e.g., UIKit-only or non-Apple platforms).
+
 ## Overview
+
 Use this skill to build, review, or improve SwiftUI features with correct state management, modern API usage, Swift concurrency best practices, optimal view composition, and iOS 26+ Liquid Glass styling. Prioritize native APIs, Apple design guidance, and performance-conscious patterns. This skill focuses on facts and best practices without enforcing specific architectural patterns.
 
 ## Workflow Decision Tree
 
 ### 1) Review existing SwiftUI code
+
 - Check property wrapper usage against the selection guide (see `references/state-management.md`)
 - Verify modern API usage (see `references/modern-apis.md`)
 - Verify view composition follows extraction rules (see `references/view-structure.md`)
@@ -21,6 +34,7 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 - Validate iOS 26+ availability handling with sensible fallbacks
 
 ### 2) Improve existing SwiftUI code
+
 - Audit state management for correct wrapper selection (prefer `@Observable` over `ObservableObject`)
 - Replace deprecated APIs with modern equivalents (see `references/modern-apis.md`)
 - Extract complex views into separate subviews (see `references/view-structure.md`)
@@ -31,6 +45,7 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 - Adopt Liquid Glass only when explicitly requested by the user
 
 ### 3) Implement new SwiftUI feature
+
 - Design data flow first: identify owned vs injected state (see `references/state-management.md`)
 - Use modern APIs (no deprecated modifiers or patterns, see `references/modern-apis.md`)
 - Use `@Observable` for shared state (with `@MainActor` if not using default actor isolation)
@@ -43,6 +58,7 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 ## Core Guidelines
 
 ### State Management
+
 - **Always prefer `@Observable` over `ObservableObject`** for new code
 - **Mark `@Observable` classes with `@MainActor`** unless using default actor isolation
 - **Always mark `@State` and `@StateObject` as `private`** (makes dependencies clear)
@@ -55,6 +71,7 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 - Nested `ObservableObject` doesn't work (pass nested objects directly); `@Observable` handles nesting fine
 
 ### Modern APIs
+
 - Use `foregroundStyle()` instead of `foregroundColor()`
 - Use `clipShape(.rect(cornerRadius:))` instead of `cornerRadius()`
 - Use `Tab` API instead of `tabItem()`
@@ -70,6 +87,7 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 - Avoid `GeometryReader` when alternatives exist (e.g., `containerRelativeFrame()`)
 
 ### Swift Best Practices
+
 - Use modern Text formatting (`.format` parameters, not `String(format:)`)
 - Use `localizedStandardContains()` for user-input filtering (not `contains()`)
 - Prefer static member lookup (`.blue` vs `Color.blue`)
@@ -77,6 +95,7 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 - Use `.task(id:)` for value-dependent tasks
 
 ### View Composition
+
 - **Prefer modifiers over conditional views** for state changes (maintains view identity)
 - Extract complex views into separate subviews for better readability and performance
 - Keep views small for optimal performance
@@ -89,6 +108,7 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 - Views should work in any context (don't assume screen size or presentation style)
 
 ### Performance
+
 - Pass only needed values to views (avoid large "config" or "context" objects)
 - Eliminate unnecessary dependencies to reduce update fan-out
 - Check for value changes before assigning state in hot paths
@@ -106,6 +126,7 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 - Use `Self._printChanges()` to debug unexpected view updates
 
 ### Animations
+
 - Use `.animation(_:value:)` with value parameter (deprecated version without value is too broad)
 - Use `withAnimation` for event-driven animations (button taps, gestures)
 - Prefer transforms (`offset`, `scale`, `rotation`) over layout changes (`frame`) for performance
@@ -117,7 +138,9 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 - Implicit animations override explicit animations (later in view tree wins)
 
 ### Liquid Glass (iOS 26+)
+
 **Only adopt when explicitly requested by the user.**
+
 - Use native `glassEffect`, `GlassEffectContainer`, and glass button styles
 - Wrap multiple glass elements in `GlassEffectContainer`
 - Apply `.glassEffect()` after layout and visual modifiers
@@ -127,13 +150,14 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 ## Quick Reference
 
 ### Property Wrapper Selection (Modern)
-| Wrapper | Use When |
-|---------|----------|
-| `@State` | Internal view state (must be `private`), or owned `@Observable` class |
-| `@Binding` | Child modifies parent's state |
-| `@Bindable` | Injected `@Observable` needing bindings |
-| `let` | Read-only value from parent |
-| `var` | Read-only value watched via `.onChange()` |
+
+| Wrapper     | Use When                                                              |
+| ----------- | --------------------------------------------------------------------- |
+| `@State`    | Internal view state (must be `private`), or owned `@Observable` class |
+| `@Binding`  | Child modifies parent's state                                         |
+| `@Bindable` | Injected `@Observable` needing bindings                               |
+| `let`       | Read-only value from parent                                           |
+| `var`       | Read-only value watched via `.onChange()`                             |
 
 **Legacy (Pre-iOS 17):**
 | Wrapper | Use When |
@@ -142,21 +166,23 @@ Use this skill to build, review, or improve SwiftUI features with correct state
 | `@ObservedObject` | View receives an `ObservableObject` |
 
 ### Modern API Replacements
-| Deprecated | Modern Alternative |
-|------------|-------------------|
-| `foregroundColor()` | `foregroundStyle()` |
-| `cornerRadius()` | `clipShape(.rect(cornerRadius:))` |
-| `tabItem()` | `Tab` API |
-| `onTapGesture()` | `Button` (unless need location/count) |
-| `NavigationView` | `NavigationStack` |
-| `onChange(of:) { value in }` | `onChange(of:) { old, new in }` or `onChange(of:) { }` |
-| `fontWeight(.bold)` | `bold()` |
-| `GeometryReader` | `containerRelativeFrame()` or `visualEffect()` |
-| `showsIndicators: false` | `.scrollIndicators(.hidden)` |
+
+| Deprecated                      | Modern Alternative                                           |
+| ------------------------------- | ------------------------------------------------------------ |
+| `foregroundColor()`             | `foregroundStyle()`                                          |
+| `cornerRadius()`                | `clipShape(.rect(cornerRadius:))`                            |
+| `tabItem()`                     | `Tab` API                                                    |
+| `onTapGesture()`                | `Button` (unless need location/count)                        |
+| `NavigationView`                | `NavigationStack`                                            |
+| `onChange(of:) { value in }`    | `onChange(of:) { old, new in }` or `onChange(of:) { }`       |
+| `fontWeight(.bold)`             | `bold()`                                                     |
+| `GeometryReader`                | `containerRelativeFrame()` or `visualEffect()`               |
+| `showsIndicators: false`        | `.scrollIndicators(.hidden)`                                 |
 | `String(format: "%.2f", value)` | `Text(value, format: .number.precision(.fractionLength(2)))` |
-| `string.contains(search)` | `string.localizedStandardContains(search)` (for user input) |
+| `string.contains(search)`       | `string.localizedStandardContains(search)` (for user input)  |
 
 ### Liquid Glass Patterns
+
 ```swift
 // Basic glass effect with fallback
 if #available(iOS 26, *) {
@@ -185,6 +211,7 @@ Button("Confirm") { }
 ## Review Checklist
 
 ### State Management
+
 - [ ] Using `@Observable` instead of `ObservableObject` for new code
 - [ ] `@Observable` classes marked with `@MainActor` (if needed)
 - [ ] Using `@State` with `@Observable` classes (not `@StateObject`)
@@ -195,6 +222,7 @@ Button("Confirm") { }
 - [ ] Nested `ObservableObject` avoided (or passed directly to child views)
 
 ### Modern APIs (see `references/modern-apis.md`)
+
 - [ ] Using `foregroundStyle()` instead of `foregroundColor()`
 - [ ] Using `clipShape(.rect(cornerRadius:))` instead of `cornerRadius()`
 - [ ] Using `Tab` API instead of `tabItem()`
@@ -205,25 +233,30 @@ Button("Confirm") { }
 - [ ] Button images include text labels for accessibility
 
 ### Sheets & Navigation (see `references/sheet-navigation-patterns.md`)
+
 - [ ] Using `.sheet(item:)` for model-based sheets
 - [ ] Sheets own their actions and dismiss internally
 - [ ] Using `navigationDestination(for:)` for type-safe navigation
 
 ### ScrollView (see `references/scroll-patterns.md`)
+
 - [ ] Using `ScrollViewReader` with stable IDs for programmatic scrolling
 - [ ] Using `.scrollIndicators(.hidden)` instead of initializer parameter
 
 ### Text & Formatting (see `references/text-formatting.md`)
+
 - [ ] Using modern Text formatting (not `String(format:)`)
 - [ ] Using `localizedStandardContains()` for search filtering
 
 ### View Structure (see `references/view-structure.md`)
+
 - [ ] Using modifiers instead of conditionals for state changes
 - [ ] Complex views extracted to separate subviews
 - [ ] Views kept small for performance
 - [ ] Container views use `@ViewBuilder let content: Content`
 
 ### Performance (see `references/performance-patterns.md`)
+
 - [ ] View `body` kept simple and pure (no side effects)
 - [ ] Passing only needed values (not large config objects)
 - [ ] Eliminating unnecessary dependencies
@@ -233,12 +266,14 @@ Button("Confirm") { }
 - [ ] Heavy computation moved out of `body`
 
 ### List Patterns (see `references/list-patterns.md`)
+
 - [ ] ForEach uses stable identity (not `.indices`)
 - [ ] Constant number of views per ForEach element
 - [ ] No inline filtering in ForEach
 - [ ] No `AnyView` in list rows
 
 ### Layout (see `references/layout-best-practices.md`)
+
 - [ ] Avoiding layout thrash (deep hierarchies, excessive GeometryReader)
 - [ ] Gating frequent geometry updates by thresholds
 - [ ] Business logic separated into testable models
@@ -247,6 +282,7 @@ Button("Confirm") { }
 - [ ] Views work in any context (context-agnostic)
 
 ### Animations (see `references/animation-basics.md`, `references/animation-transitions.md`, `references/animation-advanced.md`)
+
 - [ ] Using `.animation(_:value:)` with value parameter
 - [ ] Using `withAnimation` for event-driven animations
 - [ ] Transitions paired with animations outside conditional structure
@@ -257,6 +293,7 @@ Button("Confirm") { }
 - [ ] Completion handlers use `.transaction(value:)` for reexecution
 
 ### Liquid Glass (iOS 26+)
+
 - [ ] `#available(iOS 26, *)` with fallback for Liquid Glass
 - [ ] Multiple glass views wrapped in `GlassEffectContainer`
 - [ ] `.glassEffect()` applied after layout/appearance modifiers
@@ -264,6 +301,7 @@ Button("Confirm") { }
 - [ ] Shapes and tints consistent across related elements
 
 ## References
+
 - `references/state-management.md` - Property wrappers and data flow (prefer `@Observable`)
 - `references/view-structure.md` - View composition, extraction, and container patterns
 - `references/performance-patterns.md` - Performance optimization techniques and anti-patterns
@@ -282,6 +320,7 @@ Button("Confirm") { }
 ## Philosophy
 
 This skill focuses on **facts and best practices**, not architectural opinions:
+
 - We don't enforce specific architectures (e.g., MVVM, VIPER)
 - We do encourage separating business logic for testability
 - We prioritize modern APIs over deprecated ones

package/dist/template/.opencode/skill/systematic-debugging/SKILL.md

@@ -1,10 +1,35 @@
 ---
 name: systematic-debugging
 description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions
+version: 1.0.0
+tags: [debugging, workflow]
+dependencies: []
 ---
 
 # Systematic Debugging
 
+## When to Use
+
+- Test failures, production bugs, build breaks, or unexpected behavior
+- Issues with unclear root cause or multiple failed fix attempts
+- Situations where time pressure makes “quick fixes” tempting
+
+## When NOT to Use
+
+- Pure feature development with no failures to investigate
+- Non-technical questions that don’t require root cause analysis
+
+## Debugging Checklist
+
+- [ ] Read error messages/stack traces fully
+- [ ] Reproduce consistently (or gather more data)
+- [ ] Check recent changes (diffs, deps, config)
+- [ ] Trace data flow to source (use root-cause-tracing if deep)
+- [ ] Form a single hypothesis and test minimally
+- [ ] Create a failing test before implementing the fix
+- [ ] Implement one change and verify it resolves the issue
+- [ ] If 3+ fixes fail, stop and question architecture
+
 ## Overview
 
 Random fixes waste time and create new bugs. Quick patches mask underlying issues.
@@ -21,31 +46,6 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 If you haven't completed Phase 1, you cannot propose fixes.
 
-## When to Use
-
-Use for ANY technical issue:
-
-- Test failures
-- Bugs in production
-- Unexpected behavior
-- Performance problems
-- Build failures
-- Integration issues
-
-**Use this ESPECIALLY when:**
-
-- Under time pressure (emergencies make guessing tempting)
-- "Just one quick fix" seems obvious
-- You've already tried multiple fixes
-- Previous fix didn't work
-- You don't fully understand the issue
-
-**Don't skip when:**
-
-- Issue seems simple (simple bugs have root causes too)
-- You're in a hurry (rushing guarantees rework)
-- Manager wants it fixed NOW (systematic is faster than thrashing)
-
 ## The Four Phases
 
 You MUST complete each phase before proceeding to the next.

package/dist/template/.opencode/skill/test-driven-development/SKILL.md

@@ -1,34 +1,38 @@
 ---
 name: test-driven-development
 description: Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
+version: 1.0.0
+tags: [testing, workflow]
+dependencies: []
 ---
 
 # Test-Driven Development (TDD)
 
-## Overview
+## When to Use
 
-Write the test first. Watch it fail. Write minimal code to pass.
+- Implementing new features or behavior changes
+- Fixing bugs that should be reproducible via a failing test first
 
-**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.
+## When NOT to Use
 
-**Violating the letter of the rules is violating the spirit of the rules.**
+- Throwaway prototypes or generated code where tests are out of scope
+- Pure configuration edits with no executable behavior
 
-## When to Use
+## TDD Checklist
 
-**Always:**
+- [ ] Write a minimal failing test for one behavior
+- [ ] Run tests and confirm the new test fails for the expected reason
+- [ ] Write the minimal code to pass the test
+- [ ] Re-run tests and confirm all pass
+- [ ] Refactor only after green and keep tests passing
 
-- New features
-- Bug fixes
-- Refactoring
-- Behavior changes
+## Overview
 
-**Exceptions (ask your human partner):**
+Write the test first. Watch it fail. Write minimal code to pass.
 
-- Throwaway prototypes
-- Generated code
-- Configuration files
+**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.
 
-Thinking "skip TDD just this once"? Stop. That's rationalization.
+**Violating the letter of the rules is violating the spirit of the rules.**
 
 ## The Iron Law
 

package/dist/template/.opencode/skill/testing-anti-patterns/SKILL.md

@@ -1,10 +1,23 @@
 ---
 name: testing-anti-patterns
 description: Use when writing or changing tests, adding mocks, or tempted to add test-only methods to production code - prevents testing mock behavior, production pollution with test-only methods, and mocking without understanding dependencies
+version: 1.0.0
+tags: [testing, code-quality]
+dependencies: []
 ---
 
 # Testing Anti-Patterns
 
+## When to Use
+
+- Writing or refactoring tests that introduce mocks or test-only helpers
+- Reviewing tests for mock misuse, incomplete mocks, or production pollution
+
+## When NOT to Use
+
+- Pure production code changes with no test work
+- Simple test updates that don’t involve mocks or structure changes
+
 ## Overview
 
 Tests must verify real behavior, not mock behavior. Mocks are a means to isolate, not the thing being tested.

package/dist/template/.opencode/skill/testing-skills-with-subagents/SKILL.md

@@ -1,10 +1,23 @@
 ---
 name: testing-skills-with-subagents
 description: Use when creating or editing skills, before deployment, to verify they work under pressure and resist rationalization - applies RED-GREEN-REFACTOR cycle to process documentation by running baseline without skill, writing to address failures, iterating to close loopholes
+version: 1.0.0
+tags: [testing, agent-coordination]
+dependencies: [writing-skills]
 ---
 
 # Testing Skills With Subagents
 
+## When to Use
+
+- You are creating or editing a skill and need to validate it under pressure
+- You want to bulletproof discipline-enforcing skills against rationalization
+
+## When NOT to Use
+
+- Pure reference skills that don’t enforce behavior or rules
+- Minor typo fixes where no behavioral change is introduced
+
 ## Overview
 
 **Testing skills is just TDD applied to process documentation.**
@@ -17,21 +30,6 @@ You run scenarios without the skill (RED - watch agent fail), write skill addres
 
 **Complete worked example:** See examples/CLAUDE_MD_TESTING.md for a full test campaign testing CLAUDE.md documentation variants.
 
-## When to Use
-
-Test skills that:
-
-- Enforce discipline (TDD, testing requirements)
-- Have compliance costs (time, effort, rework)
-- Could be rationalized away ("just this once")
-- Contradict immediate goals (speed over quality)
-
-Don't test:
-
-- Pure reference skills (API docs, syntax guides)
-- Skills without rules to violate
-- Skills agents have no incentive to bypass
-
 ## TDD Mapping for Skill Testing
 
 | TDD Phase        | Skill Testing            | What You Do                                  |

package/dist/template/.opencode/skill/tool-priority/SKILL.md

@@ -1,10 +1,23 @@
 ---
 name: tool-priority
 description: Use when choosing between tools or need tool reference - covers LSP, search, swarm, memory, and research tools with correct syntax
+version: 1.0.0
+tags: [workflow, context]
+dependencies: []
 ---
 
 # Tool Priority Skill
 
+## When to Use
+
+- You need to decide which tool to use for a task or recall tool syntax
+- You are about to edit code and want the correct discovery/order of operations
+
+## When NOT to Use
+
+- You already know the exact tool and syntax required
+- The task is purely conceptual with no tool usage
+
 ## Priority Order
 
 **LSP → Search → Swarm → Memory → File Operations**

package/dist/template/.opencode/skill/ui-ux-research/SKILL.md

@@ -1,12 +1,13 @@
 ---
 name: ui-ux-research
 description: Use when analyzing UI patterns across codebases, comparing design system implementations, auditing UI consistency, or understanding existing patterns before implementation
+version: 1.0.0
+tags: [design, research]
+dependencies: []
 ---
 
 # UI/UX Research Skill
 
-Research UI patterns, design systems, and user experience across codebases.
-
 ## When to Use
 
 - Analyzing UI patterns across large codebases
@@ -14,6 +15,11 @@ Research UI patterns, design systems, and user experience across codebases.
 - Auditing UI consistency
 - Understanding existing patterns before implementation
 
+## When NOT to Use
+
+- Single-file UI changes without broader pattern investigation.
+
+
 ## Research Patterns
 
 ### Find All UI Components
@@ -121,5 +127,5 @@ Save research findings to `.opencode/memory/design/research/`
 | After Research              | Use Skill             |
 | --------------------------- | --------------------- |
 | Need implementation         | `mockup-to-code`      |
-| Need aesthetic improvements | `frontend-design` |
+| Need aesthetic improvements | `frontend-design`     |
 | Need accessibility fixes    | `accessibility-audit` |

package/dist/template/.opencode/skill/using-git-worktrees/SKILL.md

@@ -1,10 +1,21 @@
 ---
 name: using-git-worktrees
 description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
+version: 1.0.0
+tags: [git, workflow]
+dependencies: []
 ---
 
 # Using Git Worktrees
 
+## When to Use
+
+- When starting feature work that needs an isolated workspace or before executing an implementation plan.
+
+## When NOT to Use
+
+- When a simple change can safely be done in the current working tree or the repo does not allow worktrees.
+
 ## Overview
 
 Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
@@ -99,6 +110,32 @@ git worktree add "$path" -b "$BRANCH_NAME"
 cd "$path"
 ```
 
+## Worktree Tracking
+
+After creating a worktree, persist its absolute path for session resume:
+
+```bash
+# After creating worktree
+mkdir -p .beads/artifacts/$BEAD_ID
+echo "/absolute/path/to/worktree" > .beads/artifacts/$BEAD_ID/worktree.txt
+```
+
+On session resume, restore the active worktree if tracking exists:
+
+```bash
+# Check if worktree exists for active bead
+if [ -f .beads/artifacts/$BEAD_ID/worktree.txt ]; then
+  WORKTREE_PATH=$(cat .beads/artifacts/$BEAD_ID/worktree.txt)
+  cd "$WORKTREE_PATH"
+fi
+```
+
+On worktree cleanup (after merge), remove the tracking file:
+
+```bash
+rm -f .beads/artifacts/$BEAD_ID/worktree.txt
+```
+
 ### 3. Run Project Setup
 
 Auto-detect and run appropriate setup:

package/dist/template/.opencode/skill/using-skills/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: using-skills
 description: Use when starting any conversation - establishes mandatory workflows for finding and using skills, including using Skill tool before announcing usage, following brainstorming before coding, and creating TodoWrite todos for checklists
+version: 1.0.0
+tags: [workflow, context]
+dependencies: []
 ---
 
 <EXTREMELY-IMPORTANT>
@@ -13,6 +16,16 @@ This is not negotiable. This is not optional. You cannot rationalize your way ou
 
 # Getting Started with Skills
 
+## When to Use
+
+- At the start of any conversation or task to determine applicable skills
+- Whenever you are about to act and need to check for mandatory workflows
+
+## When NOT to Use
+
+- After you already loaded the correct skill and are executing it
+- For a task that explicitly says to follow a different skill workflow
+
 ## MANDATORY FIRST RESPONSE PROTOCOL
 
 Before responding to ANY user message, you MUST complete this checklist:

package/dist/template/.opencode/skill/v0/SKILL.md

@@ -7,11 +7,21 @@ mcp:
     args: ["mcp-remote", "https://mcp.v0.dev", "--header", "Authorization: Bearer ${V0_API_KEY}"]
     env:
       V0_API_KEY: "${V0_API_KEY}"
+version: 1.0.0
+tags: [ui, mcp, design]
+dependencies: []
 ---
 
 # v0 AI Code Generation (MCP)
 
-Access v0's AI-powered code generation via MCP. When this skill is loaded, the `v0` MCP server auto-starts and exposes tools for creating and managing v0 chats.
+## When to Use
+
+- When you need AI-generated UI components or chat-based design iteration via v0.
+
+## When NOT to Use
+
+- When you need to implement UI from a fixed design system without AI generation.
+
 
 ## Prerequisites
 

package/dist/template/.opencode/skill/v1-run/SKILL.md

@@ -1,11 +1,21 @@
 ---
 name: v1-run
 description: npm package intelligence via MCP. Real-time versions, vulnerability data, health scores, and package comparisons. Use when selecting npm packages, checking for vulnerabilities, or comparing alternatives.
+version: 1.0.0
+tags: [integration, mcp, research]
+dependencies: []
 ---
 
 # v1.run MCP
 
-Fast, accurate npm package intelligence for AI agents via Model Context Protocol.
+## When to Use
+
+- When you need real-time npm package health, vulnerabilities, or comparisons.
+
+## When NOT to Use
+
+- When package selection or security analysis is not in scope.
+
 
 ## Overview
 

package/dist/template/.opencode/skill/vercel-deploy-claimable/SKILL.md

@@ -1,6 +1,9 @@
 ---
-name: vercel-deploy
+name: vercel-deploy-claimable
 description: Deploy applications and websites to Vercel. Use this skill when the user requests deployment actions such as "Deploy my app", "Deploy this to production", "Create a preview deployment", "Deploy and give me the link", or "Push this live". No authentication required - returns preview URL and claimable deployment link.
+version: 1.0.0
+tags: [devops, integration]
+dependencies: []
 metadata:
   author: vercel
   version: "1.0.0"
@@ -8,7 +11,14 @@ metadata:
 
 # Vercel Deploy
 
-Deploy any project to Vercel instantly. No authentication required.
+## When to Use
+
+- When the user requests deploying a project to Vercel and needs preview/claim links.
+
+## When NOT to Use
+
+- When deployment is not requested or targets a non-Vercel platform.
+
 
 ## How It Works
 
@@ -24,6 +34,7 @@ bash /mnt/skills/user/vercel-deploy/scripts/deploy.sh [path]
 ```
 
 **Arguments:**
+
 - `path` - Directory to deploy, or a `.tgz` file (defaults to current directory)
 
 **Examples:**
@@ -80,6 +91,7 @@ For static HTML projects (no `package.json`), framework is set to `null`.
 ## Static HTML Projects
 
 For projects without a `package.json`:
+
 - If there's a single `.html` file not named `index.html`, it gets renamed automatically
 - This ensures the page is served at the root URL (`/`)