[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C1T2RNVZFPWDSP59Y633QD":3,"skill-same:01M6C1T2RNVZFPWDSP59Y633QD":99},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":14,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":42,"install":43,"resources":56},"01M6C1T2RNVZFPWDSP59Y633QD","fix-bug",null,"Fix bugs using a strict TDD workflow. Use when the user reports a bug, asks to fix a bug, debug an issue, or says things like \"fix this bug\", \"this is broken\", \"test and fix\", or \"why is this failing\". Enforces test-first discipline — a failing test must exist before any fix is applied.","cartaorobbin\u002Fpyramid-temporal","cartaorobbin","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F133803757?v=4","01M6C1SVA1FFVXFG0QTK8ZRNDV","robbin Pagamentos","01M6C1SVEDYW8ZDTP82V7DF2BQ",0,"MIT","https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Ffix-bug\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"fix bug","fix","tdd","workflow","test","debug","tdd workflow","first","why","broken","user","use","discipline","2026-11-10 10:12:30",false,"---\nname: fix-bug\ndescription: Fix bugs using a strict TDD workflow. Use when the user reports a bug, asks to fix a bug, debug an issue, or says things like \"fix this bug\", \"this is broken\", \"test and fix\", or \"why is this failing\". Enforces test-first discipline — a failing test must exist before any fix is applied.\n---\n\n# Fix Bug (TDD)\n\nFix bugs by writing a failing test first, then making the minimal code change to pass it. **No fix is allowed until a failing test proves the bug exists.**\n\n---\n\n## Issue Tracker Access\n\nPhase 0 (creating or linking an issue) and Phase 1 (reading an existing issue) both need a tracker. Detect what is available — only when an issue is actually involved:\n\n1. **GitHub MCP** (preferred): Check if a GitHub MCP server is configured by scanning the mcps folder for a server matching `github` or containing `github` in its name. If found, verify with a `get_me` call.\n2. **gh CLI** (fallback): Run `gh auth status` to verify authentication.\n3. **Linear MCP**: Check the mcps folder for a server matching `linear` or containing `linear` in its name.\n\nFor GitHub, resolve `owner` and `repo` from the git remote:\n\n```bash\ngit remote get-url origin\n```\n\nSkip tracker detection entirely when the bug comes from a direct description and the user opts out of tracking in Phase 0.\n\n---\n\n## Constraints\n\n### MUST DO\n- Write a failing test before any fix\n- Confirm hypothesis with user before proceeding to code\n- Run the broader test suite after the fix\n- Make the minimal fix — smallest change that makes the test pass\n\n### MUST NOT DO\n- Fix code before a failing test exists (cardinal rule)\n- Assert buggy behavior in the test (`assert result == wrong_value`)\n- Write overly broad tests that check 10 things at once\n- Refactor or improve nearby code during the fix (separate task)\n- Confuse test errors (import failures) with test failures (assertion failures)\n- Skip running the test — never assume pass\u002Ffail from reading code\n\n---\n\n## Phase 0: Track the Work (Issue & Branch)\n\n> **Skip this entire phase** if you are being driven by the dev-workflow skill — it has already created the issue and the branch. Start directly at Phase 1.\n\nWhen invoked directly (e.g., the user said \"fix this bug\"), decide whether to track the work before touching code.\n\n### 0.1 Ask whether to track\n\nUse AskQuestion:\n\n```\nprompt: \"Track this bug with an issue and a feature branch before fixing?\"\noptions:\n  - id: track\n    label: \"Yes — create\u002Flink an issue and a branch\"\n  - id: inplace\n    label: \"No — fix in place on the current branch\"\n```\n\nIf the user chooses **No**, skip to Phase 1 (use any issue link or description they gave only as context).\n\n### 0.2 Create or link the issue\n\nIf the user chose **Yes**, first detect the tracker (see [Issue Tracker Access](#issue-tracker-access)), then:\n\n**The user already referenced an issue** (a GitHub URL\u002F`#\u003Cnumber>`, or a Linear ID like `ENG-123`) — link it and fetch its details for context.\n\nGitHub via MCP:\n\n```\nCallMcpTool: server=github, toolName=issue_read\narguments: { \"owner\": \"\u003Cowner>\", \"repo\": \"\u003Crepo>\", \"issue_number\": \u003Cnumber>, \"method\": \"get\" }\n```\n\nGitHub via CLI:\n\n```bash\ngh issue view \u003Cnumber> --json title,body,labels,comments\n```\n\nLinear via MCP:\n\n```\nCallMcpTool: server=plugin-linear-linear, toolName=get_issue\narguments: { \"id\": \"\u003Cissue-id>\" }\n```\n\n**No issue exists yet** — define a concise title, a description (what is happening, what should happen, how to trigger it), and create it with the `bug` label.\n\nGitHub via MCP:\n\n```\nCallMcpTool: server=github, toolName=issue_write\narguments: { \"owner\": \"\u003Cowner>\", \"repo\": \"\u003Crepo>\", \"method\": \"create\", \"title\": \"\u003Ctitle>\", \"body\": \"\u003Cdescription>\", \"labels\": [\"bug\"] }\n```\n\nGitHub via CLI:\n\n```bash\ngh issue create --title \"\u003Ctitle>\" --body \"\u003Cdescription>\" --label \"bug\"\n```\n\nLinear via MCP (`save_issue` creates when no `id` is passed; `title` and `team` are required). Resolve `team` first — list the available teams and confirm with the user if there is more than one:\n\n```\nCallMcpTool: server=plugin-linear-linear, toolName=list_teams\narguments: {}\n```\n\n```\nCallMcpTool: server=plugin-linear-linear, toolName=save_issue\narguments: { \"title\": \"\u003Ctitle>\", \"description\": \"\u003Cdescription>\", \"team\": \"\u003Cteam>\", \"labels\": [\"bug\"] }\n```\n\nCapture the issue number\u002Fidentifier.\n\n### 0.3 Create the branch\n\nFor **Linear**, prefer the git branch name that `get_issue` already returns for the issue — Linear's GitHub integration auto-links branches that match it. For **GitHub**, create a slug from the issue title (lowercase, hyphens, max 40 chars):\n\n```bash\ngit checkout -b bug\u002F\u003Cissue-ref>-\u003Cslug>\ngit push -u origin HEAD\n```\n\nWhere `\u003Cissue-ref>` is the GitHub issue number or the Linear identifier (e.g., `bug\u002F42-login-timeout`, `bug\u002FENG-123-login-timeout`).\n\nThen continue to Phase 1.\n\n---\n\n## Phase 1: Understand the Bug\n\nGather enough context to reproduce the problem. Ask the user **one question at a time** if anything is unclear.\n\n### 1.1 Establish the bug context\n\nUse whatever source you have:\n\n- **An issue from Phase 0** (linked or created) — read its title, description, and comments.\n- **A direct description, error log, or stack trace** the user provided — use it as-is.\n\nIf you reached Phase 1 from the dev-workflow, the issue already exists; fetch it via the [Issue Tracker Access](#issue-tracker-access) method if you need its details.\n\n### 1.2 Extract the bug facts\n\nRegardless of the source, extract these three items:\n\n- **What is happening** — the actual (broken) behavior\n- **What should happen** — the expected (correct) behavior\n- **How to trigger it** — steps, input, or conditions that reproduce the bug\n\nIf any of these are missing from the issue or description, ask the user to clarify.\n\n### 1.3 Read the affected code\n\nRead the source file(s) involved. Trace the execution path from the entry point (route, CLI command, function call) through to where the bug manifests.\n\n### 1.4 Identify the root cause area\n\nNarrow down the specific function, method, or code block that is responsible. State your hypothesis to the user before proceeding:\n\n> \"The bug appears to be in `\u003Cfunction>` — it does X when it should do Y because of Z. I'll write a test that proves this.\"\n\nWait for the user to confirm or correct the hypothesis.\n\n---\n\n## Phase 2: Discover Test Infrastructure\n\nBefore writing the test, understand the project's testing conventions.\n\n### 2.1 Detect the test runner\n\nLook for configuration files that indicate the test framework:\n\n| Signal | Test runner |\n|--------|-------------|\n| `pytest.ini`, `pyproject.toml [tool.pytest]`, `conftest.py` | pytest |\n| `package.json` with `test` script, `jest.config.*`, `vitest.config.*` | jest \u002F vitest |\n| `Cargo.toml` | cargo test |\n| `go.mod` | go test |\n| `mix.exs` | mix test |\n| `build.gradle`, `pom.xml` | JUnit |\n\nIf multiple signals exist, prefer the one closest to the affected module.\n\n### 2.2 Find existing tests for the module\n\nSearch for test files that correspond to the buggy module:\n\n- Same directory (`test_*.py`, `*.test.ts`, `*_test.go`, etc.)\n- Mirror directory (`tests\u002F`, `__tests__\u002F`, `spec\u002F`)\n\n### 2.3 Read test conventions\n\nRead 1-2 existing test files to understand:\n\n- Naming patterns (function names, file names)\n- Available fixtures, helpers, or test utilities\n- How test data is set up (factories, fixtures, builders, inline)\n- Import style and organization\n\nMatch these conventions when writing the new test.\n\n---\n\n## Phase 3: Write the Failing Test (RED)\n\nThis is the critical phase. The test must fail against the current code.\n\n### 3.1 Write the test\n\nCreate a test that:\n\n- Asserts the **correct\u002Fexpected** behavior (not the buggy behavior)\n- Is minimal — tests only the specific bug, not unrelated concerns\n- Has a descriptive name: `test_\u003Cwhat>_\u003Cexpected_outcome>` or equivalent for the language\n- Follows the project's existing test conventions (from Phase 2)\n\nPlace the test in the appropriate test file. If no test file exists for the module, create one following the project's naming convention.\n\n### 3.2 Run the test\n\nRun **only** the new test:\n\n```\n\u003Ctest-runner> \u003Cpath-to-test-file>::\u003Ctest-name>\n```\n\n### 3.3 Confirm the test fails\n\n**HARD GATE — Do not proceed to Phase 4 until this is satisfied.**\n\nThe test MUST fail. Verify:\n\n1. The test **ran** (did not error due to import\u002Fsyntax issues)\n2. The test **failed on the assertion** (not on setup or unrelated errors)\n3. The failure message reflects the bug (e.g., \"expected 200 but got 500\", \"expected True but got False\")\n\nIf the test passes, it does not capture the bug. Go back to 3.1 and rethink:\n\n- Is the hypothesis from Phase 1 correct?\n- Is the test exercising the right code path?\n- Are the test inputs triggering the buggy condition?\n\nIf the test errors (import failure, missing fixture, syntax error), fix the test infrastructure issue and re-run. Do not confuse test errors with test failures.\n\n---\n\n## Phase 4: Fix the Bug (GREEN)\n\nNow — and only now — fix the code.\n\n### 4.1 Make the minimal fix\n\nChange the **smallest amount of code** that makes the failing test pass. Resist the urge to refactor, clean up, or improve nearby code. Those are separate tasks.\n\n### 4.2 Run the test again\n\nRun the same test from Phase 3:\n\n```\n\u003Ctest-runner> \u003Cpath-to-test-file>::\u003Ctest-name>\n```\n\n### 4.3 Confirm the test passes\n\nThe test MUST pass. If it still fails:\n\n- Re-read the failure message\n- Adjust the fix\n- Re-run\n\nIterate until the test is green.\n\n---\n\n## Phase 5: Verify No Regressions\n\n### 5.1 Run the broader test suite\n\nRun all tests in the affected module or directory:\n\n```\n\u003Ctest-runner> \u003Cpath-to-test-directory>\n```\n\nIf the test suite is small enough, run the full suite. If it is large, run at minimum the tests for the affected module and any closely related modules.\n\n### 5.2 Handle failures\n\nIf any existing tests broke:\n\n- Determine if the fix changed correct behavior (the fix is wrong) or if the old test was asserting buggy behavior (the test needs updating)\n- Fix the issue and re-run\n- Do not suppress or delete existing tests without explaining why to the user\n\n### 5.3 Report results\n\nTell the user:\n\n- The test that was written and what it verifies\n- The fix that was applied and why\n- The test suite results (all passing, or any issues found)\n\n---\n\n## Error Recovery\n\n**Cannot reproduce the bug:**\n- Ask user for more specific reproduction steps\n- Check if the bug is environment-dependent (OS, Python version, DB state)\n- Try running with verbose\u002Fdebug logging enabled\n- If still unable to reproduce, tell the user and do not proceed with a speculative fix\n\n**Test passes immediately (doesn't capture the bug):**\n- Re-examine the hypothesis — is the root cause correct?\n- Check if test inputs actually trigger the buggy code path\n- Look for conditional logic that only triggers under specific state\n- Go back to Phase 1.4 and revise the hypothesis with the user\n\n**Test errors on setup (not an assertion failure):**\n- Fix the infrastructure issue (missing import, fixture, dependency) first\n- Re-run to confirm the test now fails on the assertion, not on setup\n- Do not confuse a broken test with a failing test\n\n**Fix breaks unrelated tests:**\n- Determine if the fix changed correct behavior (fix is wrong) or old test asserted buggy behavior (test needs updating)\n- Never silently delete or suppress existing tests\n- If unclear, ask the user before modifying existing tests\n\n**Cannot find existing test infrastructure:**\n- Check for test configuration in `pyproject.toml`, `package.json`, `Cargo.toml`, etc.\n- If no tests exist at all, ask the user which test framework to use\n- Create the minimal test setup needed (test file, conftest if Python)\n","# Fix Bug (TDD)\n\nFix bugs by writing a failing test first, then making the minimal code change to pass it. **No fix is allowed until a failing test proves the bug exists.**\n\n---\n\n## Issue Tracker Access\n\nPhase 0 (creating or linking an issue) and Phase 1 (reading an existing issue) both need a tracker. Detect what is available — only when an issue is actually involved:\n\n1. **GitHub MCP** (preferred): Check if a GitHub MCP server is configured by scanning the mcps folder for a server matching `github` or containing `github` in its name. If found, verify with a `get_me` call.\n2. **gh CLI** (fallback): Run `gh auth status` to verify authentication.\n3. **Linear MCP**: Check the mcps folder for a server matching `linear` or containing `linear` in its name.\n\nFor GitHub, resolve `owner` and `repo` from the git remote:\n\n```bash\ngit remote get-url origin\n```\n\nSkip tracker detection entirely when the bug comes from a direct description and the user opts out of tracking in Phase 0.\n\n---\n\n## Constraints\n\n### MUST DO\n- Write a failing test before any fix\n- Confirm hypothesis with user before proceeding to code\n- Run the broader test suite after the fix\n- Make the minimal fix — smallest change that makes the test pass\n\n### MUST NOT DO\n- Fix code before a failing test exists (cardinal rule)\n- Assert buggy behavior in the test (`assert result == wrong_value`)\n- Write overly broad tests that check 10 things at once\n- Refactor or improve nearby code during the fix (separate task)\n- Confuse test errors (import failures) with test failures (assertion failures)\n- Skip running the test — never assume pass\u002Ffail from reading code\n\n---\n\n## Phase 0: Track the Work (Issue & Branch)\n\n> **Skip this entire phase** if you are being driven by the dev-workflow skill — it has already created the issue and the branch. Start directly at Phase 1.\n\nWhen invoked directly (e.g., the user said \"fix this bug\"), decide whether to track the work before touching code.\n\n### 0.1 Ask whether to track\n\nUse AskQuestion:\n\n```\nprompt: \"Track this bug with an issue and a feature branch before fixing?\"\noptions:\n  - id: track\n    label: \"Yes — create\u002Flink an issue and a branch\"\n  - id: inplace\n    label: \"No — fix in place on the current branch\"\n```\n\nIf the user chooses **No**, skip to Phase 1 (use any issue link or description they gave only as context).\n\n### 0.2 Create or link the issue\n\nIf the user chose **Yes**, first detect the tracker (see [Issue Tracker Access](#issue-tracker-access)), then:\n\n**The user already referenced an issue** (a GitHub URL\u002F`#\u003Cnumber>`, or a Linear ID like `ENG-123`) — link it and fetch its details for context.\n\nGitHub via MCP:\n\n```\nCallMcpTool: server=github, toolName=issue_read\narguments: { \"owner\": \"\u003Cowner>\", \"repo\": \"\u003Crepo>\", \"issue_number\": \u003Cnumber>, \"method\": \"get\" }\n```\n\nGitHub via CLI:\n\n```bash\ngh issue view \u003Cnumber> --json title,body,labels,comments\n```\n\nLinear via MCP:\n\n```\nCallMcpTool: server=plugin-linear-linear, toolName=get_issue\narguments: { \"id\": \"\u003Cissue-id>\" }\n```\n\n**No issue exists yet** — define a concise title, a description (what is happening, what should happen, how to trigger it), and create it with the `bug` label.\n\nGitHub via MCP:\n\n```\nCallMcpTool: server=github, toolName=issue_write\narguments: { \"owner\": \"\u003Cowner>\", \"repo\": \"\u003Crepo>\", \"method\": \"create\", \"title\": \"\u003Ctitle>\", \"body\": \"\u003Cdescription>\", \"labels\": [\"bug\"] }\n```\n\nGitHub via CLI:\n\n```bash\ngh issue create --title \"\u003Ctitle>\" --body \"\u003Cdescription>\" --label \"bug\"\n```\n\nLinear via MCP (`save_issue` creates when no `id` is passed; `title` and `team` are required). Resolve `team` first — list the available teams and confirm with the user if there is more than one:\n\n```\nCallMcpTool: server=plugin-linear-linear, toolName=list_teams\narguments: {}\n```\n\n```\nCallMcpTool: server=plugin-linear-linear, toolName=save_issue\narguments: { \"title\": \"\u003Ctitle>\", \"description\": \"\u003Cdescription>\", \"team\": \"\u003Cteam>\", \"labels\": [\"bug\"] }\n```\n\nCapture the issue number\u002Fidentifier.\n\n### 0.3 Create the branch\n\nFor **Linear**, prefer the git branch name that `get_issue` already returns for the issue — Linear's GitHub integration auto-links branches that match it. For **GitHub**, create a slug from the issue title (lowercase, hyphens, max 40 chars):\n\n```bash\ngit checkout -b bug\u002F\u003Cissue-ref>-\u003Cslug>\ngit push -u origin HEAD\n```\n\nWhere `\u003Cissue-ref>` is the GitHub issue number or the Linear identifier (e.g., `bug\u002F42-login-timeout`, `bug\u002FENG-123-login-timeout`).\n\nThen continue to Phase 1.\n\n---\n\n## Phase 1: Understand the Bug\n\nGather enough context to reproduce the problem. Ask the user **one question at a time** if anything is unclear.\n\n### 1.1 Establish the bug context\n\nUse whatever source you have:\n\n- **An issue from Phase 0** (linked or created) — read its title, description, and comments.\n- **A direct description, error log, or stack trace** the user provided — use it as-is.\n\nIf you reached Phase 1 from the dev-workflow, the issue already exists; fetch it via the [Issue Tracker Access](#issue-tracker-access) method if you need its details.\n\n### 1.2 Extract the bug facts\n\nRegardless of the source, extract these three items:\n\n- **What is happening** — the actual (broken) behavior\n- **What should happen** — the expected (correct) behavior\n- **How to trigger it** — steps, input, or conditions that reproduce the bug\n\nIf any of these are missing from the issue or description, ask the user to clarify.\n\n### 1.3 Read the affected code\n\nRead the source file(s) involved. Trace the execution path from the entry point (route, CLI command, function call) through to where the bug manifests.\n\n### 1.4 Identify the root cause area\n\nNarrow down the specific function, method, or code block that is responsible. State your hypothesis to the user before proceeding:\n\n> \"The bug appears to be in `\u003Cfunction>` — it does X when it should do Y because of Z. I'll write a test that proves this.\"\n\nWait for the user to confirm or correct the hypothesis.\n\n---\n\n## Phase 2: Discover Test Infrastructure\n\nBefore writing the test, understand the project's testing conventions.\n\n### 2.1 Detect the test runner\n\nLook for configuration files that indicate the test framework:\n\n| Signal | Test runner |\n|--------|-------------|\n| `pytest.ini`, `pyproject.toml [tool.pytest]`, `conftest.py` | pytest |\n| `package.json` with `test` script, `jest.config.*`, `vitest.config.*` | jest \u002F vitest |\n| `Cargo.toml` | cargo test |\n| `go.mod` | go test |\n| `mix.exs` | mix test |\n| `build.gradle`, `pom.xml` | JUnit |\n\nIf multiple signals exist, prefer the one closest to the affected module.\n\n### 2.2 Find existing tests for the module\n\nSearch for test files that correspond to the buggy module:\n\n- Same directory (`test_*.py`, `*.test.ts`, `*_test.go`, etc.)\n- Mirror directory (`tests\u002F`, `__tests__\u002F`, `spec\u002F`)\n\n### 2.3 Read test conventions\n\nRead 1-2 existing test files to understand:\n\n- Naming patterns (function names, file names)\n- Available fixtures, helpers, or test utilities\n- How test data is set up (factories, fixtures, builders, inline)\n- Import style and organization\n\nMatch these conventions when writing the new test.\n\n---\n\n## Phase 3: Write the Failing Test (RED)\n\nThis is the critical phase. The test must fail against the current code.\n\n### 3.1 Write the test\n\nCreate a test that:\n\n- Asserts the **correct\u002Fexpected** behavior (not the buggy behavior)\n- Is minimal — tests only the specific bug, not unrelated concerns\n- Has a descriptive name: `test_\u003Cwhat>_\u003Cexpected_outcome>` or equivalent for the language\n- Follows the project's existing test conventions (from Phase 2)\n\nPlace the test in the appropriate test file. If no test file exists for the module, create one following the project's naming convention.\n\n### 3.2 Run the test\n\nRun **only** the new test:\n\n```\n\u003Ctest-runner> \u003Cpath-to-test-file>::\u003Ctest-name>\n```\n\n### 3.3 Confirm the test fails\n\n**HARD GATE — Do not proceed to Phase 4 until this is satisfied.**\n\nThe test MUST fail. Verify:\n\n1. The test **ran** (did not error due to import\u002Fsyntax issues)\n2. The test **failed on the assertion** (not on setup or unrelated errors)\n3. The failure message reflects the bug (e.g., \"expected 200 but got 500\", \"expected True but got False\")\n\nIf the test passes, it does not capture the bug. Go back to 3.1 and rethink:\n\n- Is the hypothesis from Phase 1 correct?\n- Is the test exercising the right code path?\n- Are the test inputs triggering the buggy condition?\n\nIf the test errors (import failure, missing fixture, syntax error), fix the test infrastructure issue and re-run. Do not confuse test errors with test failures.\n\n---\n\n## Phase 4: Fix the Bug (GREEN)\n\nNow — and only now — fix the code.\n\n### 4.1 Make the minimal fix\n\nChange the **smallest amount of code** that makes the failing test pass. Resist the urge to refactor, clean up, or improve nearby code. Those are separate tasks.\n\n### 4.2 Run the test again\n\nRun the same test from Phase 3:\n\n```\n\u003Ctest-runner> \u003Cpath-to-test-file>::\u003Ctest-name>\n```\n\n### 4.3 Confirm the test passes\n\nThe test MUST pass. If it still fails:\n\n- Re-read the failure message\n- Adjust the fix\n- Re-run\n\nIterate until the test is green.\n\n---\n\n## Phase 5: Verify No Regressions\n\n### 5.1 Run the broader test suite\n\nRun all tests in the affected module or directory:\n\n```\n\u003Ctest-runner> \u003Cpath-to-test-directory>\n```\n\nIf the test suite is small enough, run the full suite. If it is large, run at minimum the tests for the affected module and any closely related modules.\n\n### 5.2 Handle failures\n\nIf any existing tests broke:\n\n- Determine if the fix changed correct behavior (the fix is wrong) or if the old test was asserting buggy behavior (the test needs updating)\n- Fix the issue and re-run\n- Do not suppress or delete existing tests without explaining why to the user\n\n### 5.3 Report results\n\nTell the user:\n\n- The test that was written and what it verifies\n- The fix that was applied and why\n- The test suite results (all passing, or any issues found)\n\n---\n\n## Error Recovery\n\n**Cannot reproduce the bug:**\n- Ask user for more specific reproduction steps\n- Check if the bug is environment-dependent (OS, Python version, DB state)\n- Try running with verbose\u002Fdebug logging enabled\n- If still unable to reproduce, tell the user and do not proceed with a speculative fix\n\n**Test passes immediately (doesn't capture the bug):**\n- Re-examine the hypothesis — is the root cause correct?\n- Check if test inputs actually trigger the buggy code path\n- Look for conditional logic that only triggers under specific state\n- Go back to Phase 1.4 and revise the hypothesis with the user\n\n**Test errors on setup (not an assertion failure):**\n- Fix the infrastructure issue (missing import, fixture, dependency) first\n- Re-run to confirm the test now fails on the assertion, not on setup\n- Do not confuse a broken test with a failing test\n\n**Fix breaks unrelated tests:**\n- Determine if the fix changed correct behavior (fix is wrong) or old test asserted buggy behavior (test needs updating)\n- Never silently delete or suppress existing tests\n- If unclear, ask the user before modifying existing tests\n\n**Cannot find existing test infrastructure:**\n- Check for test configuration in `pyproject.toml`, `package.json`, `Cargo.toml`, etc.\n- If no tests exist at all, ask the user which test framework to use\n- Create the minimal test setup needed (test file, conftest if Python)\n",{"name":5,"description":7},"main","ea5172c58cf8fe53f20b59482e62cc45741da12d",".cursor\u002Fskills\u002Ffix-bug","https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal","https:\u002F\u002Fgithub.com\u002Fcartaorobbin","2026-10-24 04:09:32",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add cartaorobbin\u002Fpyramid-temporal --skill fix-bug",{"tool":49,"command":50},"bunx","bunx skills add cartaorobbin\u002Fpyramid-temporal --skill fix-bug",{"tool":52,"command":53},"pnpm","pnpm dlx skills add cartaorobbin\u002Fpyramid-temporal --skill fix-bug","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Ffix-bug\u002FSKILL.md",true,[57,63,69,75,79,83,87,91,95],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"bin\u002Fmode-handoff-hook","OTHER","其他",403,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002Fbin\u002Fmode-handoff-hook",{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"bin\u002Fmode-handoff-hook.ts","SCRIPT","脚本",2019,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002Fbin\u002Fmode-handoff-hook.ts",{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"sections\u002Fchecklist.md","REFERENCE","参考文档",1971,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002Fsections\u002Fchecklist.md",{"path":76,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":77,"sourceHtmlUrl":78},"sections\u002Fchecklist.md.tmpl",1855,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002Fsections\u002Fchecklist.md.tmpl",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"sections\u002Fmanifest.json",1374,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002Fsections\u002Fmanifest.json",{"path":84,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":85,"sourceHtmlUrl":86},"sections\u002Fpreamble.md",22396,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002Fsections\u002Fpreamble.md",{"path":88,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":89,"sourceHtmlUrl":90},"sections\u002Freview-sections.md",80738,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002Fsections\u002Freview-sections.md",{"path":92,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":93,"sourceHtmlUrl":94},"sections\u002Freview-sections.md.tmpl",41245,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002Fsections\u002Freview-sections.md.tmpl",{"path":96,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":97,"sourceHtmlUrl":98},"SKILL.md.tmpl",31127,"https:\u002F\u002Fgithub.com\u002Fgarrytan\u002Fgstack\u002Fblob\u002Fmain\u002Fplan-ceo-review\u002FSKILL.md.tmpl",[100,124,143,167,178,192],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":114,"publishedAt":32},"01M6C1TXVJXMQ0VWWGMHD7PKG9","write-pytest","Write pytest tests for any Python codebase. Use when the user asks to write tests, create tests, add tests, or test a module\u002Fservice\u002Fendpoint\u002Ffunction. Framework-agnostic; routes to framework-specific helpers when signals are detected. Follows a research-then-discuss-then-write flow.","https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Fwrite-pytest\u002FSKILL.md",[106,111],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":112,"categoryName":113,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000021","资料检索与研究",[115,116,117,30,29,118,119,23,120,121,122,123],"write","write pytest","research","write tests","python","endpoint","flow","framework","create",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":133,"publishedAt":32},"01M6C1TTVR96XWX68FQY37S2QZ","quality-assurance","Run quality assurance checks on the current chat session — pre-task validation, post-task checklist, and code review. Use when finishing a task, before committing, or when the user asks for a QA review.","https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Fquality-assurance\u002FSKILL.md",[130],{"categoryNo":131,"categoryName":132,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000007","代码审查",[134,135,136,137,138,139,140,141,29,142,30],"quality","quality assurance","run","code review","review","code","validation","qa","session",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":154,"publishedAt":32},"01M6C1TR2SWA481C00S2VQ12DW","python-developer","Python developer umbrella — installs Python coding conventions and bundles companion skills (best practices, testing, dependency management) in a single setup. Use when the user asks to set up Python development conventions, install Python skills, or says \"set up Python development\".","https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Fpython-developer\u002FSKILL.md",[149],{"categoryNo":150,"categoryName":151,"taxonomyType":152,"taxonomyTypeDesc":153},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[155,119,156,157,158,159,29,160,161,30,162,163,164,165,166],"developer","python developer","SET","coding","management","dependency management","install","python development","best practices","testing","setup","development",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":32},"01M6C1TNAANT8RS9XKB2F3JF3E","python-best-practices","Comprehensive Python coding conventions and best practices. Use when the user asks about Python conventions, coding patterns, best practices, code style, anti-patterns, or \"how should I write this\" in Python.","https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Fpython-best-practices\u002FSKILL.md",[],[174,163,119,175,139,176,158,115,29,30,177],"python best practices","code style","how","anti-patterns",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":185,"publishedAt":32},"01M6C1TJEMGMNGNVE4DKWF4TNA","pyramid-library","Library Developer persona: developing standalone Pyramid extensions (own repo, own package) that expose includeme for external consumers. Use when the user builds a reusable Pyramid library, designs includeme for consumers, registers custom directives\u002Ftweens\u002Frequest methods, or tests a library with a proper app.","https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Fpyramid-library\u002FSKILL.md",[184],{"categoryNo":150,"categoryName":151,"taxonomyType":152,"taxonomyTypeDesc":153},[186,187,188,189,190,155,191,29,30],"pyramid library","library","repo","core","package","persona",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":199,"publishedAt":32},"01M6C1TFT8Z6MCBEAQ7S24XQ77","pyramid-developer","Pyramid framework conventions — configuration\u002Fregistry, module system with includeme, pyramid_services, models, Cornice REST, ACL authorization, and transactions. Use when setting up Pyramid development conventions for a project.","https:\u002F\u002Fgithub.com\u002Fcartaorobbin\u002Fpyramid-temporal\u002Fblob\u002Fmain\u002F.cursor\u002Fskills\u002Fpyramid-developer\u002FSKILL.md",[198],{"categoryNo":150,"categoryName":151,"taxonomyType":152,"taxonomyTypeDesc":153},[200,155,166,201,122,202,203,204,205,206,207,30,208,119],"pyramid developer","registry","services","ACL","REST","authorization","transactions","system","micromonolith"]