Agent-Skills.md

Agent Skills: Gaia Engineering

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.

UncategorizedID: frostaura/ai.toolkit.gaia/fa-engineering

Repository

frostaura/ai.toolkit.gaia
frostauraLicense: MIT
3026

Install this agent skill to your local

pnpm dlx add-skill https://github.com/frostaura/ai.toolkit.gaia/tree/HEAD/plugins/engineering/skills/fa-engineering

Skill Files

Browse the full folder contents for fa-engineering.

Download Skill

Loading file tree…

plugins/engineering/skills/fa-engineering/SKILL.md

Skill Metadata

Name
fa-engineering
Description
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.

Gaia Engineering

Scope and when to use

Use this skill to deliver the branch that the plan already made explicit.

Use this skill when:

  • a planned branch is ready for code or configuration changes
  • Gaia definition files need direct edits after the operating model is approved
  • localized stabilization is needed before formal QA
  • the work needs practical implementation standards and execution discipline

Do not use this skill when:

  • architecture or plan prerequisites are missing
  • the main problem is broad regression strategy or final release approval
  • the change requires inventing a new target solution instead of implementing the approved one

Required inputs

  • current architecture basis and plan branch
  • repo structure and toolchain constraints
  • local runtime, validation, and build expectations
  • adjacent risk areas or known downstream QA concerns

Owned outputs

  • implemented branch changes aligned to the plan
  • localized stabilization and branch-coherence fixes
  • concise testing and rollout handoff notes
  • explicit upstream escalation when the true issue is not local implementation

Decision tree

  • If the branch is ready, implement the smallest complete set of changes that satisfies the plan.
  • If the branch changes React UI, invoke fa-ui-engineering before editing components, classes, or layout behavior.
  • If the work reveals a design contradiction, stop and route to architecture.
  • If the work reveals a missing dependency or acceptance model, route to planning.
  • If the branch is stable enough for targeted early QA, involve testing deliberately rather than waiting blindly.
  • If the branch is stable enough for formal validation, hand it off with clear notes.

Core workflow

  1. Review the active branch, acceptance criteria, and architecture invariants.
  2. Implement the required code or definition-file changes.
  3. Stabilize the branch by addressing tightly coupled issues caused by the change.
  4. Run the existing build or validation commands needed to keep the branch coherent.
  5. Prepare a direct testing handoff with known risk areas and assumptions.

Implementation guardrails

  • keep edits aligned with the approved architecture and current plan branch
  • route user-facing React UI work through fa-ui-engineering so design-system rules stay explicit during delivery
  • fix tightly coupled breakage caused by the change, but do not expand scope casually
  • preserve explicit configuration and toolchain conventions already used in the repo
  • stop and escalate when the branch cannot be completed without redesign or re-planning

Failure recovery

| Failure mode | Recovery | Owner | Escalation | | -------------------- | ----------------------------------- | -------- | ------------------------ | | design mismatch | stop and surface the contradiction | engineer | send to architect | | sequencing gap | request a plan update | engineer | send to planner | | unstable branch | continue local stabilization | engineer | block formal QA handoff | | release-only blocker | surface the concern for gate review | engineer | involve release after QA |

Anti-patterns

  • do not silently redesign the system during implementation
  • do not patch around a planning problem with hidden local assumptions
  • do not hand off an unstable branch just to move work forward
  • do not grow branch scope without reflecting it back into the plan

Handoff and downstream impact

  • tell testing what changed, what is risky, and what still needs evidence
  • tell release about any remaining gate or rollout concerns that are not code defects
  • tell planning when the branch revealed a hidden dependency or acceptance gap
  • tell architecture when the requested change conflicts with the documented target solution

Examples

  • Good fit: rewrite Gaia's agent or skill files to the new template after the architecture and contract are approved.
  • Good fit: make the local definition edits and run the existing build to ensure the repo stays healthy.
  • Not a fit: decide whether Gaia should adopt a new role or source-of-truth order.

Completion checklist

  • the branch matches the approved architecture and plan
  • local stabilization is complete enough for formal QA
  • upstream mismatches are surfaced instead of hidden
  • the testing handoff is explicit and actionable

References