gear-foundation/vara-skills

gear-architecture-planner

Use when an approved Gear or Vara spec must be mapped onto program boundaries, services, message flow, and integration surfaces. Do not use when the feature is still undefined or when the task is already reduced to code edits.

First seen Apr 4, 2026

Installation

$ npx skills add gear-foundation/vara-skills --skill gear-architecture-planner

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from gear-foundation/vara-skills · top by installs.

npx skills add gear-foundation/vara-skills

Browse all from gear-foundation/vara-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 17
License LICENSE
Default branch main
Open issues 1
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 1,765 B
  • docs SUMMARY.md 259 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

Gear Architecture Planner

Overview

Turn an approved spec into a concrete Gear/Sails architecture note.

Start Here

Read ../../references/vara-domain-overview.md, ../../references/sails-cheatsheet.md, ../../references/sails-program-and-service-architecture.md, ../../references/gear-messaging-and-replies.md, and ../../references/sails-idl-client-pipeline.md.

If the architecture choice depends on what Gear programs can express through gstd, review ../gear-gstd-api-map/SKILL.md before locking the design.

Use ../../assets/architecture-template.md as the output shape.

Write the result to docs/plans/YYYY-MM-DD-<topic>-architecture.md.

Workflow

  1. Confirm the spec artifact exists and is approved.
  2. Choose program constructors and service boundaries.
  3. Map state ownership, routing, messages, replies, and events.
  4. Record generated-IDL or generated-client implications.
  5. Capture off-chain components, failure paths, and explicit non-goals.

Guardrails

  • Keep #[program] thin and push business logic into services.
  • Make the constructor shape and storage pattern explicit instead of leaving them to implementation guesswork.
  • Treat generated clients or equivalent Sails Header-aware encoding as the default Sails message contract.
  • Treat actor boundaries and async flow as design constraints.
  • Call out remote-call failure policy instead of leaving it implicit.
  • Do not collapse architecture into a file-by-file coding checklist.