frostaura

Provides Gaia architecture documentation guidance that keeps docs, README messaging, and design decisions aligned to the current operating model. Use it by updating the relevant files under /docs/architecture/ (system components, use cases, class diagrams, UI) before any planning or implementation that changes structure, then resolving doc↔code drift before resuming feature work. Use it when system structure, trust boundaries, interfaces, workflows, ownership, or architectural assumptions change, or when architecture drift blocks planning or delivery.

Provides Gaia's default full-stack baseline with React, TypeScript, Redux Toolkit, Tailwind CSS, and shadcn/ui on the frontend plus .NET, EF Core, PostgreSQL, and MCP exposure on the backend. Use it by adopting the documented baseline (versions, scaffolds, references) for any new app or unspecified-stack request, and by declaring the stack explicitly before planning when the request leaves it implicit. Use it when the request or repo leaves stack choice open, when bootstrapping a new application, or when standardizing an existing codebase onto Gaia's preferred platform.

Provides planned implementation delivery guidance that keeps a branch coherent, stabilized, and ready for testing without redefining the target solution. Use it by implementing the planned tasks against existing repo conventions, keeping diffs scoped, running lint/build locally, and updating tasks_update as work progresses. Use it when a current plan branch is ready for code or definition-file edits, when implementation-side cleanup is needed, or when targeted early QA support is useful during delivery.

Provides execution planning guidance that turns approved architecture into a branch-aware plan with dependencies, QA checkpoints, release gates, and proof expectations. Use it by translating the current architecture into MCP tasks (tasks_create) sequenced by branch, with explicit required_gates and blockers, then keeping the plan current as new work is discovered. Use it after architecture is current, when work needs explicit sequencing instead of informal next steps, or when new branches, blockers, or gate definitions require re-planning.

Provides Gaia's end-to-end workflow coordination guidance for intake, routing, QA checkpoints, release gates, and proof expectations. Use it by routing every meaningful request through the intake → architecture → planning → engineering → testing → release sequence and only completing tasks once the corresponding gates and proof are recorded. Use it for meaningful requests, workflow resets after drift or blockers, and maintenance work that changes Gaia's operating model.

Provides Gaia's formal validation guidance across unit, integration, manual regression, automated regression, and evidence review. Use it by running the test layers required by each task's gates (unit → integration → e2e → manual regression), recording proof labels (e.g. 'curl', 'playwright-mcp') on tasks_complete, and vetoing completion when evidence is missing. Use it when a branch is stable enough for hardening, when high-risk behavior needs targeted early validation, or when release readiness depends on a clear QA signal.

Provides React UI implementation guidance that enforces the design system, shadcn/ui composition, semantic Tailwind tokens, and responsive layout discipline. Use it by composing shadcn/ui primitives with semantic Tailwind tokens (no raw color/spacing literals), respecting the responsive layout rules, and removing dead tokens as you go. Use it when building or refactoring user-facing React components, screens, forms, dialogs, or styling where UI consistency and token cleanup matter.

Provides the money-gated lifecycle and coordination playbook for taking a consumer one-off / in-app-purchase product from idea to validated bet through launch and live-ops. Use it to classify a product request, run each of the 10 stages as fan-out -> adversarial review -> synthesis against one shared unit-economics model, and apply net-of-fee money gates with explicit loop-backs. Use when coordinating product discovery, monetization design, validation, soft-launch, or live-ops for non-SaaS consumer software.

Add/extend Playwright E2E/integration specs for web use-case changes. Prefer existing repo naming conventions; include UC ID when introducing new use-case-specific specs.

Ensure GitHub Actions CI exists and is green. CI must run lint/format, build, and tests as applicable. Failing CI is blocking.

Derive comprehensive `/docs` from an existing codebase when docs are missing/stale. This is blocking work before new features.

Add docker-compose for HTTP APIs (required before implementing/changing use cases). Provide .env.example + Make targets: up/down/test/lint/build.

