opencodekit 0.18.0 → 0.18.2

package/dist/template/.opencode/skill/react-best-practices/SKILL.md

@@ -1,19 +1,26 @@
 ---
-name: vercel-react-best-practices
+name: react-best-practices
 description: React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
-license: MIT
-metadata:
-  author: vercel
-  version: "1.0.0"
+version: 1.0.0
+tags: [ui, code-quality]
+dependencies: []
 ---
 
 # Vercel React Best Practices
 
-Comprehensive performance optimization guide for React and Next.js applications, maintained by Vercel. Contains 45 rules across 8 categories, prioritized by impact to guide automated refactoring and code generation.
+## When to Use
+
+- Applying performance guidelines to React/Next.js components or pages.
+
+## When NOT to Use
+
+- Non-React codebases or UI-free/backend-only changes.
+
 
 ## When to Apply
 
 Reference these guidelines when:
+
 - Writing new React components or Next.js pages
 - Implementing data fetching (client or server-side)
 - Reviewing code for performance issues
@@ -22,16 +29,16 @@ Reference these guidelines when:
 
 ## Rule Categories by Priority
 
-| Priority | Category | Impact | Prefix |
-|----------|----------|--------|--------|
-| 1 | Eliminating Waterfalls | CRITICAL | `async-` |
-| 2 | Bundle Size Optimization | CRITICAL | `bundle-` |
-| 3 | Server-Side Performance | HIGH | `server-` |
-| 4 | Client-Side Data Fetching | MEDIUM-HIGH | `client-` |
-| 5 | Re-render Optimization | MEDIUM | `rerender-` |
-| 6 | Rendering Performance | MEDIUM | `rendering-` |
-| 7 | JavaScript Performance | LOW-MEDIUM | `js-` |
-| 8 | Advanced Patterns | LOW | `advanced-` |
+| Priority | Category                  | Impact      | Prefix       |
+| -------- | ------------------------- | ----------- | ------------ |
+| 1        | Eliminating Waterfalls    | CRITICAL    | `async-`     |
+| 2        | Bundle Size Optimization  | CRITICAL    | `bundle-`    |
+| 3        | Server-Side Performance   | HIGH        | `server-`    |
+| 4        | Client-Side Data Fetching | MEDIUM-HIGH | `client-`    |
+| 5        | Re-render Optimization    | MEDIUM      | `rerender-`  |
+| 6        | Rendering Performance     | MEDIUM      | `rendering-` |
+| 7        | JavaScript Performance    | LOW-MEDIUM  | `js-`        |
+| 8        | Advanced Patterns         | LOW         | `advanced-`  |
 
 ## Quick Reference
 
@@ -115,6 +122,7 @@ rules/_sections.md
 ```
 
 Each rule file contains:
+
 - Brief explanation of why it matters
 - Incorrect code example with explanation
 - Correct code example with explanation

package/dist/template/.opencode/skill/receiving-code-review/SKILL.md

@@ -1,10 +1,23 @@
 ---
 name: receiving-code-review
 description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
+version: 1.0.0
+tags: [workflow, code-quality]
+dependencies: []
 ---
 
 # Code Review Reception
 
+## When to Use
+
+- You received review feedback and need to evaluate it before implementing
+- Feedback seems unclear, questionable, or potentially wrong for this codebase
+
+## When NOT to Use
+
+- You already verified and accepted the feedback and are ready to implement
+- You need to request a review (use requesting-code-review)
+
 ## Overview
 
 Code review requires technical evaluation, not emotional performance.
@@ -24,6 +37,15 @@ WHEN receiving code review feedback:
 6. IMPLEMENT: One item at a time, test each
 ```
 
+## Review Intake Checklist
+
+- [ ] Read the full feedback without reacting
+- [ ] Restate requirements in your own words
+- [ ] Verify against codebase reality
+- [ ] Evaluate technical correctness for this stack
+- [ ] Respond with acknowledgment or reasoned pushback
+- [ ] Implement one item at a time with tests
+
 ## Forbidden Responses
 
 **NEVER:**

package/dist/template/.opencode/skill/requesting-code-review/SKILL.md

@@ -1,13 +1,24 @@
 ---
 name: requesting-code-review
 description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches 5 parallel specialized review agents for comprehensive multi-angle review
+version: 1.0.0
+tags: [workflow, code-quality]
+dependencies: []
 ---
 
 # Requesting Code Review
 
-Dispatch 5 parallel specialized review agents. One generic reviewer is not review — it's a checkbox.
+## When to Use
+
+- After completing a feature/task batch and before moving on
+- Before merging to main or shipping changes
+
+## When NOT to Use
+
+- During TDD RED commits or other intentionally failing states
+- When you only need a targeted answer to a specific question
+
 
-**Core principle:** All 5 angles, every time. No tiers, no exit ramps.
 
 ## When to Request Review
 
