opencodekit 0.19.6 → 0.20.1

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

@@ -1,28 +1,28 @@
 ---
 name: opensrc
-description: Fetch source code for npm, PyPI, or crates.io packages and GitHub/GitLab repos to provide AI agents with implementation context beyond types and docs. Use when needing to understand how a library works internally, debug dependency issues, or explore package implementations.
-version: 1.0.0
-tags: [research, integration]
+description: Use when you need to understand how a library works internally, debug dependency issues, or inspect package source code beyond types and docs. Fetches source for npm, PyPI, crates.io packages and GitHub repos. Includes structured research workflow for deep investigation.
+version: 1.1.0
+tags: [research, integration, source-code]
 dependencies: []
 ---
 
 # opensrc
 
-## When to Use
-
-- When you need actual dependency source code to understand behavior or debug issues.
-
-## When NOT to Use
-
-- When API docs or local type definitions are sufficient for the task.
-
+Fetch and inspect dependency source code, then run a structured research workflow to answer implementation-level questions with evidence.
 
 ## When to Use
 
 - Need to understand how a library/package works internally (not just its interface)
-- Debugging issues where types alone are insufficient
+- Debugging issues where types or docs are insufficient
 - Exploring implementation patterns in dependencies
-- Agent needs to reference actual source code of a package
+- Investigating edge cases and behavior not documented officially
+- Evaluating dependency quality before adoption
+
+## When NOT to Use
+
+- Official docs already answer the question (check Context7 first)
+- You only need public API syntax or quick examples
+- The target is your own codebase (use project search/LSP tools)
 
 ## Quick Start
 
@@ -58,7 +58,7 @@ npx opensrc owner/repo@v1.0.0
 
 ## Output Structure
 
-After fetching, sources stored in `opensrc/` directory:
+After fetching, sources are stored in `opensrc/`:
 
 ```
 opensrc/
@@ -72,56 +72,213 @@ opensrc/
 
 ## File Modifications
 
-On first run, opensrc prompts to modify:
+On first run, opensrc may prompt to modify:
 
 - `.gitignore` - adds `opensrc/` to ignore list
 - `tsconfig.json` - excludes `opensrc/` from compilation
 - `AGENTS.md` - adds section pointing agents to source code
 
-Use `--modify` or `--modify=false` to skip prompt.
+Use `--modify` or `--modify=false` to control this behavior.
 
 ## Key Behaviors
 
 1. **Version Detection** - For npm, auto-detects installed version from `node_modules`, `package-lock.json`, `pnpm-lock.yaml`, or `yarn.lock`
 2. **Repository Resolution** - Resolves package to its git repo via registry API, clones at matching tag
-3. **Monorepo Support** - Handles packages in monorepos via `repository.directory` field
+3. **Monorepo Support** - Handles packages in monorepos via `repository.directory`
 4. **Shallow Clone** - Uses `--depth 1` for efficient cloning, removes `.git` after clone
 5. **Tag Fallback** - Tries `v{version}`, `{version}`, then default branch if tag not found
 
+## Research Workflow (Structured)
+
+Use this 5-step workflow for deep investigations.
+
+### Step 1: Identify
+
+Define the smallest useful target and scope:
+
+- Package/repo name and version
+- Specific question (e.g., retry behavior, parsing path, cache invalidation)
+- Candidate symbols/files to inspect first
+
+```bash
+# Good: scoped target with version
+npx opensrc zod@3.22.0
+
+# Also valid
+npx opensrc pypi:requests
+npx opensrc crates:serde
+npx opensrc vercel/ai@v3.0.0
+```
+
+### Step 2: Fetch
+
+Fetch source with opensrc and confirm location:
+
+```bash
+npx opensrc <target>
+npx opensrc list
+```
+
+Expected result:
+
+- Source cloned into `opensrc/repos/<host>/<owner>/<repo>/`
+- Metadata recorded in `opensrc/sources.json`
+
+### Step 3: Locate
+
+Find relevant files/symbols before deep reading:
+
+- Search by exported symbol names, error classes, feature flags, config keys
+- Prefer implementation files over declaration/type-only files
+- Include tests/examples to infer intended behavior
+
+Suggested search sequence:
+
+1. Entry points (`index`, `main`, package exports)
+2. Core implementation modules
+3. Tests and fixtures
+4. Changelog/release notes for behavioral changes
+
+### Step 4: Analyze
+
+Read code paths end-to-end and collect evidence:
+
+- Trace function call flow from public API to internal logic
+- Note edge-case guards, fallbacks, and error paths
+- Distinguish public API from private/internal contracts
+- Record exact file:line evidence for each claim
+
+Evidence standard:
+
+- Prefer direct source snippets + `file:line`
+- Mark uncertain conclusions explicitly
+- Avoid claims based only on docs/types when source contradicts them
+
+### Step 5: Document
+
+Write findings in a reusable format:
+
+```markdown
+# Research: <library>
+
+- Package/Version: <name@version>
+- Source Path: opensrc/repos/<host>/<owner>/<repo>
+- Research Question: <question>
+
+## Findings
+1. <claim>
+   - Evidence: `path/to/file.ts:42-68`
+   - Confidence: High | Medium | Low
+
+## Answer
+- <direct answer to original question>
+
+## Caveats
+- Version-specific behavior and limits
+```
+
+## Integration with Other Research Methods
+
+Use source inspection as part of a layered approach:
+
+| Method         | Best For                   | Source Code Adds               |
+| -------------- | -------------------------- | ------------------------------ |
+| **Context7**   | API docs, official guides  | Implementation details         |
+| **codesearch** | Usage patterns in the wild | Canonical implementation       |
+| **grepsearch** | Real-world examples        | How library itself works       |
+| **Web search** | Tutorials, blog posts      | Ground truth from source       |
+| **Codebase**   | Project-specific patterns  | How dependencies actually work |
+
+Recommended order:
+
+1. Context7 (official docs)
+2. Local codebase usage
+3. **opensrc source inspection**
+4. codesearch/grepsearch external usage patterns
+5. Web search for supplementary context
+
+## Limitations
+
+### When Source Code May Not Fully Explain Runtime Behavior
+
+- **Build-time transforms**: transpilation/macros/plugins can alter runtime shape
+- **Native modules**: C/C++/Rust bindings require native-level inspection
+- **Generated/minified artifacts**: published package may omit readable source
+- **Monorepo indirection**: behavior may span multiple internal packages
+- **Environment-specific paths**: Node/browser/edge branches can diverge
+
+### Practical Alternatives
+
+If opensrc is incomplete or blocked:
+
+1. Browse repository directly on GitHub
+2. Use `npm pack <package>` and inspect tarball contents
+3. Inspect installed `node_modules/<package>/` output
+4. Use source maps during runtime debugging when available
+
 ## Common Workflows
 
 ### Fetching a Package
 
 ```bash
