使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/integralist/agent-skills --skill fix-failing-tests開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Fix Failing Tests
Find the failures in a test-output file, have a read-only subagent diagnose their root causes, then apply the fixes in the main thread, where the user can redirect or stop any fix before work piles up.
- Find the output. Use the path the user gave, else
/tmp/output. Read
it; if it's missing or empty, ask the user where the output is. Done when you have a non-empty file.
- Search for failures. Search for markers rather than reading, because
failures slip past in long output mixed with passing lines and infra logs:
rg -n 'FAIL|--- FAIL|^panic:|DATA RACE|^not ok|Error Trace|build failed' <path>If nothing matches, report "no failures found" with the command you ran, and stop. Done when you have the list of failures, or have reported none.
- Diagnose in a read-only subagent. Follow the completion and retry
rules in the shared subagent policy. Tell the subagent to:
- read the output file and the failures you found, then the relevant
source, before reasoning about causes;
- find the root cause from evidence, saying so when evidence is missing
instead of guessing;
- stay read-only: no edits, no
make test, no workspace changes; - prefer fixing the implementation over weakening an assertion;
- note any
docs/**/*.mdor**/README.mda fix would touch if it
changes behaviour, public APIs, or usage;
- note that
e2eor integration failures need a running stack for
make test-integration;
- follow the project's AGENTS.md;
- return, per failure, the test, the root cause, and the proposed fix.
Done when every failure has a root cause and a proposed fix.
- Fix in the main thread. Show the root causes and fixes, then apply
them, flagging any you're unsure of so the user can redirect, skip, or stop. Never weaken an assertion to make a test pass. Update the docs a fix affects. Run make test after applying; if a fix doesn't hold, re-diagnose rather than guess. After 3 runs that still fail, stop editing, name the assumption you haven't verified, and ask one diagnostic question. Leave committing to the user. Done when make test passes or you've stopped after 3 runs.