@@ -25,6 +36,11 @@ Dispatch 5 parallel specialized review agents. One generic reviewer is not revie
 
 ### Step 1: Get git context
 
+#### Review Setup Checklist
+
+- [ ] Determine BASE_SHA and HEAD_SHA
+- [ ] Ensure requirements summary or plan link is available
+
 ```bash
 BASE_SHA=$(git rev-parse origin/main 2>/dev/null || git rev-parse HEAD~1)
 HEAD_SHA=$(git rev-parse HEAD)
@@ -139,6 +155,12 @@ Return: CRITICAL / IMPORTANT / MINOR findings with file:line references.`,
 
 ### Step 3: Synthesize findings
 
+#### Synthesis Checklist
+
+- [ ] Count Critical / Important / Minor findings
+- [ ] List file:line references for each issue
+- [ ] Mark readiness: proceed vs fix required
+
 After all 5 agents return:
 
 ```markdown
@@ -164,6 +186,12 @@ After all 5 agents return:
 
 ### Step 4: Act on findings
 
+#### Remediation Checklist
+
+- [ ] Fix all Critical issues before proceeding
+- [ ] Fix Important issues in this PR
+- [ ] Record Minor issues for later
+
 | Severity      | Action                                   |
 | ------------- | ---------------------------------------- |
 | **Critical**  | Fix immediately before any other work    |

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

@@ -5,11 +5,21 @@ references:
   - send-email
   - receive-email
   - react-email
+version: 1.0.0
+tags: [integration, mcp]
+dependencies: []
 ---
 
 # Resend Email Platform
 
-Consolidated skill for building email systems with Resend. Use decision trees below to find the right approach, then load detailed references.
+## When to Use
+
+- When integrating Resend for sending/receiving emails or building React Email templates.
+
+## When NOT to Use
+
+- When email delivery is handled by a different provider or not required.
+
 
 ## How to Use This Skill
 

package/dist/template/.opencode/skill/root-cause-tracing/SKILL.md

@@ -1,39 +1,28 @@
 ---
 name: root-cause-tracing
 description: Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior
+version: 1.0.0
+tags: [debugging, workflow]
+dependencies: []
 ---
 
 # Root Cause Tracing
 
-## Overview
+## When to Use
 
-Bugs often manifest deep in the call stack (git init in wrong directory, file created in wrong location, database opened with wrong path). Your instinct is to fix where the error appears, but that's treating a symptom.
+- Errors occur deep in a call stack and the immediate failure is just a symptom
+- You need to trace where invalid data or state originated
 
-**Core principle:** Trace backward through the call chain until you find the original trigger, then fix at the source.
+## When NOT to Use
 
-## When to Use
+- The error is at the entry point and the root cause is obvious
+- You’re doing feature work with no failures to trace
 
-```dot
-digraph when_to_use {
-    "Bug appears deep in stack?" [shape=diamond];
-    "Can trace backwards?" [shape=diamond];
-    "Fix at symptom point" [shape=box];
-    "Trace to original trigger" [shape=box];
-    "BETTER: Also add defense-in-depth" [shape=box];
-
-    "Bug appears deep in stack?" -> "Can trace backwards?" [label="yes"];
-    "Can trace backwards?" -> "Trace to original trigger" [label="yes"];
-    "Can trace backwards?" -> "Fix at symptom point" [label="no - dead end"];
-    "Trace to original trigger" -> "BETTER: Also add defense-in-depth";
-}
-```
+## Overview
 
-**Use when:**
+Bugs often manifest deep in the call stack (git init in wrong directory, file created in wrong location, database opened with wrong path). Your instinct is to fix where the error appears, but that's treating a symptom.
 
-- Error happens deep in execution (not at entry point)
-- Stack trace shows long call chain
-- Unclear where invalid data originated
-- Need to find which test/code triggers the problem
+**Core principle:** Trace backward through the call chain until you find the original trigger, then fix at the source.
 
 ## The Tracing Process
 

package/dist/template/.opencode/skill/session-management/SKILL.md

@@ -1,11 +1,21 @@
 ---
 name: session-management
 description: Use when context is growing large, switching tasks, or needing previous session context - covers thresholds, session tools, and workflow patterns
+version: 1.0.0
+tags: [context, workflow]
+dependencies: []
 ---
 
 # Session Management
 
-**Philosophy**: Short sessions (<150k tokens) beat long bloated ones. Agents get worse with too much context. Cost is exponential.
+## When to Use
+
+- Managing context growth, switching tasks, or resuming past sessions.
+
+## When NOT to Use
+
+- Single, short tasks that don't require session transitions.
+
 
 ## Context Thresholds
 
@@ -19,48 +29,35 @@ The environment monitors context usage and warns at these thresholds:
 
 ## Session Tools
 
-### list_sessions
+### find_sessions
 
-Discover available sessions before reading:
+Search and discover sessions by keyword. Returns ranked results with match counts and snippets.
 
 ```typescript
