skills.rest
gear-foundation
gear-foundationOFFICIAL
Explore all skills by this author →
Website𝕏@VaraNetworkGitHub

sails-architecture

Create Sails architecture plans covering state ownership, message flow, and compatibility.

17|23|Updated Mar 12, 2026
Search Tags:#program-design#message-flow#state-ownership#gear-vara#contract-evolution#sails-architecture#gas-reservations
One-click install
npx skills add https://github.com/gear-foundation/vara-skills --skill sails-architecture
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: sails-architecture
Source: https://github.com/gear-foundation/vara-skills/tree/main/skills/sails-architecture
Command: npx skills add https://github.com/gear-foundation/vara-skills --skill sails-architecture

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill eliminates the risk of inconsistent, incompatible Gear/Vara Sails program design by providing a structured workflow to turn approved specs into production-ready architecture artifacts, especially for released contracts that require backward compatibility.

Core Features & Use Cases

  • Structured Architecture Generation: Creates detailed Sails-specific architecture plans covering service boundaries, state ownership, message flow, and execution model constraints like gas reservations and delayed messages.
  • Released Contract Compatibility Guardrails: Includes checklists and defaults for evolving existing deployed contracts without breaking public routes, replies, events, or off-chain consumers like frontends and indexers.
  • Migration and Evolution Planning: Guides designers to plan for future state migration, contract versioning, and cutover strategies to avoid costly in-place hot swaps of live contract code.
  • Use Case: If you are adding a new feature to a live Sails program that already has active frontend and indexer integrations, this Skill ensures your architecture preserves all existing public interfaces while accounting for Gear execution constraints like Waitlist rent and gas reservation lifetimes.

Quick Start

Use the sails-architecture skill to create a detailed architecture plan for your approved Sails program feature, including compatibility notes for existing public routes and off-chain consumers.

Frequently Asked Questions about sails-architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design Gear Vara Sails program architecture for new features?▼

Designing Gear Vara Sails program architecture requires defining state ownership, message flow, and gas reservations to ensure consistent service boundaries. A structured workflow transforms approved specs into production-ready architecture artifacts aligned with Sails best practices.

How do I evolve a deployed Sails contract without breaking frontend integrations?▼

Evolving a deployed Sails contract without breaking frontend integrations requires compatibility guardrails to preserve public routes, replies, and events. Architecture planning ensures existing off-chain consumers like indexers continue functioning when adding new features to live programs.

What are Gear execution model constraints for Sails message flow design?▼

Gear execution model constraints for Sails message flow design include delayed messages, Waitlist rent, and gas reservation lifetimes. Architecture planning accounts for these limitations by mapping state ownership and execution boundaries to prevent runtime failures.

When do I need to plan state migration for existing Sails programs?▼

State migration planning for existing Sails programs is needed when evolving released contracts requires data structure changes. Planning versioning and cutover strategies avoids costly in-place hot swaps of live contract code while maintaining backward compatibility.

Can I use Sails architecture planning for gas reservation and Waitlist management?▼

Sails architecture planning supports gas reservation and Waitlist management by mapping execution model constraints into service boundaries. This ensures delayed messages and gas lifetimes are accounted for in the program design before deployment.

What is the best way to define state ownership boundaries in Sails services?▼

The best way to define state ownership boundaries in Sails services is through structured architecture generation that separates service responsibilities. This approach produces artifacts aligning with Sails best practices while respecting Gear execution model constraints.

Related Skills

Explore More Software Engineering Skills→
gear-foundationgear-foundation
17

sails-rust-implementer

Implement approved Gear and Vara Sails Rust changes with backward compatibility.

Official
Advanced
gear-foundationgear-foundation
17

sails-program-evolution

Plan safe V1 to V2 cutover for deployed Gear/Vara Sails contracts.

Official
Advanced
gear-foundationgear-foundation
17

gear-message-execution

Diagnose Gear/Vara Sails message flow, timeout, and byte decoding issues.

Official
Intermediate
gear-foundationgear-foundation
17

gear-architecture-planner

Translate Gear and Vara feature specifications into structured architecture and service boundary definitions.

Official
Intermediate