awesome-sails-vft
Skill17 starsChanged 7 months agoMITView on GitHub
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.
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 10 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
Keep the IDL and generated client path intact.
- Very specific: line 34
Write and execute the selected tests from assets/token-gtest-matrix.md.
- Distinctive: line 39
Use the smallest awesome-sails surface that satisfies the feature.
- Distinctive: line 40
Prefer base VFT-compatible behavior over custom token logic.
- Distinctive: line 41
Add admin and RBAC layers only when the spec requires privileged token operations.
- Distinctive: line 42
Add native-exchange only when value↔token conversion is part of the design.
- Very specific: line 51
Do not use absolute paths into ~/.cargo/git/checkouts, target, or other machine-local caches.
- Distinctive: line 55
Do not write a custom fungible token from scratch when awesome-sails already covers the standard path.
- Distinctive: line 56
Do not mix unrelated token policy decisions into implementation before the spec is written.
- Distinctive: line 57
Do not bypass IDL/generated clients for the normal token path.
- Distinctive: line 58
Do not treat token events as optional for production-facing state transitions.
- Very specific: line 59
Do not make every app build its own mint/burn/allowance logic ad hoc.
- Very specific: line 60
Do not point dependencies to ~/.cargo/git/checkouts/...
- Distinctive: line 61
Prefer crates.io versions, a pinned git dependency, or a repository-relative path only when the project intentionally vendors or …
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.
In this repository27 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- vara-skillsSkill
- vara-skillsSkill
- gear-architecture-plannerSkill
- gear-builtin-actorsSkill
- gear-gstd-api-mapSkill
- gear-message-executionSkill
- gtest-tdd-loopSkill
- idea-to-specSkill
- sails-architectureSkill
- sails-dev-envSkill
- sails-ethexe-architectureSkill
- sails-ethexe-implementerSkill
- sails-feature-workflowSkill
- sails-frontendSkill
- sails-gtestSkill
- sails-idl-clientSkill
- sails-indexerSkill
- sails-local-smokeSkill
- sails-new-appSkill
- sails-program-evolutionSkill
- sails-rust-implementerSkill
- ship-sails-appSkill
- task-decomposerSkill
- vara-skills-upgradeSkill
- vara-walletSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

