opencodekit 0.21.9 → 0.22.0

package/dist/template/.opencode/skill/agent-code-quality-gate/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: agent-code-quality-gate
+description: Use before a coding agent claims implementation work is complete, especially after bugfixes, feature edits, refactors, or subagent changes - converts code quality into an operational gate for scope, duplication, behavior tests, verification evidence, and regressions.
+version: 1.0.0
+---
+
+# Agent Code Quality Gate
+
+## Overview
+
+Code quality for an agent is not "clean-looking code." It is a small, reviewable, verified change that improves or preserves system health while solving the requested problem.
+
+Core rule: **do not claim completion until the diff is scoped, integrated, tested for behavior, and freshly verified.**
+
+## When to Use
+
+Use before saying work is complete, fixed, passing, ready, or high quality after:
+
+- implementing a feature or bugfix;
+- editing production code or tests;
+- receiving subagent/worker changes;
+- refactoring, optimizing, or migrating code;
+- touching security, auth, data, concurrency, payments, accessibility, performance, or public APIs.
+
+Do not use as a substitute for specialist review. For final merge/security/API review, also load the relevant review/security/API skill.
+
+## Quality Gate
+
+Answer every item. If any answer is "no" or "unknown," either fix it, verify it, or report the remaining risk explicitly.
+
+| Gate | Pass condition | Reject if |
+| --- | --- | --- |
+| Goal | The change satisfies the user's actual request and acceptance criteria. | It solves a nearby or imagined problem. |
+| Scope | Every changed line traces to the current request. | Drive-by cleanup, broad formatting, or speculative refactor is mixed in. |
+| Design fit | The change belongs in the touched layer and follows existing architecture. | It adds a parallel pattern, hidden business logic, or misplaced abstraction. |
+| Simplicity | The solution is the smallest clear working change. | It adds flexibility for hypothetical future needs. |
+| Duplication | Existing helpers/components/patterns were searched and reused. | A second home for the same concept was created. |
+| Behavior | Relevant happy path, edge cases, and failure path were considered. | Only the obvious path works. |
+| Tests | Tests are meaningful for behavior and would fail if the behavior broke. | Tests only assert mocks, snapshots, implementation details, or coverage numbers. |
+| Verification | Fresh relevant lint/typecheck/test/build/manual check evidence exists. | Success is inferred from code appearance or a subagent report. |
+| Regressions | Security, reliability, performance, accessibility, compatibility, and developer workflow are not worsened. | Any regression is unexamined or hand-waved. |
+| Reviewability | Diff is coherent and easy to review. | Reviewer must reverse-engineer why unrelated changes exist. |
+
+## Agent-Specific Failure Modes
+
+Brutally check for these before completion:
+
+- **Hallucinated API:** Did you verify signatures/options against local types, source, or official docs?
+- **Fake confidence:** Are you saying "should work" instead of citing command output or runtime evidence?
+- **Subagent trust:** Did you read changed files and verify independently instead of trusting a summary?
+- **Mock theater:** Do tests prove production behavior, or just that mocks were called?
+- **Coverage worship:** Coverage can reveal untested code; it does not prove test quality.
+- **Speculative abstraction:** Did you add generic hooks/options/classes before the actual need exists?
+- **Duplicate utility:** Did you search before creating a helper/component/schema wrapper?
+- **Generated-file edit:** Did you modify generated output instead of the canonical schema/generator/input?
+- **Silent behavior change:** Did any external behavior, API shape, data format, or command contract change without explicit approval?
+- **Unreviewable diff:** Did formatting churn or cleanup obscure the real behavior change?
+
+## Minimal Completion Procedure
+
+1. Re-read the user request and acceptance criteria.
+2. Inspect the diff, not just the files.
+3. Remove unrelated or speculative changes.
+4. Search for existing concepts before keeping new helpers/components.
+5. Check behavioral edges: invalid input, empty state, permission failure, error path, concurrency/race risk where relevant.
+6. Run the smallest relevant verification first; expand only if risk requires it.
+7. If tests were added or changed, run those tests directly and confirm they fail for the right reason when practical.
+8. Record exact evidence in the final response: command/check + result + remaining risk.
+
+## Source-Backed Principles
+
+- Google Engineering Practices: approve changes that improve overall code health; reject changes that worsen it even if they appear functional. Review design, functionality, complexity, tests, names, comments, style, consistency, docs, and every relevant line.
+- Martin Fowler on test coverage: coverage is useful for finding untested code, but high coverage is not proof of good tests.
+- OWASP Secure Coding Practices: quality includes input validation, output encoding, auth/session/access control, cryptography, error handling/logging, data protection, database/file/memory safety, and general secure coding.
+
+## Final Response Evidence Pattern
+
+Use this shape when reporting completion:
+
+```text
+Changed <what> in <file:line> to satisfy <requirement>.
+Verification: <command/check> passed/failed with <specific result>.
+Risk: <none known | untested area and why>.
+```
+
+Never say "done," "fixed," "passes," or "high quality" without fresh evidence.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>agent-code-quality-gate</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Diff reviewed, scope checked, tests/verification run, sources checked if APIs used</evidence>
+  <artifacts>Files reviewed or commands run</artifacts>
+  <risks>Remaining unverified paths or none</risks>
+</skill_result>
+```

package/dist/template/.opencode/skill/behavioral-kernel/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: behavioral-kernel
+description: Use when work starts drifting into silent assumptions, overengineering, drive-by refactors, or vague completion claims. Re-centers the agent on a compact Pi-native execution kernel with concrete anti-pattern examples.
+version: 1.0.0
+tags: [workflow, behavior, anti-slop]
+dependencies: []
+agent_types: [planner, worker, reviewer]
+tools: []
+---
+
+# Behavioral Kernel
+
+A short reset skill for non-trivial work when the larger prompt is getting noisy.
+
+## Kernel
+
+1. **Clarify before committing** — surface assumptions or ask instead of silently choosing.
+2. **Choose the smallest working change** — solve today's problem directly before inventing flexibility.
+3. **Keep diffs surgical** — change only what the request requires; log unrelated issues and keep moving.
+4. **Define proof before acting** — say how success will be verified before implementation, then run that proof after.
+
+## Apply the Kernel
+
+Before coding, write down:
+
+- the ambiguity or assumptions in 1-3 bullets
+- the smallest acceptable diff
+- what you are explicitly not touching
+- the verification command, test path, or evidence you will use
+
+## Drift Signals
+
+Stop and reload this kernel if you catch yourself:
+
+- adding abstraction for a single use case
+- changing adjacent code "while you're here"
+- postponing verification until the end
+- claiming completion without a named proof path
+- silently picking one interpretation from multiple valid readings
+
+## Recovery Move
+
+When drift is detected:
+
+1. Re-state the request in one sentence.
+2. Re-state the smallest working change.
+3. Re-state the proof path.
+4. Delete or avoid anything outside that boundary.
+
+## References
+
+- See [references/examples.md](references/examples.md) for Pi-native bad-vs-good examples.

package/dist/template/.opencode/skill/browser-testing-with-devtools/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: browser-testing-with-devtools
+description: "Use when verifying or debugging browser behavior with live runtime evidence: DOM state, console errors, network requests, screenshots, performance traces, or end-to-end user flows. Routes between Chrome DevTools and Playwright."
+version: 1.0.0
+tags: [browser, testing, debugging, verification]
+dependencies: [chrome-devtools, playwright]
+agent_types: [planner, worker, reviewer]
+tools: []
+---
+
+# Browser Testing with DevTools
+
+## Overview
+
+Browser testing proves what users actually experience. Use runtime evidence instead of assuming UI code works from static inspection.
+
+## When to Use
+
+- Building, debugging, or reviewing anything that runs in a browser.
+- Validating forms, navigation, responsive layout, accessibility-visible state, or screenshots.
+- Investigating console errors, network failures, hydration issues, or performance regressions.
+- Reproducing bugs that only appear in a real browser runtime.
+
+## When NOT to Use
+
+- Pure backend or CLI-only changes.
+- Unit-level logic that is faster and clearer to test without a browser.
+
+## Tool Routing
+
+| Need | Use |
+| --- | --- |
+| Cross-browser automation, screenshots, repeatable flows | `playwright` |
+| Live Chrome inspection, console/network/runtime state | `chrome-devtools` |
+| Bot-protected docs or static page extraction | `webclaw` |
+| UI implementation guidance | `frontend-design` |
+
+## Process
+
+1. Define the user-visible behavior to prove.
+2. Start the app or identify the target URL.
+3. Choose the lightest browser tool that can produce evidence.
+4. Capture initial state: page URL, screenshot or DOM snapshot, console/network baseline if relevant.
+5. Exercise the user flow with stable selectors or accessible labels.
+6. Capture final evidence: screenshot, DOM state, response status, console output, or trace.
+7. If a bug appears, hand off to `debugging-and-error-recovery` with reproduction steps.
+8. Record exact commands/tool actions and observed result.
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "The component compiles, so the browser is fine." | Runtime integration, CSS, hydration, and network behavior fail outside compilation. |
+| "A screenshot is enough." | Screenshots miss console errors, failed requests, and inaccessible states. |
+| "Manual clicking is faster." | Repeatable scripted flows create evidence and prevent regression. |
+| "The test is flaky, just wait longer." | Use condition-based waiting and prove the actual state changed. |
+
+## Red Flags
+
+- No browser evidence for UI behavior changes.
+- Ignored console errors or failed network requests.
+- Arbitrary sleeps instead of waiting for conditions.
+- Screenshots captured before animations/data loading settle.
+- Selectors coupled to fragile layout instead of accessible names or stable IDs.
+
+## Verification
+
+Before declaring browser work complete, provide:
+
+- URL or local command used.
+- Browser tool used and why.
+- Screenshots, traces, console/network output, or test result.
+- Any untested browsers/devices and residual risk.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>browser-testing-with-devtools</skill>
+  <status>completed|blocked|skipped</status>
+  <artifacts>Screenshot, trace, test file, console/network log, or none</artifacts>
+  <evidence>Commands/tool actions and observed browser result</evidence>
+  <risks>Untested browsers, flaky state, missing app server, or none</risks>
+</skill_result>
+```

