TL;DR: An experiment automating a progressive web app's maintenance by hooking mobile data collection directly to an issue-driven AI coding pipeline.
With the advent of coding agents like ClaudeCode and OpenCode, I have been able to convert many of my ideas into working applications. I have now ended up with a large number of applications that I regularly (but infrequently) use where the code does not change often.
There does come that occasional bug or feature that I want. At those instances, I find myself bound to my workstation, needing to download and build the app, and then stare at the LLM generating one token after another till the work is done.
I wanted to see if we could move the entire maintenance loop for a such projects off a local dev machine into GitHub issues with an hosted LLM orchestrating the work. Shifting the entry point to an issue forces a clear discipline of making my prompts traceable while giving me the flexibility to "work from anywhere".
The project
I tried this out on a project that was born out of curiosity. I recently visited the capital and found a lot of cars with a diplomatic license plates. With a kid is interested in international politics (thanks to Model UN), I thought this would be a fun way for them to understand what country the plate was mapped to, and learn about the country.
I built the first version using Claude code, but have not changed the code much. Occasional bugs popped up, so I wanted a setup where I could add changes purely using Github issues.
The Pipeline Automation
The repository uses GitHub Actions to orchestrate mutations and dependencies without local execution environments:
- First Run: Triage relies on a strict label validation script. The workflow immediately strips labels unless they originate from a verified account, preventing unauthorized API usage and token resource depletion from random public traffic.
- AI Generation: The orchestrator packages the issue text with repository formatting rules and testing constraints. It sends this prompt payload to an asynchronous coding agent to generate the change and open a pull request.
- Inline Consolidation: Because GitHub suppresses secondary webhooks for standard tokens, a single workflow sequence handles the full chain: waiting for required checks, squash-merging, closing the issue, and initiating the final deployment.
With these three in place, I was able to open a github issue and label it. The prompt would then hand it over to Jules that would create a pull request, and merge and deploy after a successful run.
Limitations
Operating a one-shot pipeline revealed structural limitations compared to interactive, command-line local development.
Prerequisite Research: Debugging mid-flight is not possible in this structure. I had to manually look up data variants on Google first to feed the issue template an exact, error-free description. A local command-line tool allows you to react incrementally to unexpected parser errors, adjusting the codebase iteratively based on stack traces. Here, any missing validation rule in the initial prompt results in a failed build that requires a new issue to resolve.
Visual Layout Blindness: The pipeline pushed and merged valid script modifications that frequently broke the interface layout. Because I was not actively inspecting terminal diffs or loading local dev servers, visual regressions went unnoticed until the code was live on the main branch. The system could easily optimize data parsing arrays while breaking CSS alignment, highlighting the risk of automated merges based purely on passing unit tests.
Future Ideas
We could make a layout-safe workflow by integrating structural snapshot tests directly into the pre-merge checks. I may be missing an existing GitHub action constraint, but running a headless visual check before the automated squash-merge would catch the interface bugs early. We should also look into configuring custom repository secrets to allow standard deployment webhooks to fire after an automated merge closes the issue, removing the need to embed subsequent triggers inside the primary orchestration file.
Until then, try out https://diplospot.github.io/, and open an issue if you find a bug or need a feature. Once I tag it, hopefully the pipeline can built it asynchronously !
