From Jira Story to Merge Request: Building a Governed Git-Agent-Force–GitLab Agent Chain

How we connected Git-Agent-Force, Jira, and GitLab into a governed agent chain that turns approved requirements into reviewable development work.

A software delivery agent is only useful when it can move through the team's existing controls. The hard part is not generating a code snippet. It is preserving context from the requirement, making technical assumptions reviewable, starting work in the right repository, and leaving a traceable change for engineers to approve.

End-to-end agent chain across Git-Agent-Force, Jira, and GitLab. Git-Agent-Force prepares the product work. GitLab takes over at a defined Jira-to-GitLab handover point: an intake agent gathers repository context, a specification agent prepares a technical plan, and an implementation agent starts development and opens a merge request.

The project outcome is a working implementation with a defined handover and a scaling concept—not an automation that treats AI output as authoritative.

Why the handover matters

A Jira story can express the desired behavior without answering every engineering question. A developer still needs to identify affected components, existing interfaces, data-model implications, and test cases. If this context is copied manually between systems, decisions become harder to trace. If an agent fills the gaps without a review point, the workflow can move quickly while hiding important assumptions.

The design therefore separates two responsibilities:

• Git-Agent-Force prepares a structured, implementation-ready requirement.
• GitLab turns an approved requirement into a technical specification and development kickoff.

The boundary is explicit. The GitLab side does not process every draft story. It starts when the agreed Jira readiness condition is met.

What Git-Agent-Force contributes

Atlassian documents Git-Agent-Force Search as a permission-aware search layer across Confluence, Jira, and Atlas, with connected third-party apps also available when authorized. Search results and answers are limited to content the current user can access. Atlassian's Git-Agent-Force Search documentation describes those access boundaries.

Git-Agent-Force agents can also use Jira and Confluence tools. The documented tools include searching Jira with JQL, creating or updating Jira work items, and creating or editing Confluence pages. Atlassian states that agents respect the invoking user's permissions and ask for confirmation before consequential mutating actions. The Git-Agent-Force agent-tools documentation describes both the available actions and the permission model.

In this project, Git-Agent-Force uses the available product knowledge to produce a clean Jira story with acceptance criteria. The story is the business input to the engineering chain. The exact prompt, fields, readiness state, and knowledge sources are implementation details of the project; they should be documented and versioned rather than assumed from the product name alone.

The Jira-to-GitLab contract

The central design decision was to treat the transition as an interface. The handover contract answers four questions:

1. What starts the workflow? A Jira story reaches the agreed ready-for-technical-processing state.
2. What crosses the boundary? The story, acceptance criteria, relevant links, and the context made available by the integration.
3. What may the GitLab agents do? Each agent has a narrow responsibility and scoped credentials.
4. What comes back to Jira? Status updates, links to the branch or merge request, pipeline information, and the next required decision.

Jira provides documented automation primitives for this kind of integration. Its Automation triggers include incoming webhooks and work-item events such as creation, updates, transitions, and assignment. An incoming webhook can start a rule through an HTTP POST and expose request data to later actions. Atlassian's Jira Automation trigger documentation describes these options.

Jira also documents a REST webhook API, but it has important constraints: dynamic webhook registration requires a Connect or OAuth 2.0 app, and REST-created webhooks expire after 30 days unless refreshed. Those details matter when turning a demo handover into a maintained integration. The Jira REST webhook documentation covers registration, refresh, and failure behavior.

The chain should not be described as a native, unrestricted Git-Agent-Force-to-GitLab connector unless the implementation has evidence for that claim. The reliable statement is narrower: Jira and an integration layer provide the handover, while GitLab processes the engineering work under the project's configured permissions.

Three GitLab responsibilities

1. Intake: assemble context before writing

The intake agent receives the Jira story and gathers the engineering information required to work on it. It reads relevant repository files and documentation, identifies nearby components and tests, and makes missing information visible.

That context boundary is important. GitLab's current Software Development Flow documentation—formerly called GitLab Workflow—states that the flow can understand project structure, code, and history, but cannot access external sources or the web. GitLab's Software Development Flow documentation makes the implication clear: Jira or Confluence context must be transferred into the GitLab workflow by the integration, not assumed to be available automatically.

2. Specification: turn intent into a reviewable plan

The specification agent derives a technical specification from the story and assembled context. The required output covers:

• Affected components and interfaces
• Data-model changes or constraints
• Integration and compatibility considerations
• Test cases mapped to the acceptance criteria
• Risks, open questions, and assumptions

The specification is submitted for approval before implementation. This is a project control point: it separates interpreting the requirement from changing the repository. A reviewer can reject an assumption or narrow the scope before code is generated.

GitLab's documented Developer Flow provides a related product capability: it can create a draft merge request from an issue and iterate on merge requests from feedback. GitLab's Developer Flow documentation also lists prerequisites such as the required Duo Agent Platform setup, project permissions, push rules, and runners. The exact specification and approval flow in this project remains a configured implementation, not a claim that every GitLab tenant behaves identically.

3. Implementation: start development without bypassing review

