opencode-plugin-coding 0.1.2

package/skills/playwright/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: playwright
+description: Browser automation and testing via Playwright MCP server. Navigate, interact, screenshot, and assert web application behavior.
+---
+
+# Playwright
+
+Browser automation and end-to-end testing via the Playwright MCP (Model Context Protocol) server. Use this skill to interact with web applications — navigate pages, fill forms, click buttons, take screenshots, and assert DOM state.
+
+**This skill requires an external MCP server** — it is not a CLI-based tool.
+
+---
+
+## When to Activate
+
+- User asks to test a web application interactively
+- End-to-end testing of a web UI
+- Visual verification of UI changes
+- Debugging UI issues that require browser interaction
+- User says "test in browser", "check the UI", "open the page"
+
+---
+
+## Prerequisites
+
+### MCP Server Required
+
+The Playwright MCP server must be configured in your OpenCode setup. Add to your `opencode.json`:
+
+```json
+{
+  "mcp": {
+    "playwright": {
+      "command": "npx",
+      "args": ["@anthropic/mcp-playwright"]
+    }
+  }
+}
+```
+
+Or use the Docker variant:
+
+```json
+{
+  "mcp": {
+    "playwright": {
+      "command": "docker",
+      "args": ["run", "-i", "--rm", "mcr.microsoft.com/playwright/mcp"]
+    }
+  }
+}
+```
+
+### Fallback When MCP is Unavailable
+
+If the Playwright MCP server is not configured:
+
+1. Report to the user: "Playwright MCP server is not available. Install it with: `npm install -g @anthropic/mcp-playwright`"
+2. Suggest alternatives:
+   - Write Playwright test scripts that the user can run manually
+   - Use `curl` for API-level testing
+   - Describe expected UI behavior for manual verification
+
+---
+
+## Available MCP Tools
+
+When the Playwright MCP server is running, these tools are available:
+
+| Tool | Description |
+|------|-------------|
+| `playwright_navigate` | Navigate to a URL |
+| `playwright_screenshot` | Take a screenshot of the current page |
+| `playwright_click` | Click an element (by selector or text) |
+| `playwright_fill` | Fill an input field |
+| `playwright_select` | Select from a dropdown |
+| `playwright_evaluate` | Execute JavaScript in the browser |
+| `playwright_get_text` | Get text content of an element |
+| `playwright_wait_for` | Wait for an element or condition |
+
+---
+
+## Workflow
+
+### 1. Start the Application
+
+Ensure the application is running locally:
+
+```bash
+# Check if already running
+curl -s http://localhost:<port> > /dev/null 2>&1 && echo "Running" || echo "Not running"
+
+# Start if needed (use the project's dev command)
+<packageManager> run dev &
+```
+
+### 2. Navigate and Interact
+
+Use MCP tools to interact with the application:
+
+```
+Navigate to http://localhost:<port>
+Screenshot the page
+Click on "Login" button
+Fill the email field with "test@example.com"
+Screenshot to verify the form state
+```
+
+### 3. Assert and Verify
+
+Check that the UI matches expectations:
+
+```
+Get text of the ".welcome-message" element
+Screenshot the final state
+```
+
+### 4. Report Results
+
+Return:
+
+1. **What was tested** — pages visited, interactions performed
+2. **Screenshots** — key states captured
+3. **Issues found** — any UI bugs or unexpected behavior
+4. **Pass/Fail** — overall assessment
+
+---
+
+## Writing Playwright Tests
+
+For persistent test coverage, write Playwright test files:
+
+```typescript
+import {test, expect} from '@playwright/test';
+
+test('should display welcome message after login', async ({page}) => {
+    await page.goto('http://localhost:3000');
+    await page.fill('[name="email"]', 'test@example.com');
+    await page.fill('[name="password"]', 'password');
+    await page.click('button[type="submit"]');
+    await expect(page.locator('.welcome-message')).toHaveText('Welcome, Test User');
+});
+```
+
+Place test files following the project's existing pattern (e.g., `e2e/`, `tests/`, `__tests__/`).
+
+---
+
+## Rules
+
+- **Always screenshot key states** — before and after interactions, to document what happened
+- **Use stable selectors** — prefer `data-testid`, `role`, or semantic selectors over fragile CSS classes
+- **Wait for readiness** — use `waitFor` before asserting on elements that load asynchronously
+- **Report MCP unavailability** — if tools are missing, tell the user how to install the MCP server
+- **Do not assume the app is running** — check first, start if needed