-list_sessions({ limit: 10, project: "current" }); // Current project
-list_sessions({ since: "today" }); // Today's sessions
-list_sessions({ project: "all", since: "yesterday" }); // Cross-project
+find_sessions({ query: "auth bug", limit: 5 }); // Search by keyword
+find_sessions({ query: "refactor" }); // Default limit
 ```
 
-### read_session
+**Parameters:**
 
-Pull context from previous session:
+- `query` (required): Search keywords — multi-word queries use AND matching
+- `limit` (optional): Max results to return
 
-```typescript
-read_session("last"); // Most recent
-read_session("2 ago", { project: "current" }); // 2nd most recent
-read_session("today"); // Today's first session
-read_session("ses_abc123", { focus: "file changes" }); // Specific aspect
-```
+**Returns:** Ranked sessions with match count, snippets, and suggested next steps.
 
-### search_session
+### read_session
 
-Full-text search across sessions:
+Read messages from a specific session. Supports optional focus filtering.
 
 ```typescript
-search_session({ query: "auth bug" }); // Search all sessions
-search_session({ query: "OAuth", session_id: "ses_abc" }); // Specific session
-search_session({ query: "error", limit: 10 }); // Limit results
+read_session({ session_id: "ses_abc123" }); // Full session
+read_session({ session_id: "ses_abc123", focus: "auth" }); // Filter to relevant messages
 ```
 
-Use to find past discussions, decisions, or work on a topic before starting new work.
-
-### summarize_session
-
-Generate AI summary of a session:
-
-```typescript
-summarize_session("ses_abc123"); // Trigger AI summarization
-```
+**Parameters:**
 
-Use before `read_session` to get a quick overview of what happened in a past session without loading full context.
+- `session_id` (required): Session ID from find_sessions results
+- `focus` (optional): Keyword to filter messages within the session
 
 ## When to Start New Session
 
@@ -74,11 +71,11 @@ Use before `read_session` to get a quick overview of what happened in a past ses
 ```
 Session 1: Implement feature X (80k tokens)
   ↓ close, update memory
-Session 2: list_sessions() → read_session("last") → Refactor (60k tokens)
+Session 2: find_sessions({ query: "feature X" }) → read_session(...) → Refactor (60k tokens)
   ↓
-Session 3: read_session("previous") → Add tests (90k tokens)
+Session 3: find_sessions({ query: "feature X" }) → Add tests (90k tokens)
   ↓
-Session 4: read_session refs → Final review (100k tokens)
+Session 4: read_session(...) → Final review (100k tokens)
 ```
 
 **Result**: 4 fresh contexts vs 1 degraded 330k context. Better performance, lower cost.
@@ -87,10 +84,10 @@ Session 4: read_session refs → Final review (100k tokens)
 
 Use all available sources:
 
-1. `read_session("last")` - Previous session work
-2. Git state - `git diff`, `git log` - Code changes
-3. Memory files - `.opencode/memory/*` - Persistent context
-4. Beads - `br show <id>` - Task specs
+1. `find_sessions` + `read_session` — Previous session work
+2. Git state — `git diff`, `git log` — Code changes
+3. Memory files — `.opencode/memory/*` — Persistent context
+4. Beads — `br show <id>` — Task specs
 
 **Don't**: Carry everything forward. Extract what's needed, discard the rest.
 

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

@@ -1,10 +1,21 @@
 ---
 name: sharing-skills
 description: Use when you've developed a broadly useful skill and want to contribute it upstream via pull request - guides process of branching, committing, pushing, and creating PR to contribute skills back to upstream repository
+version: 1.0.0
+tags: [workflow, git]
+dependencies: []
 ---
 
 # Sharing Skills
 
+## When to Use
+
+- When a skill is broadly useful and ready to be contributed upstream via pull request.
+
+## When NOT to Use
+
+- When the skill is project-specific, experimental, or contains sensitive information.
+
 ## Overview
 
 Contribute skills from your local branch back to the upstream repository.

package/dist/template/.opencode/skill/skill-creator/SKILL.md

@@ -1,21 +1,22 @@
 ---
 name: skill-creator
 description: Guide for creating effective skills. Use when creating a new skill or updating an existing skill that extends an agent's capabilities with specialized knowledge, workflows, or tool integrations.
+version: 1.0.0
+tags: [documentation, workflow]
+dependencies: []
 ---
 
 # Skill Creator
 
-Guide for creating effective skills that extend agent capabilities.
-
-> **CRITICAL: YAML FRONTMATTER REQUIRED**
-> Every SKILL.md **MUST** begin with YAML frontmatter on line 1.
->
-> ```yaml
-> ---
-> name: skill-name
-> description: One-line description of what this skill does
-> ---
-> ```
+## When to Use
+
+- When creating a new skill or updating an existing skill with specialized workflows or tool integrations.
+
+## When NOT to Use
+
+- When making routine project changes that don't require a reusable skill.
+
+
 
 ## What Skills Provide