opencodekit 0.14.6 → 0.15.0

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

@@ -27,11 +27,13 @@ WHEN receiving code review feedback:
 ## Forbidden Responses
 
 **NEVER:**
+
 - "You're absolutely right!" (explicit CLAUDE.md violation)
 - "Great point!" / "Excellent feedback!" (performative)
 - "Let me implement that now" (before verification)
 
 **INSTEAD:**
+
 - Restate the technical requirement
 - Ask clarifying questions
 - Push back with technical reasoning if wrong
@@ -48,6 +50,7 @@ WHY: Items may be related. Partial understanding = wrong implementation.
 ```
 
 **Example:**
+
 ```
 your human partner: "Fix 1-6"
 You understand 1,2,3,6. Unclear on 4,5.
@@ -59,12 +62,14 @@ You understand 1,2,3,6. Unclear on 4,5.
 ## Source-Specific Handling
 
 ### From your human partner
+
 - **Trusted** - implement after understanding
 - **Still ask** if scope unclear
 - **No performative agreement**
 - **Skip to action** or technical acknowledgment
 
 ### From External Reviewers
+
 ```
 BEFORE implementing:
   1. Check: Technically correct for THIS codebase?
@@ -113,6 +118,7 @@ FOR multi-item feedback:
 ## When To Push Back
 
 Push back when:
+
 - Suggestion breaks existing functionality
 - Reviewer lacks full context
 - Violates YAGNI (unused feature)
@@ -121,6 +127,7 @@ Push back when:
 - Conflicts with your human partner's architectural decisions
 
 **How to push back:**
+
 - Use technical reasoning, not defensiveness
 - Ask specific questions
 - Reference working tests/code
@@ -131,6 +138,7 @@ Push back when:
 ## Acknowledging Correct Feedback
 
 When feedback IS correct:
+
 ```
 ✅ "Fixed. [Brief description of what changed]"
 ✅ "Good catch - [specific issue]. Fixed in [location]."
@@ -150,6 +158,7 @@ When feedback IS correct:
 ## Gracefully Correcting Your Pushback
 
 If you pushed back and were wrong:
+
 ```
 ✅ "You were right - I checked [X] and it does [Y]. Implementing now."
 ✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
@@ -163,37 +172,41 @@ State the correction factually and move on.
 
 ## Common Mistakes
 
-| Mistake | Fix |
-|---------|-----|
-| Performative agreement | State requirement or just act |
-| Blind implementation | Verify against codebase first |
-| Batch without testing | One at a time, test each |
-| Assuming reviewer is right | Check if breaks things |
-| Avoiding pushback | Technical correctness > comfort |
-| Partial implementation | Clarify all items first |
+| Mistake                      | Fix                                 |
+| ---------------------------- | ----------------------------------- |
+| Performative agreement       | State requirement or just act       |
+| Blind implementation         | Verify against codebase first       |
+| Batch without testing        | One at a time, test each            |
+| Assuming reviewer is right   | Check if breaks things              |
+| Avoiding pushback            | Technical correctness > comfort     |
+| Partial implementation       | Clarify all items first             |
 | Can't verify, proceed anyway | State limitation, ask for direction |
 
 ## Real Examples
 
 **Performative Agreement (Bad):**
+
 ```
 Reviewer: "Remove legacy code"
 ❌ "You're absolutely right! Let me remove that..."
 ```
 
 **Technical Verification (Good):**
+
 ```
 Reviewer: "Remove legacy code"
 ✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
 ```
 
 **YAGNI (Good):**
+
 ```
 Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
 ✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
 ```
 
 **Unclear Item (Good):**
+
 ```
 your human partner: "Fix items 1-6"
 You understand 1,2,3,6. Unclear on 4,5.

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

@@ -3,6 +3,7 @@
 You are reviewing code changes for production readiness.
 
 **Your task:**
+
 1. Review {WHAT_WAS_IMPLEMENTED}
 2. Compare against {PLAN_OR_REQUIREMENTS}
 3. Check code quality, architecture, testing
@@ -30,6 +31,7 @@ git diff {BASE_SHA}..{HEAD_SHA}
 ## Review Checklist
 
 **Code Quality:**
+
 - Clean separation of concerns?
 - Proper error handling?
 - Type safety (if applicable)?
@@ -37,24 +39,28 @@ git diff {BASE_SHA}..{HEAD_SHA}
 - Edge cases handled?
 
 **Architecture:**
+
 - Sound design decisions?
 - Scalability considerations?
 - Performance implications?
 - Security concerns?
 
 **Testing:**
