Integration Skill
What Is the FH2 Integration Skill
The FH2 Integration Skill is a domain knowledge package designed for AI coding assistants. Once installed, whenever you raise a FlightHub 2 integration requirement with your AI assistant, the assistant answers according to a validated methodology instead of guessing from memory or inventing interfaces. It supports mainstream coding assistants such as Claude Code, Cursor, OpenCode, Trae, and Tongyi Lingma.
The Skill covers two mainstream integration workflows — DFR emergency response and inspection / patrol — and includes a complete set of resources such as the knowledge base, a reference demo implementation, and evaluation cases.
Problems It Solves
| Without the Skill | With the Skill |
|---|---|
| The AI may invent API endpoints that do not exist | Anti-hallucination is enforced: when uncertain, it says so and points to the official documentation for verification |
| Public Cloud and On-Premises interfaces get mixed up | The deployment model is confirmed first, and API boundaries are strictly separated |
| Emergency dispatch practices are applied to routine inspection | The scenario is confirmed first, and the two workflows are designed separately |
| Official documentation is scattered and hard to navigate | Selection tables organized by capability domain, plus requirement-to-endpoint matching |
| Generated code lacks security guardrails | Built-in minimum requirements for signature verification, idempotency, permissions, and auditing |
The Integration Skill does not write your business code for you. It ensures that, within the FlightHub 2 domain, the AI does not make things up, does not cross boundaries, and does not omit security items.
Who Should Use It, and How
Users Without Custom Development Experience
Goal: Understand what FlightHub 2 can do.
Simply ask the AI assistant in plain language. The Skill introduces capabilities through a capability menu, then works out a solution that fits your business through multi-turn conversation.
Sample question: We want to use drones for campus security. What capabilities can FlightHub 2 provide?
Users With Some Development Experience Who Need a Quick Demo
Goal: Get a demo running quickly.
Use the runnable demo bundled with the Skill. Enter your FlightHub 2 organization key to experience the complete workflow.
Sample question: I want to quickly run a demo to show my manager. How do I start?
Experienced Developers
Goal: Map requirements to specific interfaces and start coding.
Have the AI assistant map your requirements to specific endpoints, then start coding once the match table is produced.
Sample question: I need to integrate livestreaming. Help me identify which endpoints match and where the gaps are.
Installation and Recommended Environment
Place the downloaded fh2-integration-skill/ directory into your AI coding assistant's skill directory, or configure its content as project-level rule files. No additional dependencies are required. After installation, simply ask questions about FlightHub 2 / DFR / inspection to trigger it automatically.
Coding Tools
| Coding Tool | How to Load |
|---|---|
| Claude Code | Place in ~/.claude/skills/fh2-integration-skill/ |
| OpenCode | Place in ~/.config/opencode/skills/fh2-integration-skill/ |
| Cursor | Copy the content of adapters/cursor-rules.md into .cursor/rules/fh2-integration.mdc |
| Trae / Tongyi Lingma | Configure as a project rule or mount as a project knowledge base |
Rule file paths vary between tool versions; refer to the official documentation of each tool. The core principle is to make SKILL.md and references/ a persistent part of the AI's context.
Recommended Models
This Skill is a fairly long set of behavioral constraints and knowledge base content, and requires strong long-context comprehension and instruction-following capability. The following models are recommended:
| Model | Vendor |
|---|---|
| DeepSeek V4 Pro and above | DeepSeek |
| Qwen 3.8 Max | Alibaba Cloud |
| Claude Opus 5 | Anthropic |
| GPT-5.6 Sol | OpenAI |
Note
Model capability does not change the Skill's security boundaries. Regardless of which model is used, the Skill enforces anti-hallucination constraints and the two confirmation gates. If a model frequently skips the follow-up questions or invents endpoints, switch to a model with stronger instruction-following capability.
Optional: Mount the OpenAPI MCP
If your environment provides the FlightHub 2 / Apifox OpenAPI MCP, this Skill prefers reading real endpoints and schemas through the MCP to complete requirement matching and code modification, rather than requiring you to browse documentation yourself. Without an MCP, it falls back to official documentation links. In neither case does it invent endpoints.
Core Mechanism: Two Gates
This is the most important design of this Skill. Before providing any API recommendation, the AI assistant must pass two confirmation gates in sequence.
Gate One · Deployment Gate
Confirm the FlightHub 2 deployment model: Public Cloud / On-Premises / AIO
The API scope and authentication model differ between deployment models, so this step determines the boundaries for subsequent interface selection.
Gate Two · Scenario Gate
Confirm the workflow category to be integrated: DFR emergency response / inspection and patrol / both
Different scenarios differ significantly in interface selection, data flow, and security focus.
After Passing Both Gates
Only then does the Skill begin to provide: architecture design → interface mapping → implementation plan → security guardrails → test plan.
Why the AI "asks you first" instead of answering directly
This is intentional. Different deployment models expose completely different APIs, and different scenarios require different interfaces. The Skill is explicitly forbidden from inferring the deployment model from clues such as token format, URL, domain, or region — the cost of guessing wrong is a solution that does not work.
Differences Between the Two Scenarios
| Dimension | DFR / Emergency | Inspection / Patrol |
|---|---|---|
| Trigger source | External alarms, CAD call handling | Plans, schedules, cycles |
| Timeliness | Second-level emergency response | Regular periodic operation |
| Primary interfaces | Automatic dispatch workflow | Waylines + planned tasks |
| Data flow focus | Real-time livestream, human takeover | Capture → analysis → sharing |
| Post-processing | On-site handling, evidence archiving | AI / VLM defect recognition, 3D reconstruction |
Capability Scope
DFR / Emergency Response
- CAD and alarm systems → FlightHub 2 dispatch middleware
- Drone livestream integration into VMS / command center displays
- Telemetry integration into GIS / PSIM situational awareness platforms
- Media and evidence archiving pipelines
Inspection / Patrol
- Wayline upload, synchronization to the FlightHub 2 wayline library, and planned task dispatch
- Inspection media → AI / VLM defect analysis → third-party platforms
- 3D reconstruction / point cloud result synchronization
Common Capabilities
- Event API callback reception and handling
- Interface selection among FlightHub Sync / OpenAPI / MQTT Bridge
- API boundary checks between Public Cloud and On-Premises
- Integrating FlightHub 2 capabilities into an existing platform (adapter layer design)
- Implementation plans, test plans, and security guardrails
How to Ask Questions
No special syntax is required; simply describe your requirements normally. The following examples can be reused directly:
Capability consultation:
We want to use drones for substation inspection. What capabilities can FlightHub 2 provide? Help me put together a solution.
DFR integration design:
We use FlightHub 2 Public Cloud. Help me design a middleware that goes from CAD alarms to dispatch.
Inspection integration design:
We are on an On-Premises deployment. Design a task dispatch middleware for scheduled thermal inspection of a substation.
Integrating with an existing system:
We already have an O&M platform and want to bring FlightHub 2 capabilities into it, rather than deploying another standalone system.
Interface mapping:
I need to integrate livestreaming. Help me identify which endpoints match and produce a requirement-to-endpoint match table.
Questioning tip
If you already know your deployment model and scenario, state them in your first sentence (for example, "We are On-Premises, doing inspection"). This lets you skip the two gates' follow-up questions and go straight to solution design.
Bundled Demo
The Skill includes a runnable FlightHub 2 Public Cloud integration reference implementation, located at examples/dfr-public-cloud-demo/.
| Page | Function | Corresponding Capability |
|---|---|---|
| Project map | Select a target and dispatch | Automatic dispatch workflow |
| MQTT information | Subscribe to drone telemetry | Telemetry forwarding |
| Inspection waylines | Upload waylines and sync to the FlightHub 2 wayline library | FlightHub Sync external bucket |
| Event API information | Receive and display callback messages | Event API |
| S3 bucket | Media and evidence file management | Object storage |
| Configuration settings | Enter all connection parameters | — |
Quick Start
Backend:
cd examples/dfr-public-cloud-demo/backend
npm install && npm start # 默认 http://localhost:3000
Frontend (in a separate terminal):
cd examples/dfr-public-cloud-demo/frontend
npm install && npm run serve
For detailed steps, see QUICKSTART.md in the demo directory. For cloud deployment, see deploy/README.md.
Real dispatch can be tried locally
As long as you have a FlightHub 2 organization key, your local
localhostcan issue real dispatch commands — no cloud server, no public IP, and no intranet tunneling required. Dispatch is a pure outbound request (browser → local backend → FlightHub Cloud) and traverses NAT without difficulty. This is the fastest path from "reading documentation" to "watching the Dock open its cover."
Local Availability Reference
| Function | Traffic Direction | Available Purely Locally |
|---|---|---|
| Dispatch | You → FlightHub Cloud | ✅ Available |
| Event API callback | FlightHub Cloud → You | ❌ Requires a public entry point |
| MQTT telemetry | FlightHub Cloud → your broker | ❌ Requires a public entry point |
| Wayline synchronization | FlightHub Cloud → your S3 bucket | ❌ Requires a public entry point |
The latter three require FlightHub 2 to initiate connections into your machine, which can be enabled with intranet tunneling tools such as ngrok or cpolar.
⚠️ Dispatch drives real equipment
This is not a simulation — the Dock will actually open its cover and the drone will take off. Before issuing a command, confirm airspace compliance and on-site supervision, and use a test Dock whenever possible.
Preparation Before Trial
- Organization key: FlightHub 2 → My Organization → Organization Settings → OpenAPI → copy the key
- Project UUID: obtain it by calling the "Get project list under an organization" interface
- (Optional) MinIO / S3, MQTT broker, streaming server
⚠️ The demo is instructional, not production-grade
To reduce the learning curve, the demo deliberately omits certain production essentials (such as Event API signature verification and database storage). Using it directly in production is unsafe. Be sure to read
LIMITATIONS.mdin the demo directory, which lists all known limitations and a production readiness checklist.
About maps
The demo automatically selects a base map according to the browser language (Amap for Chinese users, Google for others). All base maps carry a coordinate system offset warning — the map position is not the drone's actual flight position; use the Dock position as the reference. In addition, the Google tiles used by the demo come from an unofficial interface and are for demonstration only; production environments must switch to the official API.
Security Boundaries
The Skill includes a set of mandatory constraints. Understanding them helps you better judge the reliability of the AI's output.
Situations Where the AI Will Stop and Ask
| Trigger Condition | What You Need to Confirm |
|---|---|
| Deployment model unknown | Public Cloud / On-Premises / AIO |
| Authentication mode unclear | Token / OAuth / SSO, and which values are placeholders |
| Involves flight control, dispatch, payloads, or device configuration | Authorized environment, human intervention, security review path |
| Operating a real customer system | Explicit authorization and target environment |
| Endpoint not confirmed in documentation | Verify against the official documentation |
What It Will Never Do
- Invent endpoints, request fields, event types, or MQTT topics
- Mix Public Cloud and On-Premises APIs
- Recommend On-Premises-only capabilities for Public Cloud
- Treat AI recognition results as a directly actionable basis for response decisions
- Omit flight safety constraints such as human-in-the-loop and geofencing
If the AI says "I cannot confirm this capability"
This is not a lack of capability — it is by design. Compared with inventing an endpoint that looks reasonable but does not work, clearly stating uncertainty and pointing to the official documentation is more valuable to you.
Directory Structure
fh2-integration-skill/
├── SKILL.md Skill entry: workflow, checkpoints, output templates
├── README.md / README.zh-CN.md Project overview (English and Chinese)
├── references/ Knowledge base (12 documents + Chinese reading guide)
│ ├── README.zh-CN.md Chinese reading guide index; recommended starting point
│ ├── api-guardrails.md Security baseline and anti-hallucination rules (highest priority)
│ ├── capability-overview.md Capability overview menu (for non-developers)
│ ├── scenario-dfr-vs-inspection.md Scenario decision
│ ├── dfr-integration-architecture.md DFR architecture and interface selection
│ ├── inspection-integration-architecture.md Inspection architecture and interface selection
│ ├── integrate-with-existing-system.md Integrating with an existing platform
│ ├── middleware-patterns.md 9 middleware design patterns
│ ├── demo-localization.md Multi-language and localization
│ └── ... Deployment boundaries, API capability panorama, source provenance
├── adapters/ Claude Code / Cursor adaptation guides
├── evals/ 14 quality evaluation cases
└── examples/
└── dfr-public-cloud-demo/ Runnable reference implementation
To learn more about the knowledge base, open
references/README.zh-CN.md, which explains what each file covers and when it is used.
FAQ
Q: Why does the AI always ask questions first instead of answering directly?
Because the deployment model and scenario fundamentally change which interfaces are available. This is a core design of the Skill, not verbosity. You can state both points in your first sentence to skip the follow-up questions.
Q: The knowledge files in the Skill are in English. Can they be translated?
Human-facing documents (README, usage guides, evaluation runbook, demo documentation) all provide Chinese versions. SKILL.md and references/ are behavioral constraint files read by the AI and are intentionally kept in English — English instructions yield higher adherence precision and avoid conflicting rules caused by translation drift. If you need to understand a specific file, simply ask the AI to explain it to you in Chinese.
Q: Can the endpoints provided by the AI be used directly?
Not directly in production. The Skill marks which content needs verification. Always confirm the exact request body, response fields, and permission requirements against the official Apifox documentation before going to production.
Q: Can the demo be adapted into our own system?
Yes, but it is recommended to treat it as an adapter layer skeleton rather than a finished product. Refer to ARCHITECTURE.md in the demo directory, which maps each module to the knowledge base and lists the items required to move from demonstration to production.
Q: Can this Skill be used for On-Premises deployments?
Yes. The Skill covers both Public Cloud and On-Premises / AIO, and strictly distinguishes their interface boundaries. Note, however, that the bundled demo is written for Public Cloud. On-Premises deployments have a broader interface surface and may use different authentication methods, so do not copy the demo code directly.
The FH2 Integration Skill is an integration design assistance tool. It cannot replace DJI official documentation, customer security review, legal review, aviation approval, or production validation.