OpenCode GitLab Duo Agent Platform Plugin

An opencode plugin for the GitLab Duo Agent Platform (DAP). Discovers agents and flows from the GitLab AI Catalog, injects them into opencode, and provides tools for managing and executing DAP workflows.

Requirements

• opencode with the gitlab provider configured and Duo Workflow (DWS) enabled
• GitLab OAuth or PAT authentication (via opencode-gitlab-auth or manual config)
• GitLab project with AI Catalog agents/flows enabled
• gitlab-ai-provider >= 6.3.0 (peer dependency, bundled with opencode's gitlab provider)
• @opencode-ai/plugin >= 1.2.24

Install

opencode plugin opencode-gitlab-dap

Or add to your ~/.config/opencode/opencode.json:

{
  "plugin": ["opencode-gitlab-dap"]
}

No further configuration needed. The plugin reads GitLab auth and model cache automatically.

MCP Server Mode

You can also run opencode-gitlab-dap as a standalone MCP server over stdio. This is useful with lazy-mcp to reduce input token context — instead of 36 tool schemas in every message, tools are lazy-loaded on demand.

npx opencode-gitlab-dap

lazy-mcp Configuration

lazy-mcp is a lightweight MCP proxy that lazy-loads tools from multiple MCP servers. Instead of sending all tool schemas to the LLM on every message, it exposes a small set of meta-tools (list_servers, list_commands, describe_commands, invoke_command) that let the LLM discover and call tools on demand.

Add the following to the servers array in ~/.config/lazy-mcp/servers.json:

{
  "name": "gitlab-dap",
  "description": "GitLab DAP: agents, flows, memory, skills, MCP servers",
  "type": "local",
  "command": ["npx", "-y", "opencode-gitlab-dap"],
  "tags": ["gitlab", "dap", "agents", "flows", "memory", "skills"]
}

Full example with lazy-mcp configured in opencode (~/.config/opencode/opencode.json):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "lazy-mcp": {
      "type": "local",
      "command": ["npx", "-y", "lazy-mcp@latest", "--config", "~/.config/lazy-mcp/servers.json"]
    }
  },
  "plugin": [["opencode-gitlab-dap", { "tools": false }]]
}

Requirements for MCP Mode

• Must have authenticated with GitLab via opencode at least once (~/.local/share/opencode/auth.json)
• Must run from a directory with a GitLab git remote (project is detected from git remote)
• For RLM features: ai and ai-rlm packages are included as dependencies (no additional install needed)

Using MCP Server with Plugin (Recommended)

For the best experience, use both the plugin and MCP server together. The plugin provides agent discovery, @ menu integration, and flow dispatch hooks. The MCP server provides the 35 DAP tools via lazy-mcp without bloating your input context.

Setting "tools": false in the plugin options disables tool registration from the plugin (agents, hooks, and system prompts are still active). The tools are then served exclusively through the MCP server via lazy-mcp.

| Mode | Tools in context | Hooks & agents | Token cost | | -------------------------- | ------------------------- | -------------- | ---------- | | Plugin only | 36 schemas always loaded | Yes | High | | MCP only (lazy-mcp) | 0 (lazy-loaded on demand) | No | Low | | Plugin + MCP (recommended) | 0 (lazy-loaded on demand) | Yes | Low |

Features

Agent & Flow Discovery

On startup, the plugin discovers all agents and flows enabled for your project:

• Foundational agents (Planner, Data Analyst, Security Analyst, etc.) via aiFoundationalChatAgents
• Custom agents and flows via aiCatalogConfiguredItems
• Agents appear in /agents dialog and Tab agent picker
• Flows appear in the @ mention menu as subagents

Use cases:

• Switch to a specialized agent mid-conversation — press Tab or open /agents to pick a Data Analyst, Security Analyst, or any custom agent enabled for your project
• Discover what automation is available — browse the @ menu to see all flows your project has access to, including both foundational and custom flows
• Use foundational agents for specialized tasks — switch to the Planner agent for project planning, or the Security Analyst for vulnerability assessment, without any setup

Flow Execution via @ Menu

Type @Flow Name followed by your goal to execute a flow:

@Fix CI/CD Pipeline fix the failing pipeline for MR !12

The plugin:

