Inspiration
kimo is my open-source video editor with no editing GUI: a headless Rust engine where every edit (cut, keyframe, grade, track, caption, mix, export) is an MCP tool call, so any AI agent can edit video. It has 376 actions in 14 tool groups. Writing it was the fun part. Shipping it was not. Every release meant hand-checking that no action got renamed (which silently breaks every AI client), copying binaries around, writing notes from memory, and hoping nothing in the 205-crate dependency tree had an advisory. That is exactly the "life after code" this hackathon is about, so I moved kimo to GitLab and gave the post-code work to agents.
What it does
Before (GitHub, manual): a maintainer reads every diff, nobody checks the MCP contract, proofs run by hand on one laptop, no security scanning, hand-written release notes, no deployment.
After (GitLab, automated):
- 8-stage pipeline (prepare, build, test, security, package, release, deploy, verify). It verifies the official kimo release's SHA-256, builds kimo from source, then drives kimo over MCP exactly like an AI agent would: it renders a verification clip and checks it with ffprobe. A contract gate fails the pipeline if any of the 376 actions disappears or gains a required argument. Secret detection, SAST, container scanning, a RustSec cargo-audit gate and a CycloneDX SBOM run on every pipeline. A tag publishes the package and a GitLab Release. GitLab Pages hosts a release & ops dashboard showing the clip kimo rendered in that pipeline, and a post-deploy job checks the live site serves the pipeline's own commit.
- kimo Security Triage (Duo flow, pipeline-event trigger): reads cargo-audit, SAST and secret-detection results and opens deduplicated, severity-labelled issues with the Cargo.lock dependency path, reachability from kimo-mcp, and a fix plan. Its first run filed 7 issues.
- kimo MR Guardian (Duo flow, MR-created / reviewer / mention triggers): reviews each MR against kimo's MCP contract, pipeline result, security and release hygiene, posts one verdict table (SHIP IT / NEEDS CHANGES / BLOCKED) and labels the MR. On the first docs MR it caught that MCP clients don't expand ${HOME} in args.
- kimo Release Captain (Duo flow, mention on an issue): writes release notes and the changelog, then runs kimo itself inside the Duo environment, re-checks the contract and renders a clip before opening the release MR. A human merges and tags; CI publishes everything.
How we built it
GitLab Duo Agent Platform custom flows (Flow Registry v1 YAML) created and triggered via the GraphQL API; agent-config with a hash-verified kimo-mcp + ffmpeg image; AGENTS.md and Duo Code Review instructions; stdlib Python tooling (MCP render check, contract gate, SBOM, Pages dashboard); GitLab CI/CD with Secret Detection, SAST, Container Scanning, package registry, Releases and Pages. The kimo engine is imported unchanged from the MIT GitHub project at commit 05cfbaa.
Challenges we ran into
The flow catalog validates stricter than the spec (rejects max_cycles); a cd in agent-config broke the first Triage session; the contract snapshot first came from a newer dev build, so the gate correctly flagged "removed" actions until it was regenerated from the v5.0.0 release.
Accomplishments that we're proud of
An agent that runs the product before proposing a release; a 376-action MCP contract gate on every pipeline; green 12-job pipelines and three flows that produced useful output on their first real run.
What we learned
Agents get much better when the repo tells them what matters, and giving flows the same verification scripts as CI makes their claims checkable.
What's next for kimo on GitLab
Let Security Triage open fix MRs and hand them to MR Guardian; host a kimo MCP endpoint per MR as a review environment; cache the Rust build and measure energy per pipeline.
Log in or sign up for Devpost to join the conversation.