自动化 on Svtter's Blog

RoboOmp: An AI Bot That Creates Its Own Pull Requests

Sat, 23 May 2026 18:00:00 +0800

Yesterday at the Oh My Pi (OMP) repository, I experienced something shocking: an AI bot didn’t just reply to my issue—it understood the problem, dug through the source code on its own, and opened a precise PR to fix the bug. The entire process took less than 5 minutes.

The Origin

When using OMP (a terminal AI coding agent), I discovered a UX issue: Ctrl+T can hide thinking blocks, but hiding them simultaneously turns off extended thinking entirely—not just hiding the display, but the model stops thinking altogether. Users assume they’re just “turning off the display,” but the actual effect is “turning off the brain.”

So I went to the OMP GitHub repository and opened a feature request: #1313.

RoboOmp’s First Response

Seconds after I submitted the issue, a bot called roboomp automatically replied. Not with template nonsense like “thanks for your feedback, forwarded to the product team.” It directly told me:

Most of this feature already exists—the hideThinkingBlock setting, Ctrl+T shortcut, and rendering path
The only missing piece is a CLI startup parameter
There’s a design decision that requires maintainer input: the coupling between hideThinkingBlock and hideThinkingSummary

And it provided exact filenames and line numbers: settings-schema.ts:663, input-controller.ts:755, stream.ts:583,697.

This wasn’t cobbled together from search results—it actually read the code.

I Pointed Out the Design Flaw

I replied with a comment explaining that this coupling is a footgun:

Users press Ctrl+T intending to reduce visual noise, but unknowingly turn off extended thinking, degrading model output quality
“Don’t want to see the reasoning process” and “don’t want the model to reason” are two different things that shouldn’t be tied together
The behavior varies across providers (MiniMax can’t turn it off, Anthropic/OpenAI can), so the same shortcut has inconsistent behavior

I also included the commit history that introduced this coupling for easier tracing.

It Opened a PR Itself

Then something unbelievable happened—roboomp replied with two consecutive comments and directly opened a PR: #1314.

The PR changes: 0 addition, 3 deletion. It only deleted three lines:

sdk.ts:1860 — agent initialization no longer assigns hideThinkingBlock to hideThinkingSummary
input-controller.ts:758 — Ctrl+T handler no longer links them
selector-controller.ts:273 — settings UI follows the same logic

The PR description included complete repro steps, root cause analysis, and fix approach. It even confirmed the commit archaeology I provided—45bd444 was indeed the commit that introduced this bug.

Why This Shocked Me

“AI can write code” isn’t news. Copilot, Claude Code, Cursor can all write code. But what’s different this time:

Complete Closed Loop

The entire process was zero-human:

I opened an issue → bot read the codebase, provided existing implementation status
I pointed out the design flaw → bot understood my point
It located the commit that introduced the bug itself, opened a PR that deletes just 3 lines

From issue to PR, no human did anything in between.

It Knows When to Wait

In its first reply, it said “Holding on implementation until a maintainer weighs in on the coupling question”—it knew this was a design decision requiring judgment and shouldn’t act autonomously. But when I clarified the coupling problem, it determined that waiting was no longer necessary and opened a PR directly.

The Fix Was Minimal

0 addition / 3 deletion. It understood what the minimal fix was—no refactoring, no abstraction, no gold-plating. Many human developers can’t do this.

What Is RoboOmp

RoboOmp is an AI bot deployed by can1357, the OMP repository maintainer. It’s not a GitHub Actions workflow (I checked the CI config to confirm), but an independent server-side agent:

Listens to GitHub Webhook events (issue creation, comments, etc.)
Reads source code through GitHub API, understands code structure
Uses LLM to analyze context, autonomously decides next steps—comment, label, open PR

From can1357’s GitHub profile, this person comes from a hypervisor/reverse engineering background (ByePg, NoVmp, NtRays), now working on AI agent platforms (agentx, hindsight). RoboOmp is likely the result of building exceptionally deep code understanding capabilities.

This project is not open source.

Are There Similar Open Source Projects

I looked around, and currently the closest ones are:

Project	Description
optio (962⭐)	AI coding agent workflow orchestration, task → merged PR
claude-code-github-agent	Hooks 40+ GitHub events, auto triage/review/fix, architecture most similar to roboomp
software-factory	Issue/PR-driven automatic development system

But honestly, none reach roboomp’s level. Most are still at the “receive webhook → call LLM → post comment” stage. RoboOmp is the first I’ve seen that can autonomously read source code, understand code structure, participate in design discussions, and make precise fixes.

What This Means

This made me realize that the capability boundaries of AI coding agents are expanding rapidly. A year ago we were discussing “can AI write correct code,” now the question is “can AI be a maintainer in open source communities.”

