[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JYTM3G8PPD0P23SRTWRYPQ":3,"skill-same:01M6JYTM3G8PPD0P23SRTWRYPQ":124},{"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":16,"sourceHtmlUrl":17,"categories":18,"keywords":27,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6JYTM3G8PPD0P23SRTWRYPQ","bug-reproducer",null,"Find likely software bugs in a codebase, rank concrete bug candidates, and prove or reject them with focused regression tests before proposing a fix. Also turn bug reports, stack traces, screenshots, failing behavior, support tickets, and regressions into minimal reproducible cases with red-to-green evidence. Use when Codex needs to hunt for unknown bugs, audit code for correctness defects, test suspicious edge cases, reproduce a reported failure, isolate root cause, or verify that an approved fix works without regressions. Honor explicit user authority for the requested fix; use approval gates only for authority that the request did not already grant or when scope materially changes. Do NOT use for ordinary implementation where no bug investigation or reproduction is needed.","AnastasiyaW\u002Fcodex-claude-code-config","AnastasiyaW","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F92753226?v=4","01M6JYPD9X5RRF8G7AH91NYD3R","Anastasiia Butova","01M6JYPDFBGM5EV8G8BABQ3GDY",214,"MIT","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002FLICENSE-upstream","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002FSKILL.md",[19,24],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000023","Skill与智能体开发",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"bug reproducer","reproducer","bug","reports","failing","when","request","authority","unknown","Bug Investigation","scope","software","green","do","screenshots","only","fix","regression","stack","audit","code","support","suspicious","2026-11-10 10:12:30",false,"---\nname: bug-reproducer\ndescription: Find likely software bugs in a codebase, rank concrete bug candidates, and prove or reject them with focused regression tests before proposing a fix. Also turn bug reports, stack traces, screenshots, failing behavior, support tickets, and regressions into minimal reproducible cases with red-to-green evidence. Use when Codex needs to hunt for unknown bugs, audit code for correctness defects, test suspicious edge cases, reproduce a reported failure, isolate root cause, or verify that an approved fix works without regressions. Honor explicit user authority for the requested fix; use approval gates only for authority that the request did not already grant or when scope materially changes. Do NOT use for ordinary implementation where no bug investigation or reproduction is needed.\n---\n\n# Bug Reproducer\n\nTurn a codebase or bug report into evidence. When no bug is supplied, discover concrete candidates from the code and its contracts, then try to prove the strongest candidates with focused tests. Never present a suspicion as a confirmed bug.\n\n## Honor existing authority, then apply missing gates\n\nInvocation alone to hunt for unknown bugs is inspection-only. A direct request to fix or implement a reported bug, or to `find and fix` bugs in a named repository, authorizes the normal reversible reproduction tests and causal production edits inside that stated task. A direct request to reproduce a reported bug or create its regression test likewise authorizes the normal reversible reproduction files and commands, but not a production repair. Record the matching task scope and proceed without stopping for duplicate confirmation, even when the exact responsible file is learned during diagnosis. Do not ask the user to approve the same scope twice.\n\nIf the user asked only to inspect, audit, find, or isolate, do not infer permission to create reproduction files or change production code. A direct reproduction or regression-test request authorizes only the normal reversible reproduction work described above; it does not authorize a production repair. Before a gate that has not been satisfied, do not create or edit project files, install dependencies, run formatters or migrations, modify configuration, generate reports, create worktrees, or execute commands likely to mutate project state. Read source, configuration, documentation, existing tests, user-supplied logs, and Git history. Run an existing targeted test only when it is clearly safe and does not require project changes.\n\n### Gate 1 — test the candidate\n\nWhen the current request has not explicitly authorized creating and running a reproducer, present and stop at:\n\n```markdown\n## Bug candidates\n\n| # | Candidate | Contract evidence | Trigger | Location | Confidence |\n|---|---|---|---|---|---|\n| 1 | ... | ... | ... | file:line | high\u002Fmedium |\n\n## Proposed bug test\n\n- Candidate(s) to test:\n- Why each could be a real bug:\n- Exact files to create or edit:\n- Minimal fixture\u002Finput:\n- Test or harness command:\n- Signal that will confirm each bug:\n- Main risk or uncertainty:\n\nNo project files have been modified. Do you want me to create and run these tests?\n```\n\nList only candidates backed by a reachable code path, a defensible expected behavior, and a specific triggering input or state. Approval covers only the displayed reproduction files and commands. A direct request to reproduce a supplied symptom or write its regression test already satisfies this gate: record that scope and continue without requiring file names that diagnosis has not yet established. Test one strong candidate by default; batch at most three only when their files and commands are all explicit.\n\n### Gate 2 — fix a proven bug\n\nWhen the current request has not already authorized a causal production repair, present and stop at:\n\n```markdown\n## Proposed fix\n\n- Reproduction status: REPRODUCED\n- Proven bug:\n- Root cause:\n- Exact production files to change:\n- Proposed transformation:\n- Behavior that must remain identical:\n- Regression and broader test plan:\n- Main risk:\n\nThe bug is proven by a failing test, but no production fix has been applied. Do you want me to apply this exact fix?\n```\n\nContinue when the current request already covers the causal repair or after explicit approval. If the file list, dependencies, public behavior, risk tier, or approach materially changes beyond that authority, request fresh approval. Never bundle unrelated cleanup or another fix into the approved patch.\n\n## Choose the workflow\n\n- `hunt-and-prove` — Default when no specific bug is supplied. Discover, rank, and test likely correctness bugs.\n- `reproduce-only` — Stop after a minimal failing case is proven. Use when the user asks only to find, reproduce, isolate, or write regression tests.\n- `prove-fix` — Use for a reported bug or after a discovered candidate is proven and the user wants it fixed. Apply only gates not already satisfied by the current request, then prove red to green.\n- `flaky` — Reproduce timing, ordering, seed, isolation, or concurrency-dependent failures across repeated controlled runs. Do not label one intermittent failure as reproduced.\n\n## Run hunt-and-prove\n\n### 1. Map the project read-only\n\n- Identify runtime, entry points, public interfaces, data boundaries, test framework, existing commands, and high-change or high-risk modules.\n- Derive intended behavior from tests, types, schemas, documentation, callers, UI copy, API contracts, and invariants. Prefer explicit contracts over personal style preferences.\n- Inspect recent changes only when repository history is available; do not assume old code is correct.\n- Read `references\u002Fbug-discovery-playbook.md` before ranking candidates.\n\n### 2. Generate concrete candidates\n\n- Trace user-controlled or boundary inputs through real reachable paths.\n- Look for falsifiable defects: off-by-one boundaries, inverted conditions, missing empty\u002Fnull handling, unsafe state transitions, ordering or deduplication errors, stale cache keys, permission gaps, precision\u002Ftime-zone mistakes, async races, inconsistent validation, and error paths that violate the surrounding contract.\n- For every candidate, identify the exact path, triggering input\u002Fstate, expected result, likely actual result, and evidence for the expectation.\n- Reject vague possibilities such as “this could be null” unless the codebase permits null and the path mishandles it.\n- Do not call security posture, performance, formatting, maintainability, or missing features a bug unless they violate a concrete product contract.\n\n### 3. Rank before testing\n\nRank candidates using:\n\n1. Contract strength — Is expected behavior explicit in tests, types, docs, schemas, callers, or consistent nearby behavior?\n2. Reachability — Can a real caller or valid input reach the path?\n3. Reproducibility — Can a small deterministic test distinguish correct from incorrect behavior?\n4. Impact — Does it affect outputs, data, permissions, crashes, or a user-visible workflow?\n\nShow no more than five candidates and label confidence `high`, `medium`, or `low`. Do not propose testing low-confidence candidates while a stronger one exists. If no candidate survives this filter, return `NO_BUG_PROVEN` and identify the next useful evidence instead of inventing a bug.\n\n### 4. Resolve Gate 1 authority\n\n- If the request explicitly asked to reproduce a supplied symptom, create a regression test, or otherwise authorized reproduction work, record the matching task scope and continue. Do not require exact file names before diagnosis establishes them.\n- Otherwise show the ranked shortlist and exact test plan for the strongest one to three candidates.\n- Name every file and command that approval would cover.\n- State that no project files have been modified, then stop and wait.\n\n### 5. Test approved candidates\n\n- Create only the approved test or harness.\n- Use deterministic inputs and the smallest fixture that reaches the real production path.\n- Assert the intended contract, not the current implementation.\n- Capture the narrow command with `scripts\u002Fcapture_command.py` when appropriate:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcapture_command.py\" --label reproduced --output reproduced.json -- npm test -- path\u002Fto\u002Fregression.test.ts\n```\n\n- Confirm that a failure matches the predicted behavior and cause. Syntax errors, missing dependencies, invalid fixtures, unrelated failures, and assertions built on an unsupported assumption reject or invalidate the candidate.\n- Return `REPRODUCED`, `NOT_REPRODUCED`, or `INCONCLUSIVE` for each tested candidate. Clearly separate rejected speculative tests by default. Delete them only with explicit user authority.\n- Stop after evidence when the user requested discovery or reproduction only. Do not slide into production changes.\n\n### 6. Isolate and resolve Gate 2 authority\n\n- Trace a reproduced failure to the smallest responsible condition and distinguish root cause from the line where it surfaces.\n- If the current request already authorized the causal fix, record how the patch remains inside it and continue.\n- Otherwise show Gate 2 with exact production files, transformation, preserved behavior, checks, and risk, then stop and wait for separate approval.\n\n### 7. Apply only the approved fix\n\n- Preserve the regression test unless the user explicitly requests a temporary harness.\n- Change only the approved production files and necessary test expectations.\n- Prefer the smallest causal fix over symptom suppression.\n- Do not weaken assertions, catch and ignore errors, add arbitrary retries, disable tests, or broaden tolerances merely to turn the test green.\n\n### 8. Prove red to green\n\n- Run the exact same targeted command used for failing evidence.\n- Run the narrowest additional check that meaningfully covers the changed behavior and its integration boundary. Escalate to a broader relevant suite, typecheck, lint, or build when the change's risk or contract requires it; record the selected scope and any unavailable or disproportionate checks as limitations.\n- Capture and classify the fixed run:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcapture_command.py\" --label fixed --output fixed.json -- npm test -- path\u002Fto\u002Fregression.test.ts\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcapture_command.py\" --label relevant-check --output relevant-check.json -- npm test -- path\u002Fto\u002Faffected-area\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcompare_evidence.py\" reproduced.json fixed.json result.json --reproduction confirmed --relevant-evidence relevant-check.json\n```\n\nWhen the exact targeted reproducer is genuinely the only proportionate relevant check, do not reuse `fixed.json` as `--relevant-evidence` or pretend an additional command ran. Record that boundary explicitly instead:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcompare_evidence.py\" reproduced.json fixed.json result.json --reproduction confirmed --targeted-scope-sufficient --scope-rationale \"Pure function; no additional integration boundary exists.\"\n```\n\n- Classify a passing targeted test with a failing captured relevant check as `FIX_REGRESSION`.\n- Classify a passing targeted test with a reused targeted receipt presented as an additional check as `FIX_UNVERIFIED`.\n- Classify a passing targeted test without a captured proportionate relevant check as `FIX_UNVERIFIED`, unless the project genuinely has no additional meaningful check and `--targeted-scope-sufficient` records the explicit rationale.\n\n## Handle an existing bug report\n\nWhen the user supplies a symptom, error, screenshot, stack trace, or failing behavior:\n\n1. Restate expected behavior, actual behavior, trigger, environment, frequency, and last-known-good version.\n2. Separate observed facts from assumptions and remove secrets or personal data.\n3. Map the report to likely paths and existing test conventions.\n4. Skip broad discovery; preserve reproduction integrity and red-to-green proof, but do not repeat Gate 1 or Gate 2 when the reported-bug fix request already satisfies them.\n5. Read `references\u002Freproduction-playbook.md` when selecting the smallest credible layer.\n\n## Use evidence labels precisely\n\n- `REPRODUCED` — A focused case fails deterministically for the predicted or reported reason.\n- `NOT_REPRODUCED` — The approved case does not produce the predicted failure.\n- `NO_BUG_PROVEN` — Read-only discovery or approved candidate tests did not prove a correctness defect.\n- `INCONCLUSIVE` — Environment, nondeterminism, missing access, or ambiguous signals prevent a conclusion.\n- `STILL_FAILING` — The same reproducer continues to fail after an attempted fix.\n- `FIX_UNVERIFIED` — The reproducer passes, but proportionate correctness evidence or an explicit targeted-only scope rationale is missing.\n- `FIX_REGRESSION` — The reproducer passes or changes, but a captured relevant correctness check fails.\n- `FIX_PROVEN` — The same reproducer goes red to green and either a captured additional proportionate relevant check passes or targeted-only scope is explicitly justified.\n\nNever claim a bug from code inspection alone. Never claim a fix without red-to-green evidence.\n\n## Create the native report\n\nCreate a native report only when the user requests one or the repository requires one. Use the existing project evidence or audit location specified by the user or repository; do not create a generic `outputs\u002F` directory. Prepare context JSON following `references\u002Freport-schema.md`, including discovery scope and ranked candidates when using `hunt-and-prove`, then run:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fgenerate_report.py\" result.json context.json path\u002Fto\u002Fexisting-evidence-location\u002Fbug-reproducer-report.md\n```\n\nInclude discovery evidence, tested candidates, minimal reproduction, root cause, approvals and scope, changed files, red\u002Fgreen commands, broader checks, limitations, and residual risks. Link the Markdown report in the final response.\n\n## Hand off\n\nLead with the strongest evidence label, then report:\n\n1. Scope inspected and candidates considered\n2. Candidate tests and outcomes\n3. What reproduced and why the failure is credible\n4. Root cause, if proven\n5. Approved fix and red-to-green evidence, if requested\n6. Broader checks, limitations, and residual risk\n7. Link to the report when one was requested\n\nIf no bug is proven, preserve the project and say so plainly. A clean hunt is evidence about the inspected scope, not proof that the entire codebase has no bugs.\n\n## Local operating rules\n\n- On Windows, prefer an explicit verified Python executable in capture commands\n  when the `python` launcher is slow or resolves to a store shim. Record the\n  runtime in the evidence JSON.\n- Treat `--reproduction confirmed` as operator input, not independent proof.\n  `compare_evidence.py` accepts an additional passing check only through a\n  captured `--relevant-evidence` receipt that is distinct from the targeted\n  reproducer. If the targeted reproducer is sufficient, declare that scope and\n  rationale explicitly. The agent or a fresh verifier must inspect the captured\n  commands, exit codes, output, and relevant-check scope before accepting the\n  status.\n- Do not use the upstream installer when the destination may already exist: it\n  force-removes the destination. A backup does not authorize that removal.\n  Install only into an absent destination; request explicit replacement or\n  deletion authority before touching an existing one, then verify the resulting\n  file list.\n\n## Gotchas\n\n- A passing focused test before a fix means `NOT_REPRODUCED`, even if the code\n  looks suspicious.\n- A syntax error, missing dependency, invalid fixture, or unrelated failing\n  suite invalidates the reproduction; it is not a product bug.\n- A clean hunt covers only the inspected scope. It never proves that the whole\n  repository is bug-free.\n- `compare_evidence.py` classifies recorded receipts and declared scope; it does\n  not prove causal root cause, independently run the relevant check, or decide\n  whether targeted-only scope is actually sufficient.\n\n## Troubleshooting\n\n- **capture command hangs on Windows**: replace the launcher with the explicit\n  verified Python executable, reduce the timeout, and rerun the same command.\n- **FIX_UNVERIFIED**: run and capture the proportionate relevant check, or\n  explicitly record why the targeted reproducer is sufficient; do not upgrade\n  the label by hand.\n- **INCONCLUSIVE**: check that before and after commands are byte-for-byte the\n  same and that the failure signal matches the predicted assertion.\n","# Bug Reproducer\n\nTurn a codebase or bug report into evidence. When no bug is supplied, discover concrete candidates from the code and its contracts, then try to prove the strongest candidates with focused tests. Never present a suspicion as a confirmed bug.\n\n## Honor existing authority, then apply missing gates\n\nInvocation alone to hunt for unknown bugs is inspection-only. A direct request to fix or implement a reported bug, or to `find and fix` bugs in a named repository, authorizes the normal reversible reproduction tests and causal production edits inside that stated task. A direct request to reproduce a reported bug or create its regression test likewise authorizes the normal reversible reproduction files and commands, but not a production repair. Record the matching task scope and proceed without stopping for duplicate confirmation, even when the exact responsible file is learned during diagnosis. Do not ask the user to approve the same scope twice.\n\nIf the user asked only to inspect, audit, find, or isolate, do not infer permission to create reproduction files or change production code. A direct reproduction or regression-test request authorizes only the normal reversible reproduction work described above; it does not authorize a production repair. Before a gate that has not been satisfied, do not create or edit project files, install dependencies, run formatters or migrations, modify configuration, generate reports, create worktrees, or execute commands likely to mutate project state. Read source, configuration, documentation, existing tests, user-supplied logs, and Git history. Run an existing targeted test only when it is clearly safe and does not require project changes.\n\n### Gate 1 — test the candidate\n\nWhen the current request has not explicitly authorized creating and running a reproducer, present and stop at:\n\n```markdown\n## Bug candidates\n\n| # | Candidate | Contract evidence | Trigger | Location | Confidence |\n|---|---|---|---|---|---|\n| 1 | ... | ... | ... | file:line | high\u002Fmedium |\n\n## Proposed bug test\n\n- Candidate(s) to test:\n- Why each could be a real bug:\n- Exact files to create or edit:\n- Minimal fixture\u002Finput:\n- Test or harness command:\n- Signal that will confirm each bug:\n- Main risk or uncertainty:\n\nNo project files have been modified. Do you want me to create and run these tests?\n```\n\nList only candidates backed by a reachable code path, a defensible expected behavior, and a specific triggering input or state. Approval covers only the displayed reproduction files and commands. A direct request to reproduce a supplied symptom or write its regression test already satisfies this gate: record that scope and continue without requiring file names that diagnosis has not yet established. Test one strong candidate by default; batch at most three only when their files and commands are all explicit.\n\n### Gate 2 — fix a proven bug\n\nWhen the current request has not already authorized a causal production repair, present and stop at:\n\n```markdown\n## Proposed fix\n\n- Reproduction status: REPRODUCED\n- Proven bug:\n- Root cause:\n- Exact production files to change:\n- Proposed transformation:\n- Behavior that must remain identical:\n- Regression and broader test plan:\n- Main risk:\n\nThe bug is proven by a failing test, but no production fix has been applied. Do you want me to apply this exact fix?\n```\n\nContinue when the current request already covers the causal repair or after explicit approval. If the file list, dependencies, public behavior, risk tier, or approach materially changes beyond that authority, request fresh approval. Never bundle unrelated cleanup or another fix into the approved patch.\n\n## Choose the workflow\n\n- `hunt-and-prove` — Default when no specific bug is supplied. Discover, rank, and test likely correctness bugs.\n- `reproduce-only` — Stop after a minimal failing case is proven. Use when the user asks only to find, reproduce, isolate, or write regression tests.\n- `prove-fix` — Use for a reported bug or after a discovered candidate is proven and the user wants it fixed. Apply only gates not already satisfied by the current request, then prove red to green.\n- `flaky` — Reproduce timing, ordering, seed, isolation, or concurrency-dependent failures across repeated controlled runs. Do not label one intermittent failure as reproduced.\n\n## Run hunt-and-prove\n\n### 1. Map the project read-only\n\n- Identify runtime, entry points, public interfaces, data boundaries, test framework, existing commands, and high-change or high-risk modules.\n- Derive intended behavior from tests, types, schemas, documentation, callers, UI copy, API contracts, and invariants. Prefer explicit contracts over personal style preferences.\n- Inspect recent changes only when repository history is available; do not assume old code is correct.\n- Read `references\u002Fbug-discovery-playbook.md` before ranking candidates.\n\n### 2. Generate concrete candidates\n\n- Trace user-controlled or boundary inputs through real reachable paths.\n- Look for falsifiable defects: off-by-one boundaries, inverted conditions, missing empty\u002Fnull handling, unsafe state transitions, ordering or deduplication errors, stale cache keys, permission gaps, precision\u002Ftime-zone mistakes, async races, inconsistent validation, and error paths that violate the surrounding contract.\n- For every candidate, identify the exact path, triggering input\u002Fstate, expected result, likely actual result, and evidence for the expectation.\n- Reject vague possibilities such as “this could be null” unless the codebase permits null and the path mishandles it.\n- Do not call security posture, performance, formatting, maintainability, or missing features a bug unless they violate a concrete product contract.\n\n### 3. Rank before testing\n\nRank candidates using:\n\n1. Contract strength — Is expected behavior explicit in tests, types, docs, schemas, callers, or consistent nearby behavior?\n2. Reachability — Can a real caller or valid input reach the path?\n3. Reproducibility — Can a small deterministic test distinguish correct from incorrect behavior?\n4. Impact — Does it affect outputs, data, permissions, crashes, or a user-visible workflow?\n\nShow no more than five candidates and label confidence `high`, `medium`, or `low`. Do not propose testing low-confidence candidates while a stronger one exists. If no candidate survives this filter, return `NO_BUG_PROVEN` and identify the next useful evidence instead of inventing a bug.\n\n### 4. Resolve Gate 1 authority\n\n- If the request explicitly asked to reproduce a supplied symptom, create a regression test, or otherwise authorized reproduction work, record the matching task scope and continue. Do not require exact file names before diagnosis establishes them.\n- Otherwise show the ranked shortlist and exact test plan for the strongest one to three candidates.\n- Name every file and command that approval would cover.\n- State that no project files have been modified, then stop and wait.\n\n### 5. Test approved candidates\n\n- Create only the approved test or harness.\n- Use deterministic inputs and the smallest fixture that reaches the real production path.\n- Assert the intended contract, not the current implementation.\n- Capture the narrow command with `scripts\u002Fcapture_command.py` when appropriate:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcapture_command.py\" --label reproduced --output reproduced.json -- npm test -- path\u002Fto\u002Fregression.test.ts\n```\n\n- Confirm that a failure matches the predicted behavior and cause. Syntax errors, missing dependencies, invalid fixtures, unrelated failures, and assertions built on an unsupported assumption reject or invalidate the candidate.\n- Return `REPRODUCED`, `NOT_REPRODUCED`, or `INCONCLUSIVE` for each tested candidate. Clearly separate rejected speculative tests by default. Delete them only with explicit user authority.\n- Stop after evidence when the user requested discovery or reproduction only. Do not slide into production changes.\n\n### 6. Isolate and resolve Gate 2 authority\n\n- Trace a reproduced failure to the smallest responsible condition and distinguish root cause from the line where it surfaces.\n- If the current request already authorized the causal fix, record how the patch remains inside it and continue.\n- Otherwise show Gate 2 with exact production files, transformation, preserved behavior, checks, and risk, then stop and wait for separate approval.\n\n### 7. Apply only the approved fix\n\n- Preserve the regression test unless the user explicitly requests a temporary harness.\n- Change only the approved production files and necessary test expectations.\n- Prefer the smallest causal fix over symptom suppression.\n- Do not weaken assertions, catch and ignore errors, add arbitrary retries, disable tests, or broaden tolerances merely to turn the test green.\n\n### 8. Prove red to green\n\n- Run the exact same targeted command used for failing evidence.\n- Run the narrowest additional check that meaningfully covers the changed behavior and its integration boundary. Escalate to a broader relevant suite, typecheck, lint, or build when the change's risk or contract requires it; record the selected scope and any unavailable or disproportionate checks as limitations.\n- Capture and classify the fixed run:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcapture_command.py\" --label fixed --output fixed.json -- npm test -- path\u002Fto\u002Fregression.test.ts\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcapture_command.py\" --label relevant-check --output relevant-check.json -- npm test -- path\u002Fto\u002Faffected-area\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcompare_evidence.py\" reproduced.json fixed.json result.json --reproduction confirmed --relevant-evidence relevant-check.json\n```\n\nWhen the exact targeted reproducer is genuinely the only proportionate relevant check, do not reuse `fixed.json` as `--relevant-evidence` or pretend an additional command ran. Record that boundary explicitly instead:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fcompare_evidence.py\" reproduced.json fixed.json result.json --reproduction confirmed --targeted-scope-sufficient --scope-rationale \"Pure function; no additional integration boundary exists.\"\n```\n\n- Classify a passing targeted test with a failing captured relevant check as `FIX_REGRESSION`.\n- Classify a passing targeted test with a reused targeted receipt presented as an additional check as `FIX_UNVERIFIED`.\n- Classify a passing targeted test without a captured proportionate relevant check as `FIX_UNVERIFIED`, unless the project genuinely has no additional meaningful check and `--targeted-scope-sufficient` records the explicit rationale.\n\n## Handle an existing bug report\n\nWhen the user supplies a symptom, error, screenshot, stack trace, or failing behavior:\n\n1. Restate expected behavior, actual behavior, trigger, environment, frequency, and last-known-good version.\n2. Separate observed facts from assumptions and remove secrets or personal data.\n3. Map the report to likely paths and existing test conventions.\n4. Skip broad discovery; preserve reproduction integrity and red-to-green proof, but do not repeat Gate 1 or Gate 2 when the reported-bug fix request already satisfies them.\n5. Read `references\u002Freproduction-playbook.md` when selecting the smallest credible layer.\n\n## Use evidence labels precisely\n\n- `REPRODUCED` — A focused case fails deterministically for the predicted or reported reason.\n- `NOT_REPRODUCED` — The approved case does not produce the predicted failure.\n- `NO_BUG_PROVEN` — Read-only discovery or approved candidate tests did not prove a correctness defect.\n- `INCONCLUSIVE` — Environment, nondeterminism, missing access, or ambiguous signals prevent a conclusion.\n- `STILL_FAILING` — The same reproducer continues to fail after an attempted fix.\n- `FIX_UNVERIFIED` — The reproducer passes, but proportionate correctness evidence or an explicit targeted-only scope rationale is missing.\n- `FIX_REGRESSION` — The reproducer passes or changes, but a captured relevant correctness check fails.\n- `FIX_PROVEN` — The same reproducer goes red to green and either a captured additional proportionate relevant check passes or targeted-only scope is explicitly justified.\n\nNever claim a bug from code inspection alone. Never claim a fix without red-to-green evidence.\n\n## Create the native report\n\nCreate a native report only when the user requests one or the repository requires one. Use the existing project evidence or audit location specified by the user or repository; do not create a generic `outputs\u002F` directory. Prepare context JSON following `references\u002Freport-schema.md`, including discovery scope and ranked candidates when using `hunt-and-prove`, then run:\n\n```bash\npython3 \"${CLAUDE_SKILL_DIR}\u002Fscripts\u002Fgenerate_report.py\" result.json context.json path\u002Fto\u002Fexisting-evidence-location\u002Fbug-reproducer-report.md\n```\n\nInclude discovery evidence, tested candidates, minimal reproduction, root cause, approvals and scope, changed files, red\u002Fgreen commands, broader checks, limitations, and residual risks. Link the Markdown report in the final response.\n\n## Hand off\n\nLead with the strongest evidence label, then report:\n\n1. Scope inspected and candidates considered\n2. Candidate tests and outcomes\n3. What reproduced and why the failure is credible\n4. Root cause, if proven\n5. Approved fix and red-to-green evidence, if requested\n6. Broader checks, limitations, and residual risk\n7. Link to the report when one was requested\n\nIf no bug is proven, preserve the project and say so plainly. A clean hunt is evidence about the inspected scope, not proof that the entire codebase has no bugs.\n\n## Local operating rules\n\n- On Windows, prefer an explicit verified Python executable in capture commands\n  when the `python` launcher is slow or resolves to a store shim. Record the\n  runtime in the evidence JSON.\n- Treat `--reproduction confirmed` as operator input, not independent proof.\n  `compare_evidence.py` accepts an additional passing check only through a\n  captured `--relevant-evidence` receipt that is distinct from the targeted\n  reproducer. If the targeted reproducer is sufficient, declare that scope and\n  rationale explicitly. The agent or a fresh verifier must inspect the captured\n  commands, exit codes, output, and relevant-check scope before accepting the\n  status.\n- Do not use the upstream installer when the destination may already exist: it\n  force-removes the destination. A backup does not authorize that removal.\n  Install only into an absent destination; request explicit replacement or\n  deletion authority before touching an existing one, then verify the resulting\n  file list.\n\n## Gotchas\n\n- A passing focused test before a fix means `NOT_REPRODUCED`, even if the code\n  looks suspicious.\n- A syntax error, missing dependency, invalid fixture, or unrelated failing\n  suite invalidates the reproduction; it is not a product bug.\n- A clean hunt covers only the inspected scope. It never proves that the whole\n  repository is bug-free.\n- `compare_evidence.py` classifies recorded receipts and declared scope; it does\n  not prove causal root cause, independently run the relevant check, or decide\n  whether targeted-only scope is actually sufficient.\n\n## Troubleshooting\n\n- **capture command hangs on Windows**: replace the launcher with the explicit\n  verified Python executable, reduce the timeout, and rerun the same command.\n- **FIX_UNVERIFIED**: run and capture the proportionate relevant check, or\n  explicitly record why the targeted reproducer is sufficient; do not upgrade\n  the label by hand.\n- **INCONCLUSIVE**: check that before and after commands are byte-for-byte the\n  same and that the failure signal matches the predicted assertion.\n",{"name":5,"description":7},"main","ac20f93f36e574610dbc51743bb21e7765142e95","skills\u002Fdevelopment\u002Fbug-reproducer",32,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config","https:\u002F\u002Fgithub.com\u002FAnastasiyaW","https:\u002F\u002Fhappyin.work","ComfyUI specialist · turnkey image-processing pipelines · diffusion models, computer vision · Belgrade","2026-11-14 01:35:49",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill bug-reproducer",{"tool":71,"command":72},"bunx","bunx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill bug-reproducer",{"tool":74,"command":75},"pnpm","pnpm dlx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill bug-reproducer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002FSKILL.md",true,[79,85,89,94,98,102,106,112,116,120],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"agents\u002Fopenai.yaml","REFERENCE","参考文档",388,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002Fagents\u002Fopenai.yaml",{"path":86,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":87,"sourceHtmlUrl":88},"ATTRIBUTION.md",958,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002FATTRIBUTION.md",{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":16},"LICENSE-upstream","LICENSE","许可证",1074,{"path":95,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fbug-discovery-playbook.md",3671,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002Freferences\u002Fbug-discovery-playbook.md",{"path":99,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Freport-schema.md",2392,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002Freferences\u002Freport-schema.md",{"path":103,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Freproduction-playbook.md",2612,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002Freferences\u002Freproduction-playbook.md",{"path":107,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":110,"sourceHtmlUrl":111},"scripts\u002Fcapture_command.py","SCRIPT","脚本",3964,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002Fscripts\u002Fcapture_command.py",{"path":113,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":114,"sourceHtmlUrl":115},"scripts\u002Fcompare_evidence.py",5846,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002Fscripts\u002Fcompare_evidence.py",{"path":117,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":118,"sourceHtmlUrl":119},"scripts\u002Fgenerate_report.py",9207,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002Fscripts\u002Fgenerate_report.py",{"path":121,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":122,"sourceHtmlUrl":123},"scripts\u002Ftest_compare_evidence.py",9672,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fbug-reproducer\u002Fscripts\u002Ftest_compare_evidence.py",[125,134,150,176,202,220],{"skillNo":126,"name":127,"nameZh":6,"description":6,"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":131,"publishedAt":51},"01M6JZ2SNGKFN8NK3HZBMVGQP1","owner-voice","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fowner-voice\u002FSKILL.md",[130],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},[132,133],"owner voice","voice",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":51},"01M6JZ2N0C2WFCAK6T8N3RMBVS","humanize-russian","Редактировать русский текст для ясности и естественного звучания, сохраняя факты,\nтермины, источники и жанр. Использовать когда: убрать канцелярит, сделать текст\nживее, отредактировать русский черновик или статью перед публикацией.\nНе определяет авторство и не обещает обход детекторов. Для английского —\nhumanize-english; для структуры и доказательств — article-structure-review.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fhumanize-russian\u002FSKILL.md",[140],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},[142,143,144,145,146,147,148,149],"russian","humanize","humanize russian","english","review","structure","article","2026",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":51},"01M6JZ2GN264R6GKBQ5QVZE0ZS","humanize-english","Edit English drafts for clear, natural language while preserving facts, uncertainty,\ntechnical meaning, citations and genre. Use when: humanize this text, remove AI-style\nfiller, improve English prose, or edit an English article before publication.\nNot an authorship detector or a promise to bypass one. For Russian use\nhumanize-russian; for thesis\u002Fevidence and structure use article-structure-review.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fhumanize-english\u002FSKILL.md",[],[143,145,157,158,142,159,160,161,162,147,163,164,165,146,166,149,33,167,168,169,170,171,172,173,148,174,175],"humanize english","technical","evidence","use","remove","edit","text","improve","Citations","Publication","for","facts","natural language","drafts","meaning","uncertainty","style","thesis","promise",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":51},"01M6JZ2BM31D5Y609DQJJJM6MM","caveman","Ultra-compressed reply mode. Cuts output tokens ~65-75% by answering in terse \"caveman\" style while keeping full technical accuracy, and shapes what survives: action first, state restated every turn, concrete time estimates, visible wins. Intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says \"caveman\", \"talk like caveman\", \"use caveman\", \"less tokens\", \"be brief\", or Russian \"пещерный режим\", \"говори как пещерный\", \"кратко\", \"меньше токенов\", \"экономь токены\" — or invokes \u002Fcaveman. Preserves the user's language (Russian in → Russian caveman out). Off only: \"stop caveman\" \u002F \"normal mode\" \u002F \"обычный режим\". Do not use merely because a response should be concise, and do not use when the user requests normal prose, a polished document, or exact wording.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fcaveman\u002FSKILL.md",[],[178,173,33,183,184,185,186,187,188,189,190,191,192,193,194,195,41,142,196,197,198,43,160,158,199,200,201],"normal","terse","accuracy","ultra","mode","document","requests","concise","output","intensity","tokens","full","time","action","default","stop","first","brief","state",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":217,"publishedAt":51},"01M6JZ25Y5GJXFKXNR6TRQX237","article-structure-review","Проверить структуру технической статьи после черновика: задача читателя, жанр,\nопора значимых утверждений на доказательства и честные ограничения.\nUse after the first draft, before publication. Исправлять структуру, когда это\nвходит в запрос; не создавать обязательный конвейер из других навыков.\nДля локальной языковой редактуры — humanize-english или humanize-russian.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Farticle-structure-review\u002FSKILL.md",[208,211,212],{"categoryNo":209,"categoryName":210,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},{"categoryNo":213,"categoryName":214,"taxonomyType":215,"taxonomyTypeDesc":216},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[218,148,147,146,219,143,142,160,199,145,166,149],"article structure review","draft",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":229,"publishedAt":51},"01M6JZ1XN7WQQCWCHHMTTD8K28","video-post-production","Video post-production rules: audio mastering, color, captions, platform export. Use when: 'add music', 'add voiceover', 'export for tiktok', 'add captions', 'color grade', 'audio levels', 'master audio', 'export settings', 'platform requirements'. Covers FFmpeg patterns, audio chain, subtitle standards, and platform-specific export configs. Do NOT use to generate or animate the video frames\u002Fscenes in code (use remotion-production-guide), to write the script (use video-narrative-arc), or to evaluate script quality (use script-evaluator); this is the finishing stage applied to an already-rendered video.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fvideo-production\u002Fvideo-post-production\u002FSKILL.md",[226],{"categoryNo":227,"categoryName":228,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000016","图像与多媒体",[230,231,232,233,234,33,235,236,237,238,239,240,241,242,243,244,245,246,247,48,248],"video post production","post","Production","Video","patterns","post-production","narrative","add","chain","tiktok","voiceover","master","export","write","music","Captions","Audio","Remotion","generate"]