FPV Video Skill
First, make the shot answer "what to fly toward, why to turn, and when to reveal the space," then tackle motion and rendering. Technical execution and the user's visual preferences are two separate doors.
Confirm the Route First
Read the actual constraints of this task, asset permissions, and the user's most recent visual feedback. Previously rejected camera moves are not the default baseline for further polishing: first propose new targets, segments, speed changes, crossing points, turns, lead-in/lead-out, and ending plans; proceed to higher-cost formal production only after confirmation. When no prior plan exists, choose lightweight preview or storyboard confirmation based on task risk; do not mechanically require approval for every step.
Distinguish between aircraft heading and line-of-sight target: the aircraft follows the course and banks with curvature, while the line of sight can preview turns, track a subject, or briefly look back, then smoothly reconnect. Do not equate random jitter, constant banking, or full-speed flight with FPV; looking back cannot mask a lack of route purpose.
When the user has selected a plan and explicitly requests to complete the rest on their own, continue production and verification within the authorized scope of that task without repeatedly requesting approval for segments or rendering. That authorization does not expand permissions for asset reading, uploading, payment, publishing, or human visual acceptance, nor does it grant permanent exemption for other tasks.
Read by Work Phase
- For route, speed, attitude, and clearance design: read references/flight-design.md.
- For researching FPV methods from open-source projects, selecting implementations, or recording evidence: read references/github-motion-research.md.
- For DCC integration, version pitfalls, native observation, MRQ, and evidence freezing: read references/native-verification.md.
- For delivery packaging, human acceptance, and public asset boundaries: read references/delivery.md.
- For learning open-source trajectories, controller previews, or attitude smoothing methods: read references/github-methods.md, paying attention to fixed commits and unvalidated boundaries.
When a small runnable example is needed, use scripts/synthetic_route.py and its corresponding tests. It only creates independent parsing curves and abstract gate openings, without original project geometry; it is not a complete flight controller, DCC interface, or cinematic shot generator. Parameters must be chosen per project; do not turn example durations or thresholds into universal requirements.
Non-Confusable Completion Levels
Report separately: route confirmed; offline motion check; native build with fresh readback; actual rendered frames; encoding with full decode; human normal-speed audiovisual acceptance; publication and visitor visibility. Success at one level cannot substitute for subsequent levels. Failure records and source assets should be retained; new fixes use reversible candidates without overwriting successful evidence to "fill in" results.
If assets prohibit AI from viewing pixels, geometry, or textures, work only within the permitted metadata scope; when AI visual diagnosis is needed, first prove that the diagnostic frames being viewed have actually excluded restricted content. Hidden screenshots do not authorize reading restricted geometry or public packaging. Fully restricted visuals are handed to a human; if that cannot be done, explicitly stop that check.
A public reference case is located at examples/changfeng/case.md in the repository; it is a summary of the process and failures, containing no source assets or approved visual proof, and is not a dependency for skill operation.