-# Agent needs to understand zod's implementation
+# Understand zod implementation
 npx opensrc zod
-# → Detects version from lockfile
-# → Finds repo URL from npm registry
-# → Clones at matching git tag
-# → Source available at opensrc/repos/github.com/colinhacks/zod/
+# → detects version from lockfile
+# → resolves registry metadata
+# → clones matching tag/revision
 ```
 
 ### Updating Sources
 
 ```bash
-# Re-run same command to update to currently installed version
+# Re-run to refresh against current installed version
 npx opensrc zod
-# → Checks if version changed
-# → Re-clones if needed
 ```
 
 ### Multiple Sources
 
 ```bash
-# Fetch multiple at once
 npx opensrc react react-dom next
 npx opensrc zod pypi:pydantic vercel/ai
 ```
 
+### Cleanup
+
+```bash
+# Remove one source
+npx opensrc remove <package>
+
+# Remove all sources
+npx opensrc clean
+
+# Remove by ecosystem
+npx opensrc clean --npm --pypi --crates
+```
+
+## Success Criteria
+
+You are done when all are true:
+
+- [ ] Fetched the correct package/repo and version
+- [ ] Located the exact implementation path relevant to the question
+- [ ] Verified behavior by reading source (not only types/docs)
+- [ ] Captured file:line evidence for major claims
+- [ ] Answered the original question with explicit confidence
+- [ ] Documented caveats (version bounds, private API risks)
+
 ## References
 
-For detailed information:
+Core opensrc references:
 
 - [CLI Usage & Options](references/cli-usage.md) - Full command reference
 - [Architecture](references/architecture.md) - Code structure and extension
 - [Registry Support](references/registry-support.md) - npm, PyPI, crates.io details
+
+Research workflow references (merged from source-code-research):
+
+- [Common Patterns](references/common-patterns.md) - Error handling, tracing behavior, quality evaluation patterns
+- [Source Structure](references/source-structure.md) - npm/PyPI/Rust source layouts
+- [Analysis Tips](references/analysis-tips.md) - Tests, examples, changelog, types, blame
+- [Example Workflow](references/example-workflow.md) - End-to-end library investigation example
+- [Anti-Patterns](references/anti-patterns.md) - What not to do when researching
+- [Further Reading](references/further-reading.md) - External links and complementary resources

package/dist/template/.opencode/skill/pdf-extract/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pdf-extract
-description: Extract text, images, tables, and metadata from PDF files. Choose the right library based on extraction needs - text only, structured data, or complex layouts.
+description: Use when extracting text, images, tables, or metadata from PDF files. MUST load to choose the correct extraction library based on PDF complexity — simple text vs structured data vs complex layouts.
 version: 1.0.0
 tags: [research, integration]
 dependencies: []

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

@@ -1,6 +1,6 @@
 ---
 name: pencil
-description: OpenPencil design-as-code workflow (legacy skill name: pencil). Create/edit .op files, export code, and use desktop-bundled MCP.
+description: Use when working with OpenPencil .op design files — creating, editing, or exporting code from designs. MUST load before any OpenPencil workflow. Requires desktop app (npm CLI does not provide openpencil-mcp).
 version: 1.0.0
 tags: [design, openpencil, mcp, cli]
 mcp:

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

@@ -1,6 +1,6 @@
 ---
 name: playwright
-description: Browser automation for testing, screenshots, form validation, and UX verification. Uses Playwright CLI for token-efficient automation, with MCP fallback for complex exploratory workflows.
+description: Use when running automated browser tests, taking screenshots, validating forms, or verifying UX flows. Playwright CLI for token efficiency with MCP fallback for complex exploration. Also covers agent-browser CLI alternative. MUST load before any automated browser testing.
 version: 1.0.0
 tags: [automation, mcp, testing]
 dependencies: []
@@ -16,13 +16,13 @@ dependencies: []
 
 - When you specifically need to control your existing Chrome session (use playwriter instead).
 
-
 ## Quick Decision
 
-| Scenario                                            | Use     |
-| --------------------------------------------------- | ------- |
-| Quick screenshots, simple forms, token efficiency   | **CLI** |
-| Complex exploratory testing, self-healing workflows | **MCP** |
+| Scenario                                                         | Use                                 |
+| ---------------------------------------------------------------- | ----------------------------------- |
+| Quick screenshots, simple forms, token efficiency                | **Playwright CLI**                  |
+| Native binary speed + persistent isolated daemon-backed sessions | **agent-browser CLI** (alternative) |
+| Complex exploratory testing, self-healing workflows              | **MCP**                             |
 
 ---
 
@@ -30,6 +30,18 @@ dependencies: []
 
 The CLI approach is **token-efficient** - no large schemas or verbose accessibility trees in context. Best for most automation tasks.
 
+### Alternative: agent-browser CLI
+
+- `agent-browser` is a Playwright-based automation stack with a **Rust binary** front-end and a **Node.js daemon** back-end.
+- Commands execute through the native CLI while the daemon keeps browser state warm between calls.
+- Uses the same snapshot-ref interaction pattern (`snapshot` → `@eN` refs → `click/fill/...`) as Playwright workflows.
+- Prefer this alternative when you want native binary command performance on repeated operations.
+- Prefer this alternative when you need explicitly isolated named sessions backed by persistent daemons.
+- Good fit for multi-session parallel workflows where each session keeps independent browser/auth/storage state.
+- Keep defaulting to `playwright-cli` for broad compatibility and token-efficient standard flows.
+- Use MCP mode when you need richer introspection or complex exploratory automation.
+- Full command and options reference lives at: `./references/agent-browser-cli.md`.
+
 ### Installation
 
 ```bash