1. Registers the flow as a subagent with a built-in prompt containing flow execution instructions
2. The subagent fetches the flow definition and parses what context:goal maps to (e.g., merge_request_iid, pipeline_url)
3. Resolves the goal to the exact value the flow expects (e.g., just 14 for an MR IID, not a sentence)
4. Gathers required additional inputs using available GitLab tools
5. Executes the flow via POST /api/v4/ai/duo_workflows/workflows
6. Monitors workflow status and reports the workflow URL for tracking in GitLab UI

Use cases:

• Trigger a code review — @Code Review 🦊 review MR !42 to get automated code review feedback on a specific merge request
• Fix a broken pipeline — @Fix CI/CD Pipeline diagnose and fix the failing pipeline on branch feature/auth to get automated pipeline diagnosis
• Resolve a security vulnerability — @Security Vulnerability Fix fix vulnerability #123 to get an automated fix generated and pushed as an MR
• Generate test coverage — @Auto Fix generate tests for the UserService class to get unit tests created automatically
• Natural language goal resolution — describe what you want in plain English and the plugin resolves it to the exact parameter the flow needs (e.g., "MR !12" → IID 12)

Parallel Multi-Flow Dispatch

Mention multiple flows in a single message to execute them simultaneously:

@AppSec Security MR Reviewer @Code Review 🦊 review all open MRs

When multiple flows are mentioned:

1. The chat.message hook detects multiple @ mentions and produces a single combined dispatch instruction
2. A single general subagent is dispatched via the Task tool
3. The subagent executes all flows concurrently — it calls gitlab_get_flow_definition for all flows at once, then gitlab_execute_project_flow for all flow+resource combinations, then polls all statuses
4. For batch operations ("for each MR", "all open MRs"), the main agent lists resources first, then the subagent dispatches N flows × M resources in parallel

The experimental.chat.system.transform hook injects system prompt guidelines that instruct the main agent on how to handle multi-flow and batch dispatch scenarios.

Use cases:

• Run security and code review simultaneously — @AppSec Security MR Reviewer @Code Review 🦊 review MR !42 to get both security analysis and code quality feedback in parallel
• Batch review all open MRs — @Code Review 🦊 review all open MRs to dispatch one flow execution per open MR, all running concurrently
• Multi-flow batch operations — combine multiple flows with "for each" semantics: the plugin lists all matching resources, then dispatches N flows × M resources in parallel
• Reduce wait time with concurrency — instead of running flows one by one, mention them all at once for simultaneous execution with a single summary at the end

RLM-Powered Memory (Recursive Language Model)

Memory tools use an AI-powered retrieval system based on Recursive Language Models. Queries run in an isolated QuickJS WASM sandbox — instead of dumping all records into the conversation context (~30K+ tokens for large knowledge bases), an RLM agent explores memory programmatically and returns only the relevant results (~500-2000 tokens).

query project memory for how does authentication work

How it works:

1. All memory records are loaded into a sandboxed JavaScript REPL as a context variable
2. A lightweight LLM (the "main model") writes JavaScript code to split, filter, and analyze records
3. A cheaper LLM (the "sub-model") is called via llm_query() inside the sandbox to semantically rank which records are most relevant to the user's query
4. Only the matching records are returned to the main conversation — the full memory never enters context

Which tools use RLM:

| Tool | RLM Behavior | | --------------------------- | ------------------------------------------------------------------------- | | gitlab_memory_query | Always uses RLM. Returns compact synthesis of most relevant records. | | gitlab_memory_load | Opt-in via rlm_query parameter. Without it, existing dump-all behavior. | | gitlab_memory_consolidate | Auto-uses RLM when enabled. Returns structured analysis report. |

Smart threshold: If total memory content is under 4K characters (~1K tokens), RLM is skipped and records are returned directly — no point spinning up a sandbox for a handful of records.

Configuration:

RLM is enabled by default. Configure in opencode.json:

{
  "plugin": [
    [
      "opencode-gitlab-dap",
      {
        "rlm": {
          "model": "duo-chat-gpt-5-4-mini",
          "subModel": "duo-chat-gpt-5-4-nano"
        }
      }
    ]
  ]
}

