gear-foundation/gear-message-execution
skills/gear-message-execution/SKILL.md
Use when a builder needs to design or debug Gear message flow, replies, delayed execution, reservations, or waitlist behavior inside a standard Gear/Vara Sails app. Do not use for Vara.eth or ethexe-first work, non-Sails repositories, or broad protocol research.
$ install --global
skillsauthnpx skillsauth add gear-foundation/vara-skills gear-message-executionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 23, 2026, 2:39 AM26.6s1 file scanned
SKILL.md
- name:
- gear-message-execution
- description:
- Use when a builder needs to design or debug Gear message flow, replies, delayed execution, reservations, or waitlist behavior inside a standard Gear/Vara Sails app. Do not use for Vara.eth or ethexe-first work, non-Sails repositories, or broad protocol research.
Gear Message Execution
Goal
Provide a focused local path for reasoning about message flow and execution behavior in standard Gear/Vara Sails work.
Inputs
../../references/gear-execution-model.md../../references/gear-sails-production-patterns.md../../references/gear-messaging-and-replies.md../../references/gear-gas-reservations-and-waitlist.md../../references/scale-binary-decoding-guide.md../../references/sails-syscall-mapping.md
Route Here When
- replies, timeouts, or error replies are surprising
- delayed work spans future blocks
- reservations or waitlist behavior affect the design
- a builder is mixing raw payload handling into an otherwise standard Sails flow
- raw hex, reply bytes, event bytes, or metadata-vs-IDL decoding path is unclear
- a reply from a hardcoded non-program
ActorIddoes not decode as a Sails route; route togear-builtin-actorsfor the matchinggbuiltin_*::Responsetype
Working Model
- Confirm what executes now versus after the next block.
- If raw bytes are involved, classify the source first: constructor, service payload, reply, event, full state, or state-function output.
- Determine whether the bytes are Sails-routed, plain SCALE, or metadata-driven state output.
- Match the decoder artifact to the source: generated client or
.idl,ProgramMetadata, orstate.meta.wasm. - Identify whether the path is fire-and-forget, reply-driven, delayed, or reservation-backed.
- Separate transport failure, timeout, and error reply.
- Check whether rollback should revert local state if a send or reply path fails.
- If the path is in tests, confirm the block-advance pattern and expected reply timing.
Guardrails
- Treat reply, timeout, and late hook execution as distinct states.
- Keep staged payload flows paired with their commit step.
- Treat reservation duration and waitlist expiry as architecture constraints.
- Use
exec::gas_available()(orSyscall::gas_available()if using Sails) when checking available gas during the current execution. - Prefer generated Sails clients unless debugging the route or codec layer.
- If a Sails route is involved, expect Sails Header-aware encoding rather than a raw struct payload.
- Keep the guidance on the standard Gear/Vara Sails path.
- Prefer local repo references over external skill dependencies.
- Do not start with plain
Decode::<T>on arbitrary bytes when a Sails route may be involved. - Match decode artifact to source: generated client or
.idlfor standard Sails interface paths,ProgramMetadatafor full state, andstate.meta.wasmfor state-function output. - Treat
gear-metaas a debugging fallback, not the first-choice default path.
Related Skills
gear-foundation/sails-ethexe-implementer
development
VerifiedTrustedCommunity
Use when approved tasks require Rust code changes in a Sails ethexe workspace with the ethexe feature enabled. Do not use for standard Gear/Vara Sails apps without ethexe, or when the spec or architecture is still unsettled.
17SKILL.mdUpdated May 23, 2026
gear-foundation/sails-ethexe-architecture
development
VerifiedTrustedCommunity
Use when a builder needs to design or review architecture for a Sails ethexe app with dual-transport, payable methods, Solidity interface generation, or Ethereum-style events. Do not use for standard Gear/Vara Sails apps without ethexe.
17SKILL.mdUpdated May 23, 2026
gear-foundation/gear-builtin-actors
development
VerifiedTrustedCommunity
Use when a builder needs to design or debug calls from a standard Gear/Vara Sails program into runtime builtin actors such as BLS12-381, staking, proxy, or ETH bridge, including ActorId derivation, request encoding, reply decoding, and gas or ED budgeting. Do not use for regular program-to-program messaging, Vara.eth or ethexe-only work, non-Sails repositories, or runtime-maintenance tasks inside the Gear repo.
17SKILL.mdUpdated May 16, 2026
gear-foundation/sails-indexer
development
VerifiedTrustedCommunity
Use when a builder needs a read-side indexer and query API for a standard Gear/Vara Sails app using program events, IDL-driven decoding, projected read models, and optional on-chain query enrichment. Do not use for command-side backends, generic Node APIs, non-Sails repositories, Vara.eth or ethexe-first work.
17SKILL.mdUpdated May 13, 2026