GitHub vs GitLab

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to GitLab
   GitHub✓fullprobed8/10

   A live probe confirms GitHub Docs serves a working llms.txt file at https://docs.github.com/llms.txt (HTTP 200) with a structured description of GitHub as a developer platform, which is exactly the agent-oriented docs entry point the story describes. Missing for 10: no independent third-party confirmation of agents actually consuming this file, and no broader agent-oriented docs index beyond the single llms.txt endpoint.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.github.com/llms.txt # GitHub Docs > GitHub is a developer platform for building, shipping, and mai…”

   proof ↗⚑ flag

   GitLab✓fullprobed9/10

   A probe confirms GitLab hosts a live llms.txt at docs.gitlab.com/llms.txt (HTTP 200) with structured documentation content, directly satisfying the story of pointing an agent at agent-oriented docs. This is reinforced by agent-oriented documentation like the Orbit skill for AI coding agents and MCP tool exposure. Missing for 10: independent/community corroboration that agents actually consume this llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.gitlab.com/llms.txt # GitLab Documentation Learn how to use and administer GitLab, the most scalabl…”
   • [claimed-docs] “The GitLab Orbit skill gives AI coding agents structured guidance for querying the GitLab Orbit graph.”
   • [claimed-docs] “GitLab Orbit exposes two MCP tools that let any MCP-compatible AI agent discover and invoke GitLab Orbit commands against your graph.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   GitHub✓fullprobed8/10

   GitHub Actions is explicitly documented as CI/CD automation running in the repository, and GitHub CLI/REST/GraphQL APIs support headless scripting and automation outside any UI, corroborated by an official CLI and probe confirmation. missing for 10: independent/hands-on evidence of Copilot agent tasks running fully headlessly in CI pipelines beyond Actions/CLI docs.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Ship faster with secure, reliable CI/CD.”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line. When you're working from the command line, you can use…”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [probe] “official CLI documented at https://cli.github.com/”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab CI/CD is inherently headless automation infrastructure, with REST API for programmatic control, personal access tokens for auth, and Duo Agent Platform explicitly designed to run agents/flows within CI/CD pipelines (via 'Custom flows', 'Sessions' tracking execution) and third-party CLI agents like Kilo integrating directly into CI/CD pipelines. Missing for 10: independent hands-on validation of headless agent runs in CI, and more detail on non-interactive/unattended flow execution specifics.

   • [claimed-docs] “Get started with GitLab CI/CD Build and test your application.”
   • [claimed-docs] “Automate your workflows and build integrations with the GitLab REST API”
   • [claimed-docs] “Custom flows are workflows you create to automate your team’s specific processes.”
   • [claimed-docs] “Sessions show the status and execution data for the agents and flows you’ve run.”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Kilo is the open-source agentic engineering platform for GitLab. Powerful CLI and IDE agents autonomously plan, code, and verify tasks. Inte…”
   • [claimed-docs] “Personal access tokens”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round to GitHub
   GitHub✓fullclaimed8/10

   GitHub Copilot Chat explicitly supports connecting external MCP servers to extend its context and tools, documented with setup instructions for IDE integration (github-docs-28, github-docs-29, github-docs-30). This directly matches the story of plugging MCP servers into the product so it can use their tools. Missing for 10: independent/hands-on user reports confirming real-world reliability of third-party MCP server connections, and broader detail on limitations across non-IDE surfaces (e.g., github.com web chat vs IDE only).

   • [claimed-docs] “Connect MCP servers to Copilot Chat to share context from other applications.”
   • [claimed-docs] “Learn how to use the GitHub Model Context Protocol (MCP) server to interact with repositories, issues, pull requests, and other GitHub featu…”
   • [claimed-docs] “The GitHub MCP server in Visual Studio Code can be configured remotely or locally.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence shows GitLab exposing its own functionality as an MCP server (e.g., GitLab Orbit's MCP tools, the official 'mcp_server' doc) and governance policies for tools invoked by connecting clients, but nothing documents the reverse capability—letting a user plug external third-party MCP servers into GitLab's Duo Agent Platform so its own agents/flows can call those tools. Missing for 10: documentation of adding/registering external MCP servers as tool sources for GitLab Duo agents, any UI/config for MCP server URLs within Agent Platform, and independent confirmation that GitLab agents can invoke tools from arbitrary MCP servers.

   • [claimed-docs] “GitLab Orbit exposes two MCP tools that let any MCP-compatible AI agent discover and invoke GitLab Orbit commands against your graph.”
   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”
   • [probe] “official MCP server documented at https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/”
   • [claimed-docs] “Custom agents are agents you create and configure for your team’s specific needs.”
   • [claimed-docs] “Custom flows are workflows you create to automate your team’s specific processes.”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to GitHub
   GitHub✓fullprobed9/10

   GitHub ships and documents an official GitHub MCP server (github-probe-3: github/github-mcp-server) that lets AI agents interact with repositories, issues, and PRs, with detailed setup docs for local/remote configuration in VS Code (github-docs-29, github-docs-30) and integration guidance for connecting MCP servers to Copilot Chat (github-docs-28). This is a first-party, well-documented server-side MCP offering rather than just client-side MCP consumption. Missing for 10: independent/hands-on community corroboration of the MCP server working reliably in third-party agent setups.

   • [probe] “official MCP server documented at https://github.com/github/github-mcp-server”
   • [claimed-docs] “Learn how to use the GitHub Model Context Protocol (MCP) server to interact with repositories, issues, pull requests, and other GitHub featu…”
   • [claimed-docs] “The GitHub MCP server in Visual Studio Code can be configured remotely or locally.”
   • [claimed-docs] “Connect MCP servers to Copilot Chat to share context from other applications.”

   proof ↗⚑ flag

   GitLab✓fullprobed8/10

   GitLab documents an official MCP server (gitlab-probe-2) and separately exposes MCP tools via GitLab Orbit for AI agent discovery/invocation (gitlab-docs-42), showing first-party MCP server support for connecting external agents. Missing for 10: independent/hands-on verification of the MCP server's reliability and breadth of tool coverage beyond vendor docs.

   • [probe] “official MCP server documented at https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/”
   • [claimed-docs] “GitLab Orbit exposes two MCP tools that let any MCP-compatible AI agent discover and invoke GitLab Orbit commands against your graph.”
   • [claimed-docs] “The GitLab Orbit skill gives AI coding agents structured guidance for querying the GitLab Orbit graph.”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to GitHub
   GitHub✓fullprobed9/10

   GitHub ships both the official GitHub CLI (gh) for repo/workflow operations and a dedicated Copilot CLI for AI-native terminal use, both with first-party docs and install instructions across platforms. missing for 10: independent/hands-on third-party review specifically validating the CLI tools (community evidence in the pack is about unrelated topics, not the CLI).

   • [claimed-docs] “The command-line interface (CLI) for GitHub Copilot allows you to use Copilot directly from your terminal.”
   • [claimed-docs] “You can install Copilot CLI using WinGet (Windows), Homebrew (macOS and Linux), npm (all platforms), or an install script (macOS and Linux).”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line. When you're working from the command line, you can use…”
   • [claimed-docs] “Enter `gh repo clone OWNER/REPO`. For example, `gh repo clone octo-org/octo-repo` clones the `octo-org/octo-repo`”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line.”
   • [probe] “official CLI documented at https://cli.github.com/”

   proof ↗⚑ flag

   GitLab✓fullprobed8/10

   GitLab documents an official CLI (glab) at docs.gitlab.com/editor_extensions/gitlab_cli, distinct from the general REST API tooling, confirming a first-party CLI exists for interacting with GitLab. Missing for 10: no independent/hands-on corroboration of CLI usability or AI-native workflow specifics, and no detail on CLI feature completeness relative to agentic use cases.

   • [probe] “official CLI documented at https://docs.gitlab.com/editor_extensions/gitlab_cli/”
   • [claimed-docs] “Interact programmatically with GitLab.”
   • [claimed-docs] “Automate your workflows and build integrations with the GitLab REST API”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   GitHub✓fullprobed9/10

   GitHub documents both a REST API (with fine-grained token permissions) and a GraphQL API for creating integrations, retrieving data, and automating workflows, plus SDK-adjacent tools like the official CLI and MCP server for programmatic access. This is exactly the kind of documented public API surface an AI-native user would drive automation through. Missing for 10: a discoverable machine-readable OpenAPI spec (probe found 404s on standard OpenAPI paths) and independent hands-on developer corroboration of API usability.

   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions. Permissions define what resources the token can acc…”
   • [probe] “official MCP server documented at https://github.com/github/github-mcp-server”
   • [probe] “official CLI documented at https://cli.github.com/”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.github.com/openapi.json, https://docs.github.com/swagger.json, https://docs.github.com/…”

   proof ↗⚑ flag

   GitLab✓fullclaimed9/10

   GitLab documents a comprehensive REST API with OpenAPI 3.0 spec, interactive docs/testing tool, versioning/deprecation policy, and clear auth via PAT/OAuth2/SSH keys, explicitly positioned for automating workflows and integrations. This is a well-established, mature public API surface that AI agents and third-party tools (e.g., Make's integration module) already use programmatically. Missing for 10: no independent hands-on developer report specifically praising/critiquing the API's ergonomics for AI-agent use cases.

   • [claimed-docs] “Interact programmatically with GitLab.”
   • [claimed-docs] “Automate your workflows and build integrations with the GitLab REST API”
   • [claimed-docs] “You can browse and test every endpoint interactively in the [REST API documentation]”
   • [claimed-docs] “Use the interactive request tool to send live requests to GitLab.”
   • [claimed-docs] “GitLab supports authentication with HTTP Bearer or OAuth 2.0 credentials.”
   • [claimed-docs] “Docs, "OpenAPI": "GitLab documents its REST API using the OpenAPI 3.0 specification (formerly called Swagger)... The OpenAPI spec is autogen…”
   • [claimed-docs] “Docs, "REST API deprecations": "You should regularly review the following deprecations and make the recommended changes"; "GitLab will not m…”
   • [claimed-docs] “Personal access tokens”
   • [claimed-docs] “Make allows you to connect GitLab to more than 700 ready-made applications or to any API to integrate your DevSecOps processes and optimize …”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to GitHub
   GitHub✓fullclaimed7/10

   GitHub's fine-grained personal access tokens let a user grant a specific, minimal set of permissions per resource, and the REST API even returns an X-Accepted-GitHub-Permissions header showing exactly what scope is required for an endpoint — a direct implementation of least-privilege credentialing that any automated actor (including an agent) can use to authenticate to the API. Missing for 10: explicit documentation tying fine-grained PAT/GitHub App scoping specifically to Copilot/agent workflows (e.g., an agent-specific token-issuance flow) and independent hands-on confirmation.

   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions. Permissions define what resources the token can acc…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions.”
   • [claimed-docs] “Permissions define what resources the token can access via the API.”

   proof ↗⚑ flag

   GitLab~partialclaimed6/10

   GitLab supports scoped Personal Access Tokens and OAuth 2.0 credentials for programmatic API access (gitlab-docs-5, gitlab-docs-22, gitlab-docs-17, gitlab-docs-32), and its AI Agent Platform governance docs explicitly describe configuring Allow/Ask/Deny policies for agent tools enforced at execution time plus session/audit monitoring (gitlab-docs-44, gitlab-docs-45), which together support least-privilege credentialing for agents. However, there is no dedicated agent-specific token type or explicit scope list tailored to agent use-cases, and no independent/hands-on corroboration of this workflow. Missing for 10: a first-party doc showing agent-specific token scopes/creation flow, and independent verification that agent credential scoping works as described.

   • [claimed-docs] “Personal access tokens”
   • [claimed-docs] “For `http`, enter your [personal access token](/user/profile/personal_access_tokens/).”
   • [claimed-docs] “[Personal access tokens](/user/profile/personal_access_tokens/)”
   • [claimed-docs] “GitLab supports authentication with HTTP Bearer or OAuth 2.0 credentials.”
   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”
   • [claimed-docs] “Monitor AI agent sessions, audit logs, and developer exposure across a group.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to GitHub
   GitHub~partialprobed5/10

   GitHub documents official REST and GraphQL APIs plus authentication mechanisms (fine-grained PATs, permissions) that developers can build against, and provides a CLI and MCP server for programmatic access, but the evidence pack never names or links an official SDK (e.g., Octokit) for any language, nor SDK-specific docs, versioning, or install instructions. missing for 10: explicit official SDK libraries, language-specific package docs/installation, and SDK versioning/support guarantees.

   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions. Permissions define what resources the token can acc…”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line. When you're working from the command line, you can use…”
   • [probe] “official MCP server documented at https://github.com/github/github-mcp-server”
   • [probe] “official CLI documented at https://cli.github.com/”

   proof ↗⚑ flag

   GitLab~partialclaimed4/10

   GitLab documents a way to 'Interact programmatically with GitLab' (API access) which implies SDK-style build capability, but the evidence pack never names specific official SDKs (e.g., Python/JS/Go client libraries) or documents their agentic/AI-native use cases explicitly. missing for 10: named official SDK packages/languages, documentation of AI-agent-specific SDK usage, independent developer corroboration of building against these SDKs.

   • [claimed-docs] “Interact programmatically with GitLab.”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   GitHub—none0/10

   The evidence pack covers GitHub Copilot, CLI, REST/GraphQL APIs, MCP servers, and marketplace integrations, but contains no documentation or mention of GitHub's webhooks feature or event subscription mechanism for AI-native/agentic use. Although webhooks are a well-known GitHub capability, none of the provided citations reference them, so this applicable axis has no supporting evidence.

   ⚑ flag

   GitLab—none0/10

   The evidence pack covers REST API, personal access tokens, SSH keys, MCP server, and CLI, but contains no mention of webhooks or event subscription mechanisms anywhere. Since webhook subscription is a plausible and common capability for a platform like GitLab, this is a 'none' rather than 'na', but there is simply no supporting evidence.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   GitHub✓fullcommunity8/10

   GitHub Copilot generates AI-driven insights and suggestions directly from a user's own codebase: it reviews code changes with actionable suggested fixes (github-docs-25), autofixes vulnerabilities (github-docs-5, github-docs-14), and in Agent/Ask mode analyzes the repository to explain and generate needed edits (github-docs-13, github-docs-56). Independent hands-on comments confirm suggestions can closely match developer intent (github-comm-11). Missing for 10: independent verification of accuracy/insight quality beyond code suggestions (e.g., non-code data insights like issue/PR analytics) and more third-party validation of Autofix/code-review reliability.

   • [claimed-docs] “Apply fixes in seconds. Spend less time debugging and more time building features with Copilot Autofix.”
   • [claimed-docs] “The user switches from 'Ask' mode to 'Agent' mode from a dropdown menu, then sends the prompt 'Update the website to allow searching for run…”
   • [claimed-docs] “Leverage security campaigns and Copilot Autofix to reduce application vulnerabilities.”
   • [claimed-docs] “GitHub Copilot can review your code and provide feedback. Where possible, Copilot's feedback includes suggested changes which you can apply …”
   • [claimed-docs] “It suggests code as you type, answers questions about a codebase, reviews your changes, and works on tasks you assign it.”
   • [community] “Early Copilot user reports: 'Copilot guesses the exact code I want to write about one in ten times... when it guesses right, it feels like i…”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab documents GitLab Duo Chat and Agent Platform features that surface AI-generated insights and suggestions directly from the product's own data — Chat has access to issues, merge requests, commits, and CI/CD pipelines and maintains context (gitlab-docs-48), can answer natural-language queries like finding relevant MRs (gitlab-docs-39), and delegates tasks like code refactoring, security scans, and research to specialized AI agents (gitlab-docs-47). Security findings and agent-driven remediation also surface directly in merge requests/IDEs (gitlab-docs-1, gitlab-docs-29). Missing for 10: independent/hands-on evidence of insight quality or accuracy, and more detail on proactive (vs. query-driven) insight generation.

   • [claimed-docs] “Agents turn issues into merge requests, remediate vulnerabilities, and review code while your team stays in control.”
   • [claimed-docs] “you can ask “Find the merge request about authentication” and Chat searches for relevant merge req”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Chat has access to your project, including issues, merge requests, commits, and CI/CD pipelines, and Chat maintains context across conversat…”
   • [claimed-docs] “Discover agents and flows created by the GitLab team and community members.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   GitHub✓fullclaimed8/10

   GitHub Actions provides scheduled/event-triggered workflows that run autonomously in the background, and Copilot cloud agent can be assigned tasks that research, plan, and implement changes asynchronously without live supervision, with a centralized dashboard to track sessions. missing for 10: independent/hands-on validation of long-running autonomous agent reliability and more detail on failure/error handling in unattended runs.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Copilot can research a repository, create an implementation plan, and make code changes on a branch. You can review the diff, iterate, and c…”
   • [claimed-docs] “Copilot cloud agent can: * Research a repository * Create implementation plans * Fix bugs * Implement incremental new features * …”
   • [claimed-docs] “Use one centralized control page to jump between agent sessions, check progress, and stay in control without losing your place.”
   • [claimed-docs] “This quickstart shows how to ask questions about code and assign a coding task to Copilot cloud agent. It takes about ten minutes.”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab Duo Agent Platform explicitly supports background automation: custom flows/agents run tasks (code refactoring, security scans, research) autonomously in CI/CD pipelines, with sessions tracking execution, governance policies (Allow/Ask/Deny), and human-in-loop approval options — all first-party documented. Missing for 10: independent/hands-on evidence of these autonomous flows actually running unattended in production and more detail on triggering/scheduling mechanisms.

   • [claimed-docs] “Discover agents and flows created by the GitLab team and community members.”
   • [claimed-docs] “Custom agents are agents you create and configure for your team’s specific needs.”
   • [claimed-docs] “Custom flows are workflows you create to automate your team’s specific processes.”
   • [claimed-docs] “Sessions show the status and execution data for the agents and flows you’ve run.”
   • [claimed-docs] “Human in the loop approvals for chat-based GitLab Duo Agent Platform sessions”
   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”
   • [claimed-docs] “Monitor AI agent sessions, audit logs, and developer exposure across a group.”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Customize workflows for development, testing, security, and deployment. Teams orchestrate from above the lifecycle while agents execute with…”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to GitLab
   GitHub✓fullclaimed8/10

   GitHub Copilot is built directly into GitHub and supports true task delegation: switching to 'Agent' mode to have Copilot plan and execute multi-file changes, a cloud agent that can research a repo, create implementation plans, fix bugs and open PRs, custom specialized agents, and assigning PR reviews or mobile tasks to Copilot (github-docs-2,13,26,48,55,9,4,27,46). This goes well beyond simple autocomplete into genuine agentic delegation of work. missing for 10: independent/hands-on evidence specifically validating the delegation-to-agent workflow (community evidence only covers basic code-suggestion quality, not agent-mode task delegation).

   • [claimed-docs] “The user switches from 'Ask' mode to 'Agent' mode from a dropdown menu, then sends the prompt 'Update the website to allow searching for run…”
   • [claimed-docs] “The user switches from 'Ask' mode to 'Agent' mode from a dropdown menu, then sends the prompt 'Update the website to allow searching for run…”
   • [claimed-docs] “Copilot can research a repository, create an implementation plan, and make code changes on a branch. You can review the diff, iterate, and c…”
   • [claimed-docs] “Copilot cloud agent can: * Research a repository * Create implementation plans * Fix bugs * Implement incremental new features * …”
   • [claimed-docs] “This quickstart shows how to ask questions about code and assign a coding task to Copilot cloud agent. It takes about ten minutes.”
   • [claimed-docs] “Assign initial reviews to Copilot for greater speed and quality.”
   • [claimed-docs] “Manage projects and assign tasks to Copilot, all from your mobile device.”
   • [claimed-docs] “You can create specialized agents with tailored expertise for specific development tasks.”
   • [claimed-docs] “Use one centralized control page to jump between agent sessions, check progress, and stay in control without losing your place.”
   • [claimed-docs] “It suggests code as you type, answers questions about a codebase, reviews your changes, and works on tasks you assign it.”

   proof ↗⚑ flag

   GitLab✓fullclaimed9/10

   GitLab Duo Agent Platform provides a built-in AI assistant/agent system where users can delegate tasks (code refactoring, security scans, research) to specialized agents and flows, with sessions tracking execution, human-in-the-loop approvals, and governance controls, plus Duo Chat for conversational delegation with project context. Missing for 10: independent hands-on user reports validating real-world reliability/effectiveness of the agent delegation beyond first-party docs.

   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Discover agents and flows created by the GitLab team and community members.”
   • [claimed-docs] “Custom agents are agents you create and configure for your team’s specific needs.”
   • [claimed-docs] “Custom flows are workflows you create to automate your team’s specific processes.”
   • [claimed-docs] “Sessions show the status and execution data for the agents and flows you’ve run.”
   • [claimed-docs] “You can customize the Agent Platform to match your workflow, coding standards, or project requirements.”
   • [claimed-docs] “you can ask “Find the merge request about authentication” and Chat searches for relevant merge req”
   • [claimed-docs] “Human in the loop approvals for chat-based GitLab Duo Agent Platform sessions”
   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”
   • [claimed-docs] “Monitor AI agent sessions, audit logs, and developer exposure across a group.”
   • [claimed-docs] “Chat has access to your project, including issues, merge requests, commits, and CI/CD pipelines, and Chat maintains context across conversat…”
   • [claimed-docs] “Customize workflows for development, testing, security, and deployment. Teams orchestrate from above the lifecycle while agents execute with…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to GitHub
   GitHub✓fullclaimed8/10

   GitHub Copilot (Chat, Agent mode, CLI, and cloud agent) lets users issue natural-language prompts like 'Update the website to allow searching for running races by name' and have Copilot plan and implement changes, and Copilot CLI brings this to the terminal directly (github-docs-2, 13, 23, 26, 48, 55). This is well documented across multiple first-party surfaces (IDE, CLI, cloud agent, mobile task assignment). missing for 10: independent hands-on evidence validating reliability of NL-driven agent actions at scale, and clearer detail on limitations/failure modes of natural-language commands.

   • [claimed-docs] “The user switches from 'Ask' mode to 'Agent' mode from a dropdown menu, then sends the prompt 'Update the website to allow searching for run…”
   • [claimed-docs] “The user switches from 'Ask' mode to 'Agent' mode from a dropdown menu, then sends the prompt 'Update the website to allow searching for run…”
   • [claimed-docs] “The command-line interface (CLI) for GitHub Copilot allows you to use Copilot directly from your terminal.”
   • [claimed-docs] “Copilot can research a repository, create an implementation plan, and make code changes on a branch. You can review the diff, iterate, and c…”
   • [claimed-docs] “Copilot cloud agent can: * Research a repository * Create implementation plans * Fix bugs * Implement incremental new features * …”
   • [claimed-docs] “This quickstart shows how to ask questions about code and assign a coding task to Copilot cloud agent. It takes about ten minutes.”
   • [claimed-docs] “It suggests code as you type, answers questions about a codebase, reviews your changes, and works on tasks you assign it.”
   • [claimed-docs] “GitHub Copilot is built into GitHub, so you can use it without installing anything.”

   proof ↗⚑ flag

   GitLab✓fullclaimed7/10

   GitLab Duo Chat and the Agent Platform let users issue natural-language requests (e.g. 'Find the merge request about authentication') that trigger context-aware search, agent delegation, and even automated MR/issue creation, backed by first-party docs on Chat context, custom agents/flows, and governance controls. Missing for 10: independent/hands-on validation of natural-language command accuracy and broader coverage showing NL control extends to all major platform actions rather than mainly chat/search and agent triggering.

   • [claimed-docs] “you can ask “Find the merge request about authentication” and Chat searches for relevant merge req”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Chat has access to your project, including issues, merge requests, commits, and CI/CD pipelines, and Chat maintains context across conversat…”
   • [claimed-docs] “Agents turn issues into merge requests, remediate vulnerabilities, and review code while your team stays in control.”
   • [claimed-docs] “Custom agents are agents you create and configure for your team’s specific needs.”
   • [claimed-docs] “Custom flows are workflows you create to automate your team’s specific processes.”
   • [claimed-docs] “Human in the loop approvals for chat-based GitLab Duo Agent Platform sessions”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to GitLab
   GitHub—none0/10

   Evidence shows GitHub has REST and GraphQL API documentation (github-docs-40,41,51) and permission references (github-docs-18,19,21,42), but nothing describes an interactive reference with runnable/try-it examples, and the probe for a discoverable OpenAPI spec returned 404s across all candidate paths (github-probe-2), suggesting no machine-readable interactive spec is exposed.

   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [claimed-docs] “The GitHub GraphQL API offers flexibility and the ability to define precisely the data you want to fetch.”
   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.github.com/openapi.json, https://docs.github.com/swagger.json, https://docs.github.com/…”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab documents an interactive OpenAPI-based REST API reference where users can browse and test every endpoint live, seeing the curl command, request URL, and server response, with authentication via personal access tokens or OAuth — directly matching the story of an interactive, runnable API reference. Missing for 10: independent/hands-on corroboration beyond GitLab's own docs, and no explicit AI-native framing (e.g., LLM-consumable examples) tied specifically to this reference tool.

   • [claimed-docs] “You can browse and test every endpoint interactively in the [REST API documentation]”
   • [claimed-docs] “Use the interactive request tool to send live requests to GitLab.”
   • [claimed-docs] “GitLab supports authentication with HTTP Bearer or OAuth 2.0 credentials.”
   • [claimed-docs] “For `http`, enter your [personal access token](/user/profile/personal_access_tokens/).”
   • [claimed-docs] “The tool displays the `curl` command, the full request URL, and the server response.”
   • [claimed-docs] “Docs, "OpenAPI": "GitLab documents its REST API using the OpenAPI 3.0 specification (formerly called Swagger)... The OpenAPI spec is autogen…”
   • [claimed-docs] “You can browse and test every endpoint interactively in the REST API documentation.”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to GitLab
   GitHub—none0/10

   While GitHub documents its REST and GraphQL APIs (github-docs-40/41), the evidence pack shows an explicit probe for a machine-readable OpenAPI/Swagger spec at all standard paths (openapi.json, swagger.json, etc.) returning 404, with no alternate documented location for a downloadable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.github.com/openapi.json, https://docs.github.com/swagger.json, https://docs.github.com/…”
   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”

   proof ↗⚑ flag

   GitLab✓fullclaimed9/10

   GitLab documents its REST API using OpenAPI 3.0, autogenerated from API code, with the raw spec file available in the monorepo (openapi_v2.yaml), plus an interactive documentation viewer for browsing/testing endpoints. This directly satisfies the machine-readable API spec download story. Missing for 10: no independent/community confirmation of the spec's completeness or ease of direct download outside vendor docs.

   • [claimed-docs] “Docs, "OpenAPI": "GitLab documents its REST API using the OpenAPI 3.0 specification (formerly called Swagger)... The OpenAPI spec is autogen…”
   • [claimed-docs] “You can browse and test every endpoint interactively in the [REST API documentation]”
   • [claimed-docs] “Use the interactive request tool to send live requests to GitLab.”
   • [claimed-docs] “You can browse and test every endpoint interactively in the REST API documentation.”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to GitHub
   GitHub~partialclaimed3/10

   GitHub Codespaces offers a 'full, cloud-based development environment' (github-docs-3) that could serve as an isolated sandbox for coding/testing, but there is no explicit documentation tying this to safely testing against non-production data or separating staging from production. Missing for 10: explicit sandbox/staging environment separate from production data, evidence of data isolation guarantees, and confirmation that AI agents (Copilot cloud agent) operate in an isolated sandbox rather than live repos/production systems.

   • [claimed-docs] “Launch a full, cloud-based development environment in seconds.”
   • [claimed-docs] “Copilot can research a repository, create an implementation plan, and make code changes on a branch. You can review the diff, iterate, and c…”
   • [claimed-docs] “Copilot cloud agent can: * Research a repository * Create implementation plans * Fix bugs * Implement incremental new features * …”

   proof ↗⚑ flag

   GitLab—none0/10

   While GitLab offers CI/CD build-and-test capabilities and an AI agent governance framework (Allow/Ask/Deny policies, session monitoring, human-in-the-loop approvals), the evidence pack contains no mention of a dedicated sandbox/staging environment isolated from production data for AI agents or AI-native testing workflows. Missing for 10: explicit sandbox/staging environment documentation, evidence of production-data isolation for agent test runs, and any hands-on confirmation that AI agent testing doesn't touch production data.

   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”
   • [claimed-docs] “Monitor AI agent sessions, audit logs, and developer exposure across a group.”
   • [claimed-docs] “Human in the loop approvals for chat-based GitLab Duo Agent Platform sessions”
   • [claimed-docs] “Get started with GitLab CI/CD Build and test your application.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to GitLab
   GitHub—none0/10

   The evidence pack documents GitHub's REST and GraphQL APIs and fine-grained token permissions, but contains no mention of API versioning schemes or any documented deprecation policy/timeline for those APIs. Missing for 10: explicit API version headers/dates, a published deprecation schedule, and changelog/sunset notices.

   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions. Permissions define what resources the token can acc…”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab documents its REST API with OpenAPI 3.0 spec autogenerated from code, explicit versioning (v4) with semantic versioning, and a dedicated deprecations page instructing users to review and adapt to upcoming changes ahead of removal. This directly matches the story of versioned APIs with a documented deprecation policy. Missing for 10: no independent/community corroboration of how deprecation policy plays out in practice, and no explicit long-term support timeline details beyond the semantic versioning statement.

   • [claimed-docs] “Docs, "OpenAPI": "GitLab documents its REST API using the OpenAPI 3.0 specification (formerly called Swagger)... The OpenAPI spec is autogen…”
   • [claimed-docs] “Docs, "REST API deprecations": "You should regularly review the following deprecations and make the recommended changes"; "GitLab will not m…”
   • [claimed-docs] “Automate your workflows and build integrations with the GitLab REST API”
   • [claimed-docs] “You can browse and test every endpoint interactively in the [REST API documentation]”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   GitHub~partialprobed5/10

   GitHub exposes REST and GraphQL APIs plus a scriptable CLI that AI-native users could combine to perform bulk operations (e.g., scripting across many issues/repos), and GitHub Actions can automate repeated workflows. However, there is no first-party documented 'bulk operations' feature or Copilot/agent capability explicitly designed for acting across many items at once—only the underlying API/CLI primitives are shown. Missing for 10: explicit bulk-edit/bulk-action documentation, an AI-agent example of operating across many items, and independent evidence of this being used at scale.

   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line. When you're working from the command line, you can use…”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line.”
   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [probe] “official CLI documented at https://cli.github.com/”

   proof ↗⚑ flag

   GitLab~partialclaimed5/10

   GitLab's REST API and CLI expose programmatic access that lets automation manage 'CI/CD processes across multiple projects' and control access 'across your organization,' enabling scripted bulk actions, and the Duo Agent Platform can delegate routine tasks to agents across a codebase. However, there is no explicit documentation of a dedicated bulk-operations endpoint/UI (e.g., bulk-close issues, bulk-update MRs) or evidence of an agent performing large batch operations in one call. Missing for 10: explicit bulk-action API/UI documentation, hands-on evidence of bulk operations at scale, and confirmation that Duo agents can act on many items simultaneously rather than one at a time.

   • [claimed-docs] “Automate your workflows and build integrations with the GitLab REST API”
   • [claimed-docs] “Manage CI/CD processes across multiple projects with precision.”
   • [claimed-docs] “Control user access programmatically to maintain consistent permissions across your organization.”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Custom flows are workflows you create to automate your team’s specific processes.”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to GitHub
   GitHub✓fullclaimed7/10

   GitHub Actions ('Automate, customize, and execute your software development workflows right in your repository') is exactly the mechanism for defining event-triggered automation rules (e.g., on push, PR, issue, schedule), which is a first-party, mainstream GitHub capability. Missing for 10: detailed docs snippets showing the actual trigger/event syntax (on: push, on: issues, etc.) and independent hands-on corroboration of automation reliability/depth.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”

   proof ↗⚑ flag

   GitLab~partialclaimed7/10

   GitLab's CI/CD pipelines are inherently event-driven (triggered by push, merge request, schedule events), and the Duo Agent Platform lets users define 'custom flows' and 'custom agents' that automate team-specific processes, with policies (Allow/Ask/Deny) governing when agent tools execute — a clear rules-on-events automation model beyond simple chat. Missing for 10: explicit documentation of rule/condition syntax (e.g., CI 'rules:' keyword, webhook trigger configuration) and independent/hands-on evidence confirming these AI Agent Platform flows work reliably in practice.

   • [claimed-docs] “Custom flows are workflows you create to automate your team’s specific processes.”
   • [claimed-docs] “You can customize the Agent Platform to match your workflow, coding standards, or project requirements.”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”
   • [claimed-docs] “Discover agents and flows created by the GitLab team and community members.”
   • [claimed-docs] “Build and test your application.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   GitHub—none0/10

   The evidence describes GitHub Actions only in general terms ('automate...workflows') without any explicit mention of scheduled/cron-triggered or recurring job capability, so per the evidence-only rule this mainstream capability cannot be credited as documented here.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack covers CI/CD, agent flows, and API automation broadly, but nothing explicitly documents recurring/scheduled job triggers (e.g., pipeline schedules, cron-based automation, or recurring agent flow runs) for AI-native users.

   ⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   GitHub~partialclaimed5/10

   GitHub Actions workflows live as code in the repository (github-docs-38), which implies they inherit git's native versioning and rollback via commits/PRs, but the evidence pack never explicitly documents PR-based review or revert workflows applied specifically to automations/workflow files. Missing for 10: explicit documentation of reviewing workflow-file changes via pull requests, rolling back a workflow to a prior version, and any audit/history UI specific to Actions.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”

   proof ↗⚑ flag

   GitLab~partialclaimed5/10

   GitLab's Duo Agent Platform lets users create custom agents/flows, review execution via session logs, and enforce human-in-the-loop approvals and governance policies (audit logs, allow/ask/deny), which supports review and monitoring of automations. However, there is no explicit documentation of versioning agent/flow definitions or rolling back a previously run automation/flow to an earlier state — this is only implied by GitLab's general git-based/CI-as-code model, not stated for the Agent Platform specifically. Missing for 10: explicit version-history UI for agents/flows, a documented rollback/revert mechanism for automations, and independent evidence of this workflow in practice.

   • [claimed-docs] “Custom agents are agents you create and configure for your team’s specific needs.”
   • [claimed-docs] “Custom flows are workflows you create to automate your team’s specific processes.”
   • [claimed-docs] “Sessions show the status and execution data for the agents and flows you’ve run.”
   • [claimed-docs] “You can customize the Agent Platform to match your workflow, coding standards, or project requirements.”
   • [claimed-docs] “Human in the loop approvals for chat-based GitLab Duo Agent Platform sessions”
   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”
   • [claimed-docs] “Monitor AI agent sessions, audit logs, and developer exposure across a group.”

   proof ↗⚑ flag

Deployment

1. developerAutomate application deployments as part of my CI/CD pipeline

   weight 2 · round to GitLab
   GitHub✓fullclaimed7/10

   GitHub Actions is explicitly positioned for CI/CD automation ('Ship faster with secure, reliable CI/CD', 'Automate...software development workflows...with GitHub Actions'), and the Marketplace shows real deployment integrations (Render CI/CD, Shopify 'push to deploy', mobile CI/CD apps) that developers can wire into pipelines. Missing for 10: deeper first-party docs on deployment-specific features (environments, approval gates, rollback) and independent hands-on confirmation of a deployment pipeline working end-to-end.

   • [claimed-docs] “Ship faster with secure, reliable CI/CD.”
   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Continuous integration and deploys with Render, the modern cloud for ambitious developers”
   • [claimed-docs] “Build themes and headless faster with Shopify for GitHub. Connect any repository, then push to deploy”
   • [claimed-docs] “Cloud-based continuous integration and delivery for Android, iOS, Flutter, React Native, Ionic and Unity projects”

   proof ↗⚑ flag

   GitLab✓fullclaimed9/10

   GitLab CI/CD natively supports build/test/deploy pipelines, with docs on getting started with CI/CD, deployment integrations (Pulumi push-to-deploy, env0 Terraform GitOps, Kubernetes agent for cloud-native deployment/monitoring), and multi-project pipeline orchestration via API. This is core, well-documented GitLab functionality with both first-party docs and ecosystem/partner integrations reinforcing deployment automation. Missing for 10: independent hands-on validation specifically of deployment pipeline reliability (community evidence only covers CI runner/performance issues broadly, not deployment automation itself).

   • [claimed-docs] “Get started with GitLab CI/CD Build and test your application.”
   • [claimed-docs] “Manage CI/CD processes across multiple projects with precision.”
   • [claimed-docs] “Manage your infrastructure-as-code by using env0 with native support for GitLab. Automate your GitOps workflow to run Terraform Plan on Merg…”
   • [claimed-docs] “The Pulumi integration with GitLab CI makes it easy to create and manage infrastructure stacks based on commits to specific Git branches so …”
   • [claimed-docs] “You can connect your Kubernetes cluster with GitLab to deploy, manage, and monitor your cloud-native solutions.”
   • [claimed-docs] “Customize workflows for development, testing, security, and deployment.”

   proof ↗⚑ flag

2. devops-leadMap incidents to deployments and require change approval before releases

   weight 1 · round drawn
   GitHub—none0/10

   The evidence pack contains only generic CI/CD and Actions references (github-docs-11, github-docs-38) but nothing on deployment environments, required-reviewer approval gates, or incident-to-deployment traceability/mapping, which are the specific capabilities this story asks about. Missing for 10: environment protection rules/required approvals before deploy, incident tracking or linking incidents to specific deployments, any audit trail connecting rollbacks/incidents to release history.

   • [claimed-docs] “Ship faster with secure, reliable CI/CD.”
   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack contains no mention of incident management, incident-to-deployment mapping, or release/change approval gates (e.g., protected environments, deployment approval rules). Only generic compliance-control and audit-evidence claims (gitlab-docs-20) appear, which do not address linking incidents to deployments or requiring approvals before releases.

   ⚑ flag

Dev environments

1. developerLaunch a ready-to-code cloud-based development environment in seconds

   weight 2 · round to GitHub
   GitHub~partialclaimed5/10

   GitHub's marketing page explicitly claims 'Launch a full, cloud-based development environment in seconds' (github-docs-3), directly matching the story, but this is a single thin marketing line with no elaboration on Codespaces features, setup workflow, or independent/hands-on corroboration in the evidence pack. Missing for 10: detailed docs on Codespaces setup/config, first-hand user reports confirming fast launch times, and any independent verification of the 'seconds' claim.

   • [claimed-docs] “Launch a full, cloud-based development environment in seconds.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack contains no mention of GitLab Workspaces, a Web IDE, or any other cloud-based, ready-to-code development environment feature — only CI/CD, API, security scanning, and Duo Agent Platform content, none of which addresses instant cloud dev environments. Since a DevOps platform could plausibly ship such a feature, the axis applies but is unevidenced.

   ⚑ flag

Pipeline authoring

1. developerReuse community-built CI/CD actions or plugins in my pipelines

   weight 2 · round to GitHub
   GitHub✓fullclaimed8/10

   GitHub Actions supports pulling in reusable community actions, and the GitHub Marketplace explicitly lists third-party CI/CD apps/actions (Render, Bitrise, Appcircle, Shopify, etc.) that developers can plug into pipelines, backed by official docs on Actions and the Marketplace ecosystem. missing for 10: independent/hands-on developer testimony specifically about reusing marketplace CI/CD actions (evidence is vendor docs/marketplace listings only).

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Extend your stack with apps, actions, and AI models.”
   • [claimed-docs] “Tools from the community and partners to simplify tasks and automate processes”
   • [claimed-docs] “Build on your workflow with apps that integrate with GitHub”
   • [claimed-docs] “Continuous integration and deploys with Render, the modern cloud for ambitious developers”
   • [claimed-docs] “Cloud-based continuous integration and delivery for Android, iOS, Flutter, React Native, Ionic and Unity projects”
   • [claimed-docs] “Build themes and headless faster with Shopify for GitHub. Connect any repository, then push to deploy”

   proof ↗⚑ flag

   GitLab~partialclaimed5/10

   Evidence shows numerous third-party/partner tools that plug directly into GitLab CI/CD pipelines (Semgrep, Aqua Trivy as default scanner, DigiCert code signing, env0 Terraform, Pulumy push-to-deploy) and a community 'AI Catalog' of agents/flows built by GitLab and community members, indicating reusable pipeline integrations exist. However there's no explicit mention of GitLab's dedicated CI/CD component/action marketplace (e.g., a 'CI/CD Catalog' of reusable YAML components analogous to GitHub Actions Marketplace), so the story is only partly evidenced. Missing for 10: explicit documentation of a reusable CI/CD components/actions catalog, examples of importing a community pipeline template, and independent developer confirmation of reuse workflow.

   • [claimed-docs] “Aqua Trivy is the fastest way for DevSecOps and security teams to shift left and get started with vulnerability and infrastructure as code (…”
   • [claimed-docs] “DigiCert® Software Trust Manager automates code signing in GitLab CI/CD pipelines, cryptographically signing artifacts before release. Signi…”
   • [claimed-docs] “Manage your infrastructure-as-code by using env0 with native support for GitLab. Automate your GitOps workflow to run Terraform Plan on Merg…”
   • [claimed-docs] “The Pulumi integration with GitLab CI makes it easy to create and manage infrastructure stacks based on commits to specific Git branches so …”
   • [claimed-docs] “Semgrep is a fast, open-source, static analysis tool that finds bugs and enforces code standards at editor, commit, and CI time. Precise rul…”
   • [claimed-docs] “Discover agents and flows created by the GitLab team and community members.”

   proof ↗⚑ flag

2. developerDefine CI/CD pipelines as code using a YAML syntax

   weight 3 · round to GitHub
   GitHub✓fullcommunity8/10

   GitHub Actions is documented as GitHub's native CI/CD system, explicitly described as letting developers 'automate, customize, and execute software development workflows right in your repository' and 'ship faster with secure, reliable CI/CD' — Actions workflows are the standard code-as-config CI/CD mechanism. Missing for 10: explicit documentation snippet showing YAML workflow syntax itself and independent hands-on confirmation of writing pipeline YAML.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Ship faster with secure, reliable CI/CD.”
   • [community] “Complaint that GitHub Actions outages seem to correlate with new feature releases, impacting the dev team and infra 'seemingly every week.'”
   • [community] “User credits GitLab for 'pushing the market forward on affordable collaborative development' and says their team moved to GitHub only after …”

   proof ↗⚑ flag

   GitLab~partialclaimed3/10

   Evidence only vaguely references CI/CD capability (e.g., 'Build and test your application', 'Manage CI/CD processes across multiple projects with precision') but never explicitly confirms YAML-based pipeline definition (e.g., .gitlab-ci.yml syntax) or documents its structure. missing for 10: explicit mention of .gitlab-ci.yml YAML pipeline definition, pipeline syntax examples, and independent corroboration of YAML-as-code CI/CD authoring.

   • [claimed-docs] “Build and test your application.”
   • [claimed-docs] “Manage CI/CD processes across multiple projects with precision.”
   • [claimed-docs] “Customize workflows for development, testing, security, and deployment.”
   • [claimed-docs] “Customize workflows for development, testing, security, and deployment. Teams orchestrate from above the lifecycle while agents execute with…”

   proof ↗⚑ flag

Runners

1. devops-leadRun CI/CD jobs on runners hosted by the platform without managing infrastructure

   weight 3 · round to GitHub
   GitHub~partialcommunity6/10

   GitHub Actions is documented as providing CI/CD 'right in your repository' (github-docs-38) and marketed as 'secure, reliable CI/CD' (github-docs-11), implying GitHub-hosted runners without customer-managed infrastructure, and GitHub also supports self-hosted runners as an alternative option (github-comm-20 notes org-level self-hosted runner gaps, implying hosted runners are the default). However, community evidence reports recurring GitHub Actions outages 'seemingly every week' correlating with feature releases (github-comm-18) and broader platform outage concerns (github-comm-1, github-comm-2), which undercut confidence in the 'without managing infrastructure' reliability promise even though the core hosted-runner capability itself is not disputed. Missing for 10: explicit documentation/specs of hosted runner types, concurrency limits, or setup steps, and independent hands-on confirmation of smooth, infrastructure-free operation rather than just marketing taglines and outage complaints.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Ship faster with secure, reliable CI/CD.”
   • [community] “Complaint that GitHub Actions outages seem to correlate with new feature releases, impacting the dev team and infra 'seemingly every week.'”
   • [community] “User notes GitHub still lacks self-hosted runners for organizations, which would make it a stronger alternative to GitLab for teams.”
   • [community] “Ghostty project is leaving GitHub; author kept a journal marking an 'X' next to every date a GitHub outage negatively impacted his ability t…”

   proof ↗⚑ flag

   GitLab~partialcommunity3/10

   The pack only offers a generic docs link ('Build and test your application', gitlab-docs-8) pointing to GitLab CI/CD documentation, with no specific mention of GitLab.com's SaaS-hosted shared runners or the ability to run jobs without managing infrastructure. Community evidence even highlights CI reliability problems ('CI workers did not run' gitlab-comm-1), which weakens confidence rather than confirming hosted-runner ease. Missing for 10: explicit documentation of GitLab.com shared/hosted runners, runner autoscaling, and infra-free operation, plus independent confirmation it works reliably.

   • [claimed-docs] “Build and test your application.”
   • [community] “GitLab's recent performance has been abysmal... we've had entire days where the team was unable to deploy because the CI workers did not run…”

   proof ↗⚑ flag

2. devops-leadGet centralized visibility into CI/CD workflow runs across the organization

   weight 2 · round to GitLab
   GitHub~partialclaimed3/10

   GitHub Actions is documented as the CI/CD engine ('Automate...workflows...with GitHub Actions' and 'Ship faster with secure, reliable CI/CD'), implying pipelines exist, but the evidence pack contains no mention of an organization-wide dashboard, insights page, or cross-repo workflow-run visibility feature that a devops-lead would use. Missing for 10: org-level Actions insights/usage dashboard, cross-repo run aggregation, audit/reporting APIs for workflow runs, and any independent corroboration of centralized visibility.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Ship faster with secure, reliable CI/CD.”

   proof ↗⚑ flag

   GitLab~partialclaimed5/10

   Evidence shows GitLab enables cross-project CI/CD management via API (gitlab-docs-13), compliance controls and audit evidence collected 'in every pipeline' (gitlab-docs-20), and Duo Chat that has access to CI/CD pipeline context (gitlab-docs-48), suggesting some organization-wide CI/CD oversight capability. However, there is no explicit evidence of a dedicated centralized CI/CD dashboard, pipeline analytics view, or org/group-level pipeline status reporting UI. Missing for 10: a documented CI/CD dashboard or analytics view aggregating pipeline runs across projects/groups, independent/hands-on confirmation of such visibility, and detail on how audit-ready pipeline evidence is surfaced centrally.

   • [claimed-docs] “Manage CI/CD processes across multiple projects with precision.”
   • [claimed-docs] “Apply controls for compliance and collect audit-ready evidence automatically in every pipeline.”
   • [claimed-docs] “Chat has access to your project, including issues, merge requests, commits, and CI/CD pipelines, and Chat maintains context across conversat…”
   • [claimed-docs] “SAST, DAST, and compliance in every pipeline.”

   proof ↗⚑ flag

3. devops-leadRun CI/CD jobs on my own self-hosted or private runners

   weight 2 · round drawn
   GitHub—none0/10

   The evidence pack only shows generic GitHub Actions marketing copy (github-docs-38, github-docs-11) with no documentation of self-hosted or private runner configuration, and the one specific piece of evidence on this topic (github-comm-20) states that GitHub 'still lacks self-hosted runners for organizations,' i.e. contradicts the story rather than supporting it.

   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Ship faster with secure, reliable CI/CD.”
   • [community] “User notes GitHub still lacks self-hosted runners for organizations, which would make it a stronger alternative to GitLab for teams.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack discusses GitLab CI/CD generally (build/test, multi-project CI/CD management) and self-hosting the GitLab instance itself (Linux package, Docker images, Helm chart), but never mentions GitLab Runners, runner registration, or private/self-hosted runner configuration — the specific capability the story asks about is unevidenced here.

   • [claimed-docs] “Build and test your application.”
   • [claimed-docs] “Manage CI/CD processes across multiple projects with precision.”
   • [claimed-docs] “The Linux package includes services and tools to install GitLab without laborious configuration.”
   • [claimed-docs] “If you're using cluster management, we recommend the Helm chart or the Operator for installing cloud-native GitLab.”
   • [claimed-docs] “GitLab maintains a set of official Docker images based on the Linux package.”
   • [claimed-docs] “If the Linux package isn't available for your distribution, you can self-compile GitLab.”

   proof ↗⚑ flag

Chat notifications

1. developerSync repository notifications and activity with chat tools

   weight 1 · round to GitHub
   GitHub~partialclaimed5/10

   GitHub Marketplace lists a Slack integration ('Connect your code without leaving Slack') enabling repo activity/notifications to sync with chat, and Atlassian integration also syncs dev activity, but the evidence pack lacks first-party GitHub docs detailing notification-sync configuration, scope, or independent hands-on confirmation of reliability. missing for 10: official GitHub docs on the Slack/Teams integration setup and notification types, independent user confirmation that sync works well in practice.

   • [claimed-docs] “Connect your code without leaving Slack”
   • [claimed-docs] “GitHub for Atlassian unifies data, automates workflows, and syncs development across GitHub, Jira, and your Atlassian apps”
   • [claimed-docs] “Build on your workflow with apps that integrate with GitHub”

   proof ↗⚑ flag

   GitLab—none0/10

   No evidence pack items mention Slack, Microsoft Teams, chat notifications, or integrations that sync repository activity to chat tools; evidence focuses on CI/CD, security scanning, REST API, and MCP/CLI docs.

   ⚑ flag

External ci cd integration

1. devops-leadConnect the platform to external CI/CD tools instead of using its native pipelines

   weight 1 · round to GitHub
   GitHub✓fullclaimed7/10

   GitHub's own Marketplace lists third-party CI/CD integrations (Render, mobile CI/CD tools) that plug into GitHub repos as alternatives to native Actions pipelines, and GitHub explicitly markets an extensible apps/actions ecosystem. This confirms devops leads can wire in external CI/CD tools rather than relying solely on GitHub Actions. Missing for 10: deeper first-party docs on webhook/status-API integration patterns for custom CI/CD tools, and independent hands-on confirmation of using a non-Actions CI/CD pipeline end-to-end with GitHub.

   • [claimed-docs] “Continuous integration and deploys with Render, the modern cloud for ambitious developers”
   • [claimed-docs] “Cloud-based continuous integration and delivery for Android, iOS, Flutter, React Native, Ionic and Unity projects”
   • [claimed-docs] “Extend your stack with apps, actions, and AI models.”
   • [claimed-docs] “Build on your workflow with apps that integrate with GitHub”
   • [claimed-docs] “Tools from the community and partners to simplify tasks and automate processes”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack shows extensive integrations (webhooks, API, third-party security scanners, IaC tools) and a robust REST API for building custom automation, but nothing documents official support for swapping GitLab's native CI/CD engine for an external CI/CD tool (e.g., Jenkins, CircleCI, TravisCI) as a replacement runner/orchestrator. One community note even states third-party CI services like TravisCI generally don't integrate with GitLab, reinforcing the gap. missing for 10: any documentation of connecting/using an external CI/CD orchestrator instead of GitLab's native pipelines, official integration guides for competing CI tools, evidence of webhook-triggered external pipeline execution replacing GitLab CI.

   • [community] “I love Gitlab but sadly, quite a lot of services that offer free accounts for open source projects (TravisCI comes to mind), generally don't…”
   • [claimed-docs] “Automate your workflows and build integrations with the GitLab REST API”
   • [claimed-docs] “Make allows you to connect GitLab to more than 700 ready-made applications or to any API to integrate your DevSecOps processes and optimize …”

   proof ↗⚑ flag

Marketplace extensions

1. developerExtend my stack with third-party apps, actions, and AI models from a marketplace

   weight 2 · round to GitHub
   GitHub✓fullclaimed9/10

   GitHub Marketplace explicitly offers apps, actions, and AI models to extend the developer stack, with documented examples spanning CI/CD, deployment, project management, chat, and IDE integrations (github-docs-10, github-docs-22, github-docs-35, github-intdir-1..7), plus Copilot's multi-model support (github-docs-34, github-docs-43). missing for 10: independent hands-on review specifically validating marketplace app/action installation quality or breadth beyond vendor listings.

   • [claimed-docs] “Extend your stack with apps, actions, and AI models.”
   • [claimed-docs] “Build on your workflow with apps that integrate with GitHub”
   • [claimed-docs] “Tools from the community and partners to simplify tasks and automate processes”
   • [claimed-docs] “Continuous integration and deploys with Render, the modern cloud for ambitious developers”
   • [claimed-docs] “Keep your Lovable project synced both ways”
   • [claimed-docs] “Login to OpenCode through Github Copilot”
   • [claimed-docs] “GitHub for Atlassian unifies data, automates workflows, and syncs development across GitHub, Jira, and your Atlassian apps”
   • [claimed-docs] “Connect your code without leaving Slack”
   • [claimed-docs] “Build themes and headless faster with Shopify for GitHub. Connect any repository, then push to deploy”
   • [claimed-docs] “Cloud-based continuous integration and delivery for Android, iOS, Flutter, React Native, Ionic and Unity projects”
   • [claimed-docs] “GitHub Copilot supports multiple AI models, each with different strengths. Some prioritize speed and cost-efficiency, while others are optim…”
   • [claimed-docs] “Automatically select the best model for each task.”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab documents an extensive technology-partners marketplace (AI coding agents like Cursor, Kilo, OpenCode, Greptile; security tools like Semgrep, Trivy; automation via Make with 700+ apps; docs, PM, and chat integrations) plus a dedicated AI Catalog/Agent Platform for discovering and configuring third-party agents/flows and AI models, with governance controls for allow/deny policies. missing for 10: independent/hands-on validation of marketplace install experience and breadth/quality curation beyond vendor listing pages.

   • [claimed-docs] “Cursor is the best way to code with AI used by millions of developers and over 50,000 enterprises. You can use any frontier model, with a po…”
   • [claimed-docs] “Greptile is building the unified validation layer for code, starting with an AI-powered code review agent that analyzes PRs with full codeba…”
   • [claimed-docs] “Kilo is the open-source agentic engineering platform for GitLab. Powerful CLI and IDE agents autonomously plan, code, and verify tasks. Inte…”
   • [claimed-docs] “Make allows you to connect GitLab to more than 700 ready-made applications or to any API to integrate your DevSecOps processes and optimize …”
   • [claimed-docs] “Aqua Trivy is the fastest way for DevSecOps and security teams to shift left and get started with vulnerability and infrastructure as code (…”
   • [claimed-docs] “Semgrep is a fast, open-source, static analysis tool that finds bugs and enforces code standards at editor, commit, and CI time. Precise rul…”
   • [claimed-docs] “Discover agents and flows created by the GitLab team and community members.”
   • [claimed-docs] “Custom agents are agents you create and configure for your team’s specific needs.”
   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”

   proof ↗⚑ flag

Security tool integrations

1. devops-leadInstall third-party security scanning integrations directly from a security tab

   weight 1 · round to GitHub
   GitHub~partialclaimed3/10

   Evidence shows GitHub has a general Marketplace for third-party apps/integrations (github-docs-22, github-intdir-*) and native security features like secret scanning, push protection, and Copilot Autofix (github-docs-7, github-docs-14, github-docs-15), but no evidence specifically describes installing third-party security scanning tools directly from a repository's Security tab. Missing for 10: documentation of the Security tab's integration/install UI, examples of third-party scanners (e.g. Snyk, Semgrep) being installed via that tab, and any workflow showing SARIF-based third-party results surfacing there.

   • [claimed-docs] “Build on your workflow with apps that integrate with GitHub”
   • [claimed-docs] “Detect, prevent, and remediate leaked secrets across your organization.”
   • [claimed-docs] “Leverage security campaigns and Copilot Autofix to reduce application vulnerabilities.”
   • [claimed-docs] “GitHub push protection confirms and displays an active secret, and blocks the push.”
   • [claimed-docs] “Continuous integration and deploys with Render, the modern cloud for ambitious developers”
   • [claimed-docs] “Cloud-based continuous integration and delivery for Android, iOS, Flutter, React Native, Ionic and Unity projects”

   proof ↗⚑ flag

   GitLab—none0/10

   Evidence shows GitLab consolidates its own built-in scanners (SAST, SCA, Secret Detection, DAST) into one platform rather than offering a marketplace/security tab for installing third-party scanning integrations. No mention of a security tab UI for adding third-party scanners exists in the evidence pack.

   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform.”
   • [claimed-docs] “Security findings appear directly in merge requests and IDEs.”

   proof ↗⚑ flag

Licensing cost management

1. devops-leadMake a single annual commitment and flexibly allocate spend across seat-based and usage-based licensing

   weight 1 · round to GitLab
   GitHub—none0/10

   The evidence pack contains no mention of annual commitments, seat-based vs usage-based licensing flexibility, or spend allocation/billing governance features; only a single note about paying extra for exhausted AI credits (individual usage-based billing), which does not address enterprise annual commitment or flexible seat/usage allocation.

   • [claimed-docs] “If you exhaust your AI credits, you can pay extra to keep working.”
   • [claimed-docs] “This plan includes limited access to a selection of Copilot features allowing you to try AI-powered coding assistance at no cost.”

   proof ↗⚑ flag

   GitLab~partialclaimed6/10

   gitlab-docs-4 directly claims a single annual commitment with flexible allocation across seat-based and usage-based licensing, matching the story closely, but this is a single first-party marketing line with no independent corroboration, pricing documentation, or hands-on confirmation of how allocation actually works. Missing for 10: detailed pricing/licensing docs explaining mechanics, third-party or customer confirmation, and any evidence of how re-allocation is executed in practice.

   • [claimed-docs] “make one annual commitment and steer their spend across seat-based licenses and usage-based credits without re-procurement”

   proof ↗⚑ flag

Onboarding

1. developerAccess built-in resources to learn the Git version control system

   weight 1 · round to GitLab
   GitHub—none0/10

   The evidence pack covers GitHub CLI, SSH setup, Copilot, APIs, and marketplace integrations, but contains no citation of built-in resources for learning Git itself (e.g., Git tutorials, Git Handbook, GitHub Skills courses). While such a capability is plausible for a platform like GitHub, nothing in the evidence documents it.

   ⚑ flag

   GitLab✓fullclaimed8/10

   GitLab docs include a dedicated 'Work with the Git version control system' resource plus related guides (personal access tokens, SSH keys) that teach developers Git fundamentals within the built-in documentation platform. This directly matches the story of accessing built-in resources to learn Git. Missing for 10: independent/community corroboration that developers actually use these docs to learn Git, and more depth on tutorial-style learning content beyond reference docs.

   • [claimed-docs] “Work with the Git version control system.”
   • [claimed-docs] “Personal access tokens”
   • [claimed-docs] “SSH keys”

   proof ↗⚑ flag

Policy enforcement

1. devops-leadRequire automated change approval workflows before code reaches production

   weight 1 · round to GitLab
   GitHub—none0/10

   The evidence pack contains no mention of branch protection rules, required reviewers, CODEOWNERS enforcement, or deployment environment approval gates that would block code from reaching production without sign-off. Docs only reference Copilot-assigned code reviews and generic CI/CD messaging, neither of which describes a governance/approval-gating workflow.

   ⚑ flag

   GitLab~partialclaimed4/10

   GitLab's docs gesture at compliance controls, audit-ready evidence, and customizable workflows for deployment, and even mention 'human in the loop approvals' for Duo Agent Platform sessions, but the evidence pack never explicitly documents core mechanisms like required merge-request approvers, protected branches, or approval gates blocking production deploys. Missing for 10: explicit documentation of merge request approval rules/required approvers, protected branch/environment gating before production, and independent confirmation these controls are enforced in practice.

   • [claimed-docs] “Apply controls for compliance and collect audit-ready evidence automatically in every pipeline.”
   • [claimed-docs] “SAST, DAST, and compliance in every pipeline.”
   • [claimed-docs] “Customize workflows for development, testing, security, and deployment.”
   • [claimed-docs] “Customize workflows for development, testing, security, and deployment. Teams orchestrate from above the lifecycle while agents execute with…”
   • [claimed-docs] “Human in the loop approvals for chat-based GitLab Duo Agent Platform sessions”

   proof ↗⚑ flag

2. devops-leadEnforce coding standards and CI/CD policies across all teams and repositories

   weight 2 · round to GitLab
   GitHub~partialclaimed6/10

   GitHub provides organization-wide governance levers referenced in the evidence — secret scanning/push protection across the org (github-docs-7, github-docs-15), configurable Copilot policies that apply everywhere Copilot is used (github-docs-53), fine-grained token permission controls (github-docs-18/19/21/42), and CI/CD via Actions (github-docs-11, github-docs-38) — which together let a devops-lead push standards and pipeline behavior broadly. However, the pack lacks explicit evidence of core enforcement mechanisms like org-wide branch protection rules, required status checks/reviews, rulesets, or CODEOWNERS enforcement across repos. Missing for 10: branch protection/rulesets enforcement, required status checks tied to CI/CD gating, CODEOWNERS/required-reviewer policy documentation, and independent confirmation that these policies are consistently enforced at scale.

   • [claimed-docs] “Detect, prevent, and remediate leaked secrets across your organization.”
   • [claimed-docs] “GitHub push protection confirms and displays an active secret, and blocks the push.”
   • [claimed-docs] “you can configure settings for GitHub Copilot on GitHub. The settings apply wherever you use GitHub Copilot.”
   • [claimed-docs] “Ship faster with secure, reliable CI/CD.”
   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions. Permissions define what resources the token can acc…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions.”
   • [claimed-docs] “Permissions define what resources the token can access via the API.”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab provides explicit governance tooling: compliance controls with automatic audit-ready evidence per pipeline (gitlab-docs-20), consolidated SAST/DAST/SCA/Secret Detection across the platform enforced in CI/CD and MRs (gitlab-docs-2, gitlab-docs-29, gitlab-docs-50), APIs to manage CI/CD and permissions consistently across projects/orgs (gitlab-docs-13, gitlab-docs-14), and AI-agent-specific governance (Allow/Ask/Deny policies, audit logs, session monitoring) that extends policy enforcement to new AI workflows (gitlab-docs-44, gitlab-docs-45). This directly matches a devops-lead's need to standardize CI/CD and coding policy across teams/repos at scale. Missing for 10: independent/hands-on validation of policy enforcement at scale (e.g., third-party case study or audit report) and more detail on cross-project policy templates/compliance frameworks beyond marketing copy.

   • [claimed-docs] “Apply controls for compliance and collect audit-ready evidence automatically in every pipeline.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”
   • [claimed-docs] “SAST, DAST, and compliance in every pipeline.”
   • [claimed-docs] “Manage CI/CD processes across multiple projects with precision.”
   • [claimed-docs] “Control user access programmatically to maintain consistent permissions across your organization.”
   • [claimed-docs] “Configure Allow, Ask, and Deny policies for agent tools, enforced at execution time for all connecting clients.”
   • [claimed-docs] “Monitor AI agent sessions, audit logs, and developer exposure across a group.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   GitHub~partialprobed7/10

   GitHub exposes a comprehensive REST API and GraphQL API, fine-grained token permissions, and an official CLI/SSH access that together let users perform most repository, issue, PR, and workflow actions programmatically (github-docs-40, github-docs-41, github-docs-18/19/21/42, github-docs-31/32/37, github-probe-4). However, the evidence never claims full 1:1 parity between every UI feature (e.g., some admin/org settings, Copilot UI toggles) and the API, so full equivalence is not documented. Missing for 10: explicit parity statement or audit showing every UI action has an API/CLI equivalent, and independent confirmation of no UI-only features.

   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions. Permissions define what resources the token can acc…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions.”
   • [claimed-docs] “Permissions define what resources the token can access via the API.”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line. When you're working from the command line, you can use…”
   • [claimed-docs] “Enter `gh repo clone OWNER/REPO`. For example, `gh repo clone octo-org/octo-repo` clones the `octo-org/octo-repo`”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line.”
   • [probe] “official CLI documented at https://cli.github.com/”
   • [probe] “official MCP server documented at https://github.com/github/github-mcp-server”

   proof ↗⚑ flag

   GitLab~partialprobed7/10

   GitLab documents a comprehensive REST API (with OpenAPI spec, interactive docs, versioning/deprecation policy) covering CI/CD, permissions, projects, and more, explicitly positioned for programmatic automation of workflows — plus an official CLI and MCP server extending API-driven access. However, there's no explicit vendor claim or evidence of full UI/API parity (e.g., some newer Agent Platform/UI-only settings, admin toggles) — missing for 10: an explicit parity statement or audit confirming every UI action has an API equivalent, and independent/community verification of this specific claim.

   • [claimed-docs] “Automate your workflows and build integrations with the GitLab REST API”
   • [claimed-docs] “You can browse and test every endpoint interactively in the [REST API documentation]”
   • [claimed-docs] “Use the interactive request tool to send live requests to GitLab.”
   • [claimed-docs] “GitLab supports authentication with HTTP Bearer or OAuth 2.0 credentials.”
   • [claimed-docs] “Docs, "OpenAPI": "GitLab documents its REST API using the OpenAPI 3.0 specification (formerly called Swagger)... The OpenAPI spec is autogen…”
   • [claimed-docs] “Docs, "REST API deprecations": "You should regularly review the following deprecations and make the recommended changes"; "GitLab will not m…”
   • [claimed-docs] “Manage CI/CD processes across multiple projects with precision.”
   • [claimed-docs] “Control user access programmatically to maintain consistent permissions across your organization.”
   • [probe] “official MCP server documented at https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/”
   • [probe] “official CLI documented at https://docs.gitlab.com/editor_extensions/gitlab_cli/”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   GitHub~partialcommunity5/10

   GitHub documents git-native portability (clone/download-zip/fork) and REST/GraphQL APIs that let users pull out repository and account data in open formats, which supports leaving the platform with code intact (github-docs-50, github-docs-41, github-docs-40, github-docs-33). However there is no evidence of a comprehensive 'export all my data' feature (issues, PR history, wiki, settings) beyond code, and community commentary shows some users have actually left GitHub citing lock-in concerns without contradicting the export mechanics themselves (github-comm-1, github-comm-7). Missing for 10: dedicated full-account data export/GDPR-style export documentation, evidence of exporting non-code artifacts (issues/projects/discussions) in open formats, and independent confirmation that a full migration-out process works smoothly.

   • [claimed-docs] “You can: Download a snapshot of a repository's files as a zip file to your own (local) computer. Clone a repository to your local computer u…”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “you must generate a new SSH key to use for authentication... you can add the public key to your account on GitHub.com to enable authenticati…”
   • [community] “Ghostty project is leaving GitHub; author kept a journal marking an 'X' next to every date a GitHub outage negatively impacted his ability t…”
   • [community] “Critic argues GitHub was always proprietary and locks users in, and welcomes anyone moving off it: 'Fuck Github. Every single outage Microsl…”

   proof ↗⚑ flag

   GitLab~partialcommunity5/10

   GitLab's Git-based architecture (gitlab-docs-7) and REST API (gitlab-docs-12,15) let users programmatically extract issues, MRs, and code, and self-hosting options (Docker/Helm/Linux package, gitlab-docs-9,21,25) mean users aren't locked into GitLab.com. However, the evidence never cites GitLab's dedicated project/group export-import feature or documentation guaranteeing full data export in open formats, and community notes only describe importing data into GitLab, not exporting out. Missing for 10: explicit documentation of a full project/group data export feature, confirmation of open/portable export formats, and independent verification that a complete migration-out is straightforward.

   • [claimed-docs] “Work with the Git version control system.”
   • [claimed-docs] “Automate your workflows and build integrations with the GitLab REST API”
   • [claimed-docs] “You can browse and test every endpoint interactively in the [REST API documentation]”
   • [claimed-docs] “The Linux package includes services and tools to install GitLab without laborious configuration.”
   • [claimed-docs] “If you're using cluster management, we recommend the Helm chart or the Operator for installing cloud-native GitLab.”
   • [community] “Migrating repos are straightforward... GitHub importer can import: repository description, Git repository data, issues, pull requests, wiki …”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to GitHub
   GitHub~partialclaimed3/10

   GitHub's own docs describe the GitHub CLI as 'an open source tool' (github-docs-31, github-docs-37), giving AI-native users a component of the product whose source they can read under an open license. However, the core GitHub.com platform, Copilot, and most other product components have no evidence of being open-licensed or source-available anywhere in the pack. Missing for 10: evidence that GitHub's main platform/service source is open-licensed, license details for the CLI repo, and any indication of open-sourcing beyond the CLI tool.

   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line. When you're working from the command line, you can use…”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line.”

   proof ↗⚑ flag

   GitLab—none0/10

   The axis clearly applies (a DevOps platform's source licensing is a fair comparison point), but nothing in the evidence pack documents GitLab's source code being available under an open license (e.g., no mention of the Community Edition repo, MIT license, or open-source status). Community items reference transparency in incident handling, not source-code licensing.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to GitLab
   GitHub—none0/10

   GitHub.com is a proprietary hosted SaaS; there is no evidence of a self-hostable core product (GitHub Enterprise Server, which does exist, is not mentioned anywhere in the pack). Absence of evidence for this applicable capability yields 'none'.

   ⚑ flag

   GitLab✓fullcommunity9/10

   GitLab's core product is explicitly documented as self-hostable via multiple official methods: Linux package (gitlab-docs-9), Docker images (gitlab-docs-25), Helm chart/Operator for Kubernetes (gitlab-docs-21), self-compilation (gitlab-docs-26), and scaling reference architectures (gitlab-docs-11). Community evidence corroborates real-world self-hosted usage (gitlab-comm-2 mentions a private self-hosted instance at work). Missing for 10: independent verification that newer AI/Duo Agent Platform features have full parity when self-managed vs. SaaS.

   • [claimed-docs] “The Linux package includes services and tools to install GitLab without laborious configuration.”
   • [claimed-docs] “If you're using cluster management, we recommend the Helm chart or the Operator for installing cloud-native GitLab.”
   • [claimed-docs] “GitLab maintains a set of official Docker images based on the Linux package.”
   • [claimed-docs] “If the Linux package isn't available for your distribution, you can self-compile GitLab.”
   • [claimed-docs] “Scale your GitLab installation by using the recommended configurations.”
   • [community] “I love GitLab, and I use a private instance at work, but I won't use it to store my public projects for one sole reason: you can't hide your…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to GitLab
   GitHub—none0/10

   No evidence pack items mention data residency, regional storage options, or geographic data controls for GitHub or Copilot; all evidence covers unrelated Copilot features, CLI, MCP, and community sentiment.

   ⚑ flag

   GitLab~partialclaimed3/10

   Evidence shows GitLab can be self-managed (Linux package, Docker images, Helm chart, self-compile) which implicitly lets an organization control where its instance and data physically reside, and mentions compliance/audit controls, but there is no explicit documentation of a GitLab.com SaaS region/residency selection feature or dedicated data-residency guarantee. missing for 10: explicit SaaS region-selection or data-residency policy documentation, evidence of enterprise data-residency add-on, independent confirmation of residency guarantees.

   • [claimed-docs] “The Linux package includes services and tools to install GitLab without laborious configuration.”
   • [claimed-docs] “If you're using cluster management, we recommend the Helm chart or the Operator for installing cloud-native GitLab.”
   • [claimed-docs] “GitLab maintains a set of official Docker images based on the Linux package.”
   • [claimed-docs] “If the Linux package isn't available for your distribution, you can self-compile GitLab.”
   • [claimed-docs] “Apply controls for compliance and collect audit-ready evidence automatically in every pipeline.”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   GitHub—none0/10

   No evidence pack item addresses AI training data opt-out or data usage policies for Copilot; only settings/policy pages are mentioned without training-data specifics. Missing for 10: explicit documentation of an opt-out/setting to exclude user data from AI model training, third-party audits or community confirmation of enforcement.

   ⚑ flag

   GitLab—none0/10

   No evidence pack item addresses opting out of AI model training on user data, data usage policies for Duo/AI features, or any privacy controls specific to training-data exclusion; the AI governance items ([gitlab-docs-44], [gitlab-docs-45]) cover tool permissions and monitoring, not training data usage.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   GitHub—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or privacy settings for AI-native features (e.g., Copilot data usage/retention configuration). Only tangential permissions/token docs are present, which do not cover retention or deletion controls.

   ⚑ flag

   GitLab—none0/10

   The evidence pack mentions AI governance features like Allow/Ask/Deny policies and audit logging (gitlab-docs-44, gitlab-docs-45) but contains no documentation of data retention periods, opt-out/deletion controls, or data handling policies specific to AI/Duo features or chat/session data. No evidence shows a user can configure or delete stored AI interaction data.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   GitHub—none0/10

   No evidence in the pack references telemetry opt-out, usage tracking controls, or privacy settings related to data collection; the closest items describe Copilot policy management (github-docs-53) without mentioning telemetry opt-out. This is a fair axis for a developer platform to address, but no supporting evidence exists.

   ⚑ flag

   GitLab—none0/10

   No evidence pack item discusses telemetry collection, usage tracking, or an opt-out/opt-in mechanism for GitLab or its AI/Duo features; ai-governance docs mention audit logs and policies but not telemetry opt-out. Missing for 10: any documentation of telemetry data collection scope, opt-out settings, or usage tracking controls.

   ⚑ flag

External pm sync

1. developerManage external issue tracker items directly within the code hosting UI

   weight 1 · round to GitHub
   GitHub~partialclaimed5/10

   GitHub Marketplace lists 'GitHub for Atlassian' which syncs Jira issues with GitHub, letting developers see/manage Jira items alongside code, but this is a third-party app integration rather than a native GitHub feature, and only one such integration is evidenced. missing for 10: native in-UI external tracker management, first-party documentation of the Jira/GitHub sync UX, and independent confirmation the integration works well.

   • [claimed-docs] “GitHub for Atlassian unifies data, automates workflows, and syncs development across GitHub, Jira, and your Atlassian apps”
   • [claimed-docs] “Create issues and manage projects with tools that adapt to your code.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack contains no mention of external issue tracker integrations (e.g., Jira, Bugzilla) or the ability to view/manage such items inside GitLab's UI; only unrelated topics like importing GitHub issues, APIs, and CI/CD are covered.

   ⚑ flag

2. developerAutomatically update linked issue tracker statuses by referencing issue keys in my commits

   weight 2 · round to GitHub
   GitHub~partialclaimed3/10

   The evidence pack does not document GitHub's native closing-keyword commit syntax, but it does show an official Atlassian integration that 'unifies data, automates workflows, and syncs development across GitHub, Jira' which implies some issue-status syncing capability from commits/PRs. This is thin, indirect evidence rather than a documented commit-keyword-to-status-update workflow. Missing for 10: explicit documentation of issue-key syntax in commit messages, confirmation that referencing keys auto-transitions ticket status in Jira or other trackers, and independent corroboration of this working end-to-end.

   • [claimed-docs] “GitHub for Atlassian unifies data, automates workflows, and syncs development across GitHub, Jira, and your Atlassian apps”
   • [claimed-docs] “Create issues and manage projects with tools that adapt to your code.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack contains no documentation of commit-message keyword parsing (e.g., 'Closes #123') that automatically transitions or closes linked issues; only generic platform and API descriptions are present, none referencing this specific capability.

   ⚑ flag

Issue tracking

1. developerTrack requirements, features, and bugs using issues with milestones, time tracking, and dependencies

   weight 3 · round to GitHub
   GitHub~partialclaimed3/10

   Evidence only generically references GitHub Issues/Projects ('Organize everything from high-level roadmaps to everyday tasks', 'Create issues and manage projects with tools that adapt to your code') with no documentation of milestones, time tracking, or issue dependencies specifically. GitHub is known to support issues/milestones and dependency links via sub-issues, but no first-party doc in this pack confirms time tracking, which is not a native GitHub feature. Missing for 10: explicit docs on milestones, native time tracking, and dependency/sub-issue linking.

   • [claimed-docs] “Organize everything from high-level roadmaps to everyday tasks.”
   • [claimed-docs] “Create issues and manage projects with tools that adapt to your code.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack contains no documentation describing GitLab's issue tracking, milestones, time tracking, or issue dependency features; the only tangential mention is that milestones are importable data from GitHub (a migration detail, not a feature description). Missing for 10: any docs or community evidence on issue creation, milestone planning, time tracking, or linking blocking/dependent issues.

   • [community] “Migrating repos are straightforward... GitHub importer can import: repository description, Git repository data, issues, pull requests, wiki …”

   proof ↗⚑ flag

2. developerManage projects and assign tasks from my mobile device

   weight 1 · round to GitHub
   GitHub✓fullclaimed8/10

   GitHub explicitly documents managing projects and assigning tasks to Copilot from a mobile device (github-docs-4), backed by GitHub Mobile's general capabilities (github-docs-54) and Projects features for organizing tasks (github-docs-8, github-docs-12). Missing for 10: independent hands-on corroboration of the mobile task-assignment workflow and more detail on mobile-specific project management UI limitations.

   • [claimed-docs] “Manage projects and assign tasks to Copilot, all from your mobile device.”
   • [claimed-docs] “GitHub Mobile gives you a way to do high-impact work on GitHub quickly and from anywhere.”
   • [claimed-docs] “Organize everything from high-level roadmaps to everyday tasks.”
   • [claimed-docs] “Create issues and manage projects with tools that adapt to your code.”

   proof ↗⚑ flag

   GitLab—none0/10

   No evidence pack item mentions a mobile app, mobile-optimized UI, or mobile-specific workflow for managing projects or assigning tasks; all cited capabilities (API, CLI, Duo Agent Platform, integrations) are desktop/web/CI-oriented. Missing for 10: any mention of a native or mobile-web GitLab app, mobile task assignment, or mobile project management workflow.

   ⚑ flag

3. developerOrganize work from high-level roadmaps to everyday tasks using project boards

   weight 2 · round to GitHub
   GitHub✓fullclaimed7/10

   GitHub explicitly markets Projects as a way to 'Organize everything from high-level roadmaps to everyday tasks' and 'Create issues and manage projects with tools that adapt to your code,' directly matching the story, with mobile task assignment also mentioned. Missing for 10: deeper docs on project board views/customization (e.g., roadmap layouts, hierarchies) and independent/hands-on corroboration beyond marketing copy.

   • [claimed-docs] “Organize everything from high-level roadmaps to everyday tasks.”
   • [claimed-docs] “Create issues and manage projects with tools that adapt to your code.”
   • [claimed-docs] “Manage projects and assign tasks to Copilot, all from your mobile device.”

   proof ↗⚑ flag

   GitLab—none0/10

   The evidence pack contains no concrete documentation of GitLab's project boards, epics, or roadmap features; only a single generic marketing mention of 'planning' appears in a broader lifecycle tagline (gitlab-docs-19), with no detail on issue boards, milestones, or roadmap views. This is insufficient to demonstrate the story's capability.

   • [claimed-docs] “From planning to source control to CI/CD, everything you need to build and ship software faster in one platform.”

   proof ↗⚑ flag

Code review

1. ai-native userHave an AI reviewer analyze code changes and suggest fixes during review

   weight 2 · round to GitHub
   GitHub✓fullclaimed9/10

   GitHub Copilot directly supports AI code review: docs confirm Copilot 'can review your code and provide feedback' with 'suggested changes which you can apply with a couple of clicks' (github-docs-25), and PR-level review assignment via 'Assign initial reviews to Copilot for greater speed and quality' (github-docs-9), backed by Copilot Autofix for applying fixes (github-docs-5). Missing for 10: independent/hands-on community corroboration specifically of the review-and-suggest-fix workflow (community evidence covers general Copilot sentiment, not this specific feature).

   • [claimed-docs] “GitHub Copilot can review your code and provide feedback. Where possible, Copilot's feedback includes suggested changes which you can apply …”
   • [claimed-docs] “Assign initial reviews to Copilot for greater speed and quality.”
   • [claimed-docs] “Apply fixes in seconds. Spend less time debugging and more time building features with Copilot Autofix.”
   • [claimed-docs] “It suggests code as you type, answers questions about a codebase, reviews your changes, and works on tasks you assign it.”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab's Duo Agent Platform explicitly supports AI agents that review code and suggest fixes ('review code while your team stays in control', findings surfaced directly in merge requests) and this is extended by third-party AI code review agents like Greptile and CodeAnt AI integrated into MR workflows. Governance controls (allow/ask/deny, human-in-the-loop approvals) further support this being a real, controllable capability rather than just marketing copy. missing for 10: independent hands-on validation of AI-suggested fixes quality/accuracy in real MR reviews, and more detail on native (non-partner) Duo code review suggestion mechanics.

   • [claimed-docs] “Agents turn issues into merge requests, remediate vulnerabilities, and review code while your team stays in control.”
   • [claimed-docs] “Security findings appear directly in merge requests and IDEs.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Human in the loop approvals for chat-based GitLab Duo Agent Platform sessions”
   • [claimed-docs] “Greptile is building the unified validation layer for code, starting with an AI-powered code review agent that analyzes PRs with full codeba…”
   • [claimed-docs] “CodeAnt AI brings AI-native code reviews, security scanning (SAST/SCA), and code quality enforcement to GitLab merge requests.”

   proof ↗⚑ flag

2. ai-native userAssign the initial code review of a pull request to an AI reviewer for faster turnaround

   weight 2 · round to GitHub
   GitHub✓fullclaimed9/10

   GitHub directly documents assigning initial PR reviews to Copilot ('Assign initial reviews to Copilot for greater speed and quality') and Copilot's code review capability with suggested changes ('GitHub Copilot can review your code and provide feedback... suggested changes'), matching the story precisely. Missing for 10: independent/hands-on evidence quantifying turnaround-speed improvement from AI-assigned reviews.

   • [claimed-docs] “Assign initial reviews to Copilot for greater speed and quality.”
   • [claimed-docs] “GitHub Copilot can review your code and provide feedback. Where possible, Copilot's feedback includes suggested changes which you can apply …”

   proof ↗⚑ flag

   GitLab~partialclaimed6/10

   GitLab documents AI agents that review code and integrate into merge requests (e.g., 'Agents ... review code while your team stays in control', security findings in MRs, Duo Agent Platform delegating tasks to specialized agents) plus third-party marketplace agents like Greptile and CodeAnt AI explicitly for AI-powered PR/MR review. However, there is no direct documentation showing a first-party workflow to explicitly 'assign' an MR's initial review to an AI reviewer as a reviewer role (vs. automated scanning/chat), so the exact story is only partially evidenced. missing for 10: explicit first-party doc on designating/assigning an AI agent as the primary/initial MR reviewer, and independent hands-on confirmation of turnaround-speed benefit.

   • [claimed-docs] “Agents turn issues into merge requests, remediate vulnerabilities, and review code while your team stays in control.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Greptile is building the unified validation layer for code, starting with an AI-powered code review agent that analyzes PRs with full codeba…”
   • [claimed-docs] “CodeAnt AI brings AI-native code reviews, security scanning (SAST/SCA), and code quality enforcement to GitLab merge requests.”

   proof ↗⚑ flag

3. developerReview code changes online and respond to inline review comments

   weight 3 · round to GitLab
   GitHub—none0/10

   The evidence pack contains no documentation of GitHub's native pull-request review interface, inline comments, or developer-to-developer review threads; the closest match (github-docs-25) describes Copilot providing automated review feedback, not a human reviewing changes online and responding to another developer's inline comments. Missing for 10: any doc on PR diff view, inline comment threads, review approval/request-changes flow, or reply-to-comment functionality.

   ⚑ flag

   GitLab~partialclaimed5/10

   The evidence repeatedly references merge requests as the code-review surface (e.g., security findings appearing directly in merge requests, agents reviewing code, Chat searching for merge requests) which implies GitLab's core online MR review workflow exists, but no citation explicitly documents inline comment threads or replying to review comments. missing for 10: explicit documentation of inline diff comments, comment threading/resolution, and reply workflows within merge requests.

   • [claimed-docs] “Agents turn issues into merge requests, remediate vulnerabilities, and review code while your team stays in control.”
   • [claimed-docs] “Security findings appear directly in merge requests and IDEs.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”
   • [claimed-docs] “you can ask “Find the merge request about authentication” and Chat searches for relevant merge req”
   • [claimed-docs] “Greptile is building the unified validation layer for code, starting with an AI-powered code review agent that analyzes PRs with full codeba…”

   proof ↗⚑ flag

4. developerReview large diffs and view third-party code quality reports directly in the review screen

   weight 2 · round to GitLab
   GitHub—none0/10

   The evidence pack shows GitHub Copilot code review (github-docs-25), CI/CD via Actions (github-docs-38), and a marketplace of third-party integrations (github-intdir-1, github-intdir-7), but nothing explicitly describes large-diff handling in the PR review screen or third-party code-quality/coverage reports rendered inline as review annotations. missing for 10: documentation of large-diff review UX (e.g. diff pagination, file-by-file review tools), evidence of third-party check results (e.g. code coverage, linting, SAST) surfaced directly in the Files Changed/review screen via the Checks API.

   • [claimed-docs] “GitHub Copilot can review your code and provide feedback. Where possible, Copilot's feedback includes suggested changes which you can apply …”
   • [claimed-docs] “Automate, customize, and execute your software development workflows right in your repository with GitHub Actions.”
   • [claimed-docs] “Continuous integration and deploys with Render, the modern cloud for ambitious developers”
   • [claimed-docs] “Cloud-based continuous integration and delivery for Android, iOS, Flutter, React Native, Ionic and Unity projects”

   proof ↗⚑ flag

   GitLab~partialclaimed5/10

   GitLab docs confirm that security/scanner findings (SAST, SCA, Secret Detection, DAST) appear directly in merge requests, which supports third-party report visibility in the review screen (gitlab-docs-2, gitlab-docs-3). However, there is no evidence specifically addressing large-diff review capabilities (e.g., diff collapsing, file-by-file navigation for large changesets) nor explicit mention of a dedicated 'code quality' report widget distinct from security scanners. Missing for 10: evidence of large-diff handling UX, explicit code-quality (non-security) report integration, and independent/hands-on confirmation.

   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform.”
   • [claimed-docs] “Security findings appear directly in merge requests and IDEs.”

   proof ↗⚑ flag

5. devops-leadEnforce standardized, customizable merge checks before code can be merged

   weight 2 · round to GitLab
   GitHub—none0/10

   The evidence pack contains no mention of branch protection rules, required status checks, required reviews, or CODEOWNERS enforcement mechanisms that would let a devops-lead gate merges. Only generic CI/CD (github-docs-11, github-docs-38) and Copilot code review (github-docs-25) items appear, none of which describe enforceable, customizable merge gating.

   ⚑ flag

   GitLab~partialclaimed5/10

   Evidence shows GitLab embeds compliance controls, audit evidence, and security scan results (SAST/DAST/SCA) directly into merge requests, and lets teams customize workflows across the lifecycle — suggesting standardized, customizable gates before merge. However, the pack never explicitly documents core merge-check mechanics like approval rules, required reviewers, or branch protection settings, only their compliance/security-adjacent framing. Missing for 10: explicit merge request approval rules/required approvers documentation, branch protection/push rules details, and independent verification that these checks are enforced as blocking gates.

   • [claimed-docs] “Apply controls for compliance and collect audit-ready evidence automatically in every pipeline.”
   • [claimed-docs] “Customize workflows for development, testing, security, and deployment.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform.”
   • [claimed-docs] “Security findings appear directly in merge requests and IDEs.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”
   • [claimed-docs] “SAST, DAST, and compliance in every pipeline.”

   proof ↗⚑ flag

Package registry

1. open-source-maintainerPublish and consume software packages in multiple package formats from the same platform

   weight 2 · round drawn
   GitHub—none0/10

   The evidence pack contains no mention of GitHub Packages, container/npm/Maven/NuGet/RubyGems registries, or any multi-format package publishing/consumption capability — all citations focus on Copilot, Actions, CLI, MCP, and community sentiment. Since this is an applicable axis for a repo-hosting platform but no supporting evidence exists in the pack, it must be scored as 'none'.

   ⚑ flag

   GitLab—none0/10

   The evidence pack contains no mention of GitLab's Package Registry or support for multiple package formats (npm, Maven, PyPI, Docker, etc.) that would let a maintainer publish and consume packages across formats from one platform; all citations focus on CI/CD, security scanning, AI agents, and integrations. missing for 10: any documentation of the Package Registry, supported package formats, publish/consume workflows, or package-registry API endpoints.

   ⚑ flag

Repo management

1. devops-leadControl granular access permissions at the workspace, project, repository, and branch level

   weight 2 · round to GitHub
   GitHub~partialclaimed4/10

   Evidence only covers fine-grained personal access token permissions (API scoping) rather than GitHub's actual RBAC system for organizations/teams, repository roles, or branch protection rules that would satisfy a devops-lead's granular access control needs. Missing for 10: branch protection rules, team/organization-level repository permission management, and workspace/project-level access control documentation.

   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions. Permissions define what resources the token can acc…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions.”
   • [claimed-docs] “Permissions define what resources the token can access via the API.”

   proof ↗⚑ flag

   GitLab~partialclaimed3/10

   Evidence only vaguely references permission control ('Control user access programmatically to maintain consistent permissions across your organization') and generic auth mechanisms (PATs, SSH keys, OAuth), but the pack contains no documentation of protected branches, CODEOWNERS, project/group role hierarchies, or workspace-level access scoping that would substantiate granular multi-level control. Missing for 10: explicit docs on protected branch rules, group/project role-based permissions, and workspace-level access scoping with independent corroboration.

   • [claimed-docs] “Control user access programmatically to maintain consistent permissions across your organization.”
   • [claimed-docs] “Personal access tokens”
   • [claimed-docs] “SSH keys”

   proof ↗⚑ flag

2. developerSearch across repositories to find code, files, and commits

   weight 2 · round to GitLab
   GitHub!disputedcontradicted3/10

   GitHub's platform docs point to APIs (REST/GraphQL) for retrieving and querying repository data, which vendor-side implies broad search/query capability across repos, but a first-hand community report explicitly states GitHub's code search is 'terribly bad'—so poor that cloning and using grep is more effective—directly contradicting the polished vendor narrative. missing for 10: no dedicated vendor documentation on the actual code/commit/file search UI or its indexing depth, no independent corroboration of search quality beyond the negative report, and no evidence addressing recent search improvements.

   • [claimed-docs] “The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.”
   • [claimed-docs] “Create integrations, retrieve data, and automate your workflows with the GitHub REST API.”
   • [community] “Complaint that GitHub's code search is 'terribly bad'—so poor that it's more efficient to clone a repo and use plain grep instead.”

   proof ↗⚑ flag

   GitLab~partialclaimed4/10

   Evidence only shows GitLab Duo Chat can search for relevant merge requests and has access to a project's issues, commits, and CI/CD data (gitlab-docs-39, gitlab-docs-48), which touches on finding commits/MRs conversationally but does not document GitLab's broader code/file search or cross-repository search capability. Missing for 10: explicit documentation of full-text code search, file search, and search scoped across multiple repositories/projects (e.g., an 'Advanced Search' feature), plus independent corroboration of search quality.

   • [claimed-docs] “you can ask “Find the merge request about authentication” and Chat searches for relevant merge req”
   • [claimed-docs] “Chat has access to your project, including issues, merge requests, commits, and CI/CD pipelines, and Chat maintains context across conversat…”

   proof ↗⚑ flag

3. developerCreate and manage Git repositories and browse their commit history

   weight 3 · round to GitLab
   GitHub✓fullclaimed7/10

   Evidence confirms core repo management: cloning via GitHub CLI (`gh repo clone`), SSH-based git authentication for push/pull, and downloading/cloning/forking repositories are all documented first-party GitHub capabilities. However, no citation explicitly addresses browsing commit history UI/API features. Missing for 10: explicit documentation of commit history browsing (e.g., commit log view, blame, diff comparison) and independent hands-on corroboration of repo creation/management workflow.

   • [claimed-docs] “Enter `gh repo clone OWNER/REPO`. For example, `gh repo clone octo-org/octo-repo` clones the `octo-org/octo-repo`”
   • [claimed-docs] “You can: Download a snapshot of a repository's files as a zip file to your own (local) computer. Clone a repository to your local computer u…”
   • [claimed-docs] “you must generate a new SSH key to use for authentication... you can add the public key to your account on GitHub.com to enable authenticati…”
   • [claimed-docs] “You can access and write data in repositories on GitHub using SSH (Secure Shell Protocol).”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line. When you're working from the command line, you can use…”
   • [claimed-docs] “GitHub CLI is an open source tool for using GitHub from your computer's command line.”

   proof ↗⚑ flag

   GitLab✓fullcommunity9/10

   GitLab is a core Git repository hosting platform with documented support for creating/managing repos, SSH/PAT authentication, and Git version control workflows (gitlab-docs-7, 31, 5, 6, 32), plus community evidence confirming real-world repo migration and usage (gitlab-comm-3). Commit history browsing is implicit in its core Git platform functionality and referenced via merge requests/commits in Chat context (gitlab-docs-48). Missing for 10: no explicit dedicated documentation snippet describing the commit-history browsing UI itself, relying on inference from broader platform docs.

   • [claimed-docs] “Work with the Git version control system.”
   • [claimed-docs] “Get started with Git Work with the Git version control system.”
   • [claimed-docs] “Personal access tokens”
   • [claimed-docs] “SSH keys”
   • [claimed-docs] “[Personal access tokens](/user/profile/personal_access_tokens/)”
   • [claimed-docs] “Chat has access to your project, including issues, merge requests, commits, and CI/CD pipelines, and Chat maintains context across conversat…”
   • [community] “Migrating repos are straightforward... GitHub importer can import: repository description, Git repository data, issues, pull requests, wiki …”

   proof ↗⚑ flag

4. developerPropose, discuss, and merge code changes using a pull or merge request workflow

   weight 3 · round to GitLab
   GitHub✓fullclaimed6/10

   Evidence confirms the pull-request workflow exists and is central to GitHub's Copilot-assisted development flow (agents 'create a pull request when you're ready', 'resolve merge conflicts', and Copilot can 'review your code and provide feedback' with suggested changes), which implies the underlying PR creation/discussion/merge mechanics. However, the pack lacks direct documentation of the core native PR UI itself (opening a PR, review comment threads, approve/merge buttons, conflict resolution UI) independent of Copilot. Missing for 10: first-party docs on PR creation/review UI, merge button and required-review settings, and independent/hands-on confirmation of the review-and-merge process.

   • [claimed-docs] “Copilot can research a repository, create an implementation plan, and make code changes on a branch. You can review the diff, iterate, and c…”
   • [claimed-docs] “GitHub Copilot can review your code and provide feedback. Where possible, Copilot's feedback includes suggested changes which you can apply …”
   • [claimed-docs] “Copilot cloud agent can: * Research a repository * Create implementation plans * Fix bugs * Implement incremental new features * …”

   proof ↗⚑ flag

   GitLab✓fullcommunity7/10

   Merge requests are referenced pervasively across the evidence pack as the core collaboration unit — security findings, Chat search, third-party integrations (Notion, PagerDuty), and GitHub-import parity all treat MRs as the central discuss/review/merge construct, and gitlab-comm-3 confirms PR/MR review comments and workflow parity with GitHub. Missing for 10: a dedicated first-party doc excerpt walking through creating/discussing/approving/merging an MR (approvals, threads, merge rules) rather than only peripheral mentions.

   • [claimed-docs] “Agents turn issues into merge requests, remediate vulnerabilities, and review code while your team stays in control.”
   • [claimed-docs] “Security findings appear directly in merge requests and IDEs.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”
   • [claimed-docs] “you can ask “Find the merge request about authentication” and Chat searches for relevant merge req”
   • [claimed-docs] “Chat has access to your project, including issues, merge requests, commits, and CI/CD pipelines, and Chat maintains context across conversat…”
   • [claimed-docs] “Send notification-free events from GitLab to PagerDuty services regarding important changes, such as merge requests, to provide context for …”
   • [claimed-docs] “Notion's synced databases integration with GitLab allows users to bring merge requests, issues, and more into their Notion workspace, so tea…”
   • [community] “Migrating repos are straightforward... GitHub importer can import: repository description, Git repository data, issues, pull requests, wiki …”

   proof ↗⚑ flag

Access security

1. devops-leadRestrict repository access to specific IP address ranges

   weight 2 · round drawn
   GitHub—none0/10

   No evidence in the pack mentions IP allow-listing or restricting repository/organization access by IP address range; GitHub Enterprise Cloud does offer this feature in reality, but nothing in the provided evidence documents it, so it must be marked none.

   ⚑ flag

   GitLab—none0/10

   The evidence pack contains no documentation of IP allowlisting/IP range restriction features for repository access; nothing about network restrictions, IP allowlists, or similar controls appears in the docs or community items.

   ⚑ flag

2. developerGenerate and manage personal access tokens for authenticating to the platform

   weight 2 · round to GitLab
   GitHub✓fullclaimed7/10

   GitHub's docs describe fine-grained personal access tokens, including granting permissions and per-endpoint permission requirements via the X-Accepted-GitHub-Permissions header, confirming first-party support for creating and managing PATs for API authentication. missing for 10: no evidence on the full token lifecycle (e.g., expiration settings, revocation, token audit log) or classic PAT management UI, and no independent/hands-on corroboration of the token management workflow.

   • [claimed-docs] “you will receive the `X-Accepted-GitHub-Permissions` header in the REST API response. The header will tell you what permissions are required…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions. Permissions define what resources the token can acc…”
   • [claimed-docs] “When you create a fine-grained personal access token, you grant it a set of permissions.”
   • [claimed-docs] “Permissions define what resources the token can access via the API.”

   proof ↗⚑ flag

   GitLab✓fullclaimed8/10

   GitLab's docs explicitly cover personal access tokens as a dedicated authentication mechanism (gitlab-docs-5), with usage shown in API auth flows (gitlab-docs-22) and support for HTTP Bearer/OAuth2 alongside PATs (gitlab-docs-17). This directly matches the developer story of generating/managing PATs for platform authentication. Missing for 10: no hands-on/community evidence confirming token management UX (expiration, scopes, rotation) works smoothly in practice, and no independent corroboration beyond first-party docs.

   • [claimed-docs] “Personal access tokens”
   • [claimed-docs] “For `http`, enter your [personal access token](/user/profile/personal_access_tokens/).”
   • [claimed-docs] “GitLab supports authentication with HTTP Bearer or OAuth 2.0 credentials.”

   proof ↗⚑ flag

3. developerSet up SSH keys to authenticate and connect securely to the platform

   weight 2 · round to GitHub
   GitHub✓fullclaimed9/10

   GitHub's official docs directly cover SSH key generation and adding it to the ssh-agent for authenticating Git operations over SSH, plus confirm SSH is a supported method to access/write repository data. missing for 10: no independent/hands-on corroboration of the SSH setup flow beyond first-party docs.

   • [claimed-docs] “you must generate a new SSH key to use for authentication... you can add the public key to your account on GitHub.com to enable authenticati…”
   • [claimed-docs] “You can access and write data in repositories on GitHub using SSH (Secure Shell Protocol).”
   • [claimed-docs] “After you've checked for existing SSH keys, you can generate a new SSH key to use for authentication, then add it to the ssh-agent.”

   proof ↗⚑ flag

   GitLab✓fullclaimed7/10

   GitLab documents SSH key setup as a first-party feature (gitlab-docs-6) alongside Git version control support (gitlab-docs-7), confirming the core capability for developers to authenticate via SSH. Missing for 10: no detailed walkthrough content in the pack (e.g., key generation steps, troubleshooting), and no independent/community corroboration of SSH auth working reliably in practice.

   • [claimed-docs] “SSH keys”
   • [claimed-docs] “Work with the Git version control system.”

   proof ↗⚑ flag

4. developerSecure my account with two-factor authentication

   weight 3 · round drawn
   GitHub—none0/10

   The evidence pack covers account creation, social login, SSH keys, and fine-grained PAT permissions, but contains no documentation or mention of two-factor authentication setup or enforcement for developer accounts. Without direct evidence for this specific security capability, it cannot be credited despite GitHub being widely known to offer 2FA.

   ⚑ flag

   GitLab—none0/10

   The evidence pack covers personal access tokens, SSH keys, and various security scanning features (SAST/DAST) but contains no mention of two-factor authentication (2FA/MFA) setup or enforcement for developer accounts. Missing for 10: any documentation of 2FA/MFA enrollment, enforcement policies, or authenticator app support.

   ⚑ flag

Vulnerability scanning

1. ai-native userHave AI automatically generate and apply fixes for detected security vulnerabilities

   weight 2 · round to GitHub
   GitHub✓fullclaimed8/10

   GitHub Copilot Autofix directly targets this story: it auto-generates fixes for code-scanning-detected vulnerabilities ('Apply fixes in seconds... Copilot Autofix'), is used in 'security campaigns' to reduce vulnerabilities, and Dependabot updates vulnerable dependencies with supported fixes. Secret scanning/push protection covers detection and blocking of another vulnerability class. Missing for 10: independent/hands-on validation of Autofix accuracy and no detail on how automatically fixes are applied without human review.

   • [claimed-docs] “Apply fixes in seconds. Spend less time debugging and more time building features with Copilot Autofix.”
   • [claimed-docs] “Update vulnerable dependencies with supported fixes for breaking changes.”
   • [claimed-docs] “Leverage security campaigns and Copilot Autofix to reduce application vulnerabilities.”
   • [claimed-docs] “Detect, prevent, and remediate leaked secrets across your organization.”
   • [claimed-docs] “GitHub push protection confirms and displays an active secret, and blocks the push.”

   proof ↗⚑ flag

   GitLab~partialclaimed6/10

   GitLab explicitly markets AI agents that 'remediate vulnerabilities' via merge requests, and Duo Agent Platform lets users 'delegate...security scans' to specialized agents, with findings surfacing in MRs/IDEs from consolidated scanners (SAST/SCA/DAST). However, evidence is limited to marketing/docs snippets without a detailed workflow description of automatic fix generation-and-apply, no hands-on/independent confirmation of remediation quality or reliability, and human-in-the-loop approval is emphasized (suggesting fixes aren't auto-applied without review). Missing for 10: independent/hands-on verification of auto-generated fix quality, detailed docs on the vulnerability-to-fix pipeline, and confirmation that fixes can be applied without human approval when desired.

   • [claimed-docs] “Agents turn issues into merge requests, remediate vulnerabilities, and review code while your team stays in control.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”
   • [claimed-docs] “Delegate routine tasks, from code refactoring and security scans to research, to specialized AI agents.”
   • [claimed-docs] “Human in the loop approvals for chat-based GitLab Duo Agent Platform sessions”
   • [claimed-docs] “SAST, DAST, and compliance in every pipeline.”

   proof ↗⚑ flag

2. developerAutomatically receive pull requests that update vulnerable dependencies

   weight 3 · round drawn
   GitHub~partialclaimed5/10

   github-docs-6 ("Update vulnerable dependencies with supported fixes for breaking changes") and github-docs-14 (security campaigns/Copilot Autofix to reduce vulnerabilities) point to GitHub's Dependabot-style automated dependency update capability, which is a well-known GitHub feature, but the evidence pack only contains thin marketing bullets rather than detailed first-party docs describing the automatic PR workflow. Missing for 10: dedicated Dependabot documentation describing PR creation triggers/config, and independent/hands-on corroboration that PRs are actually opened automatically.

   • [claimed-docs] “Update vulnerable dependencies with supported fixes for breaking changes.”
   • [claimed-docs] “Leverage security campaigns and Copilot Autofix to reduce application vulnerabilities.”
   • [claimed-docs] “Apply fixes in seconds. Spend less time debugging and more time building features with Copilot Autofix.”

   proof ↗⚑ flag

   GitLab~partialclaimed5/10

   GitLab's SCA/Dependency Scanning surfaces vulnerability findings directly in merge requests, and its Duo Agent Platform explicitly states agents can 'turn issues into merge requests, remediate vulnerabilities' (gitlab-docs-1, gitlab-docs-2, gitlab-docs-29), which implies auto-generated MRs to fix vulnerable dependencies. However, there's no explicit documentation of a Dependabot/Renovate-style automatic bot that proactively opens dependency-bump PRs on a schedule — the evidence only shows scan findings appearing in MRs and agent-driven remediation, not a dedicated automated dependency-update workflow. missing for 10: explicit doc of automatic scheduled dependency-update merge requests (Renovate/Dependabot-equivalent), independent/hands-on confirmation of this exact workflow.

   • [claimed-docs] “Agents turn issues into merge requests, remediate vulnerabilities, and review code while your team stays in control.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”

   proof ↗⚑ flag

3. devops-leadConsolidate static analysis, dependency, secret, and dynamic security scanning into one platform

   weight 3 · round to GitLab
   GitHub~partialclaimed6/10

   Evidence shows GitHub bundles secret scanning/push protection (github-docs-7, github-docs-15), dependency vulnerability fixes (github-docs-6), and Copilot Autofix tied to security campaigns (github-docs-5, github-docs-14), which together imply static/code scanning plus dependency and secret scanning in one platform. However, there is no evidence of dynamic application security testing (DAST) being part of this consolidated offering. Missing for 10: explicit dynamic/DAST scanning capability, and independent/hands-on validation that all four scan types are unified in one dashboard.

   • [claimed-docs] “Apply fixes in seconds. Spend less time debugging and more time building features with Copilot Autofix.”
   • [claimed-docs] “Update vulnerable dependencies with supported fixes for breaking changes.”
   • [claimed-docs] “Detect, prevent, and remediate leaked secrets across your organization.”
   • [claimed-docs] “Leverage security campaigns and Copilot Autofix to reduce application vulnerabilities.”
   • [claimed-docs] “GitHub push protection confirms and displays an active secret, and blocks the push.”

   proof ↗⚑ flag

   GitLab✓fullclaimed9/10

   GitLab explicitly documents consolidating SAST, SCA (dependency scanning), Secret Detection, and DAST into one platform, with findings surfacing directly in merge requests and IDEs, plus compliance controls and audit evidence per pipeline — directly matching the devops-lead's consolidation story. Missing for 10: independent/hands-on third-party validation of the combined scanning workflow (only vendor docs are present, no community corroboration specific to security scanning consolidation).

   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform.”
   • [claimed-docs] “Security findings appear directly in merge requests and IDEs.”
   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform. Security findings appear directly in merge requests and I…”
   • [claimed-docs] “SAST, DAST, and compliance in every pipeline.”
   • [claimed-docs] “Apply controls for compliance and collect audit-ready evidence automatically in every pipeline.”

   proof ↗⚑ flag

4. devops-leadDetect and remediate leaked secrets across the organization's repositories

   weight 2 · round to GitHub
   GitHub✓fullclaimed8/10

   GitHub explicitly advertises secret scanning to 'detect, prevent, and remediate leaked secrets across your organization' and push protection that blocks pushes containing active secrets, directly matching the devops-lead story. missing for 10: independent/hands-on corroboration of remediation workflow at org scale and detail on remediation tooling beyond blocking.

   • [claimed-docs] “Detect, prevent, and remediate leaked secrets across your organization.”
   • [claimed-docs] “GitHub push protection confirms and displays an active secret, and blocks the push.”

   proof ↗⚑ flag

   GitLab~partialclaimed5/10

   GitLab's docs mention Secret Detection as part of a consolidated scanning platform with findings surfacing in merge requests/IDEs, which supports detection of leaked secrets, but there is no specific evidence of organization-wide scanning across all repos, remediation workflows (revocation, rotation, historic commit scrubbing), or any alerting/dashboard for leaked secrets specifically. Missing for 10: org-wide/cross-repo secret scanning details, concrete remediation workflow (auto-revoke, git history purge), independent/hands-on validation of Secret Detection efficacy.

   • [claimed-docs] “Consolidate scanners like SAST, SCA, Secret Detection, and DAST into one platform.”
   • [claimed-docs] “Security findings appear directly in merge requests and IDEs.”

   proof ↗⚑ flag

Deployment options

1. devops-leadRun my self-hosted instance on my choice of operating system and architecture, including containers

   weight 2 · round to GitLab
   GitHub—none0/10

   The evidence pack contains no mention of GitHub Enterprise Server, self-hosted deployment options, supported operating systems/architectures, or container-based installation — all evidence describes GitHub.com as a cloud SaaS plus Copilot/CLI/API features. Self-hosting is a plausible axis for a dev platform like GitHub, but nothing in the pack substantiates it.

   ⚑ flag

   GitLab~partialclaimed7/10

   GitLab documents multiple self-hosting install paths: the Linux package for various distros, official Docker images, Helm chart/Operator for Kubernetes/cloud-native deployments, and self-compilation as a fallback for unsupported distros, plus scaling guidance for larger installs. This covers OS flexibility and containerized deployment well, but there is no explicit mention of architecture support (e.g., ARM64 vs x86_64) or non-Linux host OS options. Missing for 10: explicit CPU architecture support details, broader OS coverage beyond Linux, and independent/community confirmation of multi-arch or container deployment success.

   • [claimed-docs] “The Linux package includes services and tools to install GitLab without laborious configuration.”
   • [claimed-docs] “If you're using cluster management, we recommend the Helm chart or the Operator for installing cloud-native GitLab.”
   • [claimed-docs] “GitLab maintains a set of official Docker images based on the Linux package.”
   • [claimed-docs] “If the Linux package isn't available for your distribution, you can self-compile GitLab.”
   • [claimed-docs] “Scale your GitLab installation by using the recommended configurations.”

   proof ↗⚑ flag

2. devops-leadScale my self-hosted installation using reference architectures supporting tens of thousands of users

   weight 2 · round to GitLab
   GitHub—none0/10

   No evidence pack items discuss GitHub Enterprise Server self-hosting, reference architectures, or scaling guidance for tens of thousands of users; all citations concern Copilot, APIs, CLI, and community sentiment unrelated to self-hosted infrastructure scaling.

   ⚑ flag

   GitLab~partialcommunity6/10

   GitLab documents reference architectures and scaling guidance ('Scale your GitLab installation by using the recommended configurations') plus supporting deployment options (Helm chart/Operator, Docker images, Linux package) that underpin large-scale self-hosted setups. However, there is no explicit mention of specific reference architecture tiers (e.g., 10k/25k/50k users) or benchmarks, and community evidence highlights real operational reliability issues (downtime, failed backups, performance problems) that raise doubts about smooth scaling in practice. Missing for 10: explicit named reference-architecture tiers for tens of thousands of users, third-party validation of scaling at that size, and resolution of community-reported reliability/performance concerns at scale.

   • [claimed-docs] “Scale your GitLab installation by using the recommended configurations.”
   • [claimed-docs] “If you're using cluster management, we recommend the Helm chart or the Operator for installing cloud-native GitLab.”
   • [claimed-docs] “GitLab maintains a set of official Docker images based on the Linux package.”
   • [claimed-docs] “The Linux package includes services and tools to install GitLab without laborious configuration.”
   • [community] “GitLab's recent performance has been abysmal... we've had entire days where the team was unable to deploy because the CI workers did not run…”
   • [community] “Meanwhile GitLab is crashing... Getting a 502 currently. I feel sorry for the Gitlab on-call right now.”
   • [community] “So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.”

   proof ↗⚑ flag

3. devops-leadUse migration tooling to move my code and users from another platform or from self-hosted to cloud

   weight 2 · round to GitLab
   GitHub—none0/10

   No evidence of migration tooling for moving code/users from another platform (e.g., GitLab, Bitbucket, SVN) or from self-hosted GitHub Enterprise Server to GitHub cloud; evidence only covers Copilot features, CLI, MCP server, and general APIs, none addressing platform migration or user/account import tooling.

   ⚑ flag

   GitLab~partialcommunity5/10

   Community evidence confirms GitLab has a GitHub importer that migrates repos, issues, PRs, wikis, labels and comments (gitlab-comm-3), and partner directory lists third-party services like Relokia and Unito for migrating from other platforms/PM tools (gitlab-intdir-12, gitlab-intdir-13). However there's no first-party documentation in the pack describing GitLab's own self-managed-to-SaaS migration tooling or user/account migration specifics. Missing for 10: official GitLab docs on bulk/group migration between self-managed and GitLab.com, user account migration details, and independent hands-on validation of a full self-hosted-to-cloud migration.

   • [community] “Migrating repos are straightforward... GitHub importer can import: repository description, Git repository data, issues, pull requests, wiki …”
   • [claimed-docs] “Relokia offers an advanced project management migration service, enabling effortless data transfer between GitLab and PM tools such as Asana…”
   • [claimed-docs] “Manage your entire development cycle more efficiently from a single tool by syncing GitLab with Unito. With Unito, you can connect GitLab wi…”
   • [claimed-docs] “The Linux package includes services and tools to install GitLab without laborious configuration.”

   proof ↗⚑ flag

4. devops-leadInstall a self-managed instance of the platform without laborious configuration

   weight 3 · round to GitLab
   GitHub—none0/10

   GitHub.com is a cloud SaaS product; while GitHub Enterprise Server exists as a self-managed option in reality, the evidence pack contains no mention of a self-hosted/on-prem installable instance or any setup/configuration process for it. No docs, quickstarts, or community evidence address self-hosting installation effort, so this axis cannot be credited as delivered.

   ⚑ flag

   GitLab✓fullclaimed7/10

   GitLab explicitly documents an omnibus 'Linux package' that 'includes services and tools to install GitLab without laborious configuration,' plus alternate self-managed paths (Docker images, Helm chart/Operator for cloud-native, self-compile) and scaling guidance, directly matching the devops-lead's self-hosting install story. Missing for 10: independent/hands-on confirmation that the install is actually low-effort in practice, and no step-count/time-to-install evidence beyond vendor docs.

   • [claimed-docs] “The Linux package includes services and tools to install GitLab without laborious configuration.”
   • [claimed-docs] “Scale your GitLab installation by using the recommended configurations.”
   • [claimed-docs] “If you're using cluster management, we recommend the Helm chart or the Operator for installing cloud-native GitLab.”
   • [claimed-docs] “GitLab maintains a set of official Docker images based on the Linux package.”
   • [claimed-docs] “If the Linux package isn't available for your distribution, you can self-compile GitLab.”

   proof ↗⚑ flag