Spider Web - Hands off Project

Spider-Web: issues travel only the strands they need, from triage and test-first build to targeted review, auto-merge and Cloud Run deploy.

Comment

Inspiration

Coding agents are already fast at writing code. The hard question is what happens next: who decides that a change is safe to merge and ship?

Most pipelines answer that with a straight line. Every change gets the same reviewers, the same checks and the same human approval. That is slow for a one-line keyboard shortcut and still too thin for a change to CI or security.

We wanted a web instead of a line: each issue travels only the strands it needs. The idea of one-way and two-way doors shaped it. A two-way door can be undone cheaply, so it should go fast. A one-way door is hard to undo, so it gets a design step first. Some requests, like removing a security gate, should never be built by an agent at all. The agent skills are inspired by mattpocock/skills: small, explicit rules that an agent loads when it needs them.

For the product, we took Marp, the MIT-licensed Markdown slideshow maker, and turned its website into a working editor, Marp Studio where we showcase the MARP in the user's browser.

What it does

You file an issue and assign it to Sense. Nobody touches it after that.

Sense (triage). It classifies the issue as a two-way or one-way door and picks the project rules that apply.

Two-way doors skip the architect and get a short brief. One-way doors go to an architect step that designs the change twice. Requests against the rules stop and ask a person. Spin (build). It writes a failing test first, makes it pass, runs the full local CI and opens a merge request.

Weave (review). It maps every changed file to the rules it touches, so only those checks run. The keyboard shortcut only pulled in the Studio sandbox check; a CI change would pull in the security gates and the architect. One verdict comes out. If changes are needed, it sends the merge request back to Spin.

The lander. This is script with four rules: Weave approved the latest commit. Its pipeline passed. The branch is current with the main branch. No protected file changed. If all four hold, it merges. If any fails, it refuses and says why.

Cloud Run. A scheduled Cloud Build deploys the new main branch once GitLab shows a green pipeline for that exact commit.

How we built it

GitLab Duo Agent Platform: three flows (triage, build and review) registered in the AI Catalog, plus a library of agent skills they load on demand. GitLab CI: build, tests, dependency audit, SAST, secret detection, SBOM, plus our own security and secret report gates. Lander: a small Node script that applies the same rules as the merge gate and is covered by unit tests. Google Cloud: Cloud Scheduler triggers Cloud Build every 5 minutes, which deploys to Cloud Run. It reads the public repo, compares the main branch with the commit recorded on the running service and checks GitLab for a green pipeline on that commit. No GitLab token and no service-account key are stored anywhere. Marp Studio: a Next.js editor with live preview, themes, presentation mode and import/download. Drafts stay in the browser. The preview runs in a sandboxed iframe under a strict Content Security Policy.

Challenges we ran into

We had no merge token or CI secrets, so the agents could not merge on their own. So the merge decision lives in a small, rule-based script. An early run took over 100 minutes. Shortening the triage brief and narrowing what the reviewer loads brought it down a lot. Review runs sometimes doubled up and posted twice, so we added a duplicate check.

Accomplishments that we're proud of

Real issues went all the way from filing to a live deploy without a human in between. The reviewer also caught real bugs and sent them back, and the builder fixed them.

What we learned

This is the first time I use the Gitlab duo platform, and value is in routing: deciding which checks a change actually needs.

What's next for Spider Web - Hands off Project

Test and measure the effectiveness of our flow for a variety of different features. Add monitoring that can open its own issues after a deploy, and package the flows so other GitLab projects can use them.

Built With

Share this project:

Updates

Submission history