package/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: systematic-debugging
+description: Systematic 4-phase debugging — reproduce, hypothesize, isolate, fix — for resolving bugs, test failures, or abnormal behaviors.
+---
+
+# Systematic Debugging
+
+A structured 4-phase approach to debugging: reproduce → hypothesize → isolate → fix. Prevents the common anti-pattern of guessing at fixes without understanding the root cause.
+
+Inspired by the systematic-debugging skill from Superpowers.
+
+---
+
+## When to Activate
+
+- A test is failing and the cause isn't obvious
+- User reports a bug or unexpected behavior
+- A verification command fails during orchestration
+- Build errors that resist simple fixes
+- User says "debug", "investigate", "figure out why"
+
+---
+
+## Phase 1: Reproduce
+
+**Goal:** Get a reliable, minimal reproduction of the problem.
+
+1. **Understand the symptom** — What exactly is failing? Error message? Wrong output? Crash?
+2. **Run the failing command** — Execute and capture the full output:
+   ```bash
+   <failing command> 2>&1
+   ```
+3. **Identify the minimal trigger** — Can you reduce the input or test case to the smallest reproduction?
+4. **Document the reproduction:**
+   ```
+   **Bug:** <one-line description>
+   **Symptom:** <what happens>
+   **Expected:** <what should happen>
+   **Reproduction:** <exact command to reproduce>
+   **Environment:** <relevant versions, OS, config>
+   ```
+
+**Do not proceed to Phase 2 until you have a reliable reproduction.** If you can't reproduce it, gather more information first.
+
+---
+
+## Phase 2: Hypothesize
+
+**Goal:** Form 2–3 concrete hypotheses about the root cause.
+
+1. **Read the error carefully** — Parse stack traces, error codes, and messages
+2. **Trace the code path** — Read the source code along the execution path:
+   ```bash
+   # Read the file where the error originates
+   # Read the callers
+   # Read the data flow
+   ```
+3. **Form hypotheses** — List 2–3 possible causes, ranked by likelihood:
+   ```
+   Hypotheses:
+   1. [Most likely] <description> — because <evidence>
+   2. [Possible] <description> — because <evidence>
+   3. [Less likely] <description> — because <evidence>
+   ```
+4. **Check recent changes** — Could a recent commit have introduced this?
+   ```bash
+   git log --oneline -20
+   git diff HEAD~5..HEAD -- <relevant files>
+   ```
+
+**Do not jump to fixing.** The goal is to understand, not to patch.
+
+---
+
+## Phase 3: Isolate
+
+**Goal:** Confirm which hypothesis is correct by testing each one.
+
+For each hypothesis:
+
+1. **Design a test** — What would confirm or disprove this hypothesis?
+2. **Execute the test** — Add logging, run with different inputs, or write a targeted unit test
+3. **Record the result:**
+   ```
+   Hypothesis 1: [CONFIRMED / DISPROVED]
+   Evidence: <what you observed>
+   ```
+
+Techniques:
+
+- **Binary search** — If the bug is in a range of commits, use `git bisect`
+- **Add logging** — Temporarily add `console.log` or equivalent at key points
+- **Simplify inputs** — Remove complexity until the bug disappears, then add back
+- **Unit test isolation** — Write a test that directly exercises the suspected code path
+
+**Continue until exactly one hypothesis is confirmed.** If all are disproved, return to Phase 2 with new information.
+
+---
+
+## Phase 4: Fix
+
+**Goal:** Apply the correct fix and verify it resolves the issue without regressions.
+
+1. **Write the fix** — Target the confirmed root cause, not the symptom
+2. **Add a regression test** — Write a test that would have caught this bug:
+   ```
+   it('should <expected behavior> when <condition that caused the bug>')
+   ```
+3. **Remove debug artifacts** — Remove any temporary logging added in Phase 3
+4. **Run the reproduction** — Confirm the original symptom is gone
+5. **Run the full test suite** — Ensure no regressions:
+   ```bash
+   <test command from workflow.json>
+   ```
+6. **Run all verification commands** — Typecheck, lint, etc.
+7. **Document the root cause:**
+   ```
+   **Root cause:** <what was wrong>
+   **Fix:** <what was changed>
+   **Regression test:** <test file and name>
+   ```
+
+---
+
+## Anti-Patterns
+
+Avoid these common debugging mistakes:
+
+- **Shotgun debugging** — Making random changes and hoping one works. Always have a hypothesis.
+- **Fixing symptoms** — Suppressing an error message without understanding the cause.
+- **Skipping reproduction** — Trying to fix a bug you can't reliably reproduce.
+- **Tunnel vision** — Getting stuck on one hypothesis. If it's disproved, move on.
+- **Leaving debug code** — Forgetting to remove `console.log`, `debugger`, or test hacks.
+
+---
+
+## Output
+
+Return to the user or orchestrator:
+
+1. **Root cause** — what was wrong
+2. **Fix applied** — what was changed (file paths and description)
+3. **Regression test** — test file and test name
+4. **Verification** — all gate commands pass
+5. **Learnings** — anything that should be added to `AGENTS.md` or `doc/TODO.md`

