fa.public

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.