Enable automatic code review on Pull Requests (Vibe Kanban)

[dreaifekks]

Summary

This PR updates the OpenCode workflow to automatically trigger code reviews on Pull Requests.

Changes

• Added pull_request event triggers: opened, synchronize, reopened, ready_for_review.
• Updated the job's if condition to allow execution on pull_request events without requiring manual /oc or /opencode commands.

Motivation

To streamline the development workflow by automatically providing AI-powered code reviews for every PR, ensuring code quality and reducing manual intervention.

---

This PR was written using Vibe Kanban

[dreaifekks]

/oc

[dreaifekks]

/oc

[dreaifekks]

/opencode

[opencode-agent]

Executive Summary

• Small, focused workflow change to auto-run opencode reviews on PR events; overall looks aligned with the stated goal.

Statistics

• Files changed: 1 (.github/workflows/opencode.yml)
• Lines: +4 / -1
• Commits reviewed: 2

Strengths

• Clear expansion of event triggers to cover common PR lifecycle events.
• if condition now allows PR events without manual /oc or /opencode, matching the PR intent.
• Model identifier updated to the fully-qualified openai/gpt-5.2-codex.

Issues by Priority

• 🟡 Important: Potential missing secret access on forked PRs.
• 🟢 Suggestion: Guard comment-body access for non-comment events.

Detailed Findings

• .github/workflows/opencode.yml:13-18
  Could this job run on forked PRs and fail because OPENAI_API_KEY isn’t available to forked workflows? If so, would it help to add a guard like github.event.pull_request.head.repo.full_name == github.repository (or !github.event.pull_request.head.repo.fork) to avoid noisy failures?
• .github/workflows/opencode.yml:13-18
  When the event is pull_request, github.event.comment won’t exist; are we confident the expression short-circuits safely, or would a small guard (e.g., github.event_name != 'pull_request' && github.event.comment.body) be safer?

Security Review

• No new permissions added; existing id-token and read permissions unchanged.
• Potential secret exposure risk is more about execution on forks than direct leakage; do you want to constrain to same-repo PRs?

Performance Review

• Negligible impact; the workflow triggers more frequently but on a single lightweight job.

Testing Recommendations

• Would it be helpful to verify behavior on a same-repo PR and a forked PR to confirm expected secret handling and job execution logic?

Documentation Needs

• None identified; workflow change is self-contained.

Next Steps

1. Decide whether to guard against forked PRs (secrets) and/or comment-body access for non-comment events.
2. If you want, I can suggest a minimal YAML tweak for those guards.

opencode session  |  github run