PromptDock Autopilot

For solo maintainers and small teams: GitLab Duo flows handle the work after code: review, broken pipelines, releases, incidents and security follow-up. Humans approve plans, merges and production.

Comment

Inspiration

Code generation is solved; shipping safely is not. After an AI-generated commit, a solo maintainer still has to review it, fix broken pipelines, cut releases, answer incidents and chase security findings. PromptDock is my MIT-licensed prompt template manager (React + Tauri). Since October 5, 2026 I moved it to GitLab and built a supervised "autopilot" for that coordination work.

What it does

Built for solo maintainers and small teams. Eight custom GitLab Duo flows run the routine workflows after code. People keep the decisions: approving plans, merging reviewed changes, authorizing production, and privileged actions such as turning on a production feature flag.

The key idea: deterministic CI decides when an agent should act, and domain-specific prompt contracts stop breaking template changes and hand the decision to a person.

  • Triage & Plan: labels and sizes each issue and posts an agent plan with acceptance criteria and a test plan. Service Desk emails get a severity, a reproduction attempt and one polite public reply; outages, security, data loss and billing go to a human.
  • Issue to MR / Backlog Worker: after a human approves the plan (moves the issue to In progress), the agent branches, writes code and tests, ships new features dark behind a GitLab feature flag, and opens an MR.
  • Code Reviewer: reviews every MR pipeline with Blocking: / Suggestion: findings, up to 3 rounds.
  • Pipeline Doctor: fixes failing pipelines and blocking review findings, or opens an incident when deploy or smoke fails.
  • Release Guardian: opens the develop → main release MR. After a human merges it and plays deploy-production, smoke and Playwright UI checks run on the live site, then a prod-<n> tag, a GitLab Release and an evidence card on the issue follow.
  • Incident Commander: a CI job checks production every 15 minutes, rechecks it under a lock, verifies the previous version on a preview channel and rolls back only when that is safe. The flow opens a GitLab incident with a UTC timeline, closes it with the measured recovery time and writes a blameless postmortem.
  • Security Steward: runs only when a scanner finds something new, opens a deduplicated security issue and, when safe, a remediation MR. A fail-closed findings gate blocks deploys on High/Critical SAST or any secret.

One complete case

Issue #11: Triage & Plan posted the plan → I approved it → Issue to MR opened MR !23 with code and tests → Code Reviewer passed it → I merged → Release Guardian opened release MR !20 → I merged and deployed → production pipeline 2987492740 ran smoke and UI checks, tagged prod-197, and posted an evidence card. About 61 minutes from issue to verified production.

More evidence

  • Contract gate: issue #9 → MR !18 → production pipeline 2987371572. The agent built the gate; Duo review found 3 issues and Doctor fixed them.
  • Stopped for a human: issue #10, a breaking template rename blocked by the contract gate and handed off with needs-human.
  • Security finding to production: issue #31 → MR !47 → release prod-572. DAST found a missing X-Content-Type-Options header; the next scan no longer reported it. The release's compliance report lists scans, a 756-component SBOM, the review verdict for each MR, and who merged and deployed.
  • Incident drill: incident #13 opened and closed automatically with a postmortem (recovery 4 minutes; drills never roll back the live site).
  • Feature-flag pilot: #12 (token estimate) was implemented by me, then reviewed by Code Reviewer and verified through the release workflow; I turned its flag on in production with no redeploy.
  • Review fixes: two external reviews led to releases prod-430 and prod-605 (rollback safety, drill/real incident separation, the findings gate, advisory-aware dedupe), each with regression tests.
  • DORA snapshot (Oct 26, 2026; 30-day query window, project on GitLab since Oct 5): 13 production deploys, median lead time 28.1 min over 118 commits, 0/13 failed deploys observed, no real incidents yet; drill restore median 10.9 min over 3 drills.

How we built it

  • Duo Agent Platform: 8 custom flows in the AI Catalog (definitions in .gitlab/duo/flows/), triggered by mentions, assignment, pipeline events and gated schedules.
  • All 9 stages: Plan (Triage & Plan) · Create (Issue to MR, Backlog Worker) · Verify (lint, unit, contract gate, browser e2e, Rust tests) · Package (Generic Package Registry build, checksums, CycloneDX SBOM, container tag) · Secure (SAST, secret detection, dependency scanning, DAST, findings gate, Security Steward) · Release (release MRs, staging, gated production, tags, Releases) · Configure (feature flags, Firebase bootstrap) · Monitor (GitLab Observability traces and OpenTelemetry synthetic metrics, Lighthouse budgets, DORA, uptime, incidents, Service Desk) · Govern (per-release compliance report, SBOM and license report, CODEOWNERS, human gates, no stored cloud keys).
  • Google Cloud: Firebase Hosting via GitLab OIDC → Workload Identity Federation; short-lived tokens, no service-account keys.
  • Sustainability: measured scheduled-run time fell 84–88%; SCI-based estimates and method in docs/SUSTAINABILITY.md.

Challenges

  • GitLab starts no flow for pipelines created by agent service accounts, so I added a scheduled sweep as a fallback.
  • Agent tokens can't create incident timeline events or toggle flags, so those stay in deterministic CI or with a human.
  • Google rejects Workload Identity subjects over 127 bytes, and long agent branch names broke preview deploys; the mapping now uses project and job IDs.
  • Rollback had to be safe and testable without touching production: verify the old version on a preview channel, recheck health under a lock, and drill on drill/* branches.

What I learned

Agents are most reliable with narrow prompts, explicit stop conditions (needs-human), labels as state, and deterministic CI deciding when they should act.

What's next

  • Approval rules and security policies enforced by GitLab, not just flow prompts (needs a Maintainer)
  • Let flows query GitLab Observability through its MCP server during incidents
  • Real-user monitoring
  • Carbon-aware scheduling from hourly grid data

Built With

Share this project:

Updates

Submission history