- name
- fix
- description
- Plan a remediation strategy after a test failure.
# `fix`
Use this skill after the `qa-test-runner` subagent returns a failure report, or invoke the `test-fixer` subagent (`.agents/agents/test-fixer/`) to handle diagnosis, remediation, generation, and re-testing end-to-end.
## Execution Options
### Option A: End-to-End Test Fix Subagent (Automated)
1. Use the `intake-test-failure` skill (`.agents/skills/utils/intake-test-failure/`) to parse the raw failure input (GitHub issue URL, GCS log link, or direct text) into a **Normalized Failure Payload**.
2. Pass the normalized payload to the `test-fixer` subagent (`.agents/agents/test-fixer/`) to classify symptoms against `.agents/skills/utils/test-failure-decision-tree/SKILL.md` (all catalog scenarios), modify Magic Modules source files, generate downstream code, build, and re-run acceptance tests to verify pass.
### Option B: Interactive Remediation Planning
1. **Analyze Failure**: Read the report returned by `qa-test-runner`. Classify symptoms against the decision tree catalog in `.agents/skills/utils/test-failure-decision-tree/SKILL.md` (all catalog scenarios) to identify the failure scenario and root cause category.
2. **Propose Strategy**: Propose a specific remediation strategy from `.agents/skills/utils/test-failure-decision-tree/SKILL.md` or user input.
3. **Handoff**: Apply the change in Magic Modules, and transition to Step 3 (Generate) to compile and verify.
## Remediation Scope Guardrails
* **Strict Evidence-Based Scoping**: When applying fixes in Magic Modules, modify ONLY the specific field(s), resource(s), or configuration(s) directly proven by the test failure logs, backtrace, or plan diff to be causing the failure.
* **No Assumption-Based Expansion**: Do NOT modify sibling, adjacent, or similarly-named fields on assumption without empirical evidence from the test output. Keep PR diffs strictly scoped to proven root causes.
* **Breaking Change Compliance & User Notification**: Consult all files in `docs/content/breaking-changes/` (`breaking-changes.md` and `make-a-breaking-change.md`) before making any schema or behavioral modifications. If a breaking change needs to be made, explicitly state it to the user and list out the reason why, referencing the applicable policy in `docs/content/breaking-changes/`.
* **Unit Test Scope**: Consult [`.agents/knowledge/test/unit-test-scope.md`](../../../knowledge/test/unit-test-scope.md).
View on GitHub