End-to-end Gaia SDLC workflow (Repo Explorer → drift/CI fixes → task graph → gated delivery → QA veto → MCP proof). Use for any work in a repo.

Run curl-style integration checks against the docker-compose stack for HTTP APIs. Required for use-case changes.

Add or extend lint/format tooling and ensure it runs locally (Makefile) and in CI. Lint/build are always required in Gaia.

Manual backend regression via curl-like HTTP checks against the docker-compose stack. Required for API use-case changes (label: curl).

Use this skill to create, revise, audit, or rationalize Gaia custom-agent definitions when role boundaries, naming, descriptions, tool scopes, delegation rules, or overlap concerns need maintenance. Use it when adding a role, evaluating whether a new role is justified, expanding an existing role, rewriting agent instructions, or aligning agent files to the global contract. Do not use it to bypass architecture decisions or to create new roles just because one workflow feels inconvenient. Its output is a clear agent definition set with strong descriptions, explicit boundaries, valid tool scopes, and no unnecessary role duplication.

Use this skill to create, update, reconcile, or explain Gaia architecture documentation when the target operating model changes, drift is detected, a repo baseline is missing, or README messaging must stay aligned with design. Use it when system structure, trust boundaries, interfaces, workflows, ownership, or architectural assumptions change; when planning or validation cannot proceed because design is unclear; or when Gaia's own plugin and workflow architecture must be documented before broader definition work continues. Do not use it for implementation delivery or release gating. Its output is current architecture documentation, explicit design decisions, and a clean handoff to planning or definition maintenance.

Use this skill to execute planned implementation work, keep a branch coherent while it changes, and stabilize behavior before formal hardening and release evaluation. Use it when a current plan branch is ready for code or definition-file edits, when implementation-side cleanup is needed to preserve the branch, or when targeted early QA support is useful during delivery. Do not use it to redefine architecture, replace planning, or make broad release decisions. Its output is implemented work that respects the approved target solution, leaves a clean testing handoff, and calls out any upstream design or planning mismatch instead of masking it locally.

Use this skill to turn approved architecture into an explicit execution plan with branch boundaries, dependencies, parallel-safe work, QA checkpoints, release gates, and proof expectations. Use it after architecture is current, whenever the work needs sequencing instead of informal next steps, or when execution reveals new branches, blockers, or gate definitions that require re-planning. Do not use it to invent a target solution or to hide QA and proof work inside vague future tasks. Its output is a current plan that downstream engineering, testing, and release roles can execute directly and audit easily.

Use this skill to run Gaia's end-to-end workflow from intake through closure. It applies when a request needs complexity classification, routing, agent selection, QA checkpoints, release gates, proof expectations, or a workflow reset after drift or repeated blockers. Use it for every meaningful request, for re-planning after major discoveries, and for maintenance efforts that change Gaia's own operating model. Do not use it as a replacement for architecture, planning, engineering, testing, or release work; use it to orchestrate those roles and verify the right artifacts are current before downstream work proceeds.

Use this skill to create, revise, audit, and rationalize Gaia skills when procedural guidance, naming, descriptions, references, or ownership boundaries need maintenance. Use it when a repeated pattern deserves a reusable skill, when an existing skill has drifted from the workflow contract, when frontmatter descriptions need better invocation quality, or when the skill set should be simplified instead of expanded. Do not use it to solve a missing architecture decision or to move global workflow policy out of AGENTS.md into scattered skill files. Its output is a coherent skill set with clear procedural ownership, valid metadata, strong descriptions, and minimal duplication.

Use this skill to define and execute Gaia's formal validation approach across unit, integration, manual regression, automated regression, and evidence review. Use it when a branch is stable enough for hardening, when high-risk behavior needs targeted early validation, when browser-based or user-visible behavior must be checked directly, or when release readiness depends on a clear QA signal. Do not use it to replace implementation ownership, invent acceptance criteria from scratch when planning is missing, or treat weak evidence as proof. Its output is explicit pass-fail-blocked routing, updated validation artifacts, and evidence that matches the risk and surface area of the change.