+
 - Tests actually test logic (not mocks)?
 - Edge cases covered?
 - Integration tests where needed?
 - All tests passing?
 
 **Requirements:**
+
 - All plan requirements met?
 - Implementation matches spec?
 - No scope creep?
 - Breaking changes documented?
 
 **Production Readiness:**
+
 - Migration strategy (if schema changes)?
 - Backward compatibility considered?
 - Documentation complete?
@@ -63,26 +69,32 @@ git diff {BASE_SHA}..{HEAD_SHA}
 ## Output Format
 
 ### Strengths
+
 [What's well done? Be specific.]
 
 ### Issues
 
 #### Critical (Must Fix)
+
 [Bugs, security issues, data loss risks, broken functionality]
 
 #### Important (Should Fix)
+
 [Architecture problems, missing features, poor error handling, test gaps]
 
 #### Minor (Nice to Have)
+
 [Code style, optimization opportunities, documentation improvements]
 
 **For each issue:**
+
 - File:line reference
 - What's wrong
 - Why it matters
 - How to fix (if not obvious)
 
 ### Recommendations
+
 [Improvements for code quality, architecture, or process]
 
 ### Assessment
@@ -94,6 +106,7 @@ git diff {BASE_SHA}..{HEAD_SHA}
 ## Critical Rules
 
 **DO:**
+
 - Categorize by actual severity (not everything is Critical)
 - Be specific (file:line, not vague)
 - Explain WHY issues matter
@@ -101,6 +114,7 @@ git diff {BASE_SHA}..{HEAD_SHA}
 - Give clear verdict
 
 **DON'T:**
+
 - Say "looks good" without checking
 - Mark nitpicks as Critical
 - Give feedback on code you didn't review

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

@@ -29,6 +29,7 @@ digraph when_to_use {
 ```
 
 **Use when:**
+
 - Error happens deep in execution (not at entry point)
 - Stack trace shows long call chain
 - Unclear where invalid data originated
@@ -37,17 +38,21 @@ digraph when_to_use {
 ## The Tracing Process
 
 ### 1. Observe the Symptom
+
 ```
 Error: git init failed in /Users/jesse/project/packages/core
 ```
 
 ### 2. Find Immediate Cause
+
 **What code directly causes this?**
+
 ```typescript
-await execFileAsync('git', ['init'], { cwd: projectDir });
+await execFileAsync("git", ["init"], { cwd: projectDir });
 ```
 
 ### 3. Ask: What Called This?
+
 ```typescript
 WorktreeManager.createSessionWorktree(projectDir, sessionId)
   → called by Session.initializeWorkspace()
@@ -56,16 +61,20 @@ WorktreeManager.createSessionWorktree(projectDir, sessionId)
 ```
 
 ### 4. Keep Tracing Up
+
 **What value was passed?**
+
 - `projectDir = ''` (empty string!)
 - Empty string as `cwd` resolves to `process.cwd()`
 - That's the source code directory!
 
 ### 5. Find Original Trigger
+
 **Where did empty string come from?**
+
 ```typescript
 const context = setupCoreTest(); // Returns { tempDir: '' }
-Project.create('name', context.tempDir); // Accessed before beforeEach!
+Project.create("name", context.tempDir); // Accessed before beforeEach!
 ```
 
 ## Adding Stack Traces
@@ -76,25 +85,27 @@ When you can't trace manually, add instrumentation:
 // Before the problematic operation
 async function gitInit(directory: string) {
   const stack = new Error().stack;
-  console.error('DEBUG git init:', {
+  console.error("DEBUG git init:", {
     directory,
     cwd: process.cwd(),
     nodeEnv: process.env.NODE_ENV,
     stack,
   });
 
-  await execFileAsync('git', ['init'], { cwd: directory });
+  await execFileAsync("git", ["init"], { cwd: directory });
 }
 ```
 
 **Critical:** Use `console.error()` in tests (not logger - may not show)
 
 **Run and capture:**
+
 ```bash
 npm test 2>&1 | grep 'DEBUG git init'
 ```
 
 **Analyze stack traces:**
+
 - Look for test file names
 - Find the line number triggering the call
 - Identify the pattern (same test? same parameter?)
@@ -116,6 +127,7 @@ Runs tests one-by-one, stops at first polluter. See script for usage.
 **Symptom:** `.git` created in `packages/core/` (source code)
 
 **Trace chain:**
+
 1. `git init` runs in `process.cwd()` ← empty cwd parameter
 2. WorktreeManager called with empty projectDir
 3. Session.create() passed empty string
@@ -127,6 +139,7 @@ Runs tests one-by-one, stops at first polluter. See script for usage.
 **Fix:** Made tempDir a getter that throws if accessed before beforeEach
 
 **Also added defense-in-depth:**
+
 - Layer 1: Project.create() validates directory
 - Layer 2: WorkspaceManager validates not empty
 - Layer 3: NODE_ENV guard refuses git init outside tmpdir
@@ -168,6 +181,7 @@ digraph principle {
 ## Real-World Impact
 
 From debugging session (2025-10-03):
+
 - Found root cause through 5-level trace
 - Fixed at source (getter validation)
 - Added 4 layers of defense

package/dist/template/.opencode/skill/source-code-research/SKILL.md

@@ -86,7 +86,7 @@ npx opensrc vercel/ai@v3.0.0       # Fetch specific tag
 
 ### Step 3: Locate Relevant Code
 
-Use search tools to find the code you need:
+Use search tools to find code you need:
 
 ```typescript
 // Find all TypeScript source files
@@ -99,10 +99,11 @@ grep({
   include: "*.ts",
 });
 
-// Use AST search for precise patterns
-ast_grep({
-  pattern: "export function parse($$$) { $$$ }",
+// Search for function pattern
+grep({
+  pattern: "export function parse",
   path: "opensrc/",
+  include: "*.ts",
 });
 ```
 
@@ -216,9 +217,10 @@ grep({ pattern: "throw new", path: "opensrc/", include: "*.ts" });
 // bash: npx opensrc react-hook-form
 
 // 2. Find function definition
-ast_grep({
-  pattern: "export function useForm($$$) { $$$ }",
+grep({
+  pattern: "export function useForm",
   path: "opensrc/",
+  include: "*.ts",
 });
 
 // 3. Read implementation
@@ -491,7 +493,7 @@ read({ filePath: "opensrc/.../helpers.ts" });
 // ... (unfocused exploration)
 ```
 
-**Do:** Use grep/ast-grep to find relevant code first, then read.
+**Do:** Use grep to find relevant code first, then read.
 
 ### ❌ Don't: Ignore Version Mismatch
 

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

@@ -16,12 +16,14 @@ Write the test first. Watch it fail. Write minimal code to pass.
 ## When to Use
 
 **Always:**
+
 - New features
 - Bug fixes
 - Refactoring
 - Behavior changes
 
 **Exceptions (ask your human partner):**
+
 - Throwaway prototypes
 - Generated code
 - Configuration files
@@ -37,6 +39,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 Write code before the 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
@@ -82,12 +85,13 @@ test('retries failed operations 3 times', async () => {
     return 'success';
   };
 
-  const result = await retryOperation(operation);
+const result = await retryOperation(operation);
 
-  expect(result).toBe('success');
-  expect(attempts).toBe(3);
+expect(result).toBe('success');
+expect(attempts).toBe(3);
 });
-```
+
+````
 Clear name, tests real behavior, one thing
 </Good>
 
@@ -101,11 +105,13 @@ test('retry works', async () => {
   await retryOperation(mock);
   expect(mock).toHaveBeenCalledTimes(3);
 });
-```
+````
+
 Vague name, tests mock not code
 </Bad>
 
 **Requirements:**
+
 - One behavior
 - Clear name
 - Real code (no mocks unless unavoidable)
@@ -119,6 +125,7 @@ npm test path/to/test.test.ts
 ```
 
 Confirm:
+
 - Test fails (not errors)
 - Failure message is expected
 - Fails because feature missing (not typos)
@@ -174,6 +181,7 @@ npm test path/to/test.test.ts
 ```
 
 Confirm:
+
 - Test passes
 - Other tests still pass
 - Output pristine (no errors, warnings)
@@ -185,6 +193,7 @@ Confirm:
 ### REFACTOR - Clean Up
 
 After green only:
+
 - Remove duplication
 - Improve names
 - Extract helpers
@@ -197,17 +206,18 @@ Next failing test for next feature.
 
 ## Good Tests
 
-| Quality | Good | Bad |
-|---------|------|-----|
-| **Minimal** | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
-| **Clear** | Name describes behavior | `test('test1')` |
-| **Shows intent** | Demonstrates desired API | Obscures what code should do |
+| Quality          | Good                                | Bad                                                 |
+| ---------------- | ----------------------------------- | --------------------------------------------------- |
+| **Minimal**      | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
+| **Clear**        | Name describes behavior             | `test('test1')`                                     |
+| **Shows intent** | Demonstrates desired API            | Obscures what code should do                        |
 
 ## Why Order Matters
 
 **"I'll write tests after to verify it works"**
 
 Tests written after code pass immediately. Passing immediately proves nothing:
+
 - Might test wrong thing
 - Might test implementation, not behavior
 - Might miss edge cases you forgot
@@ -218,6 +228,7 @@ Test-first forces you to see the test fail, proving it actually tests something.
 **"I already manually tested all the edge cases"**
 
 Manual testing is ad-hoc. You think you tested everything but:
+
 - No record of what you tested
 - Can't re-run when code changes
 - Easy to forget cases under pressure
@@ -228,6 +239,7 @@ Automated tests are systematic. They run the same way every time.
 **"Deleting X hours of work is wasteful"**
 
 Sunk cost fallacy. The time is already gone. Your choice now:
+
 - Delete and rewrite with TDD (X more hours, high confidence)
 - Keep it and add tests after (30 min, low confidence, likely bugs)
 
@@ -236,6 +248,7 @@ The "waste" is keeping code you can't trust. Working code without real tests is
 **"TDD is dogmatic, being pragmatic means adapting"**
 
 TDD IS pragmatic:
+
 - Finds bugs before commit (faster than debugging after)
 - Prevents regressions (tests catch breaks immediately)
 - Documents behavior (tests show how to use code)
@@ -255,19 +268,19 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 
 ## Common Rationalizations
 
-| Excuse | Reality |
-|--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
-| "I'll test after" | Tests passing immediately prove nothing. |
-| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
-| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
-| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
-| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
-| "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
-| "Existing code has no tests" | You're improving it. Add tests for existing code. |
+| Excuse                                 | Reality                                                                 |
+| -------------------------------------- | ----------------------------------------------------------------------- |
+| "Too simple to test"                   | Simple code breaks. Test takes 30 seconds.                              |
+| "I'll test after"                      | Tests passing immediately prove nothing.                                |
+| "Tests after achieve same goals"       | Tests-after = "what does this do?" Tests-first = "what should this do?" |
+| "Already manually tested"              | Ad-hoc ≠ systematic. No record, can't re-run.                           |
+| "Deleting X hours is wasteful"         | Sunk cost fallacy. Keeping unverified code is technical debt.           |
+| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete.             |
+| "Need to explore first"                | Fine. Throw away exploration, start with TDD.                           |
+| "Test hard = design unclear"           | Listen to test. Hard to test = hard to use.                             |
+| "TDD will slow me down"                | TDD faster than debugging. Pragmatic = test-first.                      |
+| "Manual test faster"                   | Manual doesn't prove edge cases. You'll re-test every change.           |
+| "Existing code has no tests"           | You're improving it. Add tests for existing code.                       |
 
 ## Red Flags - STOP and Start Over
 
@@ -292,30 +305,34 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 **Bug:** Empty email accepted
 
 **RED**
+
 ```typescript
-test('rejects empty email', async () => {
-  const result = await submitForm({ email: '' });
-  expect(result.error).toBe('Email required');
+test("rejects empty email", async () => {
+  const result = await submitForm({ email: "" });
+  expect(result.error).toBe("Email required");
 });
 ```
 
 **Verify RED**
+
 ```bash
 $ npm test
 FAIL: expected 'Email required', got undefined
 ```
 
 **GREEN**
+
 ```typescript
 function submitForm(data: FormData) {
   if (!data.email?.trim()) {
-    return { error: 'Email required' };
+    return { error: "Email required" };
   }
   // ...
 }
 ```
 
 **Verify GREEN**
+
 ```bash
 $ npm test
 PASS
@@ -341,12 +358,12 @@ Can't check all boxes? You skipped TDD. Start over.
 
 ## When Stuck
 
-| Problem | Solution |
-|---------|----------|
+| Problem                | Solution                                                             |
+| ---------------------- | -------------------------------------------------------------------- |
 | Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
-| Test too complicated | Design too complicated. Simplify interface. |
-| Must mock everything | Code too coupled. Use dependency injection. |
-| Test setup huge | Extract helpers. Still complex? Simplify design. |
+| Test too complicated   | Design too complicated. Simplify interface.                          |
+| Must mock everything   | Code too coupled. Use dependency injection.                          |
+| Test setup huge        | Extract helpers. Still complex? Simplify design.                     |
 
 ## Debugging Integration