mikkeli
fb08692dde
Hermes' own skill descriptions run under 60, lenient to ~80 - the original ran to nearly 280 and buried the trigger in an enumerated macro list that belongs in the body, not here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011EBCcjJvEvhpToahqdsLLA
1.5 KiB
name, description
| name | description |
|---|---|
| gdext-verify-live-docs | Verify gdext (Godot Rust bindings) API calls against live docs, not recall. |
gdext: verify against live docs, don't trust recall
gdext is pre-1.0 and under active development — breaking changes between versions are routine, not
exceptional. Training-data recall of its API is likely to be stale in exactly the way that looks
correct: a plausible macro invocation or trait bound that compiled against an earlier version and
silently doesn't against the one actually in use.
Before writing gdext-specific code (a #[derive(GodotClass)], #[godot_api] block, signal
registration, an exported property, or any other gdext macro/trait), check the version actually
pinned in the project's Cargo.toml, then verify the API against:
https://docs.rs/gdext— pin the query to the pinned version, not/latest, if the two differ.https://godot-rust.github.io/book— the official book; tutorials and patterns change with the crate, so prefer the version-matched section over a remembered pattern.
If a build fails on a gdext API call that looks like it should work, the first hypothesis is a version mismatch between what's remembered and what's pinned — check the docs at the pinned version before assuming the code is wrong.
Do not treat this skill as a place to cache gdext API details for next time. Anything gdext-specific written here would go stale the same way recall does — the whole point is redirecting to a source that stays current on its own.