Add opencode workflows

[danlapid]

No description provided.

[ask-bonk]

This PR adds OpenCode GitHub Action workflows for automated PR review and comment-triggered agent interaction, alongside a reviewer prompt file.

Issues found (ranked by severity):

1. Medium -- /oc trigger is an overly broad substring match. GitHub's contains() is a case-insensitive substring match, so any comment containing /oc anywhere -- e.g. /docs, /october, block/occurs -- will trigger the workflow. The existing Bonk workflow avoids this by using a mentions input parameter on the action itself (which presumably does more precise matching). Either use a longer unique prefix or use startsWith() + word boundary logic.

2. Low -- Both the Bonk and OpenCode review workflows will fire on the same PR events. new-pr-review.yml triggers on opened and opencode-review.yml triggers on opened, synchronize, reopened, ready_for_review. Every new PR will get two AI reviews (one from Bonk, one from OpenCode). If this is intentional for a comparison/trial period, it's fine but worth noting. If not, the existing new-pr-review.yml should be removed or the triggers should be made mutually exclusive.

[ask-bonk]

Medium: contains(github.event.comment.body, '/oc') is a substring match -- it will fire on any comment containing /oc anywhere (e.g. /docs, /october, block/occurs). The existing Bonk workflow uses a mentions input on the action to handle this correctly. Consider using a similar mechanism, or at minimum use a less ambiguous trigger like /opencode only:

Suggested change

	if: |
	github.event.sender.type != 'Bot' &&
	(contains(github.event.comment.body, '/oc') ||
	contains(github.event.comment.body, '/opencode'))
	if: |
	github.event.sender.type != 'Bot' &&
	contains(github.event.comment.body, '/opencode')

[ask-bonk]

Bonk workflow was cancelled.

View workflow run · To retry, trigger Bonk again.

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

This PR adds OpenCode GitHub Action workflows (auto-review on PRs and comment-triggered agent) plus a reviewer prompt file that's nearly identical to the existing Bonk one.

Issues posted as review comments:

1. Medium -- /oc trigger is an overly broad substring match. contains(github.event.comment.body, '/oc') will match any comment containing that substring anywhere (e.g. /docs, /october). Suggested fix: drop the /oc shorthand and keep only /opencode, or use the action's mentions input like the Bonk workflow does.

2. Low -- Duplicate auto-review on new PRs. Both new-pr-review.yml (Bonk) and opencode-review.yml (OpenCode) will fire on opened PRs, resulting in two separate AI reviews. Fine if this is an intentional comparison period, but worth being explicit about.

github run

[opencode-agent]

I don't have GitHub CLI access to post review comments. I'll provide my review inline here instead.

I'm OpenCode, and I've done a quick review of your PR.

Summary: Adds two GitHub Actions workflows for OpenCode integration — an automated PR reviewer (opencode-review.yml) and a comment-triggered assistant (opencode.yml) — along with the reviewer prompt (opencode_reviewer.md).

Issues (ranked by severity):

1. Medium — /oc trigger is too easily matched by accident (opencode.yml:17-18)

   The contains(github.event.comment.body, '/oc') check is a substring match. It will fire on any comment containing /oc as a substring — e.g., "ad/hoc fix", "/occur", "bl/ock", "/occasional". This will spin up a runner and spend API credits on false triggers. The existing Bonk workflow avoids this by delegating mention-matching to the action's mentions parameter rather than using contains() in the if condition.

   Suggested fix: Either tighten the pattern (e.g., check for /oc or /oc\n with startsWith), or remove the contains check from the if condition and rely on the OpenCode action to filter by mentions (if it supports a mentions parameter like Bonk does). At minimum, dropping the /oc shorthand and keeping only /opencode would significantly reduce false positives.

2. Low — Missing permissions parameter in opencode-review.yml (opencode-review.yml:37-44)

   The comparable new-pr-review.yml passes permissions: write to the Bonk action. The OpenCode review workflow doesn't pass any permissions parameter. If the anomalyco/opencode/github action requires this to post review comments, the workflow will silently fail to comment. Verify whether the OpenCode action needs this parameter.

3. Low — Missing forks: 'false' parameter in opencode-review.yml (opencode-review.yml:37-44)

   The if condition already gates against fork PRs (line 9), which is good. However, the existing Bonk review workflow also passes forks: 'false' to the action as a defense-in-depth measure. If the OpenCode action supports a similar parameter, it would be worth adding for consistency.

opencode session  |  github run

[ask-bonk]

Bonk Review

Findings from automated review (generated by an AI assistant -- may contain errors):

Issues

[LOW] Unused include in export-loopback.c++
#include <workerd/io/features.h> at line 7 is not used anywhere in the file. FeatureFlags and nothing else from features.h appear in this translation unit. This was also flagged by jp4a50 -- looks like it may be left over from an earlier approach.

[LOW] versionRequest parameter silently ignored in server.c++ override
In server.c++:3294-3312, the getSubrequestChannel override accepts the new versionRequest parameter but never uses it. The function only acts on props -- if props is kj::none, it simply adds a ref to the existing channel. The PR description acknowledges this ("workerd's server implementation currently ignores this information"), but it would be good to add a brief inline comment (e.g. // TODO: versionRequest is currently ignored by workerd) so future readers don't have to check the PR description to understand this is intentional.

[LOW] Test only verifies the version info doesn't break anything, not that it's propagated
The test at server-test.c++:4453 calls ctx.exports.default(...) with various version shapes and then checks that service.version returns the constant getter value. This confirms the call doesn't blow up, but since the version is silently ignored in workerd, the test doesn't verify any version-related behavior. This is noted in the PR description as intentional, which is fine for now. jp4a50 suggested also passing props and undefined in the test -- that feedback still appears unaddressed.

Observations (non-blocking)

• The jsg::Optional<kj::Maybe<kj::String>> cohort type correctly models the JS semantics where cohort can be absent (undefined), explicitly null, or a string. This follows the established codebase pattern (e.g. actor.h:172).

• The compat flag approach (two separate JSG_CALLABLE registrations gated on flags.getEnableVersionApi()) cleanly preserves backward compatibility. The discussion between jasnell and sohpeach about whether to have a single call method vs. two methods is resolved -- the current approach avoids subtle type-checking changes for existing users who don't have the flag enabled.

• The VersionRequest::clone() method is well-implemented using cohort.map(...).

• The OptionsWithVersion::Version and OptionsWithVersion structs are correctly registered in EW_EXPORT_LOOPBACK_ISOLATE_TYPES.

• Generated TypeScript snapshots look correct and match the C++ type definitions.

---

This review was generated by an AI assistant and may contain inaccuracies. Please verify any suggestions before applying them.

[jasnell]

for consistency, you could have this point to the existing .opencode/skills that I've added. There are some there for kj-style, workerd-api, workerd-safety. And I just opened another PR that adds rust, js, and ts checklists.

I did primarily write those for a local workflow but they ought to work for CI as well.