A good GitHub issue usually comes at the wrong moment: while you're on your phone, in a meeting, or in the middle of testing. If you then open GitHub and try to write a title, description, repro steps, and expected behavior, it's very easy to give up or leave a note that later doesn't have enough context.
That's why I built a small workflow with OpenClaw and Signal. The goal isn't "AI that manages the project," but something much more modest: capture a short note while it's fresh and turn it into a good enough issue without manual copy-pasting.
A workflow that works because it's intentionally narrow
The system has four parts: a dedicated Signal number, a sender allowlist, an OpenClaw agent with limited GitHub access, and a custom skill that knows how to write an issue. No broad permissions and no open "do what you think is needed" space.
Typical message
"On mobile checkout, an error toast disappears before the user can read the message. Happens after a failed card. Need to check timeout and payment retry."
The skill turns that into a title, problem, context, repro steps, expected behavior, risk, and suggested labels. The agent doesn't try to solve the bug. It just prepares a quality intake.
The most important part is the limitation of permissions
With this kind of automation, it's not enough to ask "can the agent do this?" It's more important to ask "what happens when it gets bad input or when the model draws the wrong conclusion?" That's why the agent has a narrow role: it creates a draft issue, doesn't touch code, doesn't change milestones, and doesn't assign priority without rules.
- Signal senders are limited by an allowlist.
- GitHub token has minimal permissions for issue intake.
- Skill defines required fields and issue tone.
- For unclear notes, the agent asks for clarification instead of making up details.
Where the real value is
The value isn't in AI "writing issues." The value is that small problems don't get lost, and the team gets a consistent format that's good enough for triage. That reduces the mental cost of reporting a bug and increases the chance the problem gets fixed while the context is still fresh.
This is a good example of engineering productivity: you're not introducing a big platform, you're removing one repetitive friction from the process. Such small automations often give a better return than large "AI transformations" that nobody uses.
What I'd do in a team setting
For team use, I'd add three things: review of the first dozen issues before automatic opening, a clear label policy, and measurement of how many drafts actually end up in the backlog. If most automated issues need manual rework, the skill needs improvement.
An AI workflow must be measurable. If you don't know what it improved, you probably just moved work from one tool to another.
Josip Budalić
HOTFIX team
Josip runs HOTFIX d.o.o. and works on software architecture, AI-assisted development workflows, codebase modernization, and practical software delivery.