| 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. |
| license | MIT |
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
- Review the active branch, acceptance criteria, and architecture invariants.
- Implement the required code or definition-file changes.
- Stabilize the branch by addressing tightly coupled issues caused by the change.
- Run the existing build or validation commands needed to keep the branch coherent.
- 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