package/dist/template/.opencode/skill/{agent-browser/SKILL.md → playwright/references/agent-browser-cli.md}

@@ -1,11 +1,3 @@
----
-name: agent-browser
-description: Browser automation CLI for AI agents using Playwright
-version: 1.0.0
-tags: [automation, mcp]
-dependencies: []
----
-
 # agent-browser
 
 ## When to Use

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

@@ -1,6 +1,6 @@
 ---
 name: playwriter
-description: Browser automation via Chrome extension. Single execute tool with full Playwright API. Uses your existing browser with extensions, sessions, cookies. 90% less context than traditional browser MCP.
+description: Use when you need browser automation using the user's existing Chrome with extensions, sessions, and cookies intact. 90% less context than traditional browser MCP. Prefer over playwright skill when existing session state matters.
 mcp:
   playwriter:
     command: npx

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

@@ -1,6 +1,6 @@
 ---
 name: polar
-description: Polar payment platform integration for monetization, subscriptions, and license keys. Use when implementing checkout, managing products, or building customer portals.
+description: Use when implementing payment flows, subscriptions, license keys, or customer portals with Polar. MUST load before writing any checkout, monetization, or billing code using Polar platform.
 version: 1.0.0
 tags: [integration, mcp]
 dependencies: []

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

@@ -1,6 +1,6 @@
 ---
 name: prd