package/dist/template/.opencode/skill/code-cleanup/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: code-cleanup
+description: Use after behavior is working but the diff is noisy, repetitive, over-complicated, or obviously AI-shaped - lock behavior first, then simplify the changed code and re-verify without expanding scope
+version: 1.0.0
+tags: [refactor, code-quality, workflow]
+dependencies: [verification-before-completion]
+agent_types: [planner, worker, reviewer]
+tools: []
+---
+
+# Code Cleanup
+
+## When to Use
+
+- Tests/build/typecheck already pass, but the changed code is clumsy
+- A feature works, but the diff contains duplication, over-nesting, dead code, or awkward naming
+- You want a final simplification pass before review or merge
+- You encountered a "broken window" (messy code, bad pattern, dead comment) that needs boarding up
+
+## When NOT to Use
+
+- Behavior is still broken or unverified
+- You are tempted to redesign architecture under the cover of "cleanup"
+- The cleanup would spread into unrelated files
+- You have not yet established how to prove nothing broke
+
+## Core Principle
+
+**Lock behavior first. Then simplify. Then re-verify.**
+
+No cleanup claim counts unless the same verification still passes after the cleanup edits.
+
+## Why Cleanup Matters: Software Entropy
+
+Left unrepaired, every messy piece of code gives permission for the next one. This is the "broken windows" theory from *The Pragmatic Programmer*: a bad design, wrong decision, or poor code left in place signals that quality doesn't matter — and more broken windows follow.
+
+AI agents accelerate this. A messy module invites the next AI to add more mess. A clean module with clear patterns invites the next AI to follow those patterns. Cleanup is not cosmetic — it's **entropy containment**. It's the difference between a codebase that decays with each AI pass and one that stabilizes.
+
+**When full cleanup is impossible, board it up.** Add a comment marking the issue, stub out the dead path, isolate the bad code behind a clear boundary. The goal is to contain the damage so it doesn't spread, even if you can't fix it right now.
+
+## Cleanup Targets
+
+Prefer cleanup that removes friction without changing behavior:
+
+- delete dead branches, unused variables, stale comments
+- collapse repeated logic when the abstraction is already obvious
+- simplify conditionals and nesting
+- improve names where the blast radius is small and verified
+- remove AI-ish filler comments, duplicated guards, or ceremony
+- **fix broken windows**: inconsistent patterns, dead TODOs, misnamed functions, formatting rot
+
+Avoid:
+
+- cross-system rewrites
+- new abstractions with speculative value
+- changing public APIs unless explicitly requested
+- moving many files just because structure feels imperfect
+
+## Process
+
+### Phase 1: Lock Behavior
+
+1. Identify the verification commands that prove the current behavior
+2. Run them and save the baseline result
+3. List the exact files that are eligible for cleanup
+
+### Phase 2: Create a Cleanup Plan
+
+Use a small table before editing:
+
+| File | Smell | Planned simplification | Risk |
+| ---- | ----- | ---------------------- | ---- |
+| ...  | ...   | ...                    | ...  |
+
+Rules:
+- Prefer deletion over abstraction
+- Prefer local simplification over shared utilities
+- If risk is medium or higher, make smaller passes
+
+### Phase 3: Simplify
+
+Apply cleanup in small, reviewable edits:
+
+1. Make one simplification
+2. Re-run the relevant verification
+3. Continue only if behavior remains locked
+
+### Phase 4: Re-verify
+
+Re-run the same commands used to lock behavior.
+
+Minimum acceptable output:
+- what was simplified
+- what was deleted
+- what verification was rerun
+- any remaining ugly areas intentionally left alone
+
+## Output Checklist
+
+- [ ] Baseline verification captured before cleanup
+- [ ] Only changed files or directly adjacent support files touched
+- [ ] Same verification rerun after cleanup
+- [ ] Simplifications reported concretely
+- [ ] No hidden architecture drift
+
+
+## Consolidated Simplification Workflow
+
+This is the canonical active simplification skill. It absorbs code-simplification. Only simplify after behavior is protected by tests or explicit verification. Avoid broad refactors bundled with feature work.
+
+
+## Agent-Skills Compatibility
+
+This skill is Pi's canonical equivalent of `code-simplification`: simplify working code while preserving exact behavior, respecting Chesterton's Fence, and re-verifying after cleanup.

