Skip to main content

Informations de source

Dépôt
GoogleCloudPlatform/magic-modules
Dernière activité de la source
1 septembre 2026 à 16:50
Langue détectée de SKILL.md
anglais
Étoiles
975
Forks
2 573

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
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).
Voir sur GitHub