| Option | Default | Description | | -------------------- | --------------------- | ---------------------------------------------------------- | | rlm.model | duo-chat-sonnet-4-6 | Main model for REPL orchestration (writes JS code) | | rlm.subModel | duo-chat-haiku-4-5 | Sub-model for llm_query() semantic ranking (cheap, fast) | | rlm.maxIterations | 10 | Max REPL iterations before stopping | | rlm.maxLLMCalls | 20 | Max total LLM calls (main + sub combined) | | rlm.maxOutputChars | 100000 | Max output size from the sandbox | | rlm | false | Set to false to disable RLM entirely |

Model recommendations:

| Combo | Speed | Cost | Quality | | ------------------------------------------------- | ------ | ------ | ------- | | duo-chat-gpt-5-4-mini + duo-chat-gpt-5-4-nano | Fast | Low | Good | | duo-chat-sonnet-4-6 + duo-chat-haiku-4-5 | Medium | Medium | Good | | duo-chat-sonnet-4-6 + duo-chat-gpt-5-4-nano | Medium | Low | Good |

The main model only needs to write simple JavaScript (split, filter, regex). The sub-model handles semantic ranking via llm_query(). Both can be cheap/small models.

Use cases:

• Find specific knowledge without reading everything — "query project memory for how does authentication work" returns only the relevant records instead of all 30K+ tokens of memory
• Consolidate memory intelligently — consolidation runs in the sandbox, producing a structured report of stale, duplicate, and contradictory records without dumping everything into context
• Scale to large knowledge bases — with 50+ records, raw context dumps become impractical. RLM keeps retrieval cost constant regardless of memory size
• Use any model provider — works with both Anthropic (Sonnet/Haiku) and OpenAI (GPT-5.4-mini/nano) models via GitLab AI Gateway

Custom Agent Creation

Create custom agents interactively:

Create an agent that responds to prompts in the form of poems

The plugin guides you through an interactive workflow:

1. Discovers available built-in tools (gitlab_list_builtin_tools) and MCP servers (gitlab_list_project_mcp_servers)
2. Asks for agent name, visibility, tool categories, and MCP servers via the question tool
3. Generates a system prompt and shows the full configuration for approval
4. Creates the agent via gitlab_create_agent (with confirmed gate to prevent accidental creation)
5. Offers to enable the agent on the current project

The confirmed parameter on gitlab_create_agent enforces the interactive workflow — the tool returns instructions instead of creating the agent when called without explicit confirmation.

Use cases:

• Build a domain-specific assistant — create an agent with a system prompt tuned to your team's domain (e.g., payments, infrastructure, data pipelines) and the relevant tools
• Create a creative writing agent — build an agent that responds in a specific format (poems, haiku, bullet points) for fun or specialized output needs
• Set up a security-focused reviewer — create an agent with security scanning tools and a system prompt that emphasizes OWASP, CVE checks, and secure coding practices
• Connect an agent to external services — assign MCP servers to an agent so it can interact with third-party APIs and services during conversations
• Share agents across your organization — create a public agent in the AI Catalog that any project in your GitLab instance can enable and use

Custom Flow Creation

Design and create custom flows interactively:

Create a flow that fetches MR data, analyzes the changes, and posts a summary comment

The plugin provides a multi-round design workflow:

1. gitlab_design_flow with action="get_schema" returns the flow YAML schema reference, two annotated examples, and step-by-step instructions
2. The LLM asks the user about the flow's purpose, resource type, and steps
3. The LLM proposes a component architecture for user approval
4. The LLM generates the full YAML, validates it client-side against the flow_v2 JSON schema via gitlab_design_flow with action="validate"
5. After user confirmation, gitlab_create_flow with confirmed=true submits it to GitLab
6. After creation, offers to enable the flow on the current project via gitlab_enable_project_flow

The vendored flow_v2.json schema from GitLab Rails powers client-side validation using ajv, catching errors before hitting the API.

Use cases:

• Automate MR summarization — create a flow that fetches MR diffs, analyzes the changes, and posts a summary comment with key observations
• Build a deployment checklist flow — design a multi-step flow that verifies prerequisites, runs pre-deployment checks, and triggers deployment
• Create a release notes generator — build a flow that collects commits since the last tag, categorizes changes, and generates formatted release notes
• Design a conditional flow with routing — create a flow with branching logic (e.g., different review steps based on file types changed in the MR)
• Validate flow definitions before submission — catch YAML schema errors locally before hitting the GitLab API, reducing back-and-forth during flow development
• Iterate on flow design interactively — use the multi-round design workflow to refine component architecture and step definitions with guided assistance

