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.
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.
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Claude CodeNot declared
CursorNot declared
CodexNot declared
GitHub CopilotNot declared
WindsurfNot declared
Gemini CLINot declared
ClineNot declared
OpenCodeNot declared
Repository health
Stars17
LicenseLICENSE
Default branchmain
Open issues1
Status
Active
Package contents
Files included with this skill beyond the listing page.
skill mdSKILL.md2,822 B
docsSUMMARY.md327 B
History
First seen on skills.sh
First recorded snapshot · 2 installs
SKILL.md
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.
Define token intent and deployment shape with assets/token-scope-checklist.md.
Choose the smallest awesome-sails token stack with assets/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 path dependencies 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.