sails-new-app
Sails New App
Goal
Move a greenfield request from scope to an approved Sails workspace path without skipping the planning artifacts that later implementation depends on.
Sequence
- If the machine does not already have
rustup, the required Wasm targets,cargo-sails, and a localgearbinary, start with../sails-dev-env/SKILL.md. - For a new standard Sails/Vara project, bootstrap the workspace first with
cargo sails new <project-name>unless the user explicitly needs a custom non-template layout. - Write the feature or app goal to
docs/plans/YYYY-MM-DD-<topic>-spec.mdusing../../assets/spec-template.md. - Route architecture decisions through
../sails-architecture/SKILL.md. - Keep the standard template workspace shape created by
cargo sails new <project-name>intact:app,client,src,tests, top-levelbuild.rs, Wasm output, and generated-client path. - Keep the standard build-script pipeline intact. In a standard Sails workspace, use the repo-generated build path for
.idland Rust client artifacts. For a dedicated client crate, prefersails-rswithfeatures = ["build"]andsails_rs::build_client::<Program>()before introducing manualsails-idl-gen/sails-client-genwiring. - Validate before moving to later phases by finishing with
../sails-gtest/SKILL.md, then../sails-local-smoke/SKILL.md. - When the builder needs a frontend, use
create-vara-appto scaffold it from the program's.idl:npx create-vara-app <name> --idl path/to/service.idl. Then route to../sails-frontend/SKILL.mdfor customization.
Shared Inputs
../../references/vara-domain-overview.md../../references/sails-cheatsheet.md../../references/sails-program-and-service-architecture.md../../references/sails-idl-client-pipeline.md
Guardrails
- Keep the builder on standard Sails scaffolding and generated clients.
- Keep the standard Sails workspace shape and build-generated
.idland.opt.wasmartifact path intact, and check the crate'sbuild.rsbefore adding ad hoc generation steps. - Do not jump into raw Gear primitives when a Sails path already exists.
- Do not skip the planning docs just because the repo is greenfield.
- Always use
cargo sails new <project-name>for greenfield Sails/Vara work. Hand-assembled workspaces are a known source of errors: shared top-level workspaces cause Cargo feature unification to enable bothgstdandgtestonsails-rssimultaneously, breaking the build. See../../references/sails-rs-imports.mdfor the canonical layout.
More from gear-foundation/vara-skills
vara-skills
Use when a builder needs the top-level router for the provisional standard Gear/Vara Sails skill pack across Codex, Claude, or OpenClaw. Do not use for Vara.eth or ethexe work, non-Sails programs, or broad protocol research.
192sails-dev-env
Use when a builder needs to prepare or repair a local macOS, Linux, or Windows machine for standard Gear/Vara Sails Rust development before building, testing, or running a local node. Do not use for live-network deployment, app-specific feature work, or Vara.eth/ethexe-only setup.
2vara-wallet
Use when an agent needs to interact with Vara Network on-chain — deploy programs, call Sails methods, manage wallets, transfer tokens, monitor events. Not for building Sails programs (use vara-skills for that).
2sails-gtest
Use when a builder needs the standard Gear/Vara Sails gtest loop for feature verification, debugging, or regression coverage. Do not use for live-network-only validation, deployment-first workflows, or non-Sails programs.
2task-decomposer
Use when approved spec and architecture artifacts must become an ordered implementation plan for Gear or Vara work. Do not use when the architecture is still unsettled or when the request is only asking for a high-level idea.
2sails-frontend
Use when a builder needs to build or extend a React or TypeScript frontend for a standard Gear/Vara Sails app, using Sails-JS, generated clients, React hooks, and low-level Gear-JS only where it adds value. Do not use for Rust-only contract work, raw gstd service design, or non-Vara frontends.
2