agentleFS
gear-foundationgear-foundation/vara-skills/skills/awesome-sails-vft/SKILL.md

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
  1. Distinctive:

    Keep the IDL and generated client path intact.

    line 33
  2. Very specific:

    Write and execute the selected tests from assets/token-gtest-matrix.md.

    line 34
  3. Distinctive:

    Use the smallest awesome-sails surface that satisfies the feature.

    line 39
  4. Distinctive:

    Prefer base VFT-compatible behavior over custom token logic.

    line 40
  5. Distinctive:

    Add admin and RBAC layers only when the spec requires privileged token operations.

    line 41
  6. Distinctive:

    Add native-exchange only when value↔token conversion is part of the design.

    line 42
  7. Very specific:

    Do not use absolute paths into ~/.cargo/git/checkouts, target, or other machine-local caches.

    line 51
  8. Distinctive:

    Do not write a custom fungible token from scratch when awesome-sails already covers the standard path.

    line 55
  9. Distinctive:

    Do not mix unrelated token policy decisions into implementation before the spec is written.

    line 56
  10. Distinctive:

    Do not bypass IDL/generated clients for the normal token path.

    line 57
  11. Distinctive:

    Do not treat token events as optional for production-facing state transitions.

    line 58
  12. Very specific:

    Do not make every app build its own mint/burn/allowance logic ad hoc.

    line 59
  13. Very specific:

    Do not point dependencies to ~/.cargo/git/checkouts/...

    line 60
  14. Distinctive:

    Prefer crates.io versions, a pinned git dependency, or a repository-relative path only when the project intentionally vendors or …

    line 61

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
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.

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.md
  • assets/token-crate-chooser.md
  • assets/token-gtest-matrix.md

Required Sequence

  1. Define token intent and deployment shape with assets/token-scope-checklist.md.
  2. Choose the smallest awesome-sails token stack with assets/token-crate-chooser.md.
  3. Decide whether the token lives as a dedicated program or as embedded token-related services.
  4. Name the role model and event model explicitly.
  5. Keep the IDL and generated client path intact.
  6. Write and execute the selected tests from assets/token-gtest-matrix.md.
  7. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.