-description: Create Product Requirements Documents (PRDs) that define the end state of a feature. Use when planning new features, migrations, or refactors. Generates structured PRDs with acceptance criteria.
+description: Use when planning new features, migrations, or refactors that need a structured requirements document. MUST load before writing any PRD or defining acceptance criteria for a feature.
 version: 1.0.0
 tags: [planning, documentation]
 dependencies: []

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

@@ -1,6 +1,6 @@
 ---
 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.
+description: MUST load when writing, reviewing, or refactoring React/Next.js code for performance. Covers Vercel Engineering patterns — components, data fetching, bundle optimization, server components. Critical for any Next.js performance work.
 version: 1.0.0
 tags: [ui, code-quality]
 dependencies: []

package/dist/template/.opencode/skill/redesign-existing-projects/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: redesign-existing-projects
-description: Upgrades existing websites and apps to premium quality. Audits current design, identifies generic AI patterns, and applies high-end design standards without breaking functionality. Works with any CSS framework or vanilla CSS.
+description: Use when upgrading an existing website or app's visual design to premium quality. Audits current design, identifies generic AI patterns, applies high-end standards without breaking functionality. MUST load before any design overhaul of existing projects.
 ---
 
 # Redesign Skill

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

@@ -1,6 +1,6 @@
 ---
 name: resend
-description: Use when working with Resend email platform - sending transactional emails, receiving inbound emails, creating email templates with React Email, handling webhooks, or integrating email into applications.
+description: MUST load before sending transactional emails, creating React Email templates, handling email webhooks, or any Resend platform integration. Covers send, receive inbound, templates, and webhook handling.
 references:
   - send-email
   - receive-email

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

@@ -1,6 +1,6 @@
 ---
 name: stitch
-description: Google Stitch UI generation via native plugin. Generate screens from text, edit designs, create variants. Use when working with Stitch designs and UI generation.
+description: Use when generating, editing, or creating variants of UI screens in Google Stitch. MUST load before any stitch_generate_screen or stitch_edit_screens tool calls.
 version: 2.0.0
 tags: [design, ui, stitch]
 dependencies: []

package/dist/template/.opencode/skill/stitch-design-taste/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: stitch-design-taste
-description: Semantic Design System Skill for Google Stitch. Generates agent-friendly DESIGN.md files that enforce premium, anti-generic UI standards — strict typography, calibrated color, asymmetric layouts, perpetual micro-motion, and hardware-accelerated performance.
+description: Use when generating DESIGN.md files for Google Stitch projects to enforce premium, anti-generic UI standards. Load BEFORE stitch skill when design quality matters. Stitch-specific only — do not use for general web projects.
 ---
 
 # Stitch Design Taste — Semantic Design System Skill

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

@@ -1,6 +1,6 @@
 ---
 name: supabase
-description: Comprehensive Supabase platform MCP for database operations, edge functions, development tools, debugging, and project management. Use when working with Supabase projects, databases, or APIs.
+description: Use when working with any Supabase service — database operations, edge functions, auth, storage, or project management. MUST load before writing Supabase queries, RLS policies, or edge functions.
 version: 1.0.0
 tags: [integration, mcp]
 dependencies: []

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

@@ -1,6 +1,6 @@
 ---
 name: supabase-postgres-best-practices
-description: Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.
+description: MUST load when writing, reviewing, or optimizing Postgres queries, schema designs, indexes, or RLS policies in Supabase. Covers Supabase-specific Postgres performance patterns and common pitfalls.
 version: 1.0.0
 tags: [integration, code-quality]
 dependencies: []

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

@@ -1,6 +1,6 @@
 ---
 name: v0
-description: AI-powered UI generation via v0 MCP. Create chats, generate React components, get design assistance. Use when building UI components, dashboards, or need AI design help.
+description: Use when you need AI-powered UI generation for React components, dashboards, or quick prototypes via v0. MUST load before creating v0 chats or generating components via v0 MCP.
 mcp:
   v0:
     command: npx

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

@@ -1,6 +1,6 @@
 ---
 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.
+description: Use when selecting npm packages, checking for vulnerabilities, comparing alternatives, or verifying package health scores. MUST load before recommending or evaluating npm dependencies. Requires network.
 version: 1.0.0
 tags: [integration, mcp, research]
 dependencies: []

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