package/dist/template/.opencode/skill/code-navigation/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: code-navigation
+description: Use when navigating unfamiliar code, tracing cross-file dependencies, or before editing — efficient code reading patterns that minimize tool calls and token waste
+version: 1.0.0
+tags: [workflow, code-quality, context]
+dependencies: []
+agent_types: [planner, worker, reviewer]
+tools: []
+---
+
+# Code Navigation Skill
+
+## When to Use
+
+- Exploring an unfamiliar codebase or module
+- Tracing a function call across multiple files
+- Understanding blast radius before a breaking change
+- Planning edits that touch multiple files
+
+## When NOT to Use
+
+- Simple single-file edits where you already know the location
+- Reading config or documentation files
+
+## Core Principle
+
+> Collapse multiple tool calls into fewer, smarter ones. Every unnecessary read or search wastes tokens and turns.
+
+## Choose The Right Navigation Tool
+
+- Use `srcwalk_search`, `srcwalk_read`, `srcwalk_files`, `srcwalk_deps` for symbol search, file reading, glob finds, and blast-radius checks
+- Use `srcwalk_callers`, `srcwalk_callees`, `srcwalk_flow`, `srcwalk_impact`, `srcwalk_map` for call graphs, orientation slices, impact triage, and repo maps — these are first-class Pi tools, no separate skill load needed
+- All tools are backed by the installed `srcwalk` binary via the `srcwalk.ts` extension
+
+## Navigation Patterns
+
+### Pattern 1: Search First, Read Second
+
+**Wrong** (3-6 tool calls):
+```
+glob("*.ts") → read(file1) → "too big" → grep("functionName") → read(file2) → read(file3, section)
+```
+
+**Right** (1-2 tool calls):
+```
+grep("functionName", path: "src/") → read(exact_file, offset: line-10, limit: 30)
+```
+
+Start with search (`srcwalk_search` or grep fallback) to locate, then read only what you need.
+
+### Pattern 2: Multi-Symbol Search
+
+When tracing a call chain (A calls B calls C), search for all symbols together:
+```
+grep({ pattern: "functionA|functionB|functionC", path: "src/" })
+```
+
+Or use `srcwalk_callers` for structural caller detection, or `srcwalk_flow` for a combined callers+callees+resolves slice.
+
+### Pattern 3: Don't Re-Read What You've Already Seen
+
+**Anti-pattern**: Search returns full function body, then agent reads the same file again.
+
+If search results already show the code you need, work from that output. Only re-read when:
+- You need surrounding context (lines above/below the match)
+- You need the exact content for editing (verify before edit)
+- The search result was truncated
+
+### Pattern 4: Blast Radius Check (Before Breaking Changes)
+
+**WHEN**: Before renaming, removing, or changing the signature of an export.
+**SKIP**: When adding new code, fixing internal bugs, or reading.
+
+Steps:
+1. `srcwalk_deps(path: "src/file.ts")` — find importers and downstream users
+2. `srcwalk_callers({ symbol: "symbolName", scope: "src" })` — find call sites with optional depth/filter
+3. Review each caller to assess impact
+4. Plan edits from leaf callers inward (furthest dependencies first)
+
+### Pattern 5: Context Locality
+
+When editing a file, search results from the same directory/package are more likely relevant. Pass context when available:
+- In grep: use `path: "src/same-module/"` to scope
+- In srcwalk_search: pass `context` param to boost nearby results
+
+### Pattern 6: Outline Before Deep Read
+
+For large files (>200 lines), get the structure first:
+```
+srcwalk_read(path: "src/large-file.ts")
+```
+
+This gives you structure and line ranges. Then read only the section you need.
+
+### Pattern 7: Follow the Call Chain (Not the File Tree)
+
+**Wrong**: Read files top-to-bottom hoping to understand the flow.
+**Right**: Start from the entry point, follow function calls:
+
+```
+1. `srcwalk_search(query: "entryPoint")` → find where it is defined
+2. `srcwalk_callees({ symbol: "entryPoint", scope: "src" })` or `srcwalk_flow` for call graph orientation
+3. `srcwalk_read(section: "line-range")` → drill into the interesting callee
+```
+
+## With Srcwalk Backend
+
+All navigation tools are native srcwalk_* tools. Available tools:
+
+| Task | Tool | Notes |
+|---|---|---|
+| `grep` + `read` | `srcwalk_search(expand: 2)` | Returns definitions with inline source — no second read needed |
+| `glob` | `srcwalk_files` | Adds token estimates per file |
+| Large file read | `srcwalk_read` | Auto-outlines, shows structure |
+| Direct callers | `srcwalk_callers` | Structural call-site evidence |
+| Transitive callers | `srcwalk_callers(depth: N)` | Multi-hop BFS up to 5 |
+| Forward call graph | `srcwalk_callees(detailed: true)` | Ordered sites with arg slots |
+| Function orientation | `srcwalk_flow` | Callers + callees + resolves |
+| Import + dependents | `srcwalk_deps` | File-scoped import evidence + heuristic |
+| Heuristic triage | `srcwalk_impact` | Follow up with callers for proof |
+| Repo shape | `srcwalk_map` | Token budgets + directory skeleton |
+
+**IMPORTANT**: Prefer `srcwalk_*` tools over built-in grep/glob/read for code navigation. Their expanded search results often include full source — do NOT re-read files already shown in search output.
+
+## Cost Awareness
+
+Every tool call has a token cost. Efficient navigation means:
+- Fewer tool calls per task
+- Less context consumed by redundant reads
+- More budget available for actual implementation
+
+**Target**: Find and understand any symbol in ≤3 tool calls, not 6+.
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---|---|
+| Read entire large file | Use outline first, then section read |
+| Search → read same code again | Work from search results directly |
+| Trace calls one-by-one | `srcwalk_callers` / `srcwalk_callees` or multi-symbol `srcwalk_search` |
+| Explore randomly | Start from entry point, follow calls |
+| Forget to check blast radius | Always check before signature changes |

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