package/skills/test-driven-development/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: test-driven-development
+description: Enforce RED-GREEN-REFACTOR test-driven development cycle. Write failing test first, implement minimal code, then refactor. Opt-in per project.
+---
+
+# Test-Driven Development
+
+Enforce the RED-GREEN-REFACTOR test-driven development cycle. This skill is **opt-in** — enable it in `workflow.json` → `testDrivenDevelopment.enabled: true`.
+
+When active, the core-coder must write failing tests before implementation code. This ensures test coverage is a first-class deliverable, not an afterthought.
+
+Inspired by the test-driven-development skill from Superpowers.
+
+---
+
+## When to Activate
+
+- `workflow.json` → `testDrivenDevelopment.enabled` is `true`
+- User explicitly requests TDD approach
+- The orchestrator or core-coder decides TDD is appropriate for a task
+
+---
+
+## The RED-GREEN-REFACTOR Cycle
+
+### RED: Write a Failing Test
+
+1. Identify the behavior to implement from the plan
+2. Write a test that asserts the expected behavior
+3. Run the test — it **must fail** (if it passes, the test is wrong or the behavior already exists)
+4. Commit the failing test: `test: add failing test for <behavior>`
+
+### GREEN: Make It Pass
+
+1. Write the **minimum** code to make the failing test pass
+2. Do not add extra features, optimizations, or edge cases yet
+3. Run the test — it **must pass**
+4. Run all other tests — ensure nothing is broken
+5. Commit: `feat(<scope>): implement <behavior>`
+
+### REFACTOR: Clean Up
+
+1. Improve code quality without changing behavior
+2. Look for: duplication, naming, structure, readability
+3. Run all tests after each refactoring step — they must still pass
+4. Commit: `refactor(<scope>): <what was improved>`
+
+### Repeat
+
+Move to the next behavior from the plan and start a new RED cycle.
+
+---
+
+## Process
+
+For each task in the plan:
+
+1. **Analyze the task** — What testable behaviors does it introduce?
+2. **List test cases** — Before writing any code, list the test cases:
+   ```
+   Test cases for Task N:
+   - [ ] When <input/condition>, should <expected behavior>
+   - [ ] When <edge case>, should <expected behavior>
+   - [ ] When <error case>, should <expected behavior>
+   ```
+3. **RED-GREEN-REFACTOR** — Execute the cycle for each test case
+4. **Verify** — Run the full test suite after completing all cases for a task
+
+### Test File Conventions
+
+- Place tests adjacent to source files or in a `__tests__/` directory, following the project's existing pattern
+- Name test files consistently: `*.test.ts`, `*.spec.ts`, or match existing convention
+- Use descriptive test names: `it('should return empty array when no items match filter')`
+
+### When TDD Doesn't Fit
+
+Some changes don't benefit from TDD:
+
+- Pure configuration changes
+- Documentation updates
+- Trivial one-line fixes with obvious correctness
+- UI layout changes (use visual testing instead)
+
+For these, write tests after implementation (or skip if truly trivial).
+
+---
+
+## Integration with Orchestrate
+
+When `testDrivenDevelopment.enabled` is true, the `orchestrate` skill modifies the core-coder implementation template:
+
+```
+Implement the approved plan using TDD (RED-GREEN-REFACTOR cycle).
+
+For each task:
+1. Write failing tests first
+2. Implement minimal code to pass
+3. Refactor
+4. Run full test suite before moving to next task
+
+Follow the test-driven-development skill instructions.
+```
+
+Reviewers should verify TDD compliance: are there tests for new behavior? Were tests written before implementation (check commit order)?
+
+---
+
+## Rules
+
+- **Tests must fail first.** If a test passes immediately, investigate — the behavior may already exist or the test may be wrong.
+- **Minimum code to pass.** Do not over-engineer in the GREEN phase. Save improvements for REFACTOR.
+- **All tests must pass after GREEN.** Never leave the codebase with failing tests.
+- **Commit at each phase.** RED, GREEN, and REFACTOR each get their own commit for traceability.
+- **Do not skip REFACTOR.** Even if the GREEN code looks clean, take a moment to evaluate.

