Develop

RenderDoc AI Tools

Updated: Sep 9, 2026

Overview

The RenderDoc Meta Fork installer ships a set of AI skills. Copy them to where your AI coding agent looks for skills, and the agent guides you through capturing a frame on a connected Meta Quest, finding the draw calls that cost the most GPU time, and testing a fix.
The skills drive the renderdoccmd command-line tool that ships in the same package, so there is no second download and no service to run. Every number the agent reports comes from a real capture of your app running on real hardware.

What The Skills Cover

SkillWhat it helps with
optimization-agent
Entry point. Coordinates capture, classification, and the per-area skills into one loop
shader-optimization
Find and fix shader bottlenecks using GPU counters and ISA analysis
vertex-optimization
Cut triangle counts and vertex-fetch stalls through geometry simplification
mesh-preview
Check simplified geometry visually
isa-analysis
Inspect compiled Adreno instruction mix and register pressure
renderdoccmd-adb-capture
Capture frames from an app on the headset
renderdoccmd-adb-session
Interactive replay session for per-draw inspection and shader hot-swap
renderdoccmd-shader
One-shot shader extract and replace from the command line
renderdoccmd-highlight
Render annotated frames for overdraw and per-resource attribution
renderdoccmd-replay
Host-side capture, replay, convert, and remote server
mcp-tool
Python API covering the same capture and replay surface. Needs the renderdoc_mcp package from the MCP folder, a sibling of the installation’s skills folder; setup is not covered here
The installation carries the same list in its own .claude/CLAUDE.md, so that index stays correct as the skills change.

Before You Start

  • RenderDoc Meta Fork, installed from the Downloads page. The skills ship in the Windows and Mac installers.
  • An AI agent that reads skill directories, such as Claude Code.
  • adb on your PATH, with the headset connected over USB and authorized. Run adb devices and confirm the headset reports the device state.
  • Your app installed on the headset. A debuggable build works as it is. A non-debuggable build, such as a store build, works only where JDWP can be enabled, which on API level 34 and above needs root access on the headset — see the troubleshooting notes below.
RenderDoc Meta Fork installs its remote server on the headset the first time it launches your app, so there is no setup step of your own for that. Taking and Loading a Capture covers the same ground from the UI, if you want to see a capture happen before you hand the job to an agent.

Copy The Skills Into Your Project

The skills ship inside the RenderDoc Meta Fork installation, at these locations:
PlatformSkills folder in the installation
Windows
C:\Program Files\RenderDocForMetaQuest\.claude\skills
Mac
/Applications/RenderDoc Meta Fork.app/Contents/Resources/.claude/skills
Do not run your agent from that folder. It belongs to the installed application, and your agent needs to sit in your own project so it can read and edit your shaders. Copy the skills into your project instead.
Run these from the root of your project, not from your home folder. Both commands use a relative path, so the skills land in whichever directory you run them from.
On Windows, in PowerShell:
New-Item -ItemType Directory -Force ".claude\skills"
Copy-Item -Recurse -Force "C:\Program Files\RenderDocForMetaQuest\.claude\skills\*" ".claude\skills\"
On Mac, in a terminal:
mkdir -p .claude/skills
cp -R "/Applications/RenderDoc Meta Fork.app/Contents/Resources/.claude/skills/"* .claude/skills/
Each skill has to sit directly inside .claude/skills, as .claude/skills/<skill-name>/SKILL.md. A grouping folder in between hides every skill under it.
The skills are all your agent needs from the installation. It also ships a .llms folder that mirrors them for agents reading that layout instead, which you can leave where it is.
Now open your project in the agent.

Make renderdoccmd Reachable

