docs(code-review): add integrations section pointing to open-code-review

[lizhengfeng101]

Summary

Instead of adding a standalone skill, this adds a lightweight "Integrations" subsection under "See Also" in code-review-and-quality/SKILL.md, pointing users to the Open Code Review CLI and its Claude Code skill for tool-augmented review on large changesets.

This follows the alternative approach suggested by @nucliweb in #327 (comment) — keeping the pack self-contained and zero-dependency while still letting users discover additional tooling.

Changes

• Added an "Integrations" subsection under "See Also" in skills/code-review-and-quality/SKILL.md
• Removed the standalone skills/open-code-review/ directory
• Reverted all changes to README.md, AGENTS.md, and docs/getting-started.md

[nucliweb]

Thanks for this, the skill itself is well-crafted and the underlying tool looks genuinely solid. Before it goes further I want to raise a scope question that I think is the real decision here, and it is ultimately a maintainer call.

My concern is fit, not quality. The skills in this pack encode a process, a tool-agnostic way a senior engineer approaches a task. This skill is a different genre: it teaches the agent to operate one specific vendor CLI and format its output. The review intelligence lives inside ocr, not in the skill, so what we would be adding is essentially a usage manual plus an output formatter for a third-party product.

Three things make me lean against adding it as a first-class skill:

1. It overlaps with code-review-and-quality and frames it as the lesser option. The skill's core message is "the built-in review is only good enough for small changes, install this external tool for real work." Positioning one of the pack's own skills as inferior to a third party reads, even if unintentionally, as promotion.
2. Maintenance coupling. The skill is tied to another project's CLI surface (--audience agent, ocr config, env vars). When that interface changes, the skill rots, and a pack that sells itself as self-contained and zero-dependency inherits the cost of documenting someone else's tool.
3. The vendor already ships this. open-code-review is distributed as a Claude Code plugin and skill by its own authors, so re-hosting it here is redundant, and it invites the same request for every other third-party review CLI, which dilutes what makes this pack distinctive.

The browser-testing-with-devtools precedent does not quite apply: DevTools gives the agent a capability it otherwise lacks (observing a running browser), whereas this is a different vendor's take on a job an existing skill already covers.

That said, the insight behind the tool is worth keeping. The failure mode it targets is real: prompt-only agents do skip files on large changesets and drift on line numbers. A lighter-touch way to capture that without taking on a vendor dependency would be a short "See also / Integrations" note in code-review-and-quality pointing to ocr (and to the authors' own skill) for teams that want tool-augmented review. Happy to help shape that if it is useful.

(Separately and minor: the description uses a YAML folded scalar >, which the repo's frontmatter parser does not handle, so the validator currently reads it as a single character rather than the real text. Worth switching to a plain single-line description regardless of the outcome above.)

[lizhengfeng101]

Thank you for the thoughtful and detailed feedback, @nucliweb — really appreciate you taking the time to lay out the reasoning so clearly.

We want to sincerely apologize if our description came across as positioning code-review-and-quality as a lesser option. That was never our intention, and we're sorry for the impression it gave. The built-in skill is excellent on its own, and we have great respect for the work that's gone into this pack.

We fully accept the suggested alternative approach. A short "See also / Integrations" note in code-review-and-quality pointing to ocr and our own skill/plugin sounds like the right fit — it keeps the pack self-contained while still letting users discover additional tooling if they want it. The goal has always been to give users more choices with a low barrier to entry, and a pointer achieves that without the maintenance coupling or scope concerns you raised.

We'll close this PR accordingly. If there's anything we can do to help shape that integrations note, happy to contribute.

[lizhengfeng101]

Hi @nucliweb 👋

Thanks again for the excellent feedback on the original approach — it was spot on.

We've reworked this PR to follow the alternative you suggested: a short Integrations section in code-review-and-quality/SKILL.md that points users to ocr as a tool-augmented option for large changesets. No standalone skill, no vendor dependency, just a lightweight pointer.

We also rebased onto the latest main to resolve the merge conflict that had come up.

Would you be able to take another look when you get a chance? Happy to adjust anything if the wording or placement needs tweaking. Thanks!

[addyosmani]

This is softer than the original standalone-skill version, and I get the intent of pointing people at tools that complement the review workflow. But it's still a link out to a specific third-party product from inside a core skill, which is the kind of mention I've been keeping the pack clear of, and once one integrations pointer goes in others follow. I'd rather not open that door in the skill files themselves. Leaning pass, but tell me if you think this one clears a bar the rest don't.

[federicobartoli]

I share the pass instinct: keeping skill files free of product-specific links is the only rule that doesn't invite a queue of similar PRs, and any exception becomes the precedent the next one cites.

One factual note from checking the diff: the "Claude Code skill" link points to anthropics/claude-code-installed-skills, which currently 404s. A live example of the link-rot risk in hosting pointers to surfaces we don't control.

@nucliweb you shaped this version, so I'd like your take before we decide.

[lizhengfeng101]

Hi everyone 👋

Thanks for all the thoughtful feedback on this PR — the concerns about scope, vendor coupling, and the "integrations pointer" precedent were well taken.

We've taken a different approach in #408 that addresses the core issues raised here:

• Independent skill (skills/open-code-review-delegate/SKILL.md) — no modifications to code-review-and-quality or any existing skill file
• Delegation mode only — OCR provides deterministic engineering (file selection, rule resolution); the host agent drives the actual review with its own LLM. No vendor LLM dependency on the OCR side.
• Process skill, not product manual — follows the same pattern as browser-testing-with-devtools: an external tool gives the agent a capability it otherwise lacks (reliable file-level coverage for large changesets), rather than replacing the agent's judgment
• Minimal CLI surface — only two commands (delegate preview and delegate rule), keeping maintenance coupling low

This PR can be closed in favor of #408. Happy to adjust anything there based on further feedback.

[lizhengfeng101]

@nucliweb @addyosmani @federicobartoli Would appreciate your review on #408 when you get a chance. Thanks!

[federicobartoli]

Thanks for the graceful way you handled the feedback here, and for reworking the approach into #408.

Closing this one as you suggested, since it's superseded by #408 and the integrations-pointer route was the one Addy was leaning to pass on anyway. The scope and vendor-coupling discussion in this thread stays useful as context for reviewing #408, so we'll pick it up from there.