# Fix

> Plan a remediation strategy after a test failure.

- Skill: `googlecloudplatform/fix` (Agent Skill)
- Install (CLI): `npx skillmds@latest add googlecloudplatform/fix`
- Raw SKILL.md: https://api.skillmd.com/api/skills/googlecloudplatform/fix/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: GoogleCloudPlatform (https://skillmd.com/u/googlecloudplatform)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/googlecloudplatform/fix

---


# `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).