The capabilities roboomp demonstrated—reading code, understanding context, participating in discussions, making minimal fixes—are essentially what a junior maintainer does. If this capability continues to improve, the maintenance model of open source projects could undergo fundamental changes.

Think about it: what does an open source maintainer spend the most time on every day? Replying to issues, triaging bugs, writing small fixes. These are exactly what roboomp excels at. If every open source project could deploy such a bot, maintainers could focus their time on architectural decisions and community building.

Of course, current limitations are obvious—it can only handle problems with clear boundaries and well-defined scope. But this experience makes me believe that “AI maintainer” is not a distant future scenario, but something happening right now.

OpenCode's GitHub Actions Automation System: Engineering Practices Behind 27 Workflows

Fri, 22 May 2026 10:00:00 +0800

opencode is a 160k-star AI coding tool with 27 workflow files in its .github/workflows/ directory. This number is not uncommon for open source projects, but what’s truly interesting is not the quantity, but the scope these workflows cover: from conventional CI/CD to AI-driven community governance, they’ve done almost everything GitHub Actions can do.

This article analyzes the design of these workflows by category, discusses the pros and cons of this level of automation, and shares insights for our own projects.

Overview

The 27 workflows can be divided into four categories:

Category	Count	Purpose
CI/Testing	4	typecheck, unit tests, e2e, Nix builds
Release/Delivery	5	CLI release, container builds, VS Code extension, GitHub Action release
Automation/Bot	16	issue governance, PR compliance, AI code review, documentation updates
Docs/Other	2	statistics, Discord notifications

16 automation workflows account for 60% of the total. opencode doesn’t just use Actions to run tests and releases—it also entrusts community governance and code quality review to the automation system.

CI/Testing: Solid but Restrained

Four testing-related workflows:

typecheck.yml — Runs bun typecheck on PR and push to dev. Simple and direct, no unnecessary actions.

test.yml — Cross-platform test matrix (Linux + Windows), runs unit tests and Playwright e2e. Has concurrency control where new commits in the same PR cancel old runs. Test results generate JUnit reports uploaded as artifacts.

nix-eval.yml — Verifies Nix flake builds on four architectures (x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin). Mandatory package failures block the build, optional package failures are just warnings.

storybook.yml — Storybook builds for UI components, only triggered when storybook/ui-related files change. Path triggering avoids unnecessary runs.

Several noteworthy design choices:

concurrency group + cancel-in-progress: Multiple workflows use this pattern so the same PR doesn’t stack multiple runs. For a project receiving lots of community PRs, this saves significant CI resources.
Path triggering: containers.yml only runs when container files change, storybook.yml only runs when UI changes. Not everything runs on all commits.
Mixed Runner Strategy: Most workflows use Blacksmith’s third-party hosted runners (blacksmith-4vcpu-ubuntu-2404, blacksmith-4vcpu-windows-2025). Blacksmith is a GitHub Actions API-compatible accelerated runner service using custom infrastructure, significantly faster than GitHub’s free runners. Only lightweight bot tasks (close-issues, close-prs, compliance-close, pr-standards, deploy) stay on GitHub’s native ubuntu-latest. Compute-intensive compilation, testing, and releases all go through Blacksmith, simple script tasks use GitHub’s native runners, allocating resources by task load.

Release/Delivery: Full Platform Coverage

publish.yml is the most complex workflow, handling the complete release process in a single file:

Version number calculation
CLI build matrix (multi-platform, multi-architecture)
Windows code signing (Azure Signing)
macOS code signing (Apple Developer)
Electron app builds
npm publishing
GitHub Release creation
AUR (Arch Linux) publishing

One workflow covers distribution for CLI, desktop apps, npm packages, and Linux packages. This “release everywhere at once” pattern is user-friendly—regardless of platform, everyone gets the new version on the same day.

Other release workflows are split by artifact type:

publish-github-action.yml — Listens for github-v* tags, publishes GitHub Action to Marketplace
publish-vscode.yml — Listens for vscode-v* tags, publishes to both VS Code Marketplace and Open VSX
containers.yml — Multi-architecture container image builds, pushes to GHCR
release-github-action.yml — Creates pre-releases when github directory changes on dev branch

Tag triggering is a good practice: releases are explicit actions, not triggered by accidental code pushes. publish.yml automatically builds snapshots when pushing to ci/dev/beta/fix branches, but official releases require manual dispatch or tags.

Automation/Bot: AI-Driven Community Governance

This is opencode’s most distinctive feature. Among the 16 automation workflows, multiple directly call upon opencode’s own AI capabilities to handle community affairs.

Issue Management

triage.yml — When a new issue is created, opencode AI automatically triages it, adding labels and categories.

duplicate-issues.yml — When a new issue is created/edited, opencode AI analyzes whether it duplicates existing issues. Also checks whether it follows one of three issue templates and whether it contains AI-generated content. Non-compliant issues get a needs:compliance label.

