test-fix

Estrelas2

Forks1

Atualizado7 de maio de 2026 às 15:15

YAAT TDD bug-fix workflow: write failing test, confirm failure, apply fix, confirm pass

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

leftos

leftos/yaat

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

Explorador de arquivos

2 arquivos

SKILL.md

readonly

name	test-fix
description	YAAT TDD bug-fix workflow: write failing test, confirm failure, apply fix, confirm pass

TDD Bug-Fix Workflow

Follow these steps exactly. Do not skip or reorder.

Step 1: Understand the bug

Read the issue or user description carefully.
Identify the affected code area (file, class, method).
Read the relevant source code to understand current behavior.

Step 2: Write the failing test FIRST

Create a test that reproduces the bug. Use real data via TestVnasData.EnsureInitialized() — no synthetic stubs.
The test must assert the correct (expected) behavior, so it fails against the current code.
Place the test in the appropriate test project mirroring the source structure.

Step 3: Confirm the test fails (RED)

Run:

timeout 30 dotnet test <test-project> --filter "FullyQualifiedName~<TestName>" 2>&1 | tee .tmp/test-red.log

If the test passes, the test doesn't reproduce the bug. Revise the test.
If the test fails for the wrong reason (compile error, unrelated exception), fix the test setup.
Only proceed when the test fails because the assertion catches the buggy behavior.

Step 4: Apply the fix

Make the minimal code change that fixes the bug.
Do not refactor surrounding code. Do not add unrelated improvements.

Step 5: Confirm the test passes (GREEN)

Run:

timeout 30 dotnet test <test-project> --filter "FullyQualifiedName~<TestName>" 2>&1 | tee .tmp/test-green.log

If the test still fails, the fix is incomplete. Iterate on Step 4.

Step 6: Run broader tests for regressions

Run the full test suite for the affected project:

timeout 30 dotnet test <test-project> 2>&1 | tee .tmp/test-suite.log

If other tests break, determine whether the fix exposed a pre-existing issue or introduced a regression.
Fix regressions. For pre-existing issues exposed by the fix, fix forward — do not revert correct fixes.

Step 7: Build with warnings as errors

dotnet build -p:TreatWarningsAsErrors=true 2>&1 | tee .tmp/build.log

Reminders

No guessing at root causes — the test must reproduce the bug before any fix attempt.
No synthetic test data — use TestVnasData.EnsureInitialized() with real NavData/CIFP.
timeout 30 on all dotnet test invocations to catch soft hangs.
tee to .tmp/ on all dotnet commands.
Enable SimLog in tests if you need debug output: SimLogBuilder.CreateForTest(output).EnableCategory("ClassName", LogLevel.Debug).InitializeSimLog().

Mais deste repositório

mesmo repositório

layout-inspect

leftos/yaat

Query airport ground graph topology via LayoutInspector CLI tool

2026-07-302

prepare-release

leftos/yaat

Prepare a YAAT release from CHANGELOG.md: verify release secret presence, choose version, draft highlights, promote the changelog heading, commit, tag, and push after approval.

2026-07-292

ship

leftos/yaat

End-to-end release of the current session's work: changelog + commit, land onto `main` in both repos, push, then close the related GitHub issue(s). Trigger when the user says "ship it", "ship this", "ship the session", "land and push", "push and close the issue", or invokes /ship. Composes /changelog-and-commit → /merge-session-to-main → push → `gh issue close`. Invoking the skill IS the approval — it pushes to origin/main and closes issues without further prompts.

2026-07-222

bug-bundle

leftos/yaat

Inspect, extract, install, and validate YAAT v4 bug bundles. Use when a *.yaat-bug-report-bundle.zip or *-recording.zip path appears in conversation, when triaging a YAAT controller bug report or recording-driven complaint, when correlating in-game behavior with recorded snapshots / actions / logs, or when fetching GitHub issue attachments into tests/Yaat.Sim.Tests/TestData/. Start with `info` for an overview, then `history --callsign X` for per-aircraft chronology.

2026-07-142

stt-pipeline-debugging

leftos/yaat

Investigate and iterate on YAAT's speech-to-text pipeline. Auto-fires when a *.yaat-speech-sample.zip path appears in the conversation OR when the user provides a raw / paraphrased ATC transcript with an intent phrase like "why doesn't this match", "should this work", "what canonical would this produce", or "how do I make X recognize this". Walks the pipeline (callsign extract → rule mapper → LLM fallback), identifies the gap, and closes the loop with a TDD-driven fix (test → rule → verbalizer regression check → full suite).

2026-05-262

consolidate-recordings

leftos/yaat

Dedupe recording .zip files in tests/Yaat.Sim.Tests/TestData via tools/Yaat.RecordingConsolidator and commit the cleanup. Internal maintenance — do not update CHANGELOG.md.

2026-05-242

name	test-fix
description	YAAT TDD bug-fix workflow: write failing test, confirm failure, apply fix, confirm pass

TDD Bug-Fix Workflow

Follow these steps exactly. Do not skip or reorder.

Step 1: Understand the bug

Read the issue or user description carefully.
Identify the affected code area (file, class, method).
Read the relevant source code to understand current behavior.

Step 2: Write the failing test FIRST

Create a test that reproduces the bug. Use real data via TestVnasData.EnsureInitialized() — no synthetic stubs.
The test must assert the correct (expected) behavior, so it fails against the current code.
Place the test in the appropriate test project mirroring the source structure.

Step 3: Confirm the test fails (RED)

Run:

timeout 30 dotnet test <test-project> --filter "FullyQualifiedName~<TestName>" 2>&1 | tee .tmp/test-red.log

If the test passes, the test doesn't reproduce the bug. Revise the test.
If the test fails for the wrong reason (compile error, unrelated exception), fix the test setup.
Only proceed when the test fails because the assertion catches the buggy behavior.

Step 4: Apply the fix

Make the minimal code change that fixes the bug.
Do not refactor surrounding code. Do not add unrelated improvements.

Step 5: Confirm the test passes (GREEN)

Run:

timeout 30 dotnet test <test-project> --filter "FullyQualifiedName~<TestName>" 2>&1 | tee .tmp/test-green.log

If the test still fails, the fix is incomplete. Iterate on Step 4.

Step 6: Run broader tests for regressions

Run the full test suite for the affected project:

timeout 30 dotnet test <test-project> 2>&1 | tee .tmp/test-suite.log

If other tests break, determine whether the fix exposed a pre-existing issue or introduced a regression.
Fix regressions. For pre-existing issues exposed by the fix, fix forward — do not revert correct fixes.

Step 7: Build with warnings as errors

dotnet build -p:TreatWarningsAsErrors=true 2>&1 | tee .tmp/build.log

Reminders

No guessing at root causes — the test must reproduce the bug before any fix attempt.
No synthetic test data — use TestVnasData.EnsureInitialized() with real NavData/CIFP.
timeout 30 on all dotnet test invocations to catch soft hangs.
tee to .tmp/ on all dotnet commands.
Enable SimLog in tests if you need debug output: SimLogBuilder.CreateForTest(output).EnableCategory("ClassName", LogLevel.Debug).InitializeSimLog().