KeelenIntegration · GitHub Issues
Add a label. Keelen turns the issue into a Request.
Add a label to a GitHub issue. Keelen turns it into a Request. It checks the work you already have. It can ask you for more detail. Any code change follows your rules. Those rules cover review and merge. Keelen only merges when your merge policy allows it and CI is green. The integration is off by default. You turn it on in Settings.
Keelen reads open issues in your repo. Only issues with your label count. It writes each one to a ledger. Then it files one Request at a time. Daily caps bound each project and each workspace. A cap on work in flight holds the line. A busy repo cannot file work without end.
- One labelled issue becomes a Request. It joins your normal workflow.
- You pick the label. You can change it later.
- Comments and close are two settings. Both can stay off.
- Caps bound each day. A zero value turns filing off.
How a labelled issue becomes reviewed work
Turn the integration on and choose a label
Open the project's Settings. Find the GitHub Issues card. Turn intake on. Set the label Keelen should watch. The default label is keelen. Turn comments on or off. Choose whether Keelen may close the issue after the work merges.
Add the label to an open issue
Put the label on an open issue in the bound repo. Keelen reads open issues only. It skips pull requests.
Keelen files a Request
Keelen checks the issue again. It must still be open. It must still carry the label. Then Keelen adds the issue as a Request. The issue text is not trusted. It never gives Keelen orders.
The project handles the Request
Intake sorts the Request. Planning sets tasks and acceptance criteria. Runs make changes in their own VMs. Review the pull request and its checks. Merges follow your policy and green CI.
Comments and closure are optional
With comments on, Keelen posts short notes. It notes picked up, pull request opened, and merged. Close is a separate setting. Keelen closes the issue only when the merge rule holds. The close setting must also allow it.
Off by default and under your control
Nothing is read until an owner turns it on. The label is yours. Change it and Keelen starts the read cursor over. Turn intake off and new claims and writes stop. A request that already started may finish.
Budgets run before work, not after
Keelen checks the caps before it files. A project cap and a workspace cap bound each day. A cap on work in flight holds the line. A zero value turns filing off. Filing also waits behind the billing gate. A paused tenant spends nothing.
Issue text is data, not instructions
A label lets Keelen read an issue for triage. It does not let the issue give orders. Keelen masks secrets and personal data. It caps the stored text. It keeps that text in a quoted block. The token Keelen mints can read issues. When you allow it, it can write issues too. That token never reaches a dev machine.
Turn on labelled issue intake
Create a project. Connect the repo. Turn on GitHub Issues in Settings. Pick a label. An open issue with that label can become a Request.
FAQ
Is GitHub issue intake on by default?
No. It is off by default. An owner turns it on in Settings. The owner also picks the label Keelen watches. Until then Keelen reads no issues.
Which issues does Keelen pick up?
Open issues in the bound repo. They must carry the label you chose. Keelen skips pull requests and closed issues. An issue you label later is read on a later pass.
Does Keelen write to my GitHub issues?
Only when you allow it. Comments and close are two settings. Both can stay off. With comments on, Keelen posts short notes. Close needs the merge rule and the close setting.
Does the integration need extra GitHub permission?
Yes. Keelen asks GitHub to read issues. It asks to write them when comments or close are on. Your GitHub App may ask you to consent once. If consent is missing, the card says so. No issue is read or written.
When does Keelen merge or close the issue?
Merges follow your policy and green CI. Keelen closes the issue only after all linked work has merge proof. Every linked task and pull request must be done. The close setting must allow it. A branch alone never closes an issue.