compliance-close.yml — Every 30 minutes, checks issues/PRs with needs:compliance label and auto-closes if not fixed within 2 hours. Different prompt messages are given for issues vs PRs when closing.

close-issues.yml — Closes stale issues daily at 2 AM UTC.

These four layers form complete issue lifecycle management:

1

New issue → AI triage → duplicate/compliance check → compliance grace period → stale cleanup

PR Management

pr-standards.yml is one of the longest workflows, doing two things:

Title format check: Enforces conventional commits format (feat/fix/refactor/…)
Template compliance check: PR description must include required sections like issue references, change type, verification method

Non-compliant PRs get a needs:compliance label and auto-close after 2 hours. Team members and bots are exempt.

pr-management.yml — Checks for duplicates when PR is created, adds labels for community contributors.

close-prs.yml — Closes PRs older than 1 month with insufficient reactions daily at 10 PM UTC. Default threshold is 2 reactions, configurable.

AI Code Review

review.yml — Input /review in PR comments, opencode AI analyzes code and leaves review comments on specific lines. Only available to repo owner/members.

opencode.yml — Input /oc or /opencode in issue or PR comments to trigger opencode AI for more general interactions.

These two workflows demonstrate the “AI as collaborator” approach: not fully automatic code review, but on-demand triggering with humans making final decisions in the loop.

Documentation & Maintenance

docs-update.yml — Every 12 hours, checks recent commits and uses opencode AI to determine if documentation needs updates.

generate.yml — Runs code generation scripts when pushing to dev, auto-commits changes.

beta.yml — Syncs beta branch hourly.

stats.yml — Updates download statistics to STATS.md daily.

Design Patterns Worth Adopting

1. Layered Governance

opencode doesn’t stuff all automation into one workflow, but splits it by responsibility. An issue goes through four workflows in relay from creation to closure. Each workflow does one thing, combining to form a complete governance chain.

Benefits of this design:

Individual workflows can be modified or disabled independently without affecting other steps
Each workflow’s trigger conditions and permission scope are minimized
Easy to locate which step has problems when they occur

2. Compliance Grace Period

compliance-close.yml doesn’t close immediately upon detecting non-compliance, but gives a 2-hour grace period. This is reasonable for global contributors in different time zones—you might submit an issue while sleeping, and wake up with time to fix it.

3. AI at Decision Points, Not Execution Points

triage, duplicate detection, and code review all have AI make initial assessments, with humans making final decisions. But execution-level tasks like code builds and releases don’t use AI at all. This is a pragmatic division: AI excels at pattern recognition and initial classification, but not precise execution.

4. Explicit vs Automatic Triggers

Releases use tag triggers, maintenance uses schedule triggers, governance uses event triggers. Three trigger types correspond to three different automation trust levels: releases need human confirmation, maintenance can be scheduled automatic, governance needs immediate response.

Risks of Over-Automation

opencode’s automation system is comprehensive, but there are points to watch:

Community barrier: New contributors submitting issues must follow specific templates, PRs must conform to conventional commits, otherwise auto-closed after 2 hours. For a 160k-star project, this strictness is reasonable—it filters out many low-quality contributions. But for small projects, this level of automation would scare away potential contributors.

Maintenance cost: 27 workflows means 27 automation scripts to maintain. opencode has custom runners and dedicated scripts. If a workflow’s logic needs adjustment, maintainers need to switch between GitHub Actions YAML and custom scripts.

AI uncertainty: duplicate-issues and triage use AI for judgment, but AI can misjudge. A reasonable issue marked as duplicate and closed creates a negative experience for contributors. opencode uses grace periods and manual review to mitigate this, but the risk remains.

Insights for Our Projects

Not every project needs 27 workflows. But opencode’s layered governance and “AI at decision points” approach are worth referencing:

Start with issue templates: If the project starts receiving lots of duplicate or low-quality issues, add templates and duplicate checking first, rather than manually handling each one.
Use grace periods for compliance checks: Always give a grace period when auto-closing non-compliant contributions.
Use AI for classification, not execution: Let AI help triage issues and check PR formats, but don’t let AI auto-merge code or publish releases.
Use tag triggers for releases: This is the safest approach. Automatic snapshot releases are acceptable, official versions need human confirmation.
Add on demand: Add automation only when you have pain points. opencode’s 27 workflows weren’t built in a day, but gradually added as community scale grew.

Summary

opencode’s GitHub Actions system demonstrates automation practices for large-scale open source projects: CI/CD covers full platform releases, community governance uses multi-workflow relay processing, AI is applied to decision points like triage and review. The core of this system is not technical complexity, but three principles: “layered, grace periods, explicit triggers”. For our own projects, we don’t need to copy all 27 workflows, but these principles can be directly applied.