[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7E8JWS1MMP5J2F63QHTFXAS":3,"skill-same:01M7E8JWS1MMP5J2F63QHTFXAS":61},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":14,"repositoryHtmlUrl":36,"repositoryHomepageUrl":6,"ownerHtmlUrl":37,"ownerBlogUrl":38,"ownerDescription":39,"updatedAt":40,"install":41,"resources":54},"01M7E8JWS1MMP5J2F63QHTFXAS","xfail",null,"Use when fixing a bug with a failing test first or a regression test, and proving it fails for the right reason (strict xfail).","tony\u002Fskills","tony","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F26336?v=4","01M72E5RNJ7SQV8F9KBM5RKRMN","Tony Narlock","01M7E7MBN5C6YZ4JJJ5Y82KBJG",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Ftdd\u002Fskills\u002Fxfail\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: xfail\ndescription: \"Use when fixing a bug with a failing test first or a regression test, and proving it fails for the right reason (strict xfail).\"\nargument-hint: Paste or describe the bug to reproduce and fix with strict xfail guards\nallowed-tools: [\"Bash\", \"Read\", \"Grep\", \"Glob\", \"Edit\", \"Write\", \"Agent\"]\n---\n\n# Strict xfail TDD Workflow\n\nFix a bug with strict reproduction guards. Each phase has a gate that passes\nbefore the next begins. The result is proof that the test fails for the right\nreason, in three commits: test only, source only, test only.\n\nInitial bug report: $ARGUMENTS\n\nShared rules: [xfail mechanisms](..\u002F..\u002Freferences\u002Fxfail-mechanisms.md) and\n[gates, commits, recovery](..\u002F..\u002Freferences\u002Fgates-and-commits.md). Write\ncommit messages per `..\u002F..\u002Freferences\u002Fprose-rules.md` and the reference's\n\"Commit messages\" section.\n\n## Orchestration Plan\n\nEnter plan mode before the first edit. In Claude Code call `EnterPlanMode`;\nin Cursor, Codex, or Gemini use `\u002Fplan` or `Shift+Tab`. Where plan mode is\nunavailable, present the plan as text.\n\nThe plan always opens with four full sentences, no bold labels and no\nnoun-colon leads (never \"Bug summary: ...\"): the first states the symptom,\nthe root cause when the report or code shows it, expected behavior, trigger,\nand affected component; the second names the test\nfile, fixtures, and xfail mechanism; the third says whether mocks are needed,\nwhat real behavior they replace, and how you will verify the failure is genuine\nand not mock-induced; the fourth names the phases that run (all, or only the\nfailing test) and, when the bug spans a dependency, the dependency checkout.\n\nAdd a further sentence only when it differs from this workflow's defaults (the\nproject's own gates, test-only and source-only patterns, marker-removal run and\nstash round trip): a mechanism other than the obvious one, test patterns beyond\nthe usual, quality-gate commands that differ from a plain run, or a way to\nprove the failure that differs from the marker-removed run and the stash round\ntrip. A pure function with one test needs a handful of lines.\n\nShort plan for a pure function:\n\n```text\nis_business_day(5) returns True for Saturday, but Saturday is not a business\nday; the function is in bizdays.py and the trigger is any weekday value of 5.\nThe xfail test goes in test_bizdays.py with @unittest.expectedFailure and no\nfixtures. No mocks are involved, so a failure there is the real bug. All\nphases run, and no dependency is involved.\n```\n\nPresent the plan and wait for approval per the approval rule in\n[gates, commits, recovery](..\u002F..\u002Freferences\u002Fgates-and-commits.md). Exit plan\nmode once approved; Phase 1 commits and Phase 4 stashes, which plan mode\nblocks.\n\nWhen the user asked only for the failing test, the plan covers Phases 0 to 2\nand the run stops after Gate 2 with the test committed. Never start Phase 3\nunasked.\n\nThe plan needs no repository: when a Phase 0 gate (dirty tree, wrong\nrepository) stops the run, the stopped report still states the full plan under\n`## Plan`, asks the user to approve it, and says what to fix in the\nrepository.\n\n## Output shape\n\nReport per the final-report and stopped-run shapes in\n`..\u002F..\u002Freferences\u002Fgates-and-commits.md`. Name commits by purpose (xfail test,\nfix, xfail removal), never by phase or number. Name no local paths.\n\n## Phase 0: Discover Conventions\n\n1. Create a todo list tracking all phases.\n2. Confirm the repository: `git rev-parse --show-toplevel` must be the\n   project the bug lives in. If there is none, or the root is the home\n   directory (`(cd ~ && pwd -P)`, since home may be a symlink) or contains it (a dotfile repository would sweep home into Phase 4's stash),\n   stop and tell the user.\n3. Confirm a clean tree: `git status --porcelain` must print nothing. If it\n   prints changes, ask the user to commit or stash them first. Without an\n   interactive question tool, stop; never stash or commit unrelated work.\n4. Read the project's AGENTS.md \u002F CLAUDE.md for test framework and conventions,\n   quality gate commands, and commit format.\n5. Detect the framework and select the mechanism from the xfail-mechanisms\n   reference.\n6. Derive the test-file patterns `diff_gate.py` takes from the project's own\n   layout and naming (see \"Diff gates\" in the reference).\n7. Use Explore agents (or read the files directly where none exist) to find the\n   relevant source and existing tests.\n8. When the bug spans a dependency, follow the cross-dependency steps in the\n   gates-and-commits reference, running this protocol in the dependency first.\n\n## Phase 1: Reproduce with an xfail test\n\nCreate an implemented test with the selected expected-failure annotation or\nskip. Verify reproduction with the annotation removed in Phase 2.\n\nThe test must exercise real code paths. When mocking is unavoidable (network,\nfilesystem, external services), the failure must match the bug's actual\nsymptom (exception type, message, or wrong-value pattern). If the mock causes\nthe failure, discard the test and start over.\n\n1. Study existing test patterns in the target file.\n2. Write a test with a descriptive name, existing fixtures, the selected\n   annotation, and an assertion of the correct behavior (not the buggy one).\n3. Run it. Strict mode must accept its expected failure; skip mode must report\n   it skipped. Check the result against the mechanism reference.\n4. Run the full test file.\n5. Run all quality gates.\n\n### Gate 1: xfail confirmation\n\nThe selected test must produce its mode's annotated broken-state result.\nAn unexpected success or ordinary pass does not reproduce the bug. A skip\nconfirms only the annotation; Phase 2 must establish the genuine failure.\nStop on setup failures or exceptions that do not match the bug's symptom.\n\nThen commit test file changes only; `diff_gate.py` in `test-only` mode (see\nthe reference's \"Diff gates\" section) must print nothing.\n\n## Phase 2: Verify Reproduction Is Genuine\n\nProve the test fails because of the bug, not the test setup.\n\n1. Temporarily remove the expected-failure annotation or skip.\n2. Run the test; it must fail.\n3. Check that the error matches the bug's symptom, the exception type is the\n   expected one, and no misconfigured mock could produce the same failure.\n4. Restore the annotation before continuing.\n\n### Gate 2: genuine-failure confirmation\n\nIf the failure does not match the symptom, the reproduction is contaminated.\nRewrite the test in place without tweaking the mock setup until it looks\nright, rerun Phase 1, and replace the Phase 1 commit with\n`git commit --amend`. When that commit was already pushed, add a new commit\ninstead of amending. This phase otherwise produces no commit.\n\n## Phase 3: Apply Fix\n\nFix the source. Zero test file changes in this commit. Apply the minimal fix\n(see the gates-and-commits reference).\n\n1. Apply the fix to the source code.\n2. Run steps 1 to 3 of \"Fix commit\" in the gates-and-commits reference.\n   Do not commit yet; Phase 4 verifies fix isolation first.\n\n### Gate 3: zero-diff on test files\n\nThe `source-only` diff gate must print nothing. If test files changed, move\nthose changes to Phase 5.\n\n## Phase 4: Verify Fix Isolation\n\nProve the fix, not an unrelated change, resolved the test. Use the \"Stash\nround trip\" commands in the gates-and-commits reference.\n\n1. Stash the fix with `push` and keep the SHA it prints. No SHA means nothing\n   was stashed: treat the missing fix as a Phase 3 failure.\n2. Verify the broken state in the mechanism reference: the annotated test must\n   produce the selected mode's result. Temporarily remove the annotation and\n   confirm the same assertion fails for the bug's symptom, then restore the\n   annotation before restoring the fix.\n3. Delete the untracked caches that step 2 created, then `restore` the SHA.\n   On a failure, stop and report the SHA.\n4. List the stashes. The list must not hold your SHA; report any stash of\n   yours that remains.\n5. Repeat the mechanism reference's fixed-state check with the fix restored.\n\n### Gate 4: stash round-trip confirmation\n\nThe unannotated assertion must fail for the original symptom with the fix\nstashed, and pass with the fix restored. Both annotated results must also\nmatch the selected mode. If any check differs, investigate stale build caches,\nunrelated changes, or dependency updates; a skip cannot prove isolation.\n\nRepeat the source-only diff gate after restoring the annotation, then commit\nthe fix with the root cause in the message.\n\n## Phase 5: Remove xfail Marker\n\nConvert the xfail test to a regression test. Zero source changes in this commit.\n\n1. Remove the expected-failure annotation or skip.\n2. Rewrite test comments to describe a regression test, not a bug report.\n3. Run the test; it must pass.\n4. Run the full suite for the affected file or module.\n5. Run all quality gates.\n\n### Gate 5: zero-diff on source files\n\nRun `diff_gate.py` in `test-only` mode (see the reference's \"Diff gates\"\nsection). It must print nothing.\n\nIf source files changed, move them to a separate commit and list it in the\nreport.\n\nThen commit.\n\n## Phase 6: Final Verification\n\n1. Run the complete test suite and all quality gates.\n2. Confirm three commits with correct separation: test only (xfail), source\n   only (fix), test only (xfail removal).\n\n### Gate 6: full suite green\n\nIf any test fails, check whether the fix introduced a regression. Add a\nminimal fix as a new commit, list it in the report, and re-run the suite;\nnever rewrite the three commits.\n\n## Recovery\n\nWhen the unannotated assertion still fails after the fix, re-examine whether\nthe test exercises the code path you fixed and redo the root cause analysis.\nAn annotated result outside the mechanism reference's fixed-state outcome\nalso requires investigation; strict unexpected success is the expected result.\nThe 3-attempt stop rule is in the gates-and-commits reference.\n\n## CI Integration\n\nPush only when the user asks; without an answer, push nothing. When the user\nopts in and the project has CI, verify the sequence against the selected mode:\n\n- Test commit: green, with an accepted expected failure or a skip.\n- Fix commit: strict mode is red specifically for unexpected success; skip\n  mode stays green with the test skipped. The skip is not fix evidence.\n- Annotation-removal commit: green, with the regression assertion executed.\n\nReport the CI results observed. When CI is absent or unobserved, report only\nthe local checks; do not infer CI success from the diff or isolation gates.\n","# Strict xfail TDD Workflow\n\nFix a bug with strict reproduction guards. Each phase has a gate that passes\nbefore the next begins. The result is proof that the test fails for the right\nreason, in three commits: test only, source only, test only.\n\nInitial bug report: $ARGUMENTS\n\nShared rules: [xfail mechanisms](..\u002F..\u002Freferences\u002Fxfail-mechanisms.md) and\n[gates, commits, recovery](..\u002F..\u002Freferences\u002Fgates-and-commits.md). Write\ncommit messages per `..\u002F..\u002Freferences\u002Fprose-rules.md` and the reference's\n\"Commit messages\" section.\n\n## Orchestration Plan\n\nEnter plan mode before the first edit. In Claude Code call `EnterPlanMode`;\nin Cursor, Codex, or Gemini use `\u002Fplan` or `Shift+Tab`. Where plan mode is\nunavailable, present the plan as text.\n\nThe plan always opens with four full sentences, no bold labels and no\nnoun-colon leads (never \"Bug summary: ...\"): the first states the symptom,\nthe root cause when the report or code shows it, expected behavior, trigger,\nand affected component; the second names the test\nfile, fixtures, and xfail mechanism; the third says whether mocks are needed,\nwhat real behavior they replace, and how you will verify the failure is genuine\nand not mock-induced; the fourth names the phases that run (all, or only the\nfailing test) and, when the bug spans a dependency, the dependency checkout.\n\nAdd a further sentence only when it differs from this workflow's defaults (the\nproject's own gates, test-only and source-only patterns, marker-removal run and\nstash round trip): a mechanism other than the obvious one, test patterns beyond\nthe usual, quality-gate commands that differ from a plain run, or a way to\nprove the failure that differs from the marker-removed run and the stash round\ntrip. A pure function with one test needs a handful of lines.\n\nShort plan for a pure function:\n\n```text\nis_business_day(5) returns True for Saturday, but Saturday is not a business\nday; the function is in bizdays.py and the trigger is any weekday value of 5.\nThe xfail test goes in test_bizdays.py with @unittest.expectedFailure and no\nfixtures. No mocks are involved, so a failure there is the real bug. All\nphases run, and no dependency is involved.\n```\n\nPresent the plan and wait for approval per the approval rule in\n[gates, commits, recovery](..\u002F..\u002Freferences\u002Fgates-and-commits.md). Exit plan\nmode once approved; Phase 1 commits and Phase 4 stashes, which plan mode\nblocks.\n\nWhen the user asked only for the failing test, the plan covers Phases 0 to 2\nand the run stops after Gate 2 with the test committed. Never start Phase 3\nunasked.\n\nThe plan needs no repository: when a Phase 0 gate (dirty tree, wrong\nrepository) stops the run, the stopped report still states the full plan under\n`## Plan`, asks the user to approve it, and says what to fix in the\nrepository.\n\n## Output shape\n\nReport per the final-report and stopped-run shapes in\n`..\u002F..\u002Freferences\u002Fgates-and-commits.md`. Name commits by purpose (xfail test,\nfix, xfail removal), never by phase or number. Name no local paths.\n\n## Phase 0: Discover Conventions\n\n1. Create a todo list tracking all phases.\n2. Confirm the repository: `git rev-parse --show-toplevel` must be the\n   project the bug lives in. If there is none, or the root is the home\n   directory (`(cd ~ && pwd -P)`, since home may be a symlink) or contains it (a dotfile repository would sweep home into Phase 4's stash),\n   stop and tell the user.\n3. Confirm a clean tree: `git status --porcelain` must print nothing. If it\n   prints changes, ask the user to commit or stash them first. Without an\n   interactive question tool, stop; never stash or commit unrelated work.\n4. Read the project's AGENTS.md \u002F CLAUDE.md for test framework and conventions,\n   quality gate commands, and commit format.\n5. Detect the framework and select the mechanism from the xfail-mechanisms\n   reference.\n6. Derive the test-file patterns `diff_gate.py` takes from the project's own\n   layout and naming (see \"Diff gates\" in the reference).\n7. Use Explore agents (or read the files directly where none exist) to find the\n   relevant source and existing tests.\n8. When the bug spans a dependency, follow the cross-dependency steps in the\n   gates-and-commits reference, running this protocol in the dependency first.\n\n## Phase 1: Reproduce with an xfail test\n\nCreate an implemented test with the selected expected-failure annotation or\nskip. Verify reproduction with the annotation removed in Phase 2.\n\nThe test must exercise real code paths. When mocking is unavoidable (network,\nfilesystem, external services), the failure must match the bug's actual\nsymptom (exception type, message, or wrong-value pattern). If the mock causes\nthe failure, discard the test and start over.\n\n1. Study existing test patterns in the target file.\n2. Write a test with a descriptive name, existing fixtures, the selected\n   annotation, and an assertion of the correct behavior (not the buggy one).\n3. Run it. Strict mode must accept its expected failure; skip mode must report\n   it skipped. Check the result against the mechanism reference.\n4. Run the full test file.\n5. Run all quality gates.\n\n### Gate 1: xfail confirmation\n\nThe selected test must produce its mode's annotated broken-state result.\nAn unexpected success or ordinary pass does not reproduce the bug. A skip\nconfirms only the annotation; Phase 2 must establish the genuine failure.\nStop on setup failures or exceptions that do not match the bug's symptom.\n\nThen commit test file changes only; `diff_gate.py` in `test-only` mode (see\nthe reference's \"Diff gates\" section) must print nothing.\n\n## Phase 2: Verify Reproduction Is Genuine\n\nProve the test fails because of the bug, not the test setup.\n\n1. Temporarily remove the expected-failure annotation or skip.\n2. Run the test; it must fail.\n3. Check that the error matches the bug's symptom, the exception type is the\n   expected one, and no misconfigured mock could produce the same failure.\n4. Restore the annotation before continuing.\n\n### Gate 2: genuine-failure confirmation\n\nIf the failure does not match the symptom, the reproduction is contaminated.\nRewrite the test in place without tweaking the mock setup until it looks\nright, rerun Phase 1, and replace the Phase 1 commit with\n`git commit --amend`. When that commit was already pushed, add a new commit\ninstead of amending. This phase otherwise produces no commit.\n\n## Phase 3: Apply Fix\n\nFix the source. Zero test file changes in this commit. Apply the minimal fix\n(see the gates-and-commits reference).\n\n1. Apply the fix to the source code.\n2. Run steps 1 to 3 of \"Fix commit\" in the gates-and-commits reference.\n   Do not commit yet; Phase 4 verifies fix isolation first.\n\n### Gate 3: zero-diff on test files\n\nThe `source-only` diff gate must print nothing. If test files changed, move\nthose changes to Phase 5.\n\n## Phase 4: Verify Fix Isolation\n\nProve the fix, not an unrelated change, resolved the test. Use the \"Stash\nround trip\" commands in the gates-and-commits reference.\n\n1. Stash the fix with `push` and keep the SHA it prints. No SHA means nothing\n   was stashed: treat the missing fix as a Phase 3 failure.\n2. Verify the broken state in the mechanism reference: the annotated test must\n   produce the selected mode's result. Temporarily remove the annotation and\n   confirm the same assertion fails for the bug's symptom, then restore the\n   annotation before restoring the fix.\n3. Delete the untracked caches that step 2 created, then `restore` the SHA.\n   On a failure, stop and report the SHA.\n4. List the stashes. The list must not hold your SHA; report any stash of\n   yours that remains.\n5. Repeat the mechanism reference's fixed-state check with the fix restored.\n\n### Gate 4: stash round-trip confirmation\n\nThe unannotated assertion must fail for the original symptom with the fix\nstashed, and pass with the fix restored. Both annotated results must also\nmatch the selected mode. If any check differs, investigate stale build caches,\nunrelated changes, or dependency updates; a skip cannot prove isolation.\n\nRepeat the source-only diff gate after restoring the annotation, then commit\nthe fix with the root cause in the message.\n\n## Phase 5: Remove xfail Marker\n\nConvert the xfail test to a regression test. Zero source changes in this commit.\n\n1. Remove the expected-failure annotation or skip.\n2. Rewrite test comments to describe a regression test, not a bug report.\n3. Run the test; it must pass.\n4. Run the full suite for the affected file or module.\n5. Run all quality gates.\n\n### Gate 5: zero-diff on source files\n\nRun `diff_gate.py` in `test-only` mode (see the reference's \"Diff gates\"\nsection). It must print nothing.\n\nIf source files changed, move them to a separate commit and list it in the\nreport.\n\nThen commit.\n\n## Phase 6: Final Verification\n\n1. Run the complete test suite and all quality gates.\n2. Confirm three commits with correct separation: test only (xfail), source\n   only (fix), test only (xfail removal).\n\n### Gate 6: full suite green\n\nIf any test fails, check whether the fix introduced a regression. Add a\nminimal fix as a new commit, list it in the report, and re-run the suite;\nnever rewrite the three commits.\n\n## Recovery\n\nWhen the unannotated assertion still fails after the fix, re-examine whether\nthe test exercises the code path you fixed and redo the root cause analysis.\nAn annotated result outside the mechanism reference's fixed-state outcome\nalso requires investigation; strict unexpected success is the expected result.\nThe 3-attempt stop rule is in the gates-and-commits reference.\n\n## CI Integration\n\nPush only when the user asks; without an answer, push nothing. When the user\nopts in and the project has CI, verify the sequence against the selected mode:\n\n- Test commit: green, with an accepted expected failure or a skip.\n- Fix commit: strict mode is red specifically for unexpected success; skip\n  mode stays green with the test skipped. The skip is not fix evidence.\n- Annotation-removal commit: green, with the regression assertion executed.\n\nReport the CI results observed. When CI is absent or unobserved, report only\nthe local checks; do not infer CI success from the diff or isolation gates.\n",{"name":5,"description":7,"allowed-tools":24,"argument-hint":32},[25,26,27,28,29,30,31],"Bash","Read","Grep","Glob","Edit","Write","Agent","Paste or describe the bug to reproduce and fix with strict xfail guards","main","5fbeb3b47beedea13813be7b7023f736a8d97a65","plugins\u002Ftdd\u002Fskills\u002Fxfail","https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills","https:\u002F\u002Fgithub.com\u002Ftony","https:\u002F\u002Ftony.sh","lighthouse keeper","2026-11-08 17:57:34",{"source":8,"skillName":5,"commands":42,"prompt":52,"zipAvailable":53},[43,46,49],{"tool":44,"command":45},"npx","npx skills add tony\u002Fskills --skill xfail",{"tool":47,"command":48},"bunx","bunx skills add tony\u002Fskills --skill xfail",{"tool":50,"command":51},"pnpm","pnpm dlx skills add tony\u002Fskills --skill xfail","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Ftdd\u002Fskills\u002Fxfail\u002FSKILL.md",true,[55],{"path":56,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":60},"agents\u002Fopenai.yaml","REFERENCE","参考文档",250,"https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Ftdd\u002Fskills\u002Fxfail\u002Fagents\u002Fopenai.yaml",[62,69,76,83,90,97],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M7E8NCSHXV2JPW4J61R0TQS7","serene-bliss","Use when asked to make a CLI --help, docs page, error message, or tooling UX more serene or calmer for developer experience; returns text, no edits.","https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fweave\u002Fskills\u002Fserene-bliss\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M7E8N87MAVJD8RRQKQB1ZPS6","review","Weave code review: run independent adversarial reviews in parallel, then synthesize findings","https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fweave\u002Fskills\u002Freview\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":19},"01M7E8N402XG4ZBFNACQ413163","refine","Use when asked to refine a draft, iterate on code until cleaner, or polish a README through repeated critique and improvement.","https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fweave\u002Fskills\u002Frefine\u002FSKILL.md",[],[],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":19},"01M7E8N01KB86A7136P00GVKJW","prompt","Weave prompt: compare independent adversarial implementations, then adopt the single best one","https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fweave\u002Fskills\u002Fprompt\u002FSKILL.md",[],[],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":19},"01M7E8MW7YJW2PCMDW3G9RTGNK","plan","Weave planning: compare independent adversarial plans, then synthesize the best one","https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fweave\u002Fskills\u002Fplan\u002FSKILL.md",[],[],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":19},"01M7E8MSBYXNCV4ZYWDS4PFJXK","fix-review","Fix weave review findings: validate, add test coverage, fix, and commit each as atomic changes","https:\u002F\u002Fgithub.com\u002Ftony\u002Fskills\u002Fblob\u002Fmain\u002Fplugins\u002Fweave\u002Fskills\u002Ffix-review\u002FSKILL.md",[],[]]