The skills call renderdoccmd, which ships beside the RenderDoc Meta Fork executable. Add its directory to your PATH so the agent can run it by name.
On Windows, in PowerShell:
$env:PATH += ";C:\Program Files\RenderDocForMetaQuest"
On Mac, in a terminal:
export PATH="/Applications/RenderDoc Meta Fork.app/Contents/MacOS:$PATH"
Each command lasts for the current session only. To make it permanent, set it through System Properties > Environment Variables on Windows, or add the line to your shell profile on Mac.
Confirm it worked:
renderdoccmd adb-list
The command prints JSON listing each connected device serial:
{"success": true, "devices": ["1WMHH816AB0123"]}

Run Your First Analysis

Talk to the agent in plain language and name your app’s Android package. For example:
Profile com.mystudio.myapp on my headset and show me the most expensive draw calls.
The agent picks the skills and runs the commands. A first pass looks like this:
# 1. Confirm the headset is visible
renderdoccmd adb-list

# 2. Launch the app with RenderDoc injected
renderdoccmd adb-launch-drawcall-profiling --device <SERIAL> --package com.mystudio.myapp

# 3. Capture one frame, using the ident returned by step 2. The .rdc lands in
#    the current directory unless you pass --output-dir
renderdoccmd adb-capture --device <SERIAL> --ident <IDENT> --frames 1
From the resulting .rdc file, the agent opens a replay session, collects per-draw GPU counters, and sorts by Clocks to rank draw calls by cost. It then reads back the shader for the draw you pick, proposes a change, swaps it in, and measures the same draw again.
Pick the launch mode that matches your goal. adb-launch gives screenshots and no GPU counters. adb-launch-profiling gives counters and blocks screenshots. adb-launch-drawcall-profiling, used above, gives both, which is what shader work needs.
To read the counters yourself, see Performing a Draw Call Trace, which explains what each one measures.

Troubleshooting

No device is found

Symptom: A command returns No ADB devices found.
Solution: Run adb devices. If the headset is missing, reconnect the cable. If it reports unauthorized, put the headset on and accept the USB debugging prompt.

Launch fails on a store or other non-debuggable build

Symptom: The launch fails and asks you to declare android:debuggable="true" in the app manifest.
Solution: RenderDoc Meta Fork injects its layer into non-debuggable apps over JDWP, and Android 14 disabled JDWP by default. Check the device API level:
adb shell getprop ro.build.version.sdk
If it reports 34 or higher, enable JDWP and reboot. The property is read at runtime startup, so the reboot is required:
adb root
adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
adb reboot
This remedy applies on API level 34 and above. If your device reports a lower level, see The layer package is not visible to your app.

The device has no root access

Symptom: The same launch failure, and adb root reports that it is unavailable on a locked build.
Solution: On API level 34 and above, JDWP cannot be enabled without root, so a non-debuggable app cannot be injected on that headset. Three ways forward: rebuild the app with android:debuggable="true", unlock the bootloader if your device supports it, or flash a userdebug OS build, which has root access.

The layer package is not visible to your app

Symptom: The same missing-android:debuggable message, on a device where JDWP is not the problem.
Solution: On Quest 2, Quest 3, Quest 3S, and Quest Pro, the RenderDoc layer package has to be installed with --force-queryable so your app can resolve it. The APK ships with the installation, so reinstall it with that flag.
On Windows, in PowerShell:
adb install -r -d --force-queryable "C:\Program Files\RenderDocForMetaQuest\plugins\android\com.oculus.renderdoccmd.arm64.apk"
On Mac, in a terminal:
adb install -r -d --force-queryable "/Applications/RenderDoc Meta Fork.app/Contents/lib/plugins/android/com.oculus.renderdoccmd.arm64.apk"

Screenshots come back blank

Symptom: Counters arrive, but render targets and screenshots are empty.
Solution: The app was launched in profile mode, which blocks screenshots. Relaunch with adb-launch-drawcall-profiling, which gives counters and screenshots together.

The capture will not open

Symptom: Opening a capture fails with Capture requires extension '<name>' which is not supported.
Solution: A capture records the exact feature set of the GPU that produced it. Replay the capture on the same headset model that captured it.

See Also

Meta
English (US)
© 2026 Meta