agentleFS
Sign inStart free
gear-foundationgear-foundation/vara-skills/skills/sails-feature-workflow/SKILL.md

sails-feature-workflow

Skill17 starsChanged 7 months agoMITView on GitHub

Use when a builder is changing behavior inside an existing standard Gear/Vara Sails app and needs the correct stage-by-stage workflow. Do not use for greenfield scaffolding, Vara.eth or ethexe paths, or non-Sails repositories.

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 4 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep feature work inside an existing Sails repo on an explicit sequence instead of skipping straight to code edits or bypassing the typed …

    line 10
  2. Very specific:

    If the request targets a released contract, a new deployed contract version, or V1->V2 evolution, route through …

    line 12
  3. Very specific:

    If the work targets a released contract, introduces a new deployed version, requires cutover planning, or prepares V1->V2 migration, review …

    line 18
  4. Very specific:

    If the feature needs API selection across gstd, review ../gear-gstd-api-map/SKILL.md before coding.

    line 19
  5. Very specific:

    If the feature changes async behavior, replies, delays, reservations, or waitlist semantics, review ../gear-message-execution/SKILL.md …

    line 20
  6. Very specific:

    If the feature introduces a fungible token, mint/burn roles, token-backed accounting, or native-value exchange, review …

    line 22
  7. Very specific:

    If the public interface changed, refresh the .idl and regenerate the typed client through the repo's standard build.rs path first.

    line 24
  8. Very specific:

    Run gtest through ../sails-gtest/SKILL.md.

    line 25
  9. Very specific:

    Run smoke validation only after green gtest, using ../sails-local-smoke/SKILL.md.

    line 26
  10. Very specific:

    If the feature includes gasless or signless UX, see ../../references/voucher-and-signless-flows.md for the canonical builder recipes, …

    line 30
  11. Distinctive:

    Do not skip the document chain for “small” features.

    line 47
  12. Distinctive:

    Do not bypass the generated client path with raw payload encoders, hand-built SCALE payloads, or EVM-style bindings.

    line 48
  13. Very specific:

    Do not claim completion before gtest is green and documented.

    line 49
  14. Very specific:

    Do not treat local-node smoke as a substitute for gtest.

    line 50
  15. Distinctive:

    Do not treat released-contract evolution, cutover, or V1->V2 migration as ordinary feature work without routing through the …

    line 51

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

Sails Feature Workflow

Goal

Keep feature work inside an existing Sails repo on an explicit sequence instead of skipping straight to code edits or bypassing the typed client path.

If the request targets a released contract, a new deployed contract version, or V1->V2 evolution, route through ../sails-program-evolution/SKILL.md before normal implementation work continues.

Required Sequence

  1. Clarify the feature in docs/plans/YYYY-MM-DD-<topic>-spec.md with idea-to-spec and ../../assets/spec-template.md.
  2. Plan architecture or public interface in ...-architecture.md with ../sails-architecture/SKILL.md and ../../assets/architecture-template.md.
  3. If the work targets a released contract, introduces a new deployed version, requires cutover planning, or prepares V1->V2 migration, review ../sails-program-evolution/SKILL.md before task breakdown and coding.
  4. If the feature needs API selection across gstd, review ../gear-gstd-api-map/SKILL.md before coding.
  5. If the feature changes async behavior, replies, delays, reservations, or waitlist semantics, review ../gear-message-execution/SKILL.md before coding.
  6. Break the work into tasks in ...-tasks.md with task-decomposer and ../../assets/task-plan-template.md.
  7. If the feature introduces a fungible token, mint/burn roles, token-backed accounting, or native-value exchange, review ../awesome-sails-vft/SKILL.md before coding.
  8. Implement the Rust changes through sails-rust-implementer.
  9. If the public interface changed, refresh the .idl and regenerate the typed client through the repo's standard build.rs path first. For dedicated Rust client crates, prefer the sails-rs build-helper path before a manual generator pipeline.
  10. Run gtest through ../sails-gtest/SKILL.md.
  11. Run smoke validation only after green gtest, using ../sails-local-smoke/SKILL.md.

Sponsored UX Cases

  • If the feature includes gasless or signless UX, see ../../references/voucher-and-signless-flows.md for the canonical builder recipes, lifecycle, and failure modes. Define the voucher or session flow in the spec and architecture.

References

  • ../../references/vara-domain-overview.md
  • ../../references/sails-cheatsheet.md
  • ../../references/gtest-cheatsheet.md
  • ../../references/gear-execution-model.md
  • ../../references/gear-messaging-and-replies.md
  • ../../references/sails-gtest-and-local-validation.md
  • ../../references/contract-interface-evolution.md
  • ../../references/voucher-and-signless-flows.md
  • ../../references/sails-idl-v2-syntax.md — IDL v2 annotations for .idl files
  • ../../references/sails-header-wire-format.md — interface ID stability for change classification

Guardrails

  • Do not skip the document chain for “small” features.
  • Do not bypass the generated client path with raw payload encoders, hand-built SCALE payloads, or EVM-style bindings.
  • Do not claim completion before gtest is green and documented.
  • Do not treat local-node smoke as a substitute for gtest.
  • Do not treat released-contract evolution, cutover, or V1->V2 migration as ordinary feature work without routing through the program-evolution flow.

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.

Check your setup, free