List the official FtcRobotController sample OpModes (drive code, sensors, AprilTag vision, gamepad, telemetry...). Start here to find working reference code for any FTC hardware or SDK feature.

Return the full Java source of an official FTC sample OpMode by name (from list_samples).

Keyword search across the Pedro Pathing documentation and the official FTC sample OpModes. Use for questions about path following, tuning, localization, coordinates, and SDK features.

Return a full Pedro Pathing documentation page as markdown, by id from search_docs (e.g. 'pathing/examples/auto').

Report local FTC sample and Pedro documentation counts, Git branches, commits, dates, and cache location without using the network.

Fast-forward the local official FTC SDK samples and Pedro docs checkouts. Refuses to touch a reference checkout with local changes.

Start here when entering a robot project or debugging setup. Summarizes the resolved project path, SDK, Git state, OpModes, subsystem docs, Pedro setup, hardware-name collisions, latest APK, reference library, and Android SDK, then gives next actions.

Read-only pre-competition audit for duplicate Driver Station names, orphaned generated file pairs, broken subsystem-doc links, incompatible hardware types, stale or missing APKs, disabled OpModes, TODOs, and uncommitted Git changes.

Clone a fresh FtcRobotController SDK project (the standard FTC season starting point) into the workspace. Skip this if the team already has a project — pass its path to the other tools instead.

List all @TeleOp/@Autonomous OpModes in the project's TeamCode module.

Inventory Java and robot-doc files marked as scaffolded by ftc-toolchain, grouped by kind. Markers identify origin only—team edits are expected and must be preserved.

List project-scoped recovery snapshots created automatically before ftc-toolchain overwrites files, including each backup ID and contained relative paths.

Preview restoration from an ftc-toolchain backup, optionally selecting relative file paths. No files change unless confirm is true; a confirmed restore backs up current versions first and never deletes files.

Scaffold a new Java OpMode in TeamCode. Templates:

• linear-teleop: Minimal LinearOpMode TeleOp skeleton (hardware mapping left to you)

• mecanum-teleop: Complete 4-motor mecanum/omni TeleOp with POV drive (based on BasicOmniOpMode). Hardware names: left_front_drive, left_back_drive, right_front_drive, right_back_drive

• linear-auto: Minimal LinearOpMode Autonomous skeleton with elapsed-time guard

• pedro-auto: Pedro Pathing autonomous using a finite state machine over PathChains. Requires install_pedro first; tune poses for your season

• pedro-teleop: Pedro Pathing TeleOp: manual mecanum drive with on-demand automated path following and slow mode. Requires install_pedro first

Install the Pedro Pathing library into an FTC SDK project: adds the Gradle maven repo + dependencies, raises compileSdk to 34, and scaffolds pedroPathing/Constants.java (mecanum + Pinpoint by default). The constants MUST be tuned afterwards — see search_docs 'tuning'.

Scaffold a plain FTC subsystem class (constructor takes HardwareMap; hardware fields, config-name constants, action methods, and a safety stop()). Also writes a bench-test TeleOp and a markdown doc in docs/. This is the recommended way to structure robot code — one class per mechanism (intake, spindexer, turret...).

Write or update the markdown knowledge-base doc for a subsystem (docs/subsystems/.md) and refresh the docs/ROBOT.md index. Use this to record what each function does, tuning values, config names, and quirks as the team describes them — so future sessions understand the robot without reading all the code.

List the robot's subsystems from the docs/ knowledge base. Start here to learn the robot's architecture.

Return a subsystem's knowledge-base doc (hardware, config names, functions, tuning, quirks), optionally with its Java source.

Scaffold a stateless static-only helper class (e.g. live trajectory math) that any OpMode or subsystem can call. Keeps math out of subsystem/OpMode files.

Scan TeamCode for every robot-configuration name (from hardwareMap.get and subsystem constructors) and list them, flagging any name used in multiple files. Use to cross-check code against the Driver Station configuration and catch typos/collisions.

Pre-flight check for robot configuration mistakes. Flags one Driver Station name requested as incompatible device types, cross-file sharing, and unresolved constants, then tells the team whether it is safe to continue.

Generate a TeleOp OpMode PLUS a separate Controls.java that holds only the controller bindings, so a driver can remap buttons without touching robot logic or an LLM. Describe the drivetrain, which subsystems to use, button actions (hold/press/toggle → subsystem calls), an optional slow mode, and named automations (multi-step or sensor-driven behaviors, which are scaffolded as stub methods to fill in).

Preferred high-level deployment entry point. With connection usb, build TeamCode and install it on a Control Hub or Robot Controller already visible to adb over a physical USB cable. With connection wifi-switch, build while online, then queue the local saved-network switch, ADB install, Robot Controller restart, and original-Wi-Fi restoration workflow.

Build TeamCode while internet is available, start a local background job that switches macOS or Windows to a saved Control Hub Wi-Fi profile, connects ADB, installs the APK, restarts Robot Controller, and restores the original Wi-Fi even after failure. Returns before the network switch so the AI can receive the job ID.

Read the latest or specified background Wi-Fi deployment job after the computer reconnects to internet. Reports queued, switching, deploying, returning, succeeded, or failed state plus the complete local build/deploy/recovery timeline.

List Android devices visible to adb (Control Hub / Robot Controller phone).

Connect adb to a REV Control Hub or RC phone over WiFi. Default target is 192.168.43.1:5555 (the Control Hub when the laptop is joined to the robot's WiFi network).

Read-only connected-device snapshot: selected adb serial, model, Android version, Robot Controller app version, battery service, and data storage. Requires an explicit serial when multiple devices are attached.

Force-stop and restart the Robot Controller app without rebuilding or reinstalling the APK. Useful when the Driver Station is stale or an OpMode left the app unhealthy.

Compile the TeamCode module with Gradle (assembleDebug). Returns the APK path on success, or the extracted compiler errors on failure. First build can take several minutes.

Install the built TeamCode APK on the connected robot (adb install) and restart the Robot Controller app. Run build first, and adb_connect/adb_devices to make sure a device is attached.

Safest competition-day deployment path: build TeamCode first and only install the APK if that build succeeds, then restart the Robot Controller app. This prevents accidentally deploying a stale APK.

Clear the connected robot's logcat buffer before reproducing a crash or bad behavior. Call robot_logs afterward for a clean signal.

Dump recent logcat from the robot. Use after deploying or when an OpMode crashes/misbehaves. Useful filters: 'RobotCore' (SDK events), your OpMode class name, 'Exception'.