@@ -0,0 +1,131 @@
+---
+name: code-review-and-quality
+description: Reviews code for correctness, regressions, security, maintainability, and goal completion. Use before merge, after subagent work, or when asked for a review.
+version: 1.0.0
+tags: [review, code-quality, verification]
+dependencies: [verification-before-completion]
+agent_types: [reviewer]
+tools: [srcwalk_search, srcwalk_deps, bash]
+---
+
+# Code Review & Quality
+
+## Overview
+
+Review is a bug-finding activity, not a compliment sandwich. The reviewer verifies that the goal is actually achieved and that the change does not introduce unacceptable risk.
+
+Core principle: findings first, with file:line evidence and impact.
+
+**Complexity is a correctness issue.** A change that works but adds structural complexity introduces risk: it makes future changes harder, slower, and more error-prone. The reviewer must assess structural quality alongside behavioral correctness.
+
+Use the **three complexity symptoms** as review lenses:
+- **Change amplification**: does a small future change require touching many places?
+- **Cognitive load**: does the reviewer (or AI agent) need to understand too much of the system to assess one change?
+- **Unknown unknowns**: is it obvious what needs to change for a new requirement, or are there hidden dependencies?
+
+## When to Use
+
+- User asks for review.
+- Before merge/ship.
+- After a worker or subagent reports completion.
+- Refactors, security-sensitive changes, API changes, migrations, concurrency, or auth.
+- Any change where complexity may have been introduced (always suspect).
+
+## When NOT to Use
+
+- Planning decisions before code exists; use `planning-and-task-breakdown`.
+- Implementation; reviewer must stay read-only.
+- Style-only commentary unless it hides a real bug.
+
+## Workflow
+
+1. Identify base and changed files.
+2. Read the diff and nearby context.
+3. Verify goal completion: exists, substantive, wired.
+4. Check key links: UI -> API, API -> database, form -> handler, state -> render, command -> effect.
+5. **Assess for complexity symptoms**:
+   - Is the interface of each new module as complex as its implementation? (shallow module — Ousterhout)
+   - Does a change leak information between unrelated modules?
+   - Would a future developer (or AI agent) know where to make the next change?
+6. Look for correctness, security, performance, compatibility, and maintainability issues.
+7. Run or inspect relevant verification when allowed.
+8. **Scan for broken windows** — does the change introduce or fix code that normalizes decay? Messy imports, inconsistent patterns, TODO rot, dead code?
+9. Report only actionable findings that the author should fix.
+10. If no findings, say so and list residual testing gaps.
+
+## Severity
+
+| Priority | Meaning |
+| --- | --- |
+| P0 | Critical: data loss, security break, crash on common path, release blocker. |
+| P1 | High: likely user-visible bug or serious regression. |
+| P2 | Medium: edge-case bug, maintainability hazard with concrete impact. |
+| P3 | Low: minor issue worth fixing but not blocking. |
+
+## Finding Template
+
+```text
+[P1] Title — path/to/file.ts:42
+Impact: What breaks and when.
+Evidence: Concrete code behavior.
+Confidence: 0.0-1.0
+```
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "The implementation looks reasonable" | Review behavior and wiring, not aesthetics. |
+| "The worker said tests pass" | Verify independently or mark as unverified. |
+| "This is probably pre-existing" | Only skip if evidence shows it was not introduced or worsened. |
+| "I should mention style too" | Style-only noise hides real findings. |
+
+## Red Flags
+
+- No file:line evidence for a finding.
+- Findings describe preferences rather than bugs/risks.
+- Review ignores acceptance criteria.
+- Created files are not imported or invoked anywhere.
+- Static placeholder responses or no-op handlers satisfy superficial tests.
+- Reviewer modifies files.
+
+## Complexity Red Flags
+
+- **New module with shallow interface**: lots of public methods/props for small implementation — it's not hiding complexity, it's exposing it.
+- **Information leakage**: one module exposes internal implementation details another module depends on.
+- **Change amplification signal**: a simple conceptual change would touch many files — the structure is fighting the domain.
+- **Cognitive load spike**: the diff requires understanding 5+ unrelated files to verify one change.
+- **Pass-through methods**: methods that do nothing but delegate with the same signature — a sign the abstraction boundary is wrong.
+- **Broken windows introduced**: messy formatting, dead imports, TODOs without tickets, inconsistent conventions within the same file.
+
+## Verification
+
+- Changed artifacts exist.
+- Implementations are substantive, not stubs/placeholders.
+- Key links are wired and exercised.
+- Findings are ordered by severity.
+- Verdict is explicit: correct or incorrect.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>code-review-and-quality</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Files reviewed, commands/checks run, findings with file:line evidence</evidence>
+  <artifacts>Reviewed files or diff range</artifacts>
+  <risks>Untested areas, unavailable base, or none</risks>
+</skill_result>
+```
+
+
+## Consolidated Review Workflow
+
+This is the canonical active review skill. It absorbs requesting-code-review, receiving-code-review, sprint-review, and reconcile responsibilities.
+
+Use it for:
+- self-review before claiming completion;
+- subagent or peer review routing;
+- skeptical treatment of received review comments;
+- severity-ranked findings with file/line evidence;
+- reconciliation between user intent, implementation, tests, and remaining risk.