@@ -1,6 +1,6 @@
 ---
 name: webclaw
-description: Web content extraction, crawling, and scraping via webclaw MCP server. Use when fetching URLs fails (403), when crawling doc sites, batch-extracting pages, tracking content changes, or extracting brand identity from websites.
+description: MUST load when webfetch returns 403 or bot protection errors, when crawling documentation sites, batch-extracting pages, or extracting brand identity. Primary web scraping tool — prefer over webfetch for all non-trivial scraping.
 ---
 
 # Webclaw Skill

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

@@ -1,6 +1,6 @@
 ---
 name: writing-skills
-description: "Use when creating new skills, editing existing skills, or verifying skills work before deployment - applies TDD to process documentation by testing with subagents before writing, iterating until bulletproof against rationalization"
+description: "Use when creating new skills, editing existing skills, or verifying skills work before deployment - applies TDD to process documentation by testing with subagents before writing, iterating until bulletproof against rationalization. Includes complete pressure testing methodology."
 version: 1.0.0
 tags: [documentation, workflow]
 dependencies: []
@@ -211,12 +211,48 @@ Run same scenarios WITH skill. Agent should now comply.
 
 Agent found new rationalization? Add explicit counter. Re-test until bulletproof.
 
-**REQUIRED SUB-SKILL:** Use skill({ name: "testing-skills-with-subagents" }) for the complete testing methodology:
+**DETAILED TESTING METHODOLOGY:** See `references/testing-methodology.md` for the complete testing guide:
 
-- How to write pressure scenarios
-- Pressure types (time, sunk cost, authority, exhaustion)
-- Plugging holes systematically
-- Meta-testing techniques
+- Full RED-GREEN-REFACTOR testing workflow for skills
+- Scenario templates and pressure campaign examples
+- Rationalization hardening patterns and iteration loops
+- End-to-end checklists and worked examples
+
+### Inline Testing Summary (Merged Essentials)
+
+Use this quick inline summary while authoring; use `references/testing-methodology.md` for full details.
+
+#### Pressure scenarios (test format)
+
+- Test behavior under realistic stress, not quiz-style prompts
+- Force concrete A/B/C choices so violations are observable
+- Combine at least 3 pressures per scenario for discipline skills
+- Capture exact rationalizations verbatim during RED
+
+| Pressure Type   | What to Inject                              |
+| --------------- | ------------------------------------------- |
+| Time            | Deadline, production incident, deploy clock |
+| Sunk cost       | Hours already spent, large diff to discard  |
+| Authority       | Senior/manager asking to skip process       |
+| Economic        | Revenue loss, promotion/job pressure        |
+| Exhaustion      | End-of-day fatigue, urgency to finish       |
+| Social          | Fear of looking rigid or uncooperative      |
+| Pragmatic frame | "Be practical, not dogmatic" framing        |
+
+#### Meta-testing (after failure)
+
+When agent fails with skill loaded, ask how the skill should be rewritten to make the right choice unambiguous.
+
+- If response is "skill was clear, I ignored it" → strengthen foundational principle
+- If response is "skill should explicitly say X" → add X verbatim
+- If response is "I missed section Y" → improve placement/prominence
+
+#### Exit criteria for bulletproof skills
+
+- Agent chooses correct action under maximum pressure
+- Agent cites relevant sections to justify action
+- No new rationalizations emerge across retests
+- Meta-test confirms clarity, not ambiguity
 
 ## STOP: Before Moving to Next Skill
 
@@ -281,6 +317,7 @@ Deploying untested skills = deploying untested code. It's a violation of quality
 - `references/claude-search-optimization.md` - CSO guidance: descriptions, keywords, token efficiency, cross-references
 - `references/flowcharts-and-examples.md` - Flowchart usage rules and code example guidance
 - `references/file-organization.md` - Patterns for self-contained vs heavy-reference skills
+- `references/testing-methodology.md` - Complete pressure-testing methodology merged from testing-skills-with-subagents
 - `references/testing-skill-types.md` - How to test discipline, technique, pattern, and reference skills
 - `references/rationalization-hardening.md` - Loophole closure, rationalization tables, red flags
 - `references/anti-patterns.md` - Anti-patterns to avoid

package/dist/template/.opencode/skill/{testing-skills-with-subagents/SKILL.md → writing-skills/references/testing-methodology.md}

@@ -1,11 +1,3 @@
----
-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

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "opencodekit",
-	"version": "0.19.6",
+	"version": "0.20.1",
 	"description": "CLI tool for bootstrapping and managing OpenCodeKit projects",
 	"keywords": [
 		"agents",