ワンクリックでManusで任意のスキルを実行

explain

スター15

フォーク6

更新日2026年6月17日 13:11

Explain ArduPilot code, architecture, or subsystems in context. Use when the user asks how something works, what a file does, or wants to understand a code path.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

fossuav

fossuav/aap

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Explain ArduPilot Code

Explain $ARGUMENTS in the context of ArduPilot's architecture.

Approach

Find the code — locate the relevant files, classes, and functions
Read the code — read the actual implementation, don't guess
Trace the call chain — understand how it's invoked (scheduler, main loop, interrupt)
Identify the subsystem — where it fits in ArduPilot's architecture
Explain clearly — use plain language, reference specific line numbers

ArduPilot architecture context

Execution model

Main loop runs in AP_Vehicle::loop() calling the scheduler
AP_Scheduler runs tasks at defined rates (400Hz, 50Hz, 10Hz, 1Hz, etc.)
Each library's update() is called from scheduler tasks
SITL runs the same code path as real hardware via HAL abstraction

Key singletons

AP::ahrs() — attitude/heading (wraps EKF)
AP::gps() — GPS data
AP::baro() — barometer
AP::ins() — inertial sensors (IMU)
AP::logger() — DataFlash logging
AP::vehicle() — current vehicle instance
gcs() — MAVLink GCS communication

Data flow patterns

Sensors → EKF → AHRS → Controllers → Actuators
Sensor drivers read hardware via HAL, publish to frontend
EKF fuses sensor data into state estimate
Vehicle mode code reads AHRS, commands controllers
Controllers output to motors/servos via HAL

Common patterns to explain

Frontend/Backend split: Public API (frontend) delegates to driver (backend)
Parameter system: AP_Param with AP_GROUPINFO tables
Scheduler tasks: Registered in vehicle's scheduler_tasks[] array
MAVLink handlers: GCS_MAVLINK::handle_message() dispatch
Flight modes: Mode base class with run() called each loop iteration
Logging: AP_Logger::Write() with format strings matching LogStructure.h

When explaining, always

Reference specific file paths and line numbers
Show the actual code, don't paraphrase
Trace the execution path from entry point
Note any compile-time guards (#if FEATURE_ENABLED)
Identify the coordinate frame (NED, body, etc.) for navigation code
Mention relevant parameters that control behavior

このリポジトリの他の Skills

同じリポジトリ

hwdef-check

fossuav/aap

Review an ArduPilot new-board hwdef PR. Stashes any local changes, checks the PR out as a branch in the current repo, runs DMA / board-ID / file-presence / commit-structure checks, layers the hwdef playbook on top, and (after confirmation) posts a review comment on the PR — then restores the original branch and pops the stash. Use when the user asks to review or pre-review an hwdef PR.

Analyze ArduPilot DataFlash .bin log files or MAVLink .tlog telemetry logs. Use when the user provides a .bin or .tlog log file path or asks to analyze flight log data.

2026-07-1215

log-analyze

fossuav/aap

Analyze ArduPilot DataFlash .bin log files or MAVLink .tlog telemetry logs. Use when the user provides a .bin or .tlog log file path or asks to analyze flight log data.

2026-06-2315

aap-update

fossuav/aap

Check the local ArduPilot AI Playbook version against the upstream GitHub version and update if newer. Use when the user asks to update the playbooks, check for playbook updates, or wants to know which version is installed.

2026-06-1715

lua-crsf

fossuav/aap

Write ArduPilot CRSF (Crossfire) menu scripts using crsf_helper.lua. Use when the user asks to create or modify CRSF/ELRS transmitter menus.

2026-06-1715

Explain ArduPilot Code

Explain $ARGUMENTS in the context of ArduPilot's architecture.

Approach

Find the code — locate the relevant files, classes, and functions

Read the code — read the actual implementation, don't guess

Trace the call chain — understand how it's invoked (scheduler, main loop, interrupt)

Identify the subsystem — where it fits in ArduPilot's architecture

Explain clearly — use plain language, reference specific line numbers

ArduPilot architecture context

Execution model

Main loop runs in AP_Vehicle::loop() calling the scheduler

AP_Scheduler runs tasks at defined rates (400Hz, 50Hz, 10Hz, 1Hz, etc.)

Each library's update() is called from scheduler tasks

SITL runs the same code path as real hardware via HAL abstraction

Key singletons

AP::ahrs() — attitude/heading (wraps EKF)

AP::gps() — GPS data

AP::baro() — barometer

AP::ins() — inertial sensors (IMU)

AP::logger() — DataFlash logging

AP::vehicle() — current vehicle instance

gcs() — MAVLink GCS communication

Data flow patterns

Sensors → EKF → AHRS → Controllers → Actuators

Sensor drivers read hardware via HAL, publish to frontend

EKF fuses sensor data into state estimate

Vehicle mode code reads AHRS, commands controllers

Controllers output to motors/servos via HAL

Common patterns to explain

Frontend/Backend split: Public API (frontend) delegates to driver (backend)

Parameter system: AP_Param with AP_GROUPINFO tables

Scheduler tasks: Registered in vehicle's scheduler_tasks[] array

MAVLink handlers: GCS_MAVLINK::handle_message() dispatch

Flight modes: Mode base class with run() called each loop iteration

Logging: AP_Logger::Write() with format strings matching LogStructure.h

When explaining, always

Reference specific file paths and line numbers

Show the actual code, don't paraphrase

Trace the execution path from entry point

Note any compile-time guards (#if FEATURE_ENABLED)

Identify the coordinate frame (NED, body, etc.) for navigation code

Mention relevant parameters that control behavior

name	explain
description	Explain ArduPilot code, architecture, or subsystems in context. Use when the user asks how something works, what a file does, or wants to understand a code path.