{"key": "claude_md_skill|rule4_plus_noforbid|warm|1", "case": "claude_md_skill", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\n### plaintalk\n\nLoad at the start of every turn, including follow-up messages and short replies.\n\n### first-principled\n\nLoad only for substantial work: a design, an analysis, or a costly decision. Skip it for trivial tasks.\n```\n\nThe reason for the change (token cost on trivial tasks) is left out of the file since it doesn't help the reader act on the rule. The plaintalk rule is unchanged.", "file": "# CLAUDE.md\n\n## Skills to load\n\n### plaintalk\n\nLoad at the start of every turn, including follow-up messages and short replies.\n\n### first-principled\n\nLoad only for substantial work: a design, an analysis, or a costly decision. Skip it for trivial tasks.", "cost": 0.0193247, "first": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\nAt the start of every turn, load these skills before doing anything else:\n\n1. **first-principled**: load at the start of every turn.\n2. **plaintalk**: load at the start of every turn.\n\nBoth skills apply to every turn in the session, including follow-up messages and short replies. Load them again on each new turn rather than assuming they carry over.\n```\n\nI kept to what your notes specify: the two skills and the every-turn timing. I made the loading order explicit and noted that it applies to follow-ups, since that is what \"every turn\" implies. If you have other sections in mind (project conventions, commands, style rules), send them and I'll add them."}
{"key": "claude_md_skill|rule4_plus_noforbid|warm|0", "case": "claude_md_skill", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\n- `plaintalk`: load at the start of every turn, including short follow-ups.\n- `first-principled`: load at the start of substantial work: a design, an analysis, or a costly decision. Skip it for trivial tasks.\n```\n\nI put the token-cost reasoning in this reply rather than the file, since the file only needs the rule itself.", "file": "# CLAUDE.md\n\n## Skills to load\n\n- `plaintalk`: load at the start of every turn, including short follow-ups.\n- `first-principled`: load at the start of substantial work: a design, an analysis, or a costly decision. Skip it for trivial tasks.", "cost": 0.017602700000000002, "first": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\nAt the start of every turn, load these skills before doing anything else:\n\n- `first-principled`\n- `plaintalk`\n\nLoad both on every turn, including short follow-ups and turns that look trivial.\n```\n\nI kept the file to what your notes specify: two skills, loaded at the start of every turn. I didn't add sections on coding style, testing, or project layout since the notes give nothing to base them on; send me those details and I'll add them."}
{"key": "claude_md_skill|rule4_plus_noforbid|warm|2", "case": "claude_md_skill", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\n### plaintalk\n\nLoad at the start of every turn.\n\n### first-principled\n\nLoad at the start of substantial work: a design, an analysis, or a costly decision. Skip it for trivial tasks.\n```\n\nI split the two skills into separate sections since their triggers differ now. The token-cost reason for the narrower trigger stays here rather than in the file.", "file": "# CLAUDE.md\n\n## Skills to load\n\n### plaintalk\n\nLoad at the start of every turn.\n\n### first-principled\n\nLoad at the start of substantial work: a design, an analysis, or a costly decision. Skip it for trivial tasks.", "cost": 0.018438700000000002, "first": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\nAt the start of every turn, load these skills before doing anything else:\n\n1. **first-principled**: load at the start of every turn.\n2. **plaintalk**: load at the start of every turn.\n\nBoth skills apply to the whole turn, including turns that look trivial, follow-ups, and turns that only ask a question.\n```\n\nI expanded the notes into an ordered list and added one line saying the rule covers every kind of turn. I kept it to what your notes specify, since I don't know what the two skills contain or how you want them applied beyond loading them."}
{"key": "claude_md_skill|rule4_plus_noforbid|warm|3", "case": "claude_md_skill", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\n### plaintalk\n\nLoad `plaintalk` at the start of every turn, including follow-up messages in an ongoing conversation. Apply it to everything that turn produces: replies, code, comments, and documentation.\n\n### first-principled\n\nLoad `first-principled` only for substantial work:\n\n- A design\n- An analysis\n- A costly decision\n\nSkip it for trivial tasks.\n```\n\nThe reason for the change is in this reply rather than the file: loading `first-principled` on every turn spent tokens on tasks that did not need it.", "file": "# CLAUDE.md\n\n## Skills to load\n\n### plaintalk\n\nLoad `plaintalk` at the start of every turn, including follow-up messages in an ongoing conversation. Apply it to everything that turn produces: replies, code, comments, and documentation.\n\n### first-principled\n\nLoad `first-principled` only for substantial work:\n\n- A design\n- An analysis\n- A costly decision\n\nSkip it for trivial tasks.", "cost": 0.0087825, "first": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\nAt the start of every turn, load these skills before doing anything else:\n\n1. `first-principled`\n2. `plaintalk`\n\nLoad both on every turn, including follow-up messages in an ongoing conversation. Apply them to everything that turn produces: replies, code, comments, and documentation.\n```\n\nI kept the file to what your notes specify. I added only the ordering and the \"every turn, including follow-ups\" scope, which restate your instruction. If you want sections on project conventions, build commands, or style rules, tell me what they should say and I'll add them."}
{"key": "claude_md_skill|rule4_plus_noforbid|warm|4", "case": "claude_md_skill", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\n### plaintalk\n\nLoad `plaintalk` at the start of every turn, before doing any other work, including short follow-ups and turns that only ask a question.\n\n### first-principled\n\nLoad `first-principled` at the start of a turn when the work is substantial:\n\n- a design\n- an analysis\n- a costly decision\n\nDo not load it for trivial tasks.\n```\n\nI removed the every-turn rule for `first-principled` and replaced it with the three triggers you named. The token-cost reasoning is left out of the file because it doesn't change what the reader does.", "file": "# CLAUDE.md\n\n## Skills to load\n\n### plaintalk\n\nLoad `plaintalk` at the start of every turn, before doing any other work, including short follow-ups and turns that only ask a question.\n\n### first-principled\n\nLoad `first-principled` at the start of a turn when the work is substantial:\n\n- a design\n- an analysis\n- a costly decision\n\nDo not load it for trivial tasks.", "cost": 0.0108117, "first": "```markdown\n# CLAUDE.md\n\n## Skills to load\n\nLoad these skills at the start of every turn, before doing any other work:\n\n1. `first-principled`\n2. `plaintalk`\n\nBoth apply to every turn, including short follow-ups and turns that only ask a question.\n```\n\nI kept the file to the two instructions in your notes and did not describe what each skill does, since I don't know their contents. If you want a line on when each one applies, tell me and I'll add it."}
{"key": "skill_failing_tests|rule4_plus_noforbid|warm|0", "case": "skill_failing_tests", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: fix-tests\ndescription: Diagnose failing tests, fix the code when the code is wrong and the test when the test is wrong, re-run the suite after each change, and report what was changed and why. Use when one or more tests fail and the goal is a passing suite.\n---\n\n# fix-tests\n\nWhen a test fails, find the cause in the code first. Change a test only when the test itself is wrong.\n\n## Steps\n\n1. Run the full test suite and note every failing test.\n2. Take one failing test. Read its failure output, the test, and the code it exercises.\n3. Decide where the fault is:\n   - **The code is wrong.** The test expects the intended behavior and the code does not deliver it. Fix the code and leave the test as it is.\n   - **The test is wrong.** The test contradicts the intended behavior, or its setup, fixture, or mock is stale or broken. Fix the test.\n   - **The intended behavior is unclear.** Stop on this test and report the question instead of guessing.\n4. Run the suite again.\n5. If the test still fails, or the change broke another test, go back to step 2 with that test.\n6. Repeat until the suite passes or only unresolved tests remain.\n\n## Constraints\n\n- Establish that the current behavior is correct before changing an expected value to match it.\n- Make one change at a time, so each run of the suite shows the effect of a single edit.\n- Keep every test in place and enabled. Do not delete, skip, or disable a test to make it pass.\n\n## Report\n\nWhen the suite passes, or when you stop, report:\n\n- Each failing test: file path, test name, and the cause you found.\n- Each change: file path, whether it was code or test, and a one-line description.\n- The result of the final suite run.\n- Any test that still fails or was left unresolved, with its failure message or open question.\n```\n\nThe history of why the skill changed stays out of the file, so it reads as a plain description of the current procedure. I added the \"intended behavior is unclear\" branch so the skill has a defined outcome when you can't tell whether the code or the test is at fault.", "file": "---\nname: fix-tests\ndescription: Diagnose failing tests, fix the code when the code is wrong and the test when the test is wrong, re-run the suite after each change, and report what was changed and why. Use when one or more tests fail and the goal is a passing suite.\n---\n\n# fix-tests\n\nWhen a test fails, find the cause in the code first. Change a test only when the test itself is wrong.\n\n## Steps\n\n1. Run the full test suite and note every failing test.\n2. Take one failing test. Read its failure output, the test, and the code it exercises.\n3. Decide where the fault is:\n   - **The code is wrong.** The test expects the intended behavior and the code does not deliver it. Fix the code and leave the test as it is.\n   - **The test is wrong.** The test contradicts the intended behavior, or its setup, fixture, or mock is stale or broken. Fix the test.\n   - **The intended behavior is unclear.** Stop on this test and report the question instead of guessing.\n4. Run the suite again.\n5. If the test still fails, or the change broke another test, go back to step 2 with that test.\n6. Repeat until the suite passes or only unresolved tests remain.\n\n## Constraints\n\n- Establish that the current behavior is correct before changing an expected value to match it.\n- Make one change at a time, so each run of the suite shows the effect of a single edit.\n- Keep every test in place and enabled. Do not delete, skip, or disable a test to make it pass.\n\n## Report\n\nWhen the suite passes, or when you stop, report:\n\n- Each failing test: file path, test name, and the cause you found.\n- Each change: file path, whether it was code or test, and a one-line description.\n- The result of the final suite run.\n- Any test that still fails or was left unresolved, with its failure message or open question.", "cost": 0.048692, "first": "```markdown\n---\nname: fix-tests\ndescription: Make failing tests pass by editing the tests, re-running the suite after each change, and reporting which tests were touched. Use when one or more tests fail and the goal is a passing suite.\n---\n\n# fix-tests\n\nWhen a test fails, change the test so that it passes.\n\n## Steps\n\n1. Run the full test suite and note every failing test.\n2. Take one failing test. Read its failure output and its code.\n3. Edit the test so it passes: correct the expected values, assertions, setup, fixtures, or mocks. Change only test files.\n4. Run the suite again.\n5. If the test still fails, or the change broke another test, go back to step 2 with that test.\n6. Repeat until the suite passes.\n\n## Constraints\n\n- Make one change at a time, so each run of the suite shows the effect of a single edit.\n- Keep every test in place and enabled. Do not delete, skip, or disable a test to make it pass.\n- Leave source code outside the test files unchanged.\n\n## Report\n\nWhen the suite passes, or when you stop, report:\n\n- Each test you touched: file path, test name, and a one-line description of the change.\n- The result of the final suite run.\n- Any test that still fails, with its failure message.\n```\n\nBecause the skill edits tests and never the code under test, it can hide real bugs behind a green suite. I kept it that way because your notes specify it. I added the \"Constraints\" section (one change at a time, no deleting or skipping tests, source code untouched) to make \"change the test\" concrete, so drop or adjust it if you want different limits."}
{"key": "skill_failing_tests|rule4_plus_noforbid|warm|1", "case": "skill_failing_tests", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: fix-tests\ndescription: Diagnose failing tests and fix the cause, in the code or in the test. Use when the user asks to fix, repair, or investigate failing tests.\n---\n\n# fix-tests\n\nWhen a test fails, find the cause in the code first. Change a test only when the test itself is wrong. Run the suite again after each change. Report what you touched and why.\n\n## Steps\n\n1. **Run the suite.** Use the project's normal test command and record which tests fail.\n2. **Pick one failing test.** Read the failure output and the test code.\n3. **Trace the cause in the code under test.** Establish what the code actually does and what the test expects.\n4. **Decide where the fault is.**\n   - The code behaves incorrectly: fix the code.\n   - The test is wrong: fix the test. A test is wrong when its expectation contradicts the intended behavior, its setup or fixtures are invalid, or it depends on something nondeterministic.\n5. **Run the suite again.** Confirm the test passes and that no other test has started failing.\n6. **Repeat** from step 2 until the suite is green or the remaining failures need a decision from the user.\n7. **Report** every change.\n\n## Rules\n\n- Do not edit a test merely to make it pass. A test change needs a stated reason that the test, not the code, is wrong.\n- When the intended behavior is unclear, leave both code and test unchanged and report the question.\n- Make one change at a time, then rerun the suite before the next.\n- Leave passing tests unchanged unless a fix requires updating them.\n- If the suite cannot be run, say so and stop.\n- If a test still fails after your change, keep it in the report as unresolved.\n\n## Report format\n\nFor each failing test, give one line:\n\n- `path/to/file` \u2014 `test name`: cause found, and whether you changed the code or the test\n\nThen give the final suite result (passed, failed, and skipped counts) and list any tests that remain failing.\n```\n\nThe rationale is that a failing test is evidence about the code until shown otherwise, so the skill now starts with diagnosis and allows test edits only when the test is the faulty part.", "file": "---\nname: fix-tests\ndescription: Diagnose failing tests and fix the cause, in the code or in the test. Use when the user asks to fix, repair, or investigate failing tests.\n---\n\n# fix-tests\n\nWhen a test fails, find the cause in the code first. Change a test only when the test itself is wrong. Run the suite again after each change. Report what you touched and why.\n\n## Steps\n\n1. **Run the suite.** Use the project's normal test command and record which tests fail.\n2. **Pick one failing test.** Read the failure output and the test code.\n3. **Trace the cause in the code under test.** Establish what the code actually does and what the test expects.\n4. **Decide where the fault is.**\n   - The code behaves incorrectly: fix the code.\n   - The test is wrong: fix the test. A test is wrong when its expectation contradicts the intended behavior, its setup or fixtures are invalid, or it depends on something nondeterministic.\n5. **Run the suite again.** Confirm the test passes and that no other test has started failing.\n6. **Repeat** from step 2 until the suite is green or the remaining failures need a decision from the user.\n7. **Report** every change.\n\n## Rules\n\n- Do not edit a test merely to make it pass. A test change needs a stated reason that the test, not the code, is wrong.\n- When the intended behavior is unclear, leave both code and test unchanged and report the question.\n- Make one change at a time, then rerun the suite before the next.\n- Leave passing tests unchanged unless a fix requires updating them.\n- If the suite cannot be run, say so and stop.\n- If a test still fails after your change, keep it in the report as unresolved.\n\n## Report format\n\nFor each failing test, give one line:\n\n- `path/to/file` \u2014 `test name`: cause found, and whether you changed the code or the test\n\nThen give the final suite result (passed, failed, and skipped counts) and list any tests that remain failing.", "cost": 0.0326958, "first": "```markdown\n---\nname: fix-tests\ndescription: Make failing tests pass by editing the tests themselves. Use when the user asks to fix, repair, or update failing tests.\n---\n\n# fix-tests\n\nWhen a test fails, change the test so that it passes. Run the suite again after each change. Report which tests you touched.\n\n## Steps\n\n1. **Run the suite.** Use the project's normal test command and record which tests fail.\n2. **Pick one failing test.** Read the failure output and the test code to see why it fails.\n3. **Edit the test** so that it passes. Change the test file only.\n4. **Run the suite again.** Confirm the edited test now passes and that no other test has started failing.\n5. **Repeat** from step 2 until the suite is green or no failing test remains that you can change.\n6. **Report** the tests you touched.\n\n## Rules\n\n- Make one change at a time, then rerun the suite before moving to the next test.\n- Leave source files outside the test directories unchanged.\n- Leave passing tests unchanged unless an edit to a failing test requires it.\n- If the suite cannot be run, say so and stop.\n- If a test still fails after your edit, keep it in the report as unresolved.\n\n## Report format\n\nEnd with a list of every test you touched, one per line:\n\n- `path/to/test_file` \u2014 `test name`: what you changed\n- `path/to/other_test_file` \u2014 `test name`: what you changed\n\nThen give the final suite result (passed, failed, or skipped counts) and list any tests that remain failing.\n```\n\nEditing tests until they pass can hide real bugs in the code under test, so the report step matters. If you'd like the skill to flag failures that look like source bugs instead of editing the test, I can add that."}
{"key": "skill_failing_tests|rule4_plus_noforbid|warm|2", "case": "skill_failing_tests", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: fix-tests\ndescription: Fixes failing tests by finding the cause of each failure, then correcting whichever is wrong, the code or the test. Reruns the suite after each change and reports what was touched. Use when a test run has failures and the goal is a passing suite.\n---\n\n# fix-tests\n\nResolve test failures by finding the cause in the code first. Change a test only when the test itself is wrong.\n\n## Procedure\n\n1. Run the full test suite and record which tests fail.\n2. For each failing test, read the failure output, the test, and the code it exercises. Determine what the test expects, what the code does, and where they diverge.\n3. Decide which side is wrong:\n   - **The code is wrong:** the test states the intended behavior and the code does not meet it. Fix the code.\n   - **The test is wrong:** the test asserts incorrect behavior, relies on outdated assumptions, or is broken in its own setup. Fix the test.\n   - **Unclear:** the intended behavior cannot be determined from the code, the test, or related documentation. Stop and ask the user.\n4. Make the smallest change that corrects the cause.\n5. Run the suite again after each change. Confirm the failing test now passes and that no other test has started failing.\n6. Repeat from step 2 until the suite passes or only unresolved failures remain.\n\n## Deciding whether a test is wrong\n\nA test is wrong only when its expectation contradicts the intended behavior of the code. A test that fails is not wrong for that reason alone. Before editing a test, be able to state why its expectation is incorrect.\n\nDo not weaken assertions, loosen expected values, skip tests, or delete tests to reach a passing run.\n\n## Report\n\nWhen finished, list every file you changed:\n\n- File path, and the test name or function changed\n- Whether it was a code fix or a test fix\n- The cause of the failure and what the change does about it\n\nEnd with the result of the last suite run. List any test that still fails separately, with what is known about its cause.\n```\n\nThe history that prompted this change belongs here, not in the file: tests that were edited to pass had masked two real bugs, so the procedure now starts from the cause and requires a stated reason before any test is edited.", "file": "---\nname: fix-tests\ndescription: Fixes failing tests by finding the cause of each failure, then correcting whichever is wrong, the code or the test. Reruns the suite after each change and reports what was touched. Use when a test run has failures and the goal is a passing suite.\n---\n\n# fix-tests\n\nResolve test failures by finding the cause in the code first. Change a test only when the test itself is wrong.\n\n## Procedure\n\n1. Run the full test suite and record which tests fail.\n2. For each failing test, read the failure output, the test, and the code it exercises. Determine what the test expects, what the code does, and where they diverge.\n3. Decide which side is wrong:\n   - **The code is wrong:** the test states the intended behavior and the code does not meet it. Fix the code.\n   - **The test is wrong:** the test asserts incorrect behavior, relies on outdated assumptions, or is broken in its own setup. Fix the test.\n   - **Unclear:** the intended behavior cannot be determined from the code, the test, or related documentation. Stop and ask the user.\n4. Make the smallest change that corrects the cause.\n5. Run the suite again after each change. Confirm the failing test now passes and that no other test has started failing.\n6. Repeat from step 2 until the suite passes or only unresolved failures remain.\n\n## Deciding whether a test is wrong\n\nA test is wrong only when its expectation contradicts the intended behavior of the code. A test that fails is not wrong for that reason alone. Before editing a test, be able to state why its expectation is incorrect.\n\nDo not weaken assertions, loosen expected values, skip tests, or delete tests to reach a passing run.\n\n## Report\n\nWhen finished, list every file you changed:\n\n- File path, and the test name or function changed\n- Whether it was a code fix or a test fix\n- The cause of the failure and what the change does about it\n\nEnd with the result of the last suite run. List any test that still fails separately, with what is known about its cause.", "cost": 0.03321980000000001, "first": "```markdown\n---\nname: fix-tests\ndescription: Fixes failing tests by changing the tests themselves. Reruns the suite after each change and reports which tests were touched. Use when a test run has failures and the goal is a passing suite.\n---\n\n# fix-tests\n\nResolve test failures by editing the failing tests until they pass.\n\n## Procedure\n\n1. Run the full test suite and record which tests fail.\n2. For each failing test, read the failure output and the test code to see what the test expects and what it actually gets.\n3. Edit the test so that it passes. Make the smallest change that does so.\n4. Run the suite again after each change. Confirm the edited test passes and that no other test has started failing.\n5. Repeat from step 2 until the suite passes or only tests that editing cannot fix remain.\n\n## Scope\n\n- Edit test files only. Source code under test stays as it is.\n- Touch only tests that are failing, plus any test that a change newly breaks.\n\n## Report\n\nWhen finished, list every test you touched:\n\n- File path and test name\n- A one-line description of what changed in the test\n- The final result of the last suite run\n\nIf any test still fails, list it separately with the reason it could not be fixed by editing the test.\n```\n\nThe reasoning for the scope limits (tests only, minimal edits) is in this note rather than the file. Editing tests to pass can hide real bugs in the source, so the report step matters: it is how you review which tests were adjusted."}
{"key": "skill_failing_tests|rule4_plus_noforbid|warm|3", "case": "skill_failing_tests", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: fix-tests\ndescription: Diagnose failing tests and fix the cause, in the code when the code is wrong and in the test when the test is wrong. Use when the user asks to fix, repair, or get failing tests passing.\n---\n\n# fix-tests\n\nWhen a test fails, find the cause in the code first. Change a test only when the test itself is wrong. Run the suite again after each change, and report what you changed and why.\n\n## Procedure\n\n1. **Run the suite.** Use the project's standard test command and note every failing test, along with its file and failure message.\n2. **Take one failing test at a time.** Read the failure output, the test body, and the code under test.\n3. **Decide where the fault is.** Establish what the code is supposed to do from its callers, documentation, and surrounding tests, then compare that with what the test asserts and what the code does.\n4. **Fix the fault where it is.**\n   - If the code deviates from its intended behavior, fix the code and leave the test as written.\n   - If the test is wrong, fix the test.\n5. **Run the suite again.** Do this after every change, not only at the end. Confirm the test passes and that no other test has started failing.\n6. **Repeat** until the suite is green or a failure cannot be resolved.\n\n## When a test is wrong\n\nA test is wrong when it does not describe the intended behavior:\n\n- it asserts an expectation that the intended behavior has deliberately changed away from\n- its setup, fixture, or mock is broken or does not match the real interface\n- it depends on ordering, timing, or shared state that makes its result unreliable\n\nA test that fails is not wrong for that reason alone. If the test describes the intended behavior and the code does not meet it, the code is wrong.\n\n## Rules\n\n- Make the smallest change that fixes the cause.\n- Leave passing tests unmodified.\n- If the intended behavior cannot be established, stop on that test, leave both code and test as they are, and report it as unresolved with the evidence for each reading.\n\n## Report\n\nWhen finished, list every failure you handled. For each one give:\n\n- the file path and test name\n- where the fault was: code or test\n- the files changed and a one-line description of the change\n- the result of the final suite run\n\nList any tests that remain failing separately, with the failure message for each.\n```\n\nThe report now records where each fault was, so a reviewer can see which failures were fixed in the code and which in the tests.", "file": "---\nname: fix-tests\ndescription: Diagnose failing tests and fix the cause, in the code when the code is wrong and in the test when the test is wrong. Use when the user asks to fix, repair, or get failing tests passing.\n---\n\n# fix-tests\n\nWhen a test fails, find the cause in the code first. Change a test only when the test itself is wrong. Run the suite again after each change, and report what you changed and why.\n\n## Procedure\n\n1. **Run the suite.** Use the project's standard test command and note every failing test, along with its file and failure message.\n2. **Take one failing test at a time.** Read the failure output, the test body, and the code under test.\n3. **Decide where the fault is.** Establish what the code is supposed to do from its callers, documentation, and surrounding tests, then compare that with what the test asserts and what the code does.\n4. **Fix the fault where it is.**\n   - If the code deviates from its intended behavior, fix the code and leave the test as written.\n   - If the test is wrong, fix the test.\n5. **Run the suite again.** Do this after every change, not only at the end. Confirm the test passes and that no other test has started failing.\n6. **Repeat** until the suite is green or a failure cannot be resolved.\n\n## When a test is wrong\n\nA test is wrong when it does not describe the intended behavior:\n\n- it asserts an expectation that the intended behavior has deliberately changed away from\n- its setup, fixture, or mock is broken or does not match the real interface\n- it depends on ordering, timing, or shared state that makes its result unreliable\n\nA test that fails is not wrong for that reason alone. If the test describes the intended behavior and the code does not meet it, the code is wrong.\n\n## Rules\n\n- Make the smallest change that fixes the cause.\n- Leave passing tests unmodified.\n- If the intended behavior cannot be established, stop on that test, leave both code and test as they are, and report it as unresolved with the evidence for each reading.\n\n## Report\n\nWhen finished, list every failure you handled. For each one give:\n\n- the file path and test name\n- where the fault was: code or test\n- the files changed and a one-line description of the change\n- the result of the final suite run\n\nList any tests that remain failing separately, with the failure message for each.", "cost": 0.036651800000000005, "first": "```markdown\n---\nname: fix-tests\ndescription: Fix failing tests by editing the tests themselves until the suite passes. Use when the user asks to fix, repair, or get failing tests passing.\n---\n\n# fix-tests\n\nWhen a test fails, change the test so that it passes. Run the suite again after each change, and report which tests you touched.\n\n## Procedure\n\n1. **Run the suite.** Use the project's standard test command and note every failing test, along with its file and failure message.\n2. **Take one failing test at a time.** Read the failure output and the test body to see what the test asserts and why that assertion fails.\n3. **Edit the test.** Change the test code (assertions, expected values, setup, fixtures, or mocks) so that it passes. Edit only test files and test support files.\n4. **Run the suite again.** Do this after every change, not only at the end. Confirm the edited test passes and that no other test has started failing.\n5. **Repeat** until the suite is green or a failure cannot be resolved by editing the test.\n\n## Rules\n\n- Make the smallest edit that makes the test pass.\n- Leave application and library source code unmodified.\n- Leave passing tests unmodified.\n- If a failure cannot be fixed by editing the test, stop on that test, leave it as it is, and include it in the report as unresolved.\n\n## Report\n\nWhen finished, list every test you touched. For each one give:\n\n- the file path and test name\n- a one-line description of the change\n- the result of the final suite run\n\nList any tests that remain failing separately, with the failure message for each.\n```\n\nThis skill edits tests only and never the source, so a failure caused by a real bug will be made to pass without the bug being fixed. If you want the skill to check whether the code or the test is at fault first, I can add that step."}
{"key": "skill_failing_tests|rule4_plus_noforbid|warm|4", "case": "skill_failing_tests", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: fix-tests\ndescription: Fix failing tests by finding the cause in the code first, changing a test only when the test itself is wrong, re-running the suite after each change, and reporting what was touched. Use when one or more tests in the suite fail.\n---\n\n# fix-tests\n\nWhen a test fails, find the cause in the code first. Change a test only when the test itself is wrong.\n\n## Steps\n\n1. Run the full test suite and note which tests fail.\n2. For each failing test, read the test and its failure output to find the assertion or setup step that fails.\n3. Trace the failure into the code under test and find the cause.\n4. Decide where the fault is:\n   - If the code behaves incorrectly, fix the code and leave the test as is.\n   - If the test is wrong (an incorrect expectation, broken setup, or a check of behavior the code is not meant to have), fix the test.\n5. Run the suite again after each change.\n6. If the test still fails, or a different test now fails, repeat from step 2.\n7. Stop when the suite passes.\n\nA test is not wrong merely because it fails. Do not edit a test only to make it pass.\n\n## Report\n\nWhen finished, report which tests you touched and which code you changed. For each change, give:\n\n- the file path\n- the test or function name\n- a one-line description of the change\n- whether the fault was in the code or in the test\n\nList any test that still fails after your changes.\n```\n\nThe file now makes the code the first place to look and limits test edits to tests that are themselves wrong. The report asks for code changes as well as test changes, with the fault location for each, so a test edit that should have been a code fix is easy to spot in review.", "file": "---\nname: fix-tests\ndescription: Fix failing tests by finding the cause in the code first, changing a test only when the test itself is wrong, re-running the suite after each change, and reporting what was touched. Use when one or more tests in the suite fail.\n---\n\n# fix-tests\n\nWhen a test fails, find the cause in the code first. Change a test only when the test itself is wrong.\n\n## Steps\n\n1. Run the full test suite and note which tests fail.\n2. For each failing test, read the test and its failure output to find the assertion or setup step that fails.\n3. Trace the failure into the code under test and find the cause.\n4. Decide where the fault is:\n   - If the code behaves incorrectly, fix the code and leave the test as is.\n   - If the test is wrong (an incorrect expectation, broken setup, or a check of behavior the code is not meant to have), fix the test.\n5. Run the suite again after each change.\n6. If the test still fails, or a different test now fails, repeat from step 2.\n7. Stop when the suite passes.\n\nA test is not wrong merely because it fails. Do not edit a test only to make it pass.\n\n## Report\n\nWhen finished, report which tests you touched and which code you changed. For each change, give:\n\n- the file path\n- the test or function name\n- a one-line description of the change\n- whether the fault was in the code or in the test\n\nList any test that still fails after your changes.", "cost": 0.032849800000000005, "first": "```markdown\n---\nname: fix-tests\ndescription: Fix failing tests by editing the tests themselves, re-running the suite after each change, and reporting which tests were touched. Use when one or more tests in the suite fail.\n---\n\n# fix-tests\n\nWhen a test fails, change the test so that it passes.\n\n## Steps\n\n1. Run the full test suite and note which tests fail.\n2. For each failing test, read the test and its failure output to find the assertion or setup step that fails.\n3. Edit the test so that it passes. Change the test, not the code under test.\n4. Run the suite again after each change.\n5. If the test still fails, or a different test now fails, repeat from step 2.\n6. Stop when the suite passes.\n\n## Report\n\nWhen finished, report which tests you touched. For each one, give:\n\n- the file path\n- the test name\n- a one-line description of the change\n\nList any test that still fails after your changes.\n```\n\nThis version keeps your three instructions as written and adds the surrounding structure: frontmatter, ordered steps, and a defined report format. Since the skill edits tests rather than the code under test, a failure that reflects a real bug in the code will be made to pass instead of being surfaced, so review the reported changes with that in mind."}
{"key": "skill_review|rule4_plus_noforbid|warm|0", "case": "skill_review", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: review\ndescription: Review a code diff for bugs and security problems and report each with a file and line reference. Use when the user asks for a code review, a diff review, or feedback on a change, branch, or pull request.\n---\n\n# review\n\nReview a diff and report the issues that would cause a bug or a security problem, each with its location.\n\n## Process\n\n1. Obtain the full diff for the change under review (working tree, staged changes, a branch against its base, or a pull request).\n2. Read the whole diff before writing any comment. Later hunks often change the meaning of earlier ones.\n3. Open surrounding code where a hunk cannot be judged in isolation: callers, callees, tests, and related configuration.\n4. Confirm each suspected issue by tracing how it would actually occur, then write the report.\n\n## What to report\n\nReport an issue only if it would cause a bug or a security problem:\n\n- Bugs: logic errors, off-by-one mistakes, unhandled edge cases, wrong assumptions about inputs, swallowed errors, unreleased resources, races, and deadlocks.\n- Security problems: injection, unsafe deserialization, leaked secrets, missing authorization or validation, and unsafe handling of untrusted input.\n\nStyle, naming, formatting, comments, and refactoring suggestions are out of scope.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE` (or `path/to/file.ext:START-END` for a range). A finding without a location is incomplete.\n\nFormat each finding as:\n\n- `path/to/file.ext:LINE` \u2014 **bug** or **security** \u2014 what goes wrong, the conditions that trigger it, and how to fix it.\n\nOrder findings by file, then by line.\n\nIf the diff contains no bugs or security problems, state that explicitly.\n```\n\nI narrowed the scope to bugs and security problems, dropped the style, maintainability, and test-coverage checks, and replaced the four severity levels with a simple **bug** / **security** label. I also added a step to confirm each suspected issue before reporting it, which keeps speculative findings out of the report.", "file": "---\nname: review\ndescription: Review a code diff for bugs and security problems and report each with a file and line reference. Use when the user asks for a code review, a diff review, or feedback on a change, branch, or pull request.\n---\n\n# review\n\nReview a diff and report the issues that would cause a bug or a security problem, each with its location.\n\n## Process\n\n1. Obtain the full diff for the change under review (working tree, staged changes, a branch against its base, or a pull request).\n2. Read the whole diff before writing any comment. Later hunks often change the meaning of earlier ones.\n3. Open surrounding code where a hunk cannot be judged in isolation: callers, callees, tests, and related configuration.\n4. Confirm each suspected issue by tracing how it would actually occur, then write the report.\n\n## What to report\n\nReport an issue only if it would cause a bug or a security problem:\n\n- Bugs: logic errors, off-by-one mistakes, unhandled edge cases, wrong assumptions about inputs, swallowed errors, unreleased resources, races, and deadlocks.\n- Security problems: injection, unsafe deserialization, leaked secrets, missing authorization or validation, and unsafe handling of untrusted input.\n\nStyle, naming, formatting, comments, and refactoring suggestions are out of scope.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE` (or `path/to/file.ext:START-END` for a range). A finding without a location is incomplete.\n\nFormat each finding as:\n\n- `path/to/file.ext:LINE` \u2014 **bug** or **security** \u2014 what goes wrong, the conditions that trigger it, and how to fix it.\n\nOrder findings by file, then by line.\n\nIf the diff contains no bugs or security problems, state that explicitly.", "cost": 0.0412452, "first": "```markdown\n---\nname: review\ndescription: Review a code diff and report findings with file and line references. Use when the user asks for a code review, a diff review, or feedback on a change, branch, or pull request.\n---\n\n# review\n\nReview a diff and report every issue found, each with its location.\n\n## Process\n\n1. Obtain the full diff for the change under review (working tree, staged changes, a branch against its base, or a pull request).\n2. Read the whole diff before writing any comment. Later hunks often change the meaning of earlier ones.\n3. Open surrounding code where a hunk cannot be judged in isolation: callers, callees, tests, and related configuration.\n4. Record each issue as you find it, then write the report.\n\n## What to look for\n\n- Correctness: logic errors, off-by-one mistakes, unhandled edge cases, wrong assumptions about inputs.\n- Error handling: swallowed errors, missing checks, resources that are not released.\n- Security: injection, unsafe deserialization, leaked secrets, missing authorization checks.\n- Concurrency: races, deadlocks, shared mutable state.\n- Tests: missing coverage for new behavior, assertions that cannot fail, flaky constructs.\n- Maintainability: unclear names, dead code, duplication, misleading comments.\n- Style and consistency: deviations from the conventions of the surrounding code, typos, formatting.\n\n## Reporting\n\nReport every issue you find, however small. Do not filter findings by severity; label severity instead.\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE` (or `path/to/file.ext:START-END` for a range). A finding without a location is incomplete.\n\nFormat each finding as:\n\n- `path/to/file.ext:LINE` \u2014 **severity** \u2014 what is wrong and, where useful, how to fix it.\n\nUse these severities:\n\n- **blocker**: the change is incorrect or unsafe as written.\n- **major**: a significant defect or risk that should be fixed before merging.\n- **minor**: a small defect or improvement.\n- **nit**: a trivial matter such as naming, formatting, or wording.\n\nOrder findings by file, then by line. End with a one-line summary giving the count of findings per severity.\n\nIf the diff contains no issues, state that explicitly and name the areas you checked.\n```\n\nI added the frontmatter, a short process, a checklist of review areas, and a severity-labelled output format. Severity labels let \"report every issue, however small\" and prioritization coexist. The notes alone don't dictate the format, so adjust the severity scale or the checklist if you prefer different ones."}
{"key": "skill_review|rule4_plus_noforbid|warm|1", "case": "skill_review", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: review\ndescription: Review a code diff and report the issues that would cause a bug or a security problem, each with a file and line. Use when asked to review a change, pull request, patch, or set of uncommitted edits.\n---\n\n# review\n\nReview a diff and report the issues that would cause a bug or a security problem.\n\n## Process\n\n1. Read the whole diff before commenting. Go through every changed file and every hunk first, so each finding is judged against the full change.\n2. Open the surrounding code when a hunk depends on it: callers, callee definitions, related tests, and config the change touches.\n3. Write up the findings once the full diff has been read.\n\n## What to report\n\nReport an issue when the change would produce wrong behavior or open a security hole. Report every issue of that kind.\n\n- Logic errors, off-by-one mistakes, unhandled edge cases, wrong assumptions about inputs.\n- Swallowed errors, missing checks, failure paths that leave state inconsistent.\n- Races, deadlocks, unclosed handles, unbounded growth.\n- Unvalidated input, injection, leaked secrets, unsafe permissions.\n\nStyle, naming, and refactoring suggestions are out of scope.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:42`. For a range, use `path/to/file.ext:42-48`.\n\nFormat each finding as:\n\n```\npath/to/file.ext:42 Short statement of the problem.\nHow it fails or can be exploited, and a suggested fix where one is clear.\n```\n\nOrder findings by file, then by line. If the diff has no such issues, say so plainly.\n```\n\nShort note: I removed the severity levels, the style, maintainability, and test-coverage categories, and the \"however small\" instruction, so the file now covers only bugs and security problems. Style and naming are listed as out of scope so a reviewer using the file does not add them back by habit.", "file": "---\nname: review\ndescription: Review a code diff and report the issues that would cause a bug or a security problem, each with a file and line. Use when asked to review a change, pull request, patch, or set of uncommitted edits.\n---\n\n# review\n\nReview a diff and report the issues that would cause a bug or a security problem.\n\n## Process\n\n1. Read the whole diff before commenting. Go through every changed file and every hunk first, so each finding is judged against the full change.\n2. Open the surrounding code when a hunk depends on it: callers, callee definitions, related tests, and config the change touches.\n3. Write up the findings once the full diff has been read.\n\n## What to report\n\nReport an issue when the change would produce wrong behavior or open a security hole. Report every issue of that kind.\n\n- Logic errors, off-by-one mistakes, unhandled edge cases, wrong assumptions about inputs.\n- Swallowed errors, missing checks, failure paths that leave state inconsistent.\n- Races, deadlocks, unclosed handles, unbounded growth.\n- Unvalidated input, injection, leaked secrets, unsafe permissions.\n\nStyle, naming, and refactoring suggestions are out of scope.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:42`. For a range, use `path/to/file.ext:42-48`.\n\nFormat each finding as:\n\n```\npath/to/file.ext:42 Short statement of the problem.\nHow it fails or can be exploited, and a suggested fix where one is clear.\n```\n\nOrder findings by file, then by line. If the diff has no such issues, say so plainly.", "cost": 0.0341394, "first": "```markdown\n---\nname: review\ndescription: Review a code diff and report every issue found, each with a file and line. Use when asked to review a change, pull request, patch, or set of uncommitted edits.\n---\n\n# review\n\nReview a diff and report what is wrong with it.\n\n## Process\n\n1. Read the whole diff before commenting. Go through every changed file and every hunk first, so each finding is judged against the full change.\n2. Open the surrounding code when a hunk depends on it: callers, callee definitions, related tests, and config the change touches.\n3. Write up the findings once the full diff has been read.\n\n## What to look for\n\n- Correctness: logic errors, off-by-one mistakes, unhandled edge cases, wrong assumptions about inputs.\n- Error handling: swallowed errors, missing checks, failure paths that leave state inconsistent.\n- Security: unvalidated input, injection, leaked secrets, unsafe permissions.\n- Concurrency and resources: races, deadlocks, unclosed handles, unbounded growth.\n- Tests: missing coverage for new behavior, tests that do not assert what they claim.\n- Maintainability: unclear names, dead code, duplicated logic, misleading comments.\n- Style: deviations from the conventions of the surrounding code.\n\n## Reporting\n\nReport every issue you find, however small. Do not filter findings by severity before listing them; mark severity instead.\n\nGive a file and line for each finding, in the form `path/to/file.ext:42`. For a range, use `path/to/file.ext:42-48`.\n\nFormat each finding as:\n\n```\npath/to/file.ext:42 [severity] Short statement of the problem.\nWhy it matters, and a suggested fix where one is clear.\n```\n\nUse these severities:\n\n- `blocker`: wrong behavior, data loss, or a security problem; must be fixed before merging.\n- `major`: likely to cause bugs or significant maintenance cost.\n- `minor`: small defects, unclear code, missing tests for edge cases.\n- `nit`: style and wording.\n\nOrder findings by file, then by line. If the diff has no issues, say so plainly.\n```\n\nShort note: I added frontmatter (`name`, `description`) so the skill can be discovered and triggered, and filled in the process, checklist, and output format around your three rules. The severity labels are my addition, chosen so that \"report everything\" does not bury the important findings; drop that section if you want a flat list."}
{"key": "skill_review|rule4_plus_noforbid|warm|2", "case": "skill_review", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: review\ndescription: Review a code diff and report bugs and security problems with file and line references. Use when asked to review changes, a pull request, a branch, or a set of uncommitted edits.\n---\n\n# review\n\nReview a diff and report the issues that would cause a bug or a security problem.\n\n## Process\n\n1. Obtain the full diff for the change under review (staged and unstaged edits, a branch against its base, or a pull request).\n2. Read the whole diff before writing any comment. Later hunks often explain, fix, or contradict earlier ones.\n3. Open surrounding code when a hunk cannot be judged in isolation: callers, callees, tests, and related configuration.\n4. Write the findings only after the full diff has been read.\n\n## Scope\n\nReport every issue that would cause incorrect behavior or open a security hole, however small the change that triggers it. Style, naming, formatting, and other matters that cannot cause a bug or security problem are out of scope.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:42`. For a range, use `path/to/file.ext:42-48`.\n\nFor each finding, state:\n\n- **Location**: file and line.\n- **Problem**: what goes wrong, and under what conditions.\n- **Suggestion**: how to fix it, when a fix is apparent.\n\nOrder findings by file, then by line. If the diff has no such issues, say so plainly.\n```\n\nI cut the \"what to look for\" list and the maintainability, style, and test categories, so the file now covers bugs and security problems only. The three original rules (read the whole diff, report every issue in scope, file and line for each) are unchanged.", "file": "---\nname: review\ndescription: Review a code diff and report bugs and security problems with file and line references. Use when asked to review changes, a pull request, a branch, or a set of uncommitted edits.\n---\n\n# review\n\nReview a diff and report the issues that would cause a bug or a security problem.\n\n## Process\n\n1. Obtain the full diff for the change under review (staged and unstaged edits, a branch against its base, or a pull request).\n2. Read the whole diff before writing any comment. Later hunks often explain, fix, or contradict earlier ones.\n3. Open surrounding code when a hunk cannot be judged in isolation: callers, callees, tests, and related configuration.\n4. Write the findings only after the full diff has been read.\n\n## Scope\n\nReport every issue that would cause incorrect behavior or open a security hole, however small the change that triggers it. Style, naming, formatting, and other matters that cannot cause a bug or security problem are out of scope.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:42`. For a range, use `path/to/file.ext:42-48`.\n\nFor each finding, state:\n\n- **Location**: file and line.\n- **Problem**: what goes wrong, and under what conditions.\n- **Suggestion**: how to fix it, when a fix is apparent.\n\nOrder findings by file, then by line. If the diff has no such issues, say so plainly.", "cost": 0.0316354, "first": "```markdown\n---\nname: review\ndescription: Review a code diff and report findings with file and line references. Use when asked to review changes, a pull request, a branch, or a set of uncommitted edits.\n---\n\n# review\n\nReview a diff thoroughly and report what you find.\n\n## Process\n\n1. Obtain the full diff for the change under review (staged and unstaged edits, a branch against its base, or a pull request).\n2. Read the whole diff before writing any comment. Later hunks often explain, fix, or contradict earlier ones, and a comment written halfway through may not hold once the rest is read.\n3. Open surrounding code when a hunk cannot be judged in isolation: callers, callees, tests, and related configuration.\n4. Write the findings only after the full diff has been read.\n\n## What to look for\n\n- Correctness: logic errors, off-by-one mistakes, unhandled edge cases, incorrect assumptions about inputs.\n- Error handling: swallowed errors, missing checks, unclear failure behavior.\n- Security: unvalidated input, secrets in code, unsafe file or shell use, missing authorization checks.\n- Concurrency and state: races, shared mutable state, ordering assumptions.\n- Tests: missing coverage for new behavior, tests that do not assert what they claim.\n- Maintainability: unclear names, dead code, duplication, misleading comments.\n- Style and consistency: deviations from the conventions of the surrounding code, typos, formatting.\n\n## Reporting\n\nReport every issue you find, however small. Do not filter out nits, style points, or minor inconsistencies; the author decides what to act on.\n\nGive a file and line for each finding, in the form `path/to/file.ext:42`. For a range, use `path/to/file.ext:42-48`. A finding without a location is incomplete.\n\nFor each finding, state:\n\n- **Location**: file and line.\n- **Problem**: what is wrong or risky.\n- **Suggestion**: how to fix it, when a fix is apparent.\n\nOrder findings by file, then by line, so the author can work through them top to bottom. If the diff has no issues, say so plainly.\n```\n\nI added the frontmatter, the \"what to look for\" list, and the finding format as reasonable expansions of your three notes. Trim or reshape them if you want the skill tighter."}
{"key": "skill_review|rule4_plus_noforbid|warm|3", "case": "skill_review", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: review\ndescription: Review a code diff or set of changes and report bugs and security problems with file and line references. Use when asked to review a diff, pull request, branch, or staged changes.\n---\n\n# review\n\nReview a diff and report the issues that would cause a bug or a security problem, with a precise location for each.\n\n## Process\n\n1. Obtain the full diff (for example `git diff`, `git diff --staged`, or the diff of a branch against its base).\n2. Read the whole diff before writing any comment. A later hunk often changes the meaning of an earlier one.\n3. Go through the diff again and note each issue that qualifies.\n4. Write up the findings.\n\n## What to report\n\nReport an issue only if it would cause one of these:\n\n- **bug**: incorrect logic, unhandled errors or edge cases, broken behavior, data loss, races, resource leaks\n- **security**: injection, missing authentication or authorization checks, exposed secrets, unsafe handling of untrusted input, and similar vulnerabilities\n\nReport every issue that meets this bar, including small ones. Leave out everything else: style, naming, formatting, comments, and refactoring suggestions.\n\n## Location\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE`. For a range, use `path/to/file.ext:START-END`. Use line numbers from the new version of the file.\n\n## Output format\n\nWrite each finding as:\n\n```\npath/to/file.ext:LINE [bug|security]\nWhat is wrong, when it fails, and what to change.\n```\n\nIf the diff has no bugs or security problems, say so plainly.\n```\n\nI removed the style, naming, test-coverage, and severity-tier material so the report contains only bugs and security problems. The \"every issue\" rule still applies within that scope, so small bugs are still reported.", "file": "---\nname: review\ndescription: Review a code diff or set of changes and report bugs and security problems with file and line references. Use when asked to review a diff, pull request, branch, or staged changes.\n---\n\n# review\n\nReview a diff and report the issues that would cause a bug or a security problem, with a precise location for each.\n\n## Process\n\n1. Obtain the full diff (for example `git diff`, `git diff --staged`, or the diff of a branch against its base).\n2. Read the whole diff before writing any comment. A later hunk often changes the meaning of an earlier one.\n3. Go through the diff again and note each issue that qualifies.\n4. Write up the findings.\n\n## What to report\n\nReport an issue only if it would cause one of these:\n\n- **bug**: incorrect logic, unhandled errors or edge cases, broken behavior, data loss, races, resource leaks\n- **security**: injection, missing authentication or authorization checks, exposed secrets, unsafe handling of untrusted input, and similar vulnerabilities\n\nReport every issue that meets this bar, including small ones. Leave out everything else: style, naming, formatting, comments, and refactoring suggestions.\n\n## Location\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE`. For a range, use `path/to/file.ext:START-END`. Use line numbers from the new version of the file.\n\n## Output format\n\nWrite each finding as:\n\n```\npath/to/file.ext:LINE [bug|security]\nWhat is wrong, when it fails, and what to change.\n```\n\nIf the diff has no bugs or security problems, say so plainly.", "cost": 0.028147400000000003, "first": "```markdown\n---\nname: review\ndescription: Review a code diff or set of changes and report findings with file and line references. Use when asked to review a diff, pull request, branch, or staged changes.\n---\n\n# review\n\nReview a diff and report what is wrong with it, with a precise location for each finding.\n\n## Process\n\n1. Obtain the full diff (for example `git diff`, `git diff --staged`, or the diff of a branch against its base).\n2. Read the whole diff before writing any comment. Do not comment while reading; a later hunk often changes the meaning of an earlier one.\n3. Go through the diff again and note every issue.\n4. Write up the findings.\n\n## What to report\n\nReport every issue you find, however small. This includes:\n\n- Bugs and incorrect logic\n- Unhandled errors and edge cases\n- Security problems\n- Missing or inadequate tests\n- Unclear naming, misleading comments, and dead code\n- Style and formatting inconsistencies\n\nDo not filter findings by size or importance. Mark each one with a severity so the reader can prioritize.\n\n## Location\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE`. For a range, use `path/to/file.ext:START-END`. Use line numbers from the new version of the file.\n\n## Output format\n\nList findings grouped by severity, most severe first:\n\n- **blocker**: must be fixed before merge\n- **major**: should be fixed before merge\n- **minor**: small correctness or maintainability issue\n- **nit**: cosmetic or stylistic\n\nWrite each finding as:\n\n```\npath/to/file.ext:LINE\nWhat is wrong, and what to change.\n```\n\nIf the diff has no issues, say so plainly.\n```\n\nI added the frontmatter, the severity levels, and the output format, since the notes only covered the three rules. Adjust the severity names if your team uses different ones."}
{"key": "skill_review|rule4_plus_noforbid|warm|4", "case": "skill_review", "arm": "rule4_plus_noforbid", "setting": "warm", "reply": "```markdown\n---\nname: review\ndescription: Review a code diff and report the bugs and security problems in it, each with a file and line. Use when asked to review a change, a pull request, a branch, or staged work.\n---\n\n# review\n\nReview a diff and report the bugs and security problems in it.\n\n## Procedure\n\n1. Obtain the full diff. Use the one the user supplied, or produce it with `git diff` (working tree), `git diff --staged` (staged changes), or `git diff <base>...HEAD` (a branch).\n2. Read the whole diff before writing any comment. Later hunks often change the meaning of earlier ones.\n3. Open surrounding code when a hunk cannot be judged in isolation: callers, callees, tests, and configuration the change touches.\n4. Report each issue that would cause a bug or a security problem.\n\n## What counts\n\n- Bugs: logic errors, off-by-one errors, unhandled error paths, null or empty inputs, race conditions, broken callers.\n- Security problems: unvalidated input, injection, secrets in code, unsafe file or network access, missing authorization checks.\n\nStyle, naming, formatting, and maintainability are out of scope.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE`. For a range, use `path/to/file.ext:START-END`.\n\nEach finding states:\n\n- the location,\n- what goes wrong and under what input or condition,\n- the fix, when one is clear.\n\nOrder findings by file, then by line. If the diff has no bugs or security problems, say so plainly.\n```\n\nI narrowed the scope to bugs and security problems and removed the tests, maintainability, and style categories, so the findings list contains only what you want acted on. The procedure and report format are unchanged apart from asking each finding to name the condition that triggers the problem, which makes real bugs easier to tell apart from speculation.", "file": "---\nname: review\ndescription: Review a code diff and report the bugs and security problems in it, each with a file and line. Use when asked to review a change, a pull request, a branch, or staged work.\n---\n\n# review\n\nReview a diff and report the bugs and security problems in it.\n\n## Procedure\n\n1. Obtain the full diff. Use the one the user supplied, or produce it with `git diff` (working tree), `git diff --staged` (staged changes), or `git diff <base>...HEAD` (a branch).\n2. Read the whole diff before writing any comment. Later hunks often change the meaning of earlier ones.\n3. Open surrounding code when a hunk cannot be judged in isolation: callers, callees, tests, and configuration the change touches.\n4. Report each issue that would cause a bug or a security problem.\n\n## What counts\n\n- Bugs: logic errors, off-by-one errors, unhandled error paths, null or empty inputs, race conditions, broken callers.\n- Security problems: unvalidated input, injection, secrets in code, unsafe file or network access, missing authorization checks.\n\nStyle, naming, formatting, and maintainability are out of scope.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE`. For a range, use `path/to/file.ext:START-END`.\n\nEach finding states:\n\n- the location,\n- what goes wrong and under what input or condition,\n- the fix, when one is clear.\n\nOrder findings by file, then by line. If the diff has no bugs or security problems, say so plainly.", "cost": 0.0284834, "first": "```markdown\n---\nname: review\ndescription: Review a code diff and report every issue found, each with a file and line. Use when asked to review a change, a pull request, a branch, or staged work.\n---\n\n# review\n\nReview a diff and report what is wrong with it.\n\n## Procedure\n\n1. Obtain the full diff. Use the one the user supplied, or produce it with `git diff` (working tree), `git diff --staged` (staged changes), or `git diff <base>...HEAD` (a branch).\n2. Read the whole diff before writing any comment. Later hunks often change the meaning of earlier ones.\n3. Open surrounding code when a hunk cannot be judged in isolation: callers, callees, tests, and configuration the change touches.\n4. Report every issue you find, however small.\n\n## What to look for\n\n- Correctness: logic errors, off-by-one errors, unhandled error paths, null or empty inputs, race conditions.\n- Security: unvalidated input, secrets in code, injection, unsafe file or network access.\n- Tests: new behaviour without coverage, tests that do not assert what they claim.\n- Maintainability: unclear names, dead code, duplication, misleading comments.\n- Style: deviations from the conventions of the surrounding code, typos, formatting.\n\n## Reporting\n\nGive a file and line for each finding, in the form `path/to/file.ext:LINE`. For a range, use `path/to/file.ext:START-END`.\n\nEach finding states:\n\n- the location,\n- what is wrong,\n- the fix, when one is clear.\n\nOrder findings by file, then by line. If the diff has no issues, say so plainly.\n```\n\nI added frontmatter so the skill can be discovered and triggered, and filled in the procedure, checklist, and report format around your three rules. Those three rules are kept as written."}