36 Tools

DAP Tools (20)

Flow Execution

| Tool | Description | | ----------------------------- | ------------------------------------------ | | gitlab_execute_project_flow | Execute a flow via DWS REST API | | gitlab_get_flow_definition | Get flow YAML config (inputs, components) | | gitlab_get_workflow_status | Monitor workflow execution status and logs |

Use cases:

• Run a code review flow on a merge request — trigger the "Code Review" flow for a specific MR to get automated review feedback posted as comments
• Fix a failing CI/CD pipeline — execute the "Fix CI/CD Pipeline" flow with the pipeline URL to get automated diagnosis and fix suggestions
• Batch-execute flows across multiple MRs — run a security review flow on all open MRs simultaneously by listing resources first, then dispatching N flows in parallel
• Inspect flow requirements before execution — use gitlab_get_flow_definition to check what inputs a flow expects (e.g., merge_request_iid, pipeline_url, vulnerability_id) before triggering it
• Monitor long-running workflows — poll gitlab_get_workflow_status to track progress, retrieve the agent conversation log, and get the GitLab UI URL for the workflow session
• Debug flow execution failures — check workflow status messages to understand where a flow failed and what the agent attempted

Catalog CRUD

| Tool | Description | | --------------------------------- | ------------------------------------------------------- | | gitlab_create_agent | Create a custom agent (interactive, confirmation-gated) | | gitlab_update_agent | Update an existing custom agent | | gitlab_list_builtin_tools | List available built-in tools for agent/flow config | | gitlab_design_flow | Interactive flow design + YAML validation | | gitlab_create_flow | Create a custom flow (confirmation-gated) | | gitlab_update_flow | Update an existing custom flow | | gitlab_list_project_mcp_servers | List MCP servers available for project agents |

Use cases:

• Create a project-specific code reviewer agent — interactively define a custom agent with a tailored system prompt, assign it the MR and code search tools, and connect it to your project's MCP servers
• Build a team-specific incident responder agent — create an agent with security scanning tools and a system prompt tuned to your team's runbooks and escalation procedures
• Design a custom flow from scratch — use gitlab_design_flow to get the YAML schema reference and examples, propose a component architecture, validate the YAML client-side, and submit it
• Create a vulnerability triage flow — design a multi-step flow that fetches vulnerability details, evaluates severity, and posts remediation guidance
• Iterate on an agent's system prompt — use gitlab_update_agent to refine the prompt after testing, bump the version, and release
• Add MCP servers to an existing agent — discover available MCP servers with gitlab_list_project_mcp_servers, then update the agent to include them
• Validate flow YAML before submission — catch schema errors locally with gitlab_design_flow(action="validate") before hitting the API
• Discover available tools for agent configuration — use gitlab_list_builtin_tools to see all tool categories (search, issues, MRs, epics, files, git, CI/CD, security, audit, planning, wiki)

Catalog Item Management

| Tool | Description | | ------------------------------ | -------------------------------------- | | gitlab_list_agents | Search agents in the global AI Catalog | | gitlab_get_agent | Get agent details by ID | | gitlab_list_project_agents | List agents enabled for a project | | gitlab_enable_project_agent | Enable an agent in a project | | gitlab_disable_project_agent | Disable an agent in a project | | gitlab_list_flows | Search flows in the global AI Catalog | | gitlab_get_flow | Get flow details by ID | | gitlab_list_project_flows | List flows enabled for a project | | gitlab_enable_project_flow | Enable a flow in a project | | gitlab_disable_project_flow | Disable a flow in a project |

Use cases:

• Browse the AI Catalog for useful agents — search the global catalog by name or description to discover agents built by other teams or the community
• Set up a new project with standard agents — enable your organization's standard set of agents and flows on a newly created project
• Audit which agents are enabled — list all agents and flows enabled for a project to verify compliance with team standards or security policies
• Enable a flow after creation — after creating a custom flow, enable it on your project so it appears in the @ mention menu
• Disable a misbehaving flow — temporarily disable a flow that is producing incorrect results while you debug and update its definition
• Inspect agent details before enabling — check an agent's creator, version, description, and permissions before adding it to your project
• Find the consumer ID for flow execution — list project flows to retrieve the consumer ID required by gitlab_execute_project_flow