package/templates/plan.md

@@ -0,0 +1,27 @@
+---
+status: not_started
+branch: 
+created: 
+---
+
+# Plan: [Title]
+
+## Context
+
+[Brief description of what this plan accomplishes]
+
+## Tasks
+
+- [ ] Task 1: [Description]
+  - Files: [exact file paths]
+  - Acceptance: [criteria]
+
+## Verification
+
+- Build: `[command]`
+- Tests: `[command]`
+- Lint: `[command]`
+
+## Learnings (updated during execution)
+
+- (none yet)

package/templates/retrospective.md

@@ -0,0 +1,51 @@
+---
+branch: 
+date: 
+pr: 
+rounds:   # integer: total review rounds completed
+---
+
+# Retrospective: [Title]
+
+## Summary
+
+[Brief summary of the completed work]
+
+## Reviewer Scores
+
+| Reviewer | Model | Focus Areas | Score | Notes |
+|----------|-------|-------------|-------|-------|
+| | | | | |
+
+## Key Findings
+
+### Critical Issues Found
+- (none)
+
+### Patterns Observed
+- (none)
+
+## Proposed AGENTS.md Updates
+
+### New Gotchas
+- (none)
+
+### Convention Updates
+- (none)
+
+## Reviewer Knowledge Updates
+
+[Replace each placeholder below with actual values and merge into `.opencode/reviewer-knowledge.json`. Example format:]
+
+```json
+{
+  "models": {
+    "<model-id>": {
+      "areas": {
+        "<area>": { "totalScore": <N>, "reviewCount": <N> }
+      }
+    }
+  },
+  "lastUpdated": "<YYYY-MM-DD>"
+}
+```

package/templates/workflow.json

@@ -0,0 +1,33 @@
+{
+
+  "project": {
+    "name": "",
+    "repo": "",
+    "defaultBranch": "master"
+  },
+  "stack": {
+    "language": "",
+    "framework": "",
+    "packageManager": ""
+  },
+  "commands": {
+    "build": "",
+    "lint": "",
+    "test": "",
+    "typecheck": ""
+  },
+  "agents": {
+    "coreCoder": { "name": "core-coder", "model": "" },
+    "coreReviewers": [
+      { "name": "core-reviewer-1", "model": "" },
+      { "name": "core-reviewer-2", "model": "" }
+    ],
+    "reviewers": [
+      { "name": "reviewer-1", "model": "" }
+    ],
+    "securityReviewers": []
+  },
+  "testDrivenDevelopment": { "enabled": false },
+  "docsToRead": [],
+  "reviewFocus": []
+}