After the specification is approved, the implementation agent creates the branch, generates the code scaffold and initial tests, runs the pipeline, and opens a merge request with a summary. The goal is to make work ready for engineering review, not to make the agent the final authority.

GitLab's Developer Flow documentation supports the issue-to-draft-merge-request pattern. GitLab also documents a separate Fix CI/CD Pipeline Flow that can inspect pipeline logs, merge-request changes, repository contents, and script errors; depending on context, it may propose changes, create a merge request, or comment when it cannot safely act. GitLab's pipeline-fix documentation is a useful reminder that automated remediation has prerequisites and failure cases.

The merge-request summary should make the result easy to evaluate: what changed, which components are affected, which tests were added, what the pipeline reported, and what remains unresolved.

Guardrails are architecture, not decoration

The project requirements include service accounts, scoped tokens, protected branches, mandatory review, and an audit trail. These controls match GitLab's documented governance model, but each must be configured deliberately.

• Scoped identities and tokens: GitLab recommends the most limited token scope, an expiration date, secure handling, and regular review or revocation. Its documentation distinguishes project and group access tokens and separates read-only read_api from broader api access. GitLab's token guidance and access-token scopes provide the relevant constraints.
• Protected branches: Protected branches can restrict who may push or merge, prevent deletion, control force-push behavior, and require Code Owner approval. GitLab's recommended production setup includes Maintainer-only merges and explicitly setting direct push access to “No one.” GitLab's protected-branch documentation documents these controls.
• Mandatory review: GitLab's required approval rules depend on the edition and project configuration. GitLab documents required approval rules and Code Owner approvals for Premium and Ultimate, while approvals are optional on Free. The merge-request approval documentation explains when approvals block merging.
• Auditability: GitLab documents audit events for actions such as approval operations and merge-request activity, but event retention and streaming depend on the event type and product tier. GitLab's audit-event documentation should be used to define the project's actual retention and export design.
• Secret handling: Tokens must not be placed in prompts, generated files, logs, or merge-request descriptions. The integration should pass only the minimum context needed for the current step.

Protected branches alone do not guarantee governance. GitLab notes that matching branch rules can result in permissive outcomes for many settings, so the effective rules must be tested with the service account that the agents use.

Scaling beyond the happy path

The goal was a working end-to-end flow with scalable foundations, not a scripted success case. The next design questions are operational:

• Can a retry avoid creating duplicate branches or merge requests?
• Can every Jira story be correlated with its agent run, branch, pipeline, and merge request?
• What status is written when context is missing, a specification is rejected, or the pipeline fails?
• Which prompt and specification version produced the technical plan?
• Which permissions and tool calls were used at each stage?

The answers should be recorded in the integration design and tested in the demo scenario. Vendor documentation also gives concrete limits to account for: GitLab says large open-ended Developer Flow tasks are more likely to hit iteration limits, and the pipeline-fix flow processes only the last 150 KiB of job logs through its AI gateway. These are not abstract concerns; they affect how tasks and diagnostics should be structured. GitLab's Developer Flow documentation and pipeline-fix documentation describe the constraints.

CI/CD, runners, webhooks, APIs, and the GitLab permission model are therefore part of the agent architecture. The model is one component. The delivery system determines whether the workflow is repeatable, reviewable, and recoverable.

Demo, documentation, and knowledge transfer

The demo scenario follows the complete path:

1. A requirement is prepared in Git-Agent-Force using available Jira and Confluence knowledge.
2. The Jira story reaches the agreed handover state.
3. The intake agent gathers repository and documentation context.
4. The specification agent proposes the affected components, interfaces, data model, and tests.
5. A reviewer approves or rejects the specification.
6. The implementation agent creates the branch, scaffold, and initial tests.
7. The pipeline runs and the agent opens a merge request with a summary.
8. Jira receives the status and links needed for follow-up.

Documentation and knowledge transfer are part of the deliverable. The team needs to understand the handover contract, agent responsibilities, credentials, approval points, failure states, and operational checks. Without that knowledge, the chain remains dependent on its original builders.

What the project demonstrates

The outcome is a practical pattern for connecting agile planning with AI-assisted development:

• Git-Agent-Force prepares a permission-aware, structured requirement.
• Jira provides the explicit handover state and traceability.
• GitLab starts engineering work from an approved story and repository context.
• CI/CD and merge requests provide automated validation and a human review surface.
• Scoped credentials, protected branches, approvals, and audit events limit the impact of mistakes.

The value is not that an agent writes the first lines of code. The value is that the path from intent to reviewable change becomes structured, visible, and repeatable.

Final thoughts

A reliable software delivery agent should be judged by how well it operates inside the team's controls: clear requirements, permission-aware context, scoped access, automated checks, and mandatory review.

By defining the Jira-to-GitLab handover and assigning each agent one controlled responsibility, this project creates a foundation for scalable delivery. Git-Agent-Force prepares the work. GitLab starts the implementation. Engineers retain the decisions that matter.

That is the difference between an AI demo and an agent chain that can grow with a software organization.