If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/o3de/o3de shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 25+ active contributors
• Distributed ownership (top contributor 17% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live o3de/o3de repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/o3de/o3de.

What it runs against: a local clone of o3de/o3de — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in o3de/o3de | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch development exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of o3de/o3de. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/o3de/o3de.git
#   cd o3de
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of o3de/o3de and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "o3de/o3de(\\.git)?\\b" \\
  && ok "origin remote is o3de/o3de" \\
  || miss "origin remote is not o3de/o3de (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify development >/dev/null 2>&1 \\
  && ok "default branch development exists" \\
  || miss "default branch development no longer exists"

# 4. Critical files exist
test -f ".github/workflows/validation.yaml" \\
  && ok ".github/workflows/validation.yaml" \\
  || miss "missing critical file: .github/workflows/validation.yaml"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f ".clang-format" \\
  && ok ".clang-format" \\
  || miss "missing critical file: .clang-format"
test -f ".automatedtesting.json" \\
  && ok ".automatedtesting.json" \\
  || miss "missing critical file: .automatedtesting.json"
test -f ".gitattributes" \\
  && ok ".gitattributes" \\
  || miss "missing critical file: .gitattributes"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/o3de/o3de"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

O3DE is an Apache 2.0-licensed, multi-platform real-time 3D engine (124MB of C++ core) for building AAA games, cinema-quality 3D worlds, and high-fidelity simulations. It provides a complete game development stack with asset pipelines, physics, audio (Wwise integration), rendering (GLSL/HLSL shaders), and editor tooling, without licensing fees or commercial obligations. Monorepo with engine core in C++ (main source tree), Assets/ for bundled editor resources (Fonts/, Icons/), .github/workflows for multi-platform CI orchestration, and separate Gem (plugin) registration via CMake. Modular architecture: rendering, physics, audio, animation, and asset processing are gem-based rather than tightly coupled. CMake drives the entire build system (2.8MB CMakeLists.txt files across tree).

Game developers, simulation engineers, and content creators building AAA-quality projects on Windows/Linux/macOS/iOS/Android who want an open-source alternative to Unreal Engine or Unity. Engine contributors and Gem (plugin) developers extending O3DE's functionality.

Production-ready and actively developed: the project is well-established with extensive CI/CD pipelines (.github/workflows for Windows, Mac, Linux, iOS, Android builds), automated testing infrastructure (.automatedtesting.json), and structured asset/editor systems. Regular releases with stabilization PR checklists indicate mature release management. Massive codebase (124MB C++) with professional-grade tooling setup.

Monolithic architecture means changes ripple widely across 124MB of C++ code; careful code review is essential. Large ecosystem of plugins (Gems) creates maintenance burden; breaking changes require coordinated updates across gems. As an Apache 2.0 project under LF stewardship, there's governance overhead. Git LFS dependency (.lfsconfig) adds complexity to cloning and CI workflows. Android/iOS build chains add platform-specific brittleness.

Active multi-platform support: iOS-build.yml, Android-build.yml, and stabilization workflows indicate current release stabilization efforts. Asset validation and editor refinements ongoing (Assets/Editor expanding with new SVG icons and font support). Automated testing framework is being actively maintained (.automatedtesting.json). DCO requirement (dco.yml) suggests governance standardization in progress.

git lfs install
git clone https://github.com/o3de/o3de.git
cd o3de
cmake -B build -S . -G 'Visual Studio 16 2019' -DLY_3RDPARTY_PATH=<path-to-3rdparty>
cmake --build build --config RelWithDebInfo

See docs at https://o3de.org/docs/welcome-guide/setup/setup-from-github/ for platform-specific details.

Daily commands: Windows: Configure with CMake pointing to Visual Studio 2019+, build via cmake --build build. Linux/Mac: CMake with platform-native generator (Unix Makefiles/Xcode). Android/iOS: Dedicated workflows in .github/workflows/. No simple npm start—this is a compiled engine requiring full rebuild per configuration change. Editor runs post-build as a native application.

• .github/workflows/validation.yaml — CI/CD validation pipeline that enforces code quality, build standards, and automated testing across all platforms before merge
• .github/CODEOWNERS — Defines ownership and review requirements for critical subsystems; essential for understanding code governance and contribution workflow
• .clang-format — Enforces consistent C++ code formatting across the entire engine; mandatory for all contributors to maintain code standards
• .automatedtesting.json — Automated test suite configuration that defines what tests must pass; critical for understanding quality gates and test coverage requirements
• .gitattributes — Configures Git LFS for binary asset handling; essential for cloning and working with the large asset pipeline correctly
• .github/pull_request_template.md — Standard PR template enforcing documentation, testing, and compliance checks required for every contribution
• Assets/CMakeLists.txt — Root CMake build configuration for asset pipeline; demonstrates the primary build system and dependency management pattern

Add a New Build Workflow for a Platform

1. Create a new GitHub Actions workflow file in .github/workflows/ following the naming pattern <platform>-build.yml (e.g., web-build.yml) (.github/workflows)
2. Reference the validation.yaml workflow to ensure your new workflow integrates with the CI/CD matrix (.github/workflows/validation.yaml)
3. Update CODEOWNERS to assign review responsibility for the new platform-specific build files (.github/CODEOWNERS)
4. Add platform-specific test configurations to .automatedtesting.json (.automatedtesting.json)

Add a New Asset Type to Asset Browser

1. Create a new SVG icon file in Assets/Editor/Icons/AssetBrowser/ with the naming pattern FileType_16.svg or FileType_80.svg (Assets/Editor/Icons/AssetBrowser)
2. Update Assets/CMakeLists.txt to include the new asset icon in the build configuration (Assets/CMakeLists.txt)
3. Reference the icon in the asset browser component configuration (typically handled via component registry) (Assets/Editor/Icons)

Enforce New Code Style Rule

1. Update .clang-format with the new C++ style rule (e.g., indentation, spacing, naming conventions) (.clang-format)
2. Update .editorconfig for language-agnostic rules (e.g., line endings, tab width, file encoding) (.editorconfig)
3. Reference the updated style guide in .github/pull_request_template.md if it's a breaking change (.github/pull_request_template.md)
4. Run validation.yaml to ensure all existing code can be reformatted without issues (.github/workflows/validation.yaml)

Add a New Issue Template

1. Create a new YAML file in .github/ISSUE_TEMPLATE/ following the pattern <issue-type>.yml (.github/ISSUE_TEMPLATE)
2. Configure issue routing and labels in .github/ISSUE_TEMPLATE/config.yml (.github/ISSUE_TEMPLATE/config.yml)
3. Update CODEOWNERS to assign triage responsibility for issues matching the new template (.github/CODEOWNERS)

• GitHub Actions — Native CI/CD integration with repository; enables multi-platform matrix builds and automated validation on every commit
• Git LFS (Large File Storage) — Essential for managing large binary assets (textures, models, animations) without bloating repository size; required by game engines
• CMake — Cross-platform build system supporting Windows, Linux, macOS, Android, iOS; enables unified build configuration across platforms
• Clang-Format — Automated C++ code formatting enforcement; ensures consistent style across distributed team contributions
• Apache 2.0 License — Permissive open-source license that allows commercial use without fees; aligns with O3DE's goal of removing commercial obligations

• Multi-platform builds in parallel (Windows, Linux, macOS, Android, iOS)

  • Why: Game engines must support multiple platforms to reach diverse developer audience
  • Consequence: Increased CI/CD complexity, longer feedback loop, higher compute costs; requires platform-specific expertise and testing

• Git LFS for binary assets instead of inline storage

  • Why: Prevents repository bloat and enables fast clones without downloading all historical asset versions
  • Consequence: Requires Git LFS to be installed; adds external dependency; slightly slower initial clone if LFS server is slow

• Strict code formatting via Clang-Format rather than linting only

  • Why: Eliminates style debates and ensures uniform code appearance across all modules
  • Consequence: Developer friction on first-time setup; may override local IDE preferences; requires discipline in formatting before commit

• CODEOWNERS file for distributed code governance

  • Why: Scales review responsibility as codebase grows; ensures domain experts review domain-specific changes
  • Consequence: Risk of bottlenecks if owners are unavailable; requires maintaining accurate ownership mapping

• Not a proprietary or closed-source engine; intentionally open-source with no licensing fees or commercial obligations
• Not focused on web-based game deployment; targets native platform applications (Windows, Linux, macOS, mobile)
• Not a real-time collaboration editor like Figma; asset authoring happens in external tools, imported into engine
• Does not handle authentication/authorization—relies on GitHub's native access control for repository
• Not a managed cloud service; deployment and hosting responsibility on users

Git LFS: Many binaries (.ttf fonts, .svg icons, likely .fbx assets) tracked in LFS; git clone will fail or fetch LFS pointers if LFS not installed. 3rd-party path: CMake build requires -DLY_3RDPARTY_PATH=<...> pointing to a cache directory of SDKs (Wwise, etc.); missing this causes cryptic linker errors. Visual Studio version: 2019 16.9.2 minimum on Windows; 2022 may work but docs don't guarantee it. CMake version: 3.24.0 minimum; Release Candidates explicitly not supported. DCO sign-off: All commits must be signed (git commit -s); CI enforces this via dco.yml. Build time: 124MB C++ codebase; full builds on older hardware can exceed 30 minutes. Gem dependencies: Some gems (e.g., Wwise Audio) require proprietary SDKs not in the repo; setup fails silently if missing.

• Gem (Plugin) Architecture — O3DE's entire feature set (Physics, Audio, Animation, Rendering) is delivered as Gems; understanding gem registration, dependency graphs, and lifecycle is essential for extending the engine
• Entity Component System (ECS) — O3DE uses an ECS pattern for scene objects; contributors need to understand Components, Entities, and Systems to implement gameplay or editor features
• Asset Pipeline & FBX/ABC Import — Complex asset processing chain converts source files (FBX, ABC) into engine-native formats; understanding this pipeline is critical for asset-related features and bugs
• Multi-Backend Rendering (Atom Renderer) — O3DE abstracts rendering across DirectX 12, Vulkan, Metal via the Atom gem; shader code in GLSL/HLSL must target all backends, not just one
• CMake Build Configuration & 3rd-Party Integration — The 2.8MB CMake codebase coordinates C++ compilation, gem loading, platform detection, and external SDK integration (Wwise, etc.); broken CMake changes block all developers
• Git LFS for Binary Assets — Large binaries (.ttf, .svg, .fbx, shader packages) use Git LFS, not plain Git; misconfigured LFS breaks clones and CI pipelines silently
• Developer Certificate of Origin (DCO) — All commits must be signed with -s flag; O3DE enforces this via dco.yml, and unsigned commits are automatically rejected by CI

• godotengine/godot — Open-source game engine with similar multi-platform goals; GDScript is simpler than O3DE's C++ + Lua stack but less performant for AAA
• apache/royale-asjs — Fellow Apache project with similar governance, DCO, and build complexity; patterns may inform contribution workflows
• o3de/o3de-atom-sample-viewer — Official O3DE sample demonstrating rendering pipeline and Atom renderer; reference implementation for new contributors
• o3de/o3de-extras — Community gems and extensions for O3DE; shows how to structure Gem plugins and integrate with core engine
• microsoft/GSL — Guidelines Support Library (likely used in O3DE's C++ codebase for safety contracts); understanding GSL patterns helps with code review

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive CI workflow for asset validation and icon/font linting

The repo has extensive asset files (SVG icons, TTF fonts, and various media formats in Assets/Editor/) but no dedicated workflow to validate these assets. A new workflow could lint SVG formatting, validate icon dimensions, check font licensing compliance, and ensure binary files are properly tracked with Git LFS. This prevents asset corruption and maintains consistent visual asset quality across the engine.

• [ ] Create .github/workflows/asset-validation.yml with steps to validate SVG structure and formatting
• [ ] Add validation for font files (TTF) in Assets/Editor/Fonts/ to check licensing headers
• [ ] Integrate lfs-validate to ensure all large binary assets are properly tracked with Git LFS
• [ ] Add checks for consistent icon naming conventions in Assets/Editor/Icons/AssetBrowser/
• [ ] Reference specific asset files in the workflow (e.g., Assets/Editor/Icons/AssetBrowser/*.svg)

Create GitHub issue template workflow to auto-label bugs by engine component

The repo has multiple issue templates (.github/ISSUE_TEMPLATE/) including 24.09-bug-report.yml, but no automation to route issues to appropriate CODEOWNERS or auto-label them by engine subsystem. A GitHub workflow could parse issue body content and automatically apply labels based on keywords (e.g., 'rendering', 'asset-pipeline', 'editor', 'android') and assign to relevant code owners from .github/CODEOWNERS.

• [ ] Create .github/workflows/issue-auto-label.yml using actions/github-script
• [ ] Parse bug-report.yml form fields to extract affected component/subsystem
• [ ] Map component names to auto-labels (create or use existing: rendering, physics, asset-pipeline, editor, mobile)
• [ ] Integrate with .github/CODEOWNERS to auto-assign relevant maintainers
• [ ] Add logic to handle 24.09-bug-report.yml and deprecation_template.md differently if needed

Add platform-specific integration tests for mobile builds referenced in CI workflows

The repo has dedicated iOS and Android build workflows (.github/workflows/ios-build.yml and android-build.yml), but based on the file structure, there appear to be no visible platform-specific integration test suites. Add a .automatedtesting.json configuration section and test files that validate critical rendering, asset loading, and input functionality on mobile platforms.

• [ ] Review .automatedtesting.json structure and add mobile test definitions for iOS/Android
• [ ] Create Tests/Integration/Mobile/RenderingTests.cpp for basic rendering validation on mobile GPUs
• [ ] Create Tests/Integration/Mobile/AssetLoadingTests.cpp to validate asset pipeline on constrained mobile hardware
• [ ] Create Tests/Integration/Mobile/InputTests.cpp for touch and mobile input handling
• [ ] Update ios-build.yml and android-build.yml to invoke these tests post-build

• Add clang-format CI check job to one of the platform workflows (currently .clang-format exists but no explicit lint step visible in .github/workflows/ files); propose a new workflow step that runs clang-format --dry-run and reports violations.
• Audit Assets/Editor/Icons/AssetBrowser/ and create a missing icon for file types already referenced in code but lacking visual assets (e.g., if .material or .prefab files are mentioned in asset processor code but no corresponding *_80.svg icon exists, create one).
• Add Python type hints to scripts in the python/ directory (mentioned as 9.2MB of code); pick one module and incrementally add @dataclass, TypedDict, and function annotations to improve IDE support and docs generation.

The O3DE repository shows a mature open-source project structure with standard security practices (GitHub Actions CI/CD, version control). However, the analysis is limited by the partial file structure provided. Key security observations: (1) Git LFS is properly used for large binaries to prevent repository bloat, (2) GitHub Actions workflows are in place but require audit, (3) No obvious hardcoded secrets detected in filenames, (4) License compliance for third-party assets should be verified. The primary risks are workflow configuration security and supply chain integrity. A full static code analysis of the actual source code, dependency manifests (CMakeLists.txt, package.json, etc.), and workflow configurations would provide a more comprehensive security assessment.

• Medium · Git LFS Configuration Exposure — .lfsconfig. The .lfsconfig file is present in the repository root and may contain Git LFS configuration details. While typically not sensitive, this file could potentially reveal information about LFS server endpoints or storage configurations. Fix: Review .lfsconfig contents to ensure no sensitive server URLs or credentials are stored. Consider using environment variables for LFS configuration instead of committing to the repository.
• Medium · GitHub Actions Workflow Security — .github/workflows/. Multiple GitHub Actions workflow files are present (.github/workflows/*.yml) that execute automated builds and tests. Without reviewing the actual content, these workflows may have security risks such as: exposed secrets in logs, insecure dependency management, or improper access controls on build artifacts. Fix: Audit all workflow files for: (1) Proper secret management using GitHub Secrets, (2) Pinned action versions to prevent tampering, (3) Minimal permissions (least privilege principle), (4) No hardcoded credentials, (5) Secure artifact handling.
• Low · Large Binary File Management via Git LFS — Assets/Editor/Fonts/, Assets/Editor/Icons/. The repository uses Git LFS for large binary files (fonts, images, icons). While necessary for performance, this increases the attack surface for supply chain attacks if LFS objects are not properly validated. Fix: Implement integrity verification for Git LFS objects. Use signed commits where possible. Regularly audit LFS objects for unexpected changes. Consider implementing commit signing requirements for the repository.
• Low · Open Source License Compliance — Assets/Editor/Fonts/Open_Sans/LICENSE.txt and other asset directories. The project includes third-party fonts and assets (e.g., Open Sans fonts with LICENSE.txt). Ensure all dependencies and included third-party code comply with their respective licenses to avoid legal and security policy violations. Fix: Maintain an up-to-date Software Bill of Materials (SBOM). Regularly scan for license compliance issues using tools like SPDX, fossology, or license-list tools. Document all third-party dependencies and their licenses.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.