oco-claude-plugin 0.1.0

package/plugin/skills/oco-trace-stack/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: oco-trace-stack
+description: Analyze a stack trace or runtime error to identify root cause. Use when a stacktrace or runtime error is present.
+triggers:
+  - "stacktrace"
+  - "stack trace"
+  - "traceback"
+  - "runtime error"
+  - "panic"
+  - "exception"
+  - "crash"
+  - "error at line"
+---
+
+# OCO: Trace Stack Error
+
+You are analyzing a runtime error or stack trace. Follow this evidence-based workflow.
+
+## Step 1: Parse the Stack Trace
+
+Extract from the error:
+- **Error type and message**
+- **File paths and line numbers** (ordered by stack depth)
+- **Relevant variable values** if visible
+- **Error chain** (caused by / wrapped errors)
+
+## Step 2: Map to Codebase
+
+Use `oco.trace_error` MCP tool if available:
+
+```
+oco.trace_error({ stacktrace: "<paste stacktrace>", workspace: "." })
+```
+
+Otherwise, manually inspect the files referenced in the stack trace, starting from the deepest application frame (skip library/framework frames).
+
+## Step 3: Inspect Likely Root Cause Regions
+
+For each candidate location:
+1. Read the file at the specific line
+2. Read surrounding context (function scope)
+3. Check for: null/undefined access, type mismatches, missing error handling, race conditions, invalid state
+
+## Step 4: Generate Hypotheses
+
+Produce 1-3 ranked hypotheses:
+- **H1** (most likely): description + evidence
+- **H2** (alternative): description + evidence
+- **H3** (edge case): description + evidence
+
+## Step 5: Verify Before Claiming a Fix
+
+**Do NOT propose a fix until you have:**
+1. Confirmed the hypothesis by reading the actual failing code
+2. Checked if the error is reproducible from the described scenario
+3. Verified the fix won't introduce regressions
+
+## Rules
+
+- Never guess at a fix without reading the code
+- If the stack trace references >5 files, delegate deep reading to `@codebase-investigator`
+- Always state which hypothesis you're most confident in and why
+- After applying a fix, run the verification workflow described in the `oco-verify-fix` skill (build, test, lint, typecheck)
+- Use `oco.collect_findings` to synthesize evidence and open questions before concluding

package/plugin/skills/oco-verify-fix/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: oco-verify-fix
+description: Run verification suite after code changes. Enforces build, test, lint, typecheck discipline with evidence-based completion.
+triggers:
+  - "verify"
+  - "check my changes"
+  - "run tests"
+  - "does it build"
+  - "make sure it works"
+  - "validate"
+---
+
+# OCO: Verify Fix
+
+You are verifying that code changes are correct and complete. Follow this structured verification workflow.
+
+## Step 1: Identify What Changed
+
+List all modified files:
+```bash
+git diff --name-only HEAD 2>/dev/null || git status --short
+```
+
+## Step 2: Detect Project Type and Available Checks
+
+Detect the verification suite from project manifests:
+
+| Signal | Build | Types | Lint | Test |
+|--------|-------|-------|------|------|
+| `Cargo.toml` | `cargo build` | `cargo check` | `cargo clippy` | `cargo test` |
+| `package.json` | `npm run build` | `tsc --noEmit` | `npm run lint` | `npm test` |
+| `pyproject.toml` | - | `mypy .` | `ruff check .` | `pytest` |
+| `go.mod` | `go build ./...` | `go vet ./...` | `golangci-lint run` | `go test ./...` |
+
+Use `oco.verify_patch` MCP tool if available for automated detection and execution.
+
+## Step 3: Run Verification Sequence
+
+Execute in order (stop on first failure):
+
+1. **Build** — Does it compile?
+2. **Type check** — Are types consistent?
+3. **Lint** — Are there style/quality issues?
+4. **Test** — Do tests pass? Are new tests needed?
+
+For each step, report:
+- Status: pass / fail / skip (not available)
+- Output summary (compact, not raw dump)
+
+## Step 4: Assess Results
+
+Produce a verification verdict:
+
+```
+VERDICT: PASS | FAIL | PARTIAL
+- Build: [pass/fail/skip]
+- Types: [pass/fail/skip]
+- Lint:  [pass/fail/skip]
+- Tests: [pass/fail/skip]
+- Missing coverage: [description if applicable]
+```
+
+## Step 5: Handle Failures
+
+If any check fails:
+1. Identify the specific failure
+2. Fix it
+3. Re-run the failing check
+4. Continue the sequence
+
+## Step 6: Verification Complete
+
+After all checks pass, the PostToolUse hook automatically detects verification commands (`cargo test`, `npm test`, etc.) and marks the session as verified. The Stop hook will then allow completion without warning.
+
+No manual marker is needed — the hook system handles this automatically.
+
+## Rules
+
+- Never skip a check that's available in the project
+- Never report PASS if any check failed
+- If tests are missing for the changed code, flag it explicitly
+- Keep output summaries compact — report failures in detail, successes briefly