gear-foundation/awesome-sails-vft
skills/awesome-sails-vft/SKILL.md
Use when a builder wants to add a fungible token to a standard Gear/Vara Sails app using awesome-sails building blocks, choose the right VFT-related crates, and wire roles, events, tests, and client integration. Do not use for NFT or RMRK work, abstract tokenomics-only analysis, or non-Sails projects.
$ install --global
skillsauthnpx skillsauth add gear-foundation/vara-skills awesome-sails-vftInstall 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 13, 2026, 2:37 AM143.5s6 files scanned
SKILL.md
- name:
- awesome-sails-vft
- description:
- Use when a builder wants to add a fungible token to a standard Gear/Vara Sails app using awesome-sails building blocks, choose the right VFT-related crates, and wire roles, events, tests, and client integration. Do not use for NFT or RMRK work, abstract tokenomics-only analysis, or non-Sails projects.
Awesome Sails VFT
Goal
Help the builder add a fungible token layer to a standard Gear/Vara Sails app through awesome-sails without reimplementing standard token behavior from scratch.
Local Handbook
../../references/gear-sails-production-patterns.md../../references/sails-program-and-service-architecture.md../../references/sails-idl-client-pipeline.md../../references/sails-gtest-and-local-validation.md../../references/sails-cheatsheet.md../../references/awesome-sails-token-patterns.md
Local Assets
assets/token-scope-checklist.mdassets/token-crate-chooser.mdassets/token-gtest-matrix.md
Required Sequence
- Define token intent and deployment shape with
assets/token-scope-checklist.md. - Choose the smallest
awesome-sailstoken stack withassets/token-crate-chooser.md. - Decide whether the token lives as a dedicated program or as embedded token-related services.
- Name the role model and event model explicitly.
- Keep the IDL and generated client path intact.
- Write and execute the selected tests from
assets/token-gtest-matrix.md. - Route to local smoke only after green gtest.
Crate Selection Rules
- Use the smallest awesome-sails surface that satisfies the feature.
- Prefer base VFT-compatible behavior over custom token logic.
- Add admin and RBAC layers only when the spec requires privileged token operations.
- Add native-exchange only when value↔token conversion is part of the design.
Dependency Source Rules
Prefer one of:
- crates.io version dependencies
- pinned git dependencies
- repository-relative
pathdependencies only for intentional local co-development
Do not use absolute paths into ~/.cargo/git/checkouts, target, or other machine-local caches.
Guardrails
- Do not write a custom fungible token from scratch when awesome-sails already covers the standard path.
- Do not mix unrelated token policy decisions into implementation before the spec is written.
- Do not bypass IDL/generated clients for the normal token path.
- Do not treat token events as optional for production-facing state transitions.
- Do not make every app build its own mint/burn/allowance logic ad hoc.
- Do not point dependencies to
~/.cargo/git/checkouts/...or other machine-local Cargo cache paths. - Prefer crates.io versions, a pinned git dependency, or a repository-relative path only when the project intentionally vendors or co-develops the dependency.
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