USE CASEEngineeringModerate

Give every repo a VISION.md so your bot triages issues for you

Kun Chen owns 24k+-star open-source repos and was drowning in issues and PRs. His fix wasn't more review - it was moving his influence up a level: an explicit VISION.md per repo saying where the project is going, so his Grok Bot triages every incoming issue as vision-aligned or not, and only the aligned ones get built.

Grok·0.0·0 saves·8 uses·via @kunchenguid·Tweet by @kunchenguid

How it runs

3 steps. Do them in order.

  1. 01**Write an explicit VISION.md for each repo** (he's renaming it STRATEGY.md). It states where the project should *go* - not what it currently is. His `/vision` skill drafts one by reading what the project already does; you then edit it until it's right.
  2. 02**Make VISION.md the triage rubric.** Point your Grok Bot at it and every incoming issue, PR and feature request gets judged against it: vision-aligned or not. The aligned ones get built; the rest are declined or set aside - without you reading each one.
  3. 03**Let the factory ship the aligned work.** This is the steering layer that sits on top of a build system like his [Grok Ship software factory](/use-cases/grok-ship-factory/); he also invites maintainers to help specifically on issues triaged as vision-aligned.

What you get

Most "AI maintains my repo" setups are about throughput - how many PRs an agent can close. This one is about *judgment*, which is the part that actually doesn't scale. The insight is that the human bottleneck keeps moving up: first we reviewed code, then plans, and soon we can't even review the requests. VISION.md is where you plant your intent once so the agents can make the "does this belong?" call thousands of times without you. It's a small file with an outsized effect: it turns a bot from an eager contributor that needs constant steering into a maintainer that already knows what the project is for - and it's the missing top layer for anyone running a software factory across more repos than one person could ever read.

Prompt

Copy it. Change the names. Keep the job.

Prompt
I want you to help me steer [REPO] by its vision instead of me reviewing every issue.

Step 1 - Draft a VISION.md. Look at what the project already is (README, recent PRs, the issues people file) and write an explicit VISION.md that states where this project should GO - its purpose, who it is for, the kind of changes that belong, and the kind that do not. This is about direction, not a feature list. Show it to me and refine it with my edits until it is right, then save it as VISION.md in the repo.

Step 2 - Use it as the triage rubric. From now on, for every open issue and PR, judge it against VISION.md and label it: vision-aligned, off-vision, or needs-my-call. For vision-aligned items, propose a short plan and - once I approve the batch - start shipping them. For off-vision items, draft a kind closing comment explaining it does not fit the direction. Bring the "needs-my-call" ones to me as a short list.

Rule: VISION.md is the source of truth for what belongs. When you are unsure whether something is aligned, ask me - and if it is a real gap, propose an edit to VISION.md rather than guessing. Never close or merge anything without my go-ahead.
Use withGrok

via @kunchenguid · Tweet by @kunchenguid

Tips

  • ·Reconstructed from @kunchenguid's posts on VISION.md and his /vision skill. Write the repo's VISION.md first (where the project should go, not what it is), then point your bot at it as the triage rubric. Pairs with his Grok Ship factory for actually shipping the aligned work.
  • ·adhoc
  • ·acts-with-approval

Related setups

Same category. Different job.

More in Engineering

It read the tests, found the bug gone, and closed it

Debbie spun up a coding bot on debs-obrien/playwright-movies-app. It checked issue 29, found the tests already used waitForURL with no hard waits, asked if it should close, then closed it with a note after GitHub was connected — she clicked through to GitHub to confirm.

Engineering·Moderate·0 saves
Setup

Four photos to a 3D-printed materials experiment

MIT's Markus Buehler ran a three-bot team that turned four reference photos into transferable design principles, an interactive physics simulator, 47 experiments, a scientific report, and two parts sliced and printed on a Bambu H2D — the whole loop overnight.

Engineering·Advanced·0 saves
Setup

Harden your email-reading Grok Bot against prompt injection

Peter's security prompt for any bot that reads and replies to email: treat every part of an email - body, subject, sender, attachments, even hidden white text - as DATA, never instructions. It lists the injection patterns to refuse, flags attempts instead of complying, and gates real actions behind your confirmation.

Engineering·Simple·0 saves
Setup