Autonomous SDLC Agent

Testing Prompt
completion of the branch creation and further proceeding furhter
proceeding to the phase 2
verification by the ship manager phase 3
phase 3 complete
Final MR link provided by the agent

Inspiration

Every developer knows the feeling: a ticket arrives, the requirement is clear, but before a single line of production code is written, there are hours of work ahead — writing technical docs, syncing branches, designing tests, implementing across multiple layers, generating migrations, and preparing a readable MR. This is not engineering. It is coordination overhead that repeats with every ticket.

The idea was simple: build an orchestration engine that handles this entire lifecycle autonomously. Give it a GitLab issue. Get back a documented, tested, migration-safe, review-ready Merge Request.

What it does

TicketToMR is powered by the Complete Autonomous SDLC Agent, a unified GitLab Duo agent. Given a GitLab issue containing a business requirement and acceptance criteria, it sequentially executes three distinct persona phases in a single run:

Phase 1 — Architect (Code-Aware): Reads the issue, generates the feature branch, analyzes the existing repository, and writes structured annexures into docs/SRS.md and docs/TRD.md with exact API contracts, DB schema changes, migration SQL, test strategy, and edge cases.
Phase 2 — Engineer (Strict TDD): Reads the generated TRD annexure, creates failing testing mappings first (TDD), implements required changes across all impacted abstractions, generates the SQL migration file if required, and self-validates the code against the TRD.
Phase 3 — Ship Manager: Verifies every layer matches the TRD, then creates the Merge Request with a comprehensive description: Problem, Implementation, API Changes, DB Changes, Test Evidence, Risks, Rollback Plan, and a reviewer checklist.

How we built it

To give the agent maximum flexibility and self-sufficiency, we provided it with an extensive toolset containing 24 distinct capabilities (including create_commit, get_repository_file, gitlab_blob_search, read_files, run_git_command, create_merge_request, and ci_linter).

We created the agent configuration (complete-autonomous-sdlc-agent.yml) with a heavy emphasis on zero-hallucination policies and strict sequential execution. Then, we built the corresponding flow configuration (complete-autonomous-sdlc-agent-flow.yml) to properly route user intent into this powerhouse agent.

Challenges we ran into

A race against time and access constraints — The hackathon provides premium GitLab Ultimate access through a request form. We submitted the form, but the activation email went to a spam folder late last night. We didn't sequence the email until noon today! With precious little time left, we had to rapidly adapt and build out everything that was technically possible.
Architecture pivot under pressure — The original plan detailed in the repository was an elegant three-agent Flow (separate Architect, Engineer, and Ship Manager entities passing context downstream). Without immediate access to test complex multi-agent flows earlier in the build, the entire orchestration had to be rapidly consolidated into a single monolithic agent.
Single agent, multi-phase enforcement — Making one agent reliably execute three fundamentally different phases in order—without collapsing them together or skipping steps—required incredibly strict prompting. We had to enforce "GLOBAL RULES" to stop execution on failure, mandate tool usage, and prevent overwrite hallucination.
TDD in an agentic context — Ensuring the agent maps requirements and writes tests before production code—and does not bypass that step—was a difficult constraint to enforce through prompting alone.
Append-only documentation — Preventing the agent from overwriting existing SRS.md and TRD.md content while still adding clean, traceable annexures required specific guidelines.

Accomplishments that we're proud of

Successfully pivoted an entire architectural design under extreme time pressure after discovering the premium access email in spam.
Designed a wildly comprehensive unified prompt that forces a single agent to act as three distinct personas sequentially without losing context.
Equipped the agent with a massive toolset (24 tools), allowing it to truly traverse the entire SDLC—from reading an issue to validating tests to opening an MR.
The documentation model (append-only SRS/TRD annexures traced to ticket ID) is a practical, adoptable standard for real engineering teams.

What we learned

Time limits force creativity. Finding our access email late forced us into a consolidated single-agent design, which taught us exactly how far a single context window can be pushed.
GitLab Duo agent prompting requires intense precision. Vague instructions produce merged or skipped steps. Explicit phase structure (Phase 1 -> Step 1.1, etc.), output format enforcement, and global bounding rules make a massive difference.
Tool abundance is powerful. Giving the agent comprehensive read, write, git, and issue/MR-management tools allowed true end-to-end autonomy.

What's next for TicketToMR

Now that we have the premium access, we plan to split the monolithic agent back into the dedicated multi-agent Flow architecture (Architect -> Engineer -> Ship Manager).
Extend the agent to handle more complex ticket types — external API integrations, complex database join updates, and performance optimizations.
Add an automated trigger on issue label assignment (e.g., workflow::ready_for_dev) so the flow kicks off without human intervention.
Introduce advanced pipeline feedback loops where the Ship Manager persona reads CI failures and kicks the branch back to the Engineer persona to self-correct before requesting a human review.