Project Knowledge Tools (16)

Persistent project memory and reusable skills. Knowledge is stored in GitLab project/group wikis but tools abstract the storage — the agent works with facts, decisions, patterns, and skills.

Say "bootstrap project memory" to automatically inspect a project and build its knowledge base. If memory already exists, it does a smart refresh — updating stale facts and archiving outdated entries.

Memory Tools (8)

| Tool | Description | | --------------------------- | --------------------------------------------------------------- | | gitlab_memory_load | Load project memory (facts, decisions, patterns, archive) | | gitlab_memory_query | Semantic memory retrieval via RLM (Recursive Language Model) | | gitlab_memory_record | Record a fact, decision, or pattern (auto-timestamped) | | gitlab_memory_update | Update an existing memory record with corrected content | | gitlab_memory_archive | Archive an outdated record (moved to archive, still searchable) | | gitlab_memory_consolidate | Review all memory and get cleanup instructions | | gitlab_memory_recall | Search project knowledge for relevant information | | gitlab_memory_log_session | Log a session summary with learnings |

Use cases:

• Bootstrap project knowledge from scratch — run "bootstrap project memory" to inspect README, issues, MRs, pipelines, and team members, then record everything as structured facts, architecture, conventions, and people entries
• Preserve context across sessions — record facts about tech stack, dependencies, and deployment targets so future sessions start with full context instead of re-exploring
• Document architectural decisions with reasoning — record why the team chose PostgreSQL over MySQL, or React over Vue, with full rationale for future reference
• Track recurring patterns — record observations like "CI pipelines fail on Mondays due to cache expiry" or "test suite is flaky on the payments module" so they aren't rediscovered each time
• Maintain a living architecture document — record and update system design, module structure, data flow, and key abstractions as the codebase evolves
• Codify coding conventions — record naming patterns, commit message formats, review processes, and coding standards so the agent follows them consistently
• Document known issues and workarounds — record troubleshooting steps for common errors so the agent can suggest solutions without investigation
• Track team roles and ownership — record who owns which modules, who to contact for specific subsystems, and team members' areas of expertise
• Record implementation plans — document feature designs, task breakdowns, and roadmap items that persist across sessions
• Refresh stale knowledge — use gitlab_memory_update to correct outdated facts (e.g., updated issue counts, new team members, changed dependencies)
• Archive superseded decisions — when a decision is reversed or a fact becomes obsolete, archive it with a reason so there's a historical record
• Periodic memory housekeeping — use gitlab_memory_consolidate to identify stale, duplicate, or contradictory records and clean them up
• Search before investigating — use gitlab_memory_recall to check if something is already known about a topic before spending time exploring the codebase
• Log session summaries — at the end of a significant work session, record what was accomplished, what was learned, and suggestions for next steps
• Semantic memory search — use gitlab_memory_query to find relevant records using natural language queries instead of keyword matching (requires RLM enabled)

Skill Tools (8)

| Tool | Description | | ----------------------- | ------------------------------------------------------------- | | gitlab_skill_list | List skills with auto-rebuilding index | | gitlab_skill_load | Load a skill (SKILL page + references + snippet info) | | gitlab_skill_save | Create/update a skill with required description for index | | gitlab_skill_promote | Promote a draft skill to published (moves all pages) | | gitlab_skill_discover | Search group wiki and skills.sh for available skills | | gitlab_skill_install | Install from group wiki or skills.sh (wiki + snippet) | | gitlab_skill_setup | Extract skill to .agents/skills/<name>/ for local execution | | gitlab_skill_delete | Delete skill (wiki pages + snippet + index entry) |

Use cases:

• Create a reusable incident retrospective procedure — save a step-by-step skill that guides the agent through conducting incident retros with checklists and templates
• Share skills across projects via group wiki — save a skill at the group level so all projects in the group can discover and install it
• Discover team-shared skills — search the group wiki and skills.sh registry to find skills other teams have built (e.g., Helm rollback procedures, database migration checklists)
• Install a skill from the community — install a skill from skills.sh into your project wiki with one command, bringing in both documentation and executable scripts
• Draft and iterate on a skill before publishing — save a skill as a draft, test it in practice, refine the instructions, then promote it to published when ready
• Bundle executable scripts with a skill — save Python, JavaScript, or Shell scripts alongside skill instructions using hybrid storage (wiki for markdown, project snippet for executables)
• Extract skills for local execution — use gitlab_skill_setup to download a skill's scripts to .agents/skills/<name>/ so opencode auto-discovers and uses them locally
• Maintain a skill index for fast discovery — the index at agents/skills/index is auto-rebuilt on every gitlab_skill_list call, keeping it in sync with actual skill pages
• Promote a proven draft skill — after validating a draft skill works well, promote it to published to make it available to all users of the project
• Remove an obsolete skill — delete a skill and its associated snippet, automatically cleaning up the index entry
• Audit available skills — list all published and draft skills with their descriptions to understand what automation is available for the project

Security Audits for skills.sh Skills

When discovering or installing skills from skills.sh, the plugin automatically checks security audit results from three independent providers:

• Gen Agent Trust Hub — AI-powered threat detection for malware, data exfiltration, and prompt injection
• Socket — Supply chain security analysis for suspicious patterns and anomalies
• Snyk — Vulnerability scanning and risk assessment

Behavior:

• Block on Fail — if any audit provider reports a failure, installation is blocked with details and a link to review the audit findings
• Warn on Warn — if any provider reports a warning, the skill is installed but warnings are displayed with links to the audit details
• Graceful degradation — if skills.sh is unreachable or audit data is unavailable, installation proceeds with a note

Use cases:

• Discover skills with security status — gitlab_skill_discover shows audit results (Pass/Warn/Fail) inline for each skills.sh result, so you can assess risk before installing
• Block installation of risky skills — skills with audit failures from any provider are automatically blocked with a link to the full audit report
• Review audit warnings before proceeding — skills with warnings install successfully but display the warnings so you can make an informed decision
• Graceful handling of unavailable audit data — if skills.sh is unreachable, install proceeds with a note rather than failing

Dynamic Refresh

After enabling or disabling an agent/flow, the plugin automatically refreshes the agent list. Restart opencode to update the @ menu.

Use cases:

• Enable an agent and use it immediately — after enabling a new agent or flow, the plugin refreshes the catalog cache so tools immediately reflect the change without restarting
• Disable a broken flow mid-session — disable a flow that is misbehaving and the agent list updates in real time for subsequent tool calls

Vendored Foundational Flow Configs

Foundational flow definitions (from gitlab-org/modelops/applied-ml/code-suggestions/ai-assist) are vendored and embedded at build time. This provides flow input schemas for foundational flows whose configs are not available via the GitLab API.

The flow_v2.json JSON schema is also vendored from GitLab Rails and bundled inline for client-side YAML validation via ajv.

Use cases:

• Execute foundational flows without API calls — flow input schemas for built-in flows are bundled in the plugin, enabling instant flow definition lookup without network requests
• Validate custom flow YAML offline — the vendored flow_v2.json schema enables client-side validation via ajv without requiring a GitLab API connection
• Stay up to date with new flow versions — run npm run vendor to pull the latest foundational flow definitions when DWS releases updates

Agent Types

Foundational Agents

Built-in GitLab agents. Appear in /agents with [GitLab Foundational Agent] label.

Custom Agents

User-defined agents from the AI Catalog. Appear in /agents with [GitLab Custom Agent] label.

Flows (Foundational & Custom)

Multi-step workflows. Appear in @ menu with [GitLab Flow] label. Each flow is registered as a subagent with a built-in prompt that handles flow definition parsing, goal resolution, and execution. Single flows dispatch natively; multiple flows are batched into a single general subagent for parallel execution.

External Agents

Third-party agents (Claude Code, Codex, etc.) are excluded — they work via CI/CD triggers, not through opencode.

Flow Definition Lookup

The plugin uses a 3-tier strategy to fetch flow YAML configs:

| Tier | Source | Used For | | ---- | ----------------------------------------------- | ------------------ | | 1 | Vendored configs (vendor/foundational-flows/) | Foundational flows | | 2 | FlowVersion.definition GraphQL field | Custom flows | | 3 | aiCatalogAgentFlowConfig GraphQL query | Custom agents |

Self-Hosted GitLab

For OAuth-based auth, the enterpriseUrl from opencode-gitlab-auth is used automatically.

For PAT-based auth:

export GITLAB_INSTANCE_URL=https://your-instance.com

Development

npm install
npm test          # Run tests (132 tests)
npm run build     # Build (auto-runs vendor:generate)
npm run type-check

Vendor Scripts

npm run vendor:update    # Fetch flow configs from gitlab.com API
npm run vendor:generate  # Generate TypeScript from vendored YAMLs
npm run vendor           # Both: update + generate

To update vendored configs when DWS releases new flow versions:

npm run vendor
npm run build
git add vendor/ src/generated/
git commit -m "chore: update vendored foundational flow definitions"

Architecture

Plugin init
  ├─ readAuth()                          reads ~/.local/share/opencode/auth.json
  ├─ GitLabModelCache                    reads model cache (no network call)
  ├─ fetchCatalogAgents()
  │    ├─ aiFoundationalChatAgents       foundational agents (GraphQL)
  │    └─ aiCatalogConfiguredItems       custom agents + flows (GraphQL)
  │         └─ aiCatalogAgentFlowConfig  flow config YAML (GraphQL)
  ├─ config hook                         injects agents (primary) + flows (subagent with prompt)
  ├─ chat.message hook                   intercepts @flow → general subagent dispatch
  ├─ experimental.chat.system.transform  injects flow dispatch + agent creation guidelines
  ├─ tool hook                           20 DAP tools + 16 knowledge tools
  └─ RLM init                           parse rlm options → RLMConfig

Single flow execution (@FlowName goal):
  ├─ chat.message hook          rewrites @mention → Task tool with general subagent
  ├─ General subagent Step 1    gitlab_get_flow_definition → parse context:goal mapping
  ├─ General subagent Step 2    Resolve goal to exact value (MR IID, URL, etc.)
  ├─ General subagent Step 3    Gather additional_context inputs via GitLab tools
  ├─ General subagent Step 4    gitlab_execute_project_flow → POST to DWS
  └─ General subagent Step 5    gitlab_get_workflow_status → report status + URL

Multi-flow execution (@Flow1 @Flow2 goal):
  ├─ chat.message hook          detects multiple @mentions → combined dispatch
  ├─ Primary agent              dispatches ONE general subagent via Task tool
  ├─ General subagent           calls gitlab_get_flow_definition for all flows (concurrent)
  ├─ (if batch)                 lists resources via GitLab API
  ├─ General subagent           calls gitlab_execute_project_flow × N (concurrent)
  ├─ General subagent           calls gitlab_get_workflow_status × N (concurrent)
  └─ General subagent           presents summary table

Agent creation (interactive):
  ├─ gitlab_create_agent        called without confirmed → returns instructions
  ├─ gitlab_list_builtin_tools  discover available tools
  ├─ gitlab_list_project_mcp_servers  discover MCP servers
  ├─ question tool              ask user for name, visibility, tools, MCP servers
  ├─ LLM generates              system prompt → user confirms
  ├─ gitlab_create_agent        called with confirmed=true → creates agent
  └─ gitlab_enable_project_agent  optionally enable on project

Flow creation (interactive, multi-round):
  ├─ gitlab_design_flow (get_schema)  returns schema reference + examples + instructions
  ├─ gitlab_list_builtin_tools        discover available tool names for flow components
  ├─ question tool                    ask user for name, visibility, purpose, steps
  ├─ LLM proposes                    component architecture → user confirms
  ├─ LLM generates                   flow YAML definition
  ├─ gitlab_design_flow (validate)   client-side validation against flow_v2.json via ajv
  ├─ User confirms                   the generated YAML
  ├─ gitlab_create_flow              called with confirmed=true → creates flow
  └─ gitlab_enable_project_flow      optionally enable on project

RLM memory query (gitlab_memory_query):
  ├─ loadMemoryPages()          GET /api/v4/projects/:id/wikis?with_content=1
  ├─ formatRecordsForSandbox()  records → <<__MEMORY_RECORD__>> delimited string
  ├─ (if <4K chars)             return records directly (skip RLM)
  ├─ createGitLab()             gitlab-ai-provider → direct_access token
  ├─ RLMAgent.generate()        main model writes JS to split/filter records
  │    └─ llm_query()           sub-model ranks records by relevance
  └─ FINAL_VAR(result)          return matching records to caller

Enable/disable:
  └─ refreshAgents()            clears cache, re-fetches, updates cfg.agent

License

MIT