Most automation prompts decay quietly. The repository changes, the team's standards move, and the output becomes less useful while the workflow keeps running. GitHub's new self-improvement feature turns the trail of outcomes into a proposal loop.
GitHub gives concrete feedback signals: whether people change labels applied by issue triage, accept code-review comments, or merge pull requests opened by an optimization automation. A separate improvement automation analyzes those signals and proposes changes to the original prompt, tools, or triggers.
The feedback signal is not the truth
A merged pull request can mean the automation was useful, or that a reviewer was in a hurry. An unchanged label can mean it was correct, or that nobody looked. Self-improvement makes those ambiguous signals operational, but it does not make them clean ground truth.
A self-improving workflow still needs a human who can say what improvement means.
Use the loop on a narrow task with a measurable acceptance signal. Review proposed changes as carefully as code, keep a record of why a prompt changed, and reject improvements that optimize activity instead of useful outcomes.
GitHub says improvement automations analyze signals such as changed labels, accepted review comments, or merged pull requests and notify the user before applying a proposal.
GitHub Changelog · Copilot Automations now learn from outcomes and self-improve ↗