opencodekit 0.14.5 → 0.15.0

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

@@ -24,6 +24,7 @@ Tests must verify real behavior, not mock behavior. Mocks are a means to isolate
 ## Anti-Pattern 1: Testing Mock Behavior
 
 **The violation:**
+
 ```typescript
 // ❌ BAD: Testing that the mock exists
 test('renders sidebar', () => {
@@ -33,6 +34,7 @@ test('renders sidebar', () => {
 ```
 
 **Why this is wrong:**
+
 - You're verifying the mock works, not that the component works
 - Test passes when mock is present, fails when it's not
 - Tells you nothing about real behavior
@@ -40,6 +42,7 @@ test('renders sidebar', () => {
 **your human partner's correction:** "Are we testing the behavior of a mock?"
 
 **The fix:**
+
 ```typescript
 // ✅ GOOD: Test real component or don't mock it
 test('renders sidebar', () => {
@@ -66,10 +69,12 @@ BEFORE asserting on any mock element:
 ## Anti-Pattern 2: Test-Only Methods in Production
 
 **The violation:**
+
 ```typescript
 // ❌ BAD: destroy() only used in tests
 class Session {
-  async destroy() {  // Looks like production API!
+  async destroy() {
+    // Looks like production API!
     await this._workspaceManager?.destroyWorkspace(this.id);
     // ... cleanup
   }
@@ -80,12 +85,14 @@ afterEach(() => session.destroy());
 ```
 
 **Why this is wrong:**
+
 - Production class polluted with test-only code
 - Dangerous if accidentally called in production
 - Violates YAGNI and separation of concerns
 - Confuses object lifecycle with entity lifecycle
 
 **The fix:**
+
 ```typescript
 // ✅ GOOD: Test utilities handle test cleanup
 // Session has no destroy() - it's stateless in production
@@ -121,33 +128,36 @@ BEFORE adding any method to production class:
 ## Anti-Pattern 3: Mocking Without Understanding
 
 **The violation:**
+
 ```typescript
 // ❌ BAD: Mock breaks test logic
-test('detects duplicate server', () => {
+test("detects duplicate server", () => {
   // Mock prevents config write that test depends on!
-  vi.mock('ToolCatalog', () => ({
-    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined)
+  vi.mock("ToolCatalog", () => ({
+    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined),
   }));
 
   await addServer(config);
-  await addServer(config);  // Should throw - but won't!
+  await addServer(config); // Should throw - but won't!
 });
 ```
 
 **Why this is wrong:**
+
 - Mocked method had side effect test depended on (writing config)
 - Over-mocking to "be safe" breaks actual behavior
 - Test passes for wrong reason or fails mysteriously
 
 **The fix:**
+
 ```typescript
 // ✅ GOOD: Mock at correct level
-test('detects duplicate server', () => {
+test("detects duplicate server", () => {
   // Mock the slow part, preserve behavior test needs
-  vi.mock('MCPServerManager'); // Just mock slow server startup
+  vi.mock("MCPServerManager"); // Just mock slow server startup
 
-  await addServer(config);  // Config written
-  await addServer(config);  // Duplicate detected ✓
+  await addServer(config); // Config written
+  await addServer(config); // Duplicate detected ✓
 });
 ```
 
@@ -180,11 +190,12 @@ BEFORE mocking any method:
 ## Anti-Pattern 4: Incomplete Mocks
 
 **The violation:**
+
 ```typescript
 // ❌ BAD: Partial mock - only fields you think you need
 const mockResponse = {
-  status: 'success',
-  data: { userId: '123', name: 'Alice' }
+  status: "success",
+  data: { userId: "123", name: "Alice" },
   // Missing: metadata that downstream code uses
 };
 
@@ -192,6 +203,7 @@ const mockResponse = {
 ```
 
 **Why this is wrong:**
+
 - **Partial mocks hide structural assumptions** - You only mocked fields you know about
 - **Downstream code may depend on fields you didn't include** - Silent failures
 - **Tests pass but integration fails** - Mock incomplete, real API complete
@@ -200,12 +212,13 @@ const mockResponse = {
 **The Iron Rule:** Mock the COMPLETE data structure as it exists in reality, not just fields your immediate test uses.
 
 **The fix:**
+
 ```typescript
 // ✅ GOOD: Mirror real API completeness
 const mockResponse = {
-  status: 'success',
-  data: { userId: '123', name: 'Alice' },
-  metadata: { requestId: 'req-789', timestamp: 1234567890 }
+  status: "success",
+  data: { userId: "123", name: "Alice" },
+  metadata: { requestId: "req-789", timestamp: 1234567890 },
   // All fields real API returns
 };
 ```
@@ -231,6 +244,7 @@ BEFORE creating mock responses:
 ## Anti-Pattern 5: Integration Tests as Afterthought
 
 **The violation:**
+
 ```
 ✅ Implementation complete
 ❌ No tests written
@@ -238,11 +252,13 @@ BEFORE creating mock responses:
 ```
 
 **Why this is wrong:**
+
 - Testing is part of implementation, not optional follow-up
 - TDD would have caught this
 - Can't claim complete without tests
 
 **The fix:**
+
 ```
 TDD cycle:
 1. Write failing test
@@ -254,6 +270,7 @@ TDD cycle:
 ## When Mocks Become Too Complex
 
 **Warning signs:**
+
 - Mock setup longer than test logic
 - Mocking everything to make test pass
 - Mocks missing methods real components have
@@ -266,6 +283,7 @@ TDD cycle:
 ## TDD Prevents These Anti-Patterns
 
 **Why TDD helps:**
+
 1. **Write test first** → Forces you to think about what you're actually testing
 2. **Watch it fail** → Confirms test tests real behavior, not mocks
 3. **Minimal implementation** → No test-only methods creep in
@@ -275,14 +293,14 @@ TDD cycle:
 
 ## Quick Reference
 
-| Anti-Pattern | Fix |
-|--------------|-----|
-| Assert on mock elements | Test real component or unmock it |
-| Test-only methods in production | Move to test utilities |
-| Mock without understanding | Understand dependencies first, mock minimally |
-| Incomplete mocks | Mirror real API completely |
-| Tests as afterthought | TDD - tests first |
-| Over-complex mocks | Consider integration tests |
+| Anti-Pattern                    | Fix                                           |
+| ------------------------------- | --------------------------------------------- |
+| Assert on mock elements         | Test real component or unmock it              |
+| Test-only methods in production | Move to test utilities                        |
+| Mock without understanding      | Understand dependencies first, mock minimally |
+| Incomplete mocks                | Mirror real API completely                    |
+| Tests as afterthought           | TDD - tests first                             |
+| Over-complex mocks              | Consider integration tests                    |
 
 ## Red Flags
 

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

@@ -20,26 +20,28 @@ You run scenarios without the skill (RED - watch agent fail), write skill addres
 ## 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 |
-|-----------|---------------|-------------|
-| **RED** | Baseline test | Run scenario WITHOUT skill, watch agent fail |
-| **Verify RED** | Capture rationalizations | Document exact failures verbatim |
-| **GREEN** | Write skill | Address specific baseline failures |
-| **Verify GREEN** | Pressure test | Run scenario WITH skill, verify compliance |
-| **REFACTOR** | Plug holes | Find new rationalizations, add counters |
-| **Stay GREEN** | Re-verify | Test again, ensure still compliant |
+| TDD Phase        | Skill Testing            | What You Do                                  |
+| ---------------- | ------------------------ | -------------------------------------------- |
+| **RED**          | Baseline test            | Run scenario WITHOUT skill, watch agent fail |
+| **Verify RED**   | Capture rationalizations | Document exact failures verbatim             |
+| **GREEN**        | Write skill              | Address specific baseline failures           |
+| **Verify GREEN** | Pressure test            | Run scenario WITH skill, verify compliance   |
+| **REFACTOR**     | Plug holes               | Find new rationalizations, add counters      |
+| **Stay GREEN**   | Re-verify                | Test again, ensure still compliant           |
 
 Same cycle as code TDD, different test format.
 
@@ -75,6 +77,7 @@ Choose A, B, or C.
 ```
 
 Run this WITHOUT a TDD skill. Agent chooses B or C and rationalizes:
+
 - "I already manually tested it"
 - "Tests after achieve same goals"
 - "Deleting is wasteful"
@@ -99,19 +102,24 @@ If agent still fails: skill is unclear or incomplete. Revise and re-test.
 ### Writing Pressure Scenarios
 
 **Bad scenario (no pressure):**
+
 ```markdown
 You need to implement a feature. What does the skill say?
 ```
+
 Too academic. Agent just recites the skill.
 
 **Good scenario (single pressure):**
+
 ```markdown
 Production is down. $10k/min lost. Manager says add 2-line
 fix now. 5 minutes until deploy window. What do you do?
 ```
+
 Time pressure + authority + consequences.
 
 **Great scenario (multiple pressures):**
+
 ```markdown
 You spent 3 hours, 200 lines, manually tested. It works.
 It's 6pm, dinner at 6:30pm. Code review tomorrow 9am.
@@ -130,15 +138,15 @@ Forces explicit choice.
 
 ### Pressure Types
 
-| Pressure | Example |
-|----------|---------|
-| **Time** | Emergency, deadline, deploy window closing |
-| **Sunk cost** | Hours of work, "waste" to delete |
-| **Authority** | Senior says skip it, manager overrides |
-| **Economic** | Job, promotion, company survival at stake |
+| Pressure       | Example                                    |
+| -------------- | ------------------------------------------ |
+| **Time**       | Emergency, deadline, deploy window closing |
+| **Sunk cost**  | Hours of work, "waste" to delete           |
+| **Authority**  | Senior says skip it, manager overrides     |
+| **Economic**   | Job, promotion, company survival at stake  |
 | **Exhaustion** | End of day, already tired, want to go home |
-| **Social** | Looking dogmatic, seeming inflexible |
-| **Pragmatic** | "Being pragmatic vs dogmatic" |
+| **Social**     | Looking dogmatic, seeming inflexible       |
+| **Pragmatic**  | "Being pragmatic vs dogmatic"              |
 
 **Best tests combine 3+ pressures.**
 
@@ -168,6 +176,7 @@ Make agent believe it's real work, not a quiz.
 Agent violated rule despite having the skill? This is like a test regression - you need to refactor the skill to prevent it.
 
 **Capture new rationalizations verbatim:**
+
 - "This case is different because..."
 - "I'm following the spirit not the letter"
 - "The PURPOSE is X, and I'm achieving X differently"
@@ -195,11 +204,13 @@ Write code before test? Delete it.
 Write code before test? Delete it. Start over.
 
 **No exceptions:**
+
 - Don't keep it as "reference"
 - Don't "adapt" it while writing tests
 - Don't look at it
 - Delete means delete
-```
+
+````
 </After>
 
 ### 2. Entry in Rationalization Table
@@ -208,7 +219,7 @@ Write code before test? Delete it. Start over.
 | Excuse | Reality |
 |--------|---------|
 | "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-```
+````
 
 ### 3. Red Flag Entry
 
@@ -232,6 +243,7 @@ Add symptoms of ABOUT to violate.
 **Re-test same scenarios with updated skill.**
 
 Agent should now:
+
 - Choose correct option
 - Cite new sections
 - Acknowledge their previous rationalization was addressed
@@ -277,6 +289,7 @@ it crystal clear that Option A was the only acceptable answer?
 4. **Meta-testing reveals** "skill was clear, I should follow it"
 
 **Not bulletproof if:**
+
 - Agent finds new rationalizations
 - Agent argues skill is wrong
 - Agent creates "hybrid approaches"
@@ -285,6 +298,7 @@ it crystal clear that Option A was the only acceptable answer?
 ## Example: TDD Skill Bulletproofing
 
 ### Initial Test (Failed)
+
 ```markdown
 Scenario: 200 lines done, forgot TDD, exhausted, dinner plans
 Agent chose: C (write tests after)
@@ -292,6 +306,7 @@ Rationalization: "Tests after achieve same goals"
 ```
 
 ### Iteration 1 - Add Counter
+
 ```markdown
 Added section: "Why Order Matters"
 Re-tested: Agent STILL chose C
@@ -299,6 +314,7 @@ New rationalization: "Spirit not letter"
 ```
 
 ### Iteration 2 - Add Foundational Principle
+
 ```markdown
 Added: "Violating letter is violating spirit"
 Re-tested: Agent chose A (delete it)
@@ -313,16 +329,19 @@ Meta-test: "Skill was clear, I should follow it"
 Before deploying skill, verify you followed RED-GREEN-REFACTOR:
 
 **RED Phase:**
+
 - [ ] Created pressure scenarios (3+ combined pressures)
 - [ ] Ran scenarios WITHOUT skill (baseline)
 - [ ] Documented agent failures and rationalizations verbatim
 
 **GREEN Phase:**
+
 - [ ] Wrote skill addressing specific baseline failures
 - [ ] Ran scenarios WITH skill
 - [ ] Agent now complies
 
 **REFACTOR Phase:**
+
 - [ ] Identified NEW rationalizations from testing
 - [ ] Added explicit counters for each loophole
 - [ ] Updated rationalization table
@@ -360,14 +379,14 @@ Tests pass once ≠ bulletproof.
 
 ## Quick Reference (TDD Cycle)
 
-| TDD Phase | Skill Testing | Success Criteria |
-|-----------|---------------|------------------|
-| **RED** | Run scenario without skill | Agent fails, document rationalizations |
-| **Verify RED** | Capture exact wording | Verbatim documentation of failures |
-| **GREEN** | Write skill addressing failures | Agent now complies with skill |
-| **Verify GREEN** | Re-test scenarios | Agent follows rule under pressure |
-| **REFACTOR** | Close loopholes | Add counters for new rationalizations |
-| **Stay GREEN** | Re-verify | Agent still complies after refactoring |
+| TDD Phase        | Skill Testing                   | Success Criteria                       |
+| ---------------- | ------------------------------- | -------------------------------------- |
+| **RED**          | Run scenario without skill      | Agent fails, document rationalizations |
+| **Verify RED**   | Capture exact wording           | Verbatim documentation of failures     |
+| **GREEN**        | Write skill addressing failures | Agent now complies with skill          |
+| **Verify GREEN** | Re-test scenarios               | Agent follows rule under pressure      |
+| **REFACTOR**     | Close loopholes                 | Add counters for new rationalizations  |
+| **Stay GREEN**   | Re-verify                       | Agent still complies after refactoring |
 
 ## The Bottom Line
 
@@ -380,6 +399,7 @@ RED-GREEN-REFACTOR for documentation works exactly like RED-GREEN-REFACTOR for c
 ## Real-World Impact
 
 From applying TDD to TDD skill itself (2025-10-03):
+
 - 6 RED-GREEN-REFACTOR iterations to bulletproof
 - Baseline testing revealed 10+ unique rationalizations
 - Each REFACTOR closed specific loopholes

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

@@ -1,37 +1,64 @@
 ---
-description: Use when choosing between search tools (LSP, ast-grep, grep, glob) or need tool reference - covers when to use each tool and detailed syntax
+description: Use when choosing between search tools (LSP, grep, glob) or need tool reference - covers when to use each tool and detailed syntax
 ---
 
 # Tool Priority Skill
 
 ## Priority Order
 
-**LSP tools → AST-grep → Built-in tools**
+**LSP tools → grep → glob**
 
 1. **LSP tools** - Semantic code intelligence (10 tools)
-2. `ast-grep` - Code search/replace (functions, patterns, imports, hooks)
-3. `grep` - Text search (logs, config, non-code files, simple strings)
-4. `glob` - File discovery by name pattern
-5. `read`, `edit`, `write` - File operations
+2. `grep` - Text search (logs, config, code patterns, strings)
+3. `glob` - File discovery by name pattern
+4. `read`, `edit`, `write` - File operations
 
 **Rule**: Always `read` before `edit` to verify content.
 
 ## Choosing the Right Tool
 
-Ask: **"Am I looking for code structure or just text?"**
-
-| Need              | Tool                      | Example                               |
-| ----------------- | ------------------------- | ------------------------------------- |
-| Function calls    | `ast-grep`                | `pattern="fetchUser($$$)"`            |
-| Hook usage        | `ast-grep`                | `pattern="useState($$$)"`             |
-| Import statements | `ast-grep`                | `pattern="import { $$ } from '$MOD'"` |
-| Error messages    | `grep`                    | `pattern="FATAL\|ERROR"`              |
-| Config values     | `grep`                    | `pattern="API_KEY"`                   |
-| TODO comments     | `grep`                    | `pattern="TODO\|FIXME"`               |
-| Symbol type info  | `lsp_lsp_hover`           | Type signature at cursor              |
-| Definition jump   | `lsp_lsp_goto_definition` | Source location                       |
-| All usages        | `lsp_lsp_find_references` | Before refactoring                    |
-| Safe rename       | `lsp_lsp_rename`          | All references updated                |
+Ask: **"Am I looking for semantic understanding or just text?"**
+
+### Code Understanding (Use LSP)
+
+| Need             | Tool                        | Example                              |
+| ---------------- | --------------------------- | ------------------------------------ |
+| Symbol type info | `lsp_lsp_hover`             | Type signature at cursor             |
+| Definition jump  | `lsp_lsp_goto_definition`   | Source location                      |
+| All usages       | `lsp_lsp_find_references`   | Before refactoring                   |
+| File structure   | `lsp_lsp_document_symbols`  | What functions/classes in this file? |
+| Safe rename      | `lsp_lsp_rename`            | Update symbol across codebase        |
+| Workspace search | `lsp_lsp_workspace_symbols` | Where is UserService defined?        |
+
+### Text Search (Use grep)
+
+| Need              | Tool   | Example pattern        |
+| ----------------- | ------ | ---------------------- |
+| Function calls    | `grep` | `functionName\(`       |
+| Import statements | `grep` | `import.*from.*module` |
+| Error messages    | `grep` | `FATAL\|ERROR`         |
+| Config values     | `grep` | `API_KEY`              |
+| TODO comments     | `grep` | `TODO\|FIXME`          |
+| Hook usage        | `grep` | `useState(`            |
+| Debug logs        | `grep` | `console\.log\(`       |
+
+### Workflow Pattern
+
+```
+# Step 1: Find it
+grep "functionName" src/
+
+# Step 2: Understand it
+read src/file.ts
+lsp_lsp_document_symbols(filePath="src/file.ts", line=1, character=1)
+
+# Step 3: Trace it
+lsp_lsp_goto_definition(filePath="src/file.ts", line=42, character=10)
+lsp_lsp_find_references(filePath="src/file.ts", line=42, character=10)
+
+# Step 4: Modify it (if needed)
+lsp_lsp_hover(filePath="src/file.ts", line=42, character=10)
+```
 
 ## LSP Tools Reference
 
@@ -64,45 +91,91 @@ Semantic code intelligence via Language Server Protocol. **Uses `lsp_lsp_*` pref
 
 **Caveat**: LSP tools modify files directly. Re-read files before further edits.
 
-## AST-Grep Reference
-
-Semantic code operations - smarter than regex.
-
-### Pattern Syntax
+## grep Reference
 
-- `$NAME` - Matches any single AST node (identifier, expression, etc.)
-- `$$$` - Matches zero or more nodes (for arguments, statements, etc.)
+Fast, text-based search using ripgrep.
 
-### Search Examples
+### Basic Patterns
 
 ```bash
-# Find all console.log calls
-ast-grep pattern="console.log($$$)"
+# Find function definitions
+grep "function\|const.*=.*(" src/
 
-# Find async functions
-ast-grep pattern="async function $NAME($$$) { $$$ }"
+# Find imports
+grep "import.*from" src/
 
 # Find React hooks
-ast-grep pattern="const [$S, $SET] = useState($$$)"
+grep "useState\|useEffect" src/
 
-# Find try-catch blocks
-ast-grep pattern="try { $$$ } catch ($E) { $$$ }"
+# Find console logs
+grep "console\.log" src/
 
-# Find class definitions
-ast-grep pattern="class $NAME { $$$ }"
+# Search for errors
+grep "Error\|Exception\|Throw" src/
 
-# Find import statements
-ast-grep pattern="import { $$ } from '$MOD'"
+# Multiple patterns
+grep -e "TODO" -e "FIXME" src/
+
+# Case insensitive
+grep -i "test" src/
+
+# Specific file types
+grep -r "API_KEY" --include="*.ts" --include="*.js"
 ```
 
-### Replace Examples
+### grep vs LSP
+
+| Scenario           | Use                       | Why                                             |
+| ------------------ | ------------------------- | ----------------------------------------------- |
+| "Find all X"       | `grep`                    | Fast text search, everything including comments |
+| "Where is X used?" | `lsp_lsp_find_references` | Semantic, only code usage, tracks dependencies  |
+| "What type is X?"  | `lsp_lsp_hover`           | Type system intelligence                        |
+| "Find TODOs"       | `grep`                    | Text search across all files                    |
+| "Rename X"         | `lsp_lsp_rename`          | Safe semantic refactoring                       |
+
+### Common Gotchas
+
+**grep finds everything:**
+
+```bash
+grep "fetchUser"  # Matches: function fetchUser(), "fetchUser" string, // fetchUser comment
+```
+
+**LSP finds only code:**
+
+```bash
+lsp_lsp_find_references  # Only actual usages in code, not strings/comments
+```
+
+**When to use grep first:**
+
+- Quick exploration ("are there any X?")
+- Finding error patterns, logs, configs
+- Searching across file types (JSON, YAML, etc.)
+
+**When to use LSP first:**
+
+- Understanding code structure
+- Before refactoring
+- Tracing dependencies
+- Getting type information
+
+## glob Reference
+
+Find files by pattern.
 
 ```bash
-# Rename function (dry run)
-ast-grep pattern="oldFunc($$$)" rewrite="newFunc($$$)" dryRun=true
+# All TypeScript files
+glob "**/*.ts"
+
+# All test files
+glob "**/*.test.ts"
+
+# Specific directory
+glob "src/**/*.ts"
 
-# Add await (apply)
-ast-grep pattern="fetch($URL)" rewrite="await fetch($URL)" dryRun=false
+# Multiple patterns
+glob ["src/**/*.ts", "tests/**/*.ts"]
 ```
 
 ## Research Tools

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

@@ -4,13 +4,7 @@ description: AI-powered UI generation via v0 MCP. Create chats, generate React c
 mcp:
   v0:
     command: npx
-    args:
-      [
-        "mcp-remote",
-        "https://mcp.v0.dev",
-        "--header",
-        "Authorization: Bearer ${V0_API_KEY}",
-      ]
+    args: ["mcp-remote", "https://mcp.v0.dev", "--header", "Authorization: Bearer ${V0_API_KEY}"]
     env:
       V0_API_KEY: "${V0_API_KEY}"
 ---