For software teams
The backlog nobody gets round to.
Kaer reads your repository, makes the change on its own computer and opens a pull request. Your CI runs on it like on anyone else's, and an engineer reviews and merges it.
Work teams hand over
The jobs that are clear enough to describe in a paragraph and dull enough to sit in the backlog for months.
Dependency upgrades
Bumps the library, fixes the code that breaks against the new version and updates the tests that need it.
Waits for you: the merge. Your team reviews the pull request.
Tests for the untested module
Reads the code that nobody wants to touch and writes the tests it should have had.
Waits for you: the merge.
Wide, boring refactors
Renames, moved modules and every call site that goes with them, following the conventions already in the codebase.
Waits for you: the merge.
Internal tools
The admin page or tracker someone keeps asking for, built and hosted by Kaer, or added to your repository.
Waits for you: publishing. It goes live when you press publish.
How it fits your workflow
- 01Connect GitHub
You grant the connection yourself and can revoke it at any time.
- 02Describe the change
In a sentence or a ticket. It reads the codebase before it writes anything.
- 03Review the pull request
Same branch rules, same CI, same reviewers as any other change.