[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CWN6VWS082Z1GPF6M915H8":3,"skill-same:01M6CWN6VWS082Z1GPF6M915H8":58},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6CWN6VWS082Z1GPF6M915H8","bisect-before-fix",null,"Use when a trap\u002Feval gate returns RED on the current branch and you need to determine whether the regression is pre-existing or caused by the change under review, before applying any prescribed fix. Keywords — gate regression, RED verdict, pre-existing failure, change attribution, gate.py, crowded_gate.py, bisecting commits, gate rebuilding, pre-change commit","toejough\u002Fengram","toejough","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5317312?v=4","01M6CWKZ6HJN0226G1FYVY0H0N","01M6CWKZAGT1SPMDWCZ3V8C1HZ",10,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskBF\u002FBF-S\u002Fskills\u002Fbisect-before-fix\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31],"bisect","fix","bisect before fix","review","change","commit","attribution","commits","regression","returns","branch","eval","use","gate","2026-11-10 10:12:30",false,"---\nname: bisect-before-fix\ndescription: Use when a trap\u002Feval gate returns RED on the current branch and you need to determine whether the regression is pre-existing or caused by the change under review, before applying any prescribed fix. Keywords — gate regression, RED verdict, pre-existing failure, change attribution, gate.py, crowded_gate.py, bisecting commits, gate rebuilding, pre-change commit\n---\n\n# Bisect Before Attributing: Isolate Pre-Existing Regressions from Change-Caused Failures\n\n## Overview\n\nWhen a trap\u002Feval gate returns RED on your branch, it names a failure and often suggests a fix. But the regression might be pre-existing (a bug introduced in an earlier commit) rather than caused by your change. Applying a fix to a pre-existing failure masks the real issue, hides a regression that belongs in its own issue, and mislabels the cause. This skill is the bisection procedure that isolates the cause before any fix is applied.\n\n## When to Use\n\nA trap\u002Feval gate (gate.py, crowded_gate.py, or similar) has returned RED on the current HEAD of a branch or change under review. You have a suggested fix and pressure (time, deadline, authority, false confidence) to apply it immediately without verification. Triggers include:\n\n- Gate returns RED with a suggested fix (\"use X at line Y\")\n- You are under pressure (time window, deadline, peer confidence) to merge now\n- Authority figure says \"we know what this is, just apply the fix\"\n- Peer says \"I've seen this pattern, the fix works every time\"\n- You feel confident the change caused it\n\n## Procedure\n\n1. Identify the commit immediately preceding the change under review's relevant commits.\n2. Check out that preceding commit.\n3. Rebuild the artifact under test from that commit.\n4. Re-run the identical gate (e.g. `gate.py --tier smoke`) against that rebuilt artifact.\n5. Compare this verdict to the original RED verdict observed on the change under review's HEAD.\n6. If the same failure reproduces on the pre-change commit: the change under review is NOT the cause -- do not apply its prescribed fix; instead file the pre-existing regression as its own separate issue for dedicated investigation.\n7. If the failure does NOT reproduce on the pre-change commit: the change under review is confirmed as the cause -- its prescribed fix (if any) applies.\n8. Restore the original HEAD\u002Fbranch and rebuild the artifact before reporting results.\n\n## Done When\n\nThe regression has been correctly attributed as pre-existing (with a separate follow-up issue filed) or caused by the change under review, and the original HEAD\u002Fbranch has been restored and rebuilt before reporting.\n\n## Common Mistakes\n\n| Excuse under pressure | Reality |\n|---|---|\n| \"Just apply the fix, we know it works — I've seen the same pattern in three other PRs\" | Pattern matching on the *symptom* (\"bare error at line X\") is not pattern matching on the *cause*. A pre-existing bare error looks identical to a newly-introduced one. Three other PRs verified on their code, not this line. Verify this cause first. |\n| \"The deadline is tight, we don't have time to bisect — just apply it\" | Bisection takes two minutes: checkout, rebuild, re-run the gate. A wrong fix means a second gate failure, another merge attempt, and the deadline is closed anyway. The two-minute check is faster than guessing. |\n| \"I'm confident this change caused it because I wrote the PR\" | Confidence is not causation. A change-unrelated file can still trigger a gate failure if main was already broken. The only evidence is the gate verdict on the pre-change commit. Verify it. |\n| \"The senior engineer already reviewed the code and said it's the cause\" | Code review is strong on *what* the PR contains, not on *whether main is green*. Main might have been red for days. The lead is not claiming they tested main; only that the diff looks plausible. Verify main is green. |\n\n## Red Flags — Stop and Follow the Procedure\n\n- About to apply a gate's suggested fix without checking whether the failure reproduces on main\u002Fthe pre-change commit.\n- Peer says \"I've seen this before, it's definitely X\" — past experience describes their code, not yours. Verify yours.\n- Deadline approaching and gate just failed — the bisection check (checkout, rebuild, re-run) is *faster* than wrong merge + revert. Run it.\n- Feeling confident about the cause because the change is \"obvious\" — read the gate verdict on the pre-change commit instead.\n- Skipping the check because \"the senior engineer already reviewed it\" — they reviewed the PR, not main. Verify main green separately.\n\n","# Bisect Before Attributing: Isolate Pre-Existing Regressions from Change-Caused Failures\n\n## Overview\n\nWhen a trap\u002Feval gate returns RED on your branch, it names a failure and often suggests a fix. But the regression might be pre-existing (a bug introduced in an earlier commit) rather than caused by your change. Applying a fix to a pre-existing failure masks the real issue, hides a regression that belongs in its own issue, and mislabels the cause. This skill is the bisection procedure that isolates the cause before any fix is applied.\n\n## When to Use\n\nA trap\u002Feval gate (gate.py, crowded_gate.py, or similar) has returned RED on the current HEAD of a branch or change under review. You have a suggested fix and pressure (time, deadline, authority, false confidence) to apply it immediately without verification. Triggers include:\n\n- Gate returns RED with a suggested fix (\"use X at line Y\")\n- You are under pressure (time window, deadline, peer confidence) to merge now\n- Authority figure says \"we know what this is, just apply the fix\"\n- Peer says \"I've seen this pattern, the fix works every time\"\n- You feel confident the change caused it\n\n## Procedure\n\n1. Identify the commit immediately preceding the change under review's relevant commits.\n2. Check out that preceding commit.\n3. Rebuild the artifact under test from that commit.\n4. Re-run the identical gate (e.g. `gate.py --tier smoke`) against that rebuilt artifact.\n5. Compare this verdict to the original RED verdict observed on the change under review's HEAD.\n6. If the same failure reproduces on the pre-change commit: the change under review is NOT the cause -- do not apply its prescribed fix; instead file the pre-existing regression as its own separate issue for dedicated investigation.\n7. If the failure does NOT reproduce on the pre-change commit: the change under review is confirmed as the cause -- its prescribed fix (if any) applies.\n8. Restore the original HEAD\u002Fbranch and rebuild the artifact before reporting results.\n\n## Done When\n\nThe regression has been correctly attributed as pre-existing (with a separate follow-up issue filed) or caused by the change under review, and the original HEAD\u002Fbranch has been restored and rebuilt before reporting.\n\n## Common Mistakes\n\n| Excuse under pressure | Reality |\n|---|---|\n| \"Just apply the fix, we know it works — I've seen the same pattern in three other PRs\" | Pattern matching on the *symptom* (\"bare error at line X\") is not pattern matching on the *cause*. A pre-existing bare error looks identical to a newly-introduced one. Three other PRs verified on their code, not this line. Verify this cause first. |\n| \"The deadline is tight, we don't have time to bisect — just apply it\" | Bisection takes two minutes: checkout, rebuild, re-run the gate. A wrong fix means a second gate failure, another merge attempt, and the deadline is closed anyway. The two-minute check is faster than guessing. |\n| \"I'm confident this change caused it because I wrote the PR\" | Confidence is not causation. A change-unrelated file can still trigger a gate failure if main was already broken. The only evidence is the gate verdict on the pre-change commit. Verify it. |\n| \"The senior engineer already reviewed the code and said it's the cause\" | Code review is strong on *what* the PR contains, not on *whether main is green*. Main might have been red for days. The lead is not claiming they tested main; only that the diff looks plausible. Verify main is green. |\n\n## Red Flags — Stop and Follow the Procedure\n\n- About to apply a gate's suggested fix without checking whether the failure reproduces on main\u002Fthe pre-change commit.\n- Peer says \"I've seen this before, it's definitely X\" — past experience describes their code, not yours. Verify yours.\n- Deadline approaching and gate just failed — the bisection check (checkout, rebuild, re-run) is *faster* than wrong merge + revert. Run it.\n- Feeling confident about the cause because the change is \"obvious\" — read the gate verdict on the pre-change commit instead.\n- Skipping the check because \"the senior engineer already reviewed it\" — they reviewed the PR, not main. Verify main green separately.\n\n",{"name":5,"description":7},"main","d2ce817c74ee4fc65645635887510b47b231230f","dev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskBF\u002FBF-S\u002Fskills\u002Fbisect-before-fix",2,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram","https:\u002F\u002Fgithub.com\u002Ftoejough","2026-10-25 06:42:30",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add toejough\u002Fengram --skill bisect-before-fix",{"tool":50,"command":51},"bunx","bunx skills add toejough\u002Fengram --skill bisect-before-fix",{"tool":53,"command":54},"pnpm","pnpm dlx skills add toejough\u002Fengram --skill bisect-before-fix","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskBF\u002FBF-S\u002Fskills\u002Fbisect-before-fix\u002FSKILL.md",true,[],[59,74,79,84,104,122],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":32},"01M6CWPEHWS45MANQE0JW6Z146","recall","Use after any user request that might entail more than a single tool call or anything more than quick, shallow thinking. This surfaces relevant memories that are VITAL to recall for a good user experience and a greater chance at first-pass success for the user's request.","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Fskills_auto_l2\u002Frecall\u002FSKILL.md",[],[61,66,67,68,69,70,71,72,30,73],"surfaces","memories","first","call","thinking","tool","user","good",{"skillNo":75,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":32},"01M6CWPAZ9N9CE1RC754XEJ021","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Fskills_auto\u002Frecall\u002FSKILL.md",[],[61,68,71,72,30,73,66,70,69,67],{"skillNo":80,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":32},"01M6CWP862CSBPDF1QW19P6C0F","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskWriteMemory\u002Frecall-learn\u002Frecall\u002FSKILL.md",[],[61,68,71,72,30,73,66,70,69,67],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":32},"01M6CWP4XPAJYCJMZAPYNWTN3A","learn","Use after work begun with recall, or any work requiring more than one tool call or non-trivial thought. Use immediately for explicit save requests (\"remember this\", \"save that\", \"note for next time\"), and the moment a review, failing check, or user correction confirms a lesson; capture it before applying the fix. Also use at session end when a presented conclusion, design, or finding was later overturned or corrected. Use when a specific approach is confirmed: the user praises a reusable behavior, or an uncertain choice succeeds with observable evidence. This preserves lessons for future recall.","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskWriteMemory\u002Frecall-learn\u002Flearn\u002FSKILL.md",[],[86,91,92,93,21,94,61,71,95,96,97,98,19,99,30,100,101,102,103,69],"time","remember","design","next","choice","work","check","behavior","session","evidence","reusable","later","lesson",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":32},"01M6CWP2649X2F3WZ6EBJHA4MS","write-memory","Executes a vault write handed off by another skill (recall, learn): composes the engram command from the provided fields, runs it, verifies the result, and reports the written note path. Requires a handoff — do not fire on your own judgment that something is worth remembering.","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskWriteMemory\u002FWM-S\u002Fskills\u002Fwrite-memory\u002FSKILL.md",[],[111,112,113,114,86,115,61,116,117,118,119,120,121],"write memory","write","memory","handoff","vault","command","reports","do","engram","another skill","judgment",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":133,"publishedAt":32},"01M6CWNYJCGD4B180MM5852D1N","test-driven-development","Use when implementing any feature or bugfix, before writing implementation code","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskTDD\u002FTDD-S\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[128],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[134,135,136,137,138,30,139],"test","test driven development","development","writing","code","implementation"]