One-off jobs are nice, but recurring automations are where your vibe-code agent pays for itself. Your Plane install runs in Docker — web, space, api, worker, database, and Redis containers the agent can inspect and restart. It can write small scripts, register cron jobs, listen for webhooks, and call Plane’s REST API with a token you generate from your profile. Here are ten workflows worth setting up, each explained with a request you can type as-is.

1. Close Plane issues when their PR merges

Teams waste minutes every day manually closing issues that a merged pull request already resolved. The agent sets up a small poller or webhook receiver that reads “Fixes PROJ-123” from merged PRs, moves the matching issue to Done through the API, and comments with the merge commit. The target state is configurable, so if your project closes work in a custom state like Ready for Deploy, the script uses that instead. Running on a five-minute cron, the board stays honest without anyone touching it. Say: “Every 5 minutes, check our GitHub repo for merged PRs that say Fixes PROJ-###, move those Plane issues to Done, and comment with the merge commit.”

2. Email yourself a weekly digest

Understanding the week should not require clicking through five screens. A Friday cron queries the database for issues opened and closed per project, anything overdue, and how far the active cycle is through its issues, then emails you a plain-text digest with links back to the filtered views. Ten lines of SQL plus a mail command, written and maintained by the agent. Say: “Email me every Friday at 5pm a digest per project: opened, closed, overdue, and how far the active cycle is through its issues.”

3. Escalate urgent issues that sit unassigned

An urgent issue with no assignee is a silent incident. A quarter-hourly check finds urgent issues older than an hour with no owner, comments asking for a volunteer, and mails your on-call address. The thresholds are easy to tune later — two hours instead of one, or high priority included — because the agent keeps the logic in one small script you can read. Say: “Every 15 minutes, find urgent issues with no assignee that are over an hour old, comment asking for a volunteer, and email the on-call address.”

4. Roll cycles over automatically

Every cycle ends with unfinished work, and moving it by hand is exactly the kind of chore that gets skipped when everyone is busy. The agent writes a scheduled job that, at midnight on the cycle’s end date, transfers unfinished issues to the next cycle, closes the old one, and logs how many issues carried over so the trend is visible over time. Monday starts with a clean, truthful board. Say: “At midnight when a cycle ends, move all its unfinished issues to the next cycle, close the finished one, and log a summary of what carried over.”

5. Pipe your support form into Intake

Customer bug reports die in inboxes. The agent stands up a tiny endpoint that accepts your contact form or support mailbox and creates an Intake issue in a SUPPORT project with the customer’s text and a label. It can also deduplicate by subject line so the same report mailed twice becomes one issue with a note, not two. Your triage flow then applies, but the intake step now happens without humans. Say: “Set up an endpoint that turns our support form submissions into Intake issues in project SUPPORT, tagged support, with the customer description.”

6. Roll up worklogs against estimates

If your team logs time on issues, the raw logs answer an important question nobody asks: where is work overrunning its estimate? A Monday cron sums worklogs per issue, flags anything where logged time is more than double the estimate, and reports the worst offenders per module. Use the flagged list as a Monday conversation starter, not a blame report — that is what keeps people logging honestly. Say: “Every Monday, total the worklogs per module and flag any issue where logged time is more than double its estimate.”

7. Relay state changes to Slack or Discord

Plane supports webhooks on issue events, and the agent can write the small receiver that forwards the interesting ones to your chat channel. Restrict it to the transitions people care about — In Review and Done — or the channel drowns in noise within a day. The receiver checks the webhook secret, filters by state ID, and formats a compact one-liner per event. It runs on the same server, so there is nothing external to subscribe to. Say: “Post to #eng whenever an issue moves to In Review or Done, with the issue ID, title, and assignee.”

8. Nightly blocked-chain check

Issues get marked blocked, their blockers get finished, and nobody tells the assignee, who assumes the work is still stuck. Once a night the agent finds issues whose blocking relations are all completed but which still sit in a blocked state, and leaves a comment telling the assignee they can resume. It is a short query against the issue relation tables, plus a comment through the API. Say: “Each night, find issues whose blockers are all done but that are still marked blocked, and comment telling the assignee they can pick it back up.”

9. Keep labels synced with GitHub

When your code lives in GitHub and your planning lives in Plane, drifting labels make cross-referencing painful. A nightly job copies repo labels into Plane, creating the missing ones and reporting which Plane labels have no GitHub counterpart for you to clean up. It preserves colors where they already match and only overwrites when told to. Keep the sync one-way; two-way merging creates conflicts nobody can debug. Say: “Every night, copy labels from our GitHub repo into Plane — create any that are missing and report which Plane labels have no GitHub counterpart.”

10. Bookkeep releases on version tags

Release day bookkeeping — commenting “shipped in v2.4.0” on forty issues — is the kind of task that gets done sloppily or not at all. The agent watches for tags, either by polling the repo on a cron or by receiving a CI webhook, and when one appears it comments on every issue in the matching module and marks the module complete. Issues closed months later stay traceable to the exact release that shipped them. Your changelog writes itself. Say: “When I tag v2.4.0, comment ‘shipped in v2.4.0’ on every issue in module Release 2.4 and mark the module as complete.”

A sensible pattern: pick one workflow, watch it run for a week, then add the next. Each of these is a small script plus a cron line or a webhook — easy to inspect and easy to remove when your process changes. Ready to try them? Get Plane on OpenSysLab.