Skip to main content

heal

Diagnose and fix the failing or flaky tests from the last stress run in stress.log. Use when the user runs `make heal`, invokes /heal, or asks to heal the suite.

소스 정보

저장소
sheshbabu/zen-e2e
최근 소스 활동
2026년 10월 3일 11:24
감지된 SKILL.md 언어
영어
스타
0
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
heal
description
Diagnose and fix the failing or flaky tests from the last stress run in stress.log. Use when the user runs `make heal`, invokes /heal, or asks to heal the suite.
# Heal Fix the tests that failed in the last stress run, and nothing else. The goal is a suite that tests zen correctly, not a suite that passes. ## 1. Read the failures - `stress.log` holds the output of `make stress`. If it is missing or shows no failures, say so and stop. - List every failed or flaky test with its error. - For each one, read `test-results/<test>/error-context.md`, which has the error, the page snapshot and the test source. - Note the pattern: does it fail on every repeat, only after the first, or at random? Failing only on later repeats usually means the shared database grew, not that the test is wrong. ## 2. Classify each failure - **Test bug**: a race, a selector that matches the wrong element, a dependency on data from other specs, or a wrong assumption about zen. Fix it. - **zen bug**: zen behaves wrongly. Don't touch ../zen. Follow the CLAUDE.md convention: keep the assertion, mark the test `test.fail()` with a comment describing the bug, and add it to the findings in `topology.md`. - **Unclear**: when you can't tell which it is from the evidence, leave the test as it is and report it. Read the zen code before deciding that a failure is a zen bug. ## 3. Rules for fixes - Only change what the failures need. Don't refactor or restyle passing tests. - Never remove, weaken or loosen an assertion to make a test pass. That includes swapping an exact match for a partial one, lowering an expected count, or deleting an `expect`. - Never add `test.skip`, `test.fixme`, retries, or a longer timeout, and don't edit `playwright.config.js`. - Don't use `test.fail()` for anything but a confirmed zen bug. - Wait on a condition (a URL, a response, an element state), not a fixed `waitForTimeout`. - Follow CLAUDE.md: selectors live in `helpers/ui.js`, setup goes through `helpers/api.js`, and names come from `unique()`. - A change to a shared helper affects every spec that uses it, so keep helper changes minimal. ## 4. Verify - Re-run each fixed spec with `npx playwright test <spec> --repeat-each 5`. - Then run `npx playwright test` once to check that nothing else broke. - If a fix doesn't hold after two attempts, revert it and report the test as unclear. ## 5. Report End with a short summary, one entry per failing test: - the test name and error - the cause and how you classified it - what you changed, or why you changed nothing Then list every file you edited.
GitHub에서 보기