[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C3ASE3N472TYC8YBEEB03F":3,"skill-same:01M6C3ASE3N472TYC8YBEEB03F":67},{"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":23,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6C3ASE3N472TYC8YBEEB03F","speckit-bug-test",null,"Validate that a previously fixed bug is resolved and record the verification report","IgorGanapolsky\u002FRandom-Timer","IgorGanapolsky","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F201209?v=4","01M6C2WB7720K13ERYVB3AJ0SQ","Igor Ganapolsky","01M6C2WBBF0NWVQV4A89FS00Q5",1,"MIT","https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer\u002Fblob\u002Fdevelop\u002F.cursor\u002Fskills\u002Fspeckit-bug-test\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33],"test","speckit bug test","directory","spec","project structure","validate","core","report","verification","specify","2026-11-10 10:12:30",false,"---\nname: speckit-bug-test\ndescription: Validate that a previously fixed bug is resolved and record the verification report\ncompatibility: Requires spec-kit project structure with .specify\u002F directory\nmetadata:\n  author: spec-kit-core\n  source: bug:commands\u002Fspeckit.bug.test.md\n---\n\n# Test Bug Fix\n\nValidate that the fix recorded by `\u002Fspeckit-bug-fix` actually resolves the bug described by `\u002Fspeckit-bug-assess`. The output is a verification report at `.specify\u002Fbugs\u002F\u003Cslug>\u002Ftest.md`.\n\n## User Input\n\n```text\n$ARGUMENTS\n```\n\nThe user input should identify the bug to validate. Accept any of:\n\n- `slug=\u003Cbug-slug>` or `--slug \u003Cbug-slug>` or a bare slug-like token.\n- A path that contains the slug (e.g. `.specify\u002Fbugs\u002Flogin-timeout\u002F`).\n- **Nothing** — fall back to context (see below).\n\n## Slug Resolution\n\nResolve `BUG_SLUG` in this order, stopping at the first match:\n\n1. **Explicit user input** — a slug passed in `$ARGUMENTS` (any of the forms above).\n2. **Conversation context** — if the current session has just run `\u002Fspeckit-bug-assess` or `\u002Fspeckit-bug-fix`, the slug it reported is the working slug. Reuse it without re-prompting. Confirm it by checking that `.specify\u002Fbugs\u002F\u003Cslug>\u002Ffix.md` exists; if it does not, fall through.\n3. **Single candidate on disk** — list `.specify\u002Fbugs\u002F*\u002Ffix.md`. If exactly one bug has a `fix.md`, use it.\n4. **Disambiguate**:\n   - **Interactive mode**: ask the user which bug to validate and list the candidates.\n   - **Automated mode**: stop with an error listing the candidates. Do not guess.\n\nOnce resolved, set `BUG_SLUG` and `BUG_DIR = .specify\u002Fbugs\u002F\u003CBUG_SLUG>`, and briefly state in your reply which resolution path was used (explicit \u002F from context \u002F single candidate \u002F asked).\n\n## Prerequisites\n\n- `BUG_DIR\u002Fassessment.md` MUST exist.\n- `BUG_DIR\u002Ffix.md` MUST exist. If not, stop and instruct the user to run `\u002Fspeckit-bug-fix` first.\n- If `BUG_DIR\u002Ftest.md` already exists, ask the user whether to overwrite it (interactive mode) or refuse (automated mode).\n- Read both `assessment.md` and `fix.md` in full so you know:\n  - The original symptom and reproduction steps (from `assessment.md`).\n  - The actual code changes and tests added (from `fix.md`).\n\n## Execution\n\n1. **Plan the validation**\n   - Decide which checks prove the bug is gone:\n     - Re-run the reproduction steps from the assessment (or their automated equivalent).\n     - Run the tests added or updated in the fix.\n     - Run any broader regression suite that touches the changed files.\n   - Decide which checks prove nothing was broken:\n     - Existing test suites for the changed modules.\n     - Lint \u002F type-check if the project uses them.\n\n2. **Run the checks**\n   - Execute each planned check. Capture command, exit status, and a short excerpt of relevant output (last few lines, or the failing assertion).\n   - If a check is destructive, network-dependent, or expensive, skip it and record it as `skipped` with a reason; do not run it without explicit user consent.\n   - If you cannot run a check at all (missing tooling, no test framework configured), record it as `not-run` with a reason instead of fabricating a result.\n\n3. **Judge the outcome**\n   - Mark the fix as:\n     - **verified** — all critical checks pass and the original symptom no longer reproduces.\n     - **partial** — the original symptom is gone but unrelated regressions appeared, or some checks are inconclusive.\n     - **failed** — the symptom still reproduces or the regression suite is broken by the fix.\n   - Do not over-claim. If reproduction was not actually performed (e.g., the bug required a production environment), say so explicitly.\n\n4. **Write the verification report**\n\n   Write to `BUG_DIR\u002Ftest.md` using this structure:\n\n   ```markdown\n   # Bug Verification: \u003Cshort title>\n\n   - **Slug**: \u003CBUG_SLUG>\n   - **Tested**: \u003CISO 8601 date>\n   - **Assessment**: .\u002Fassessment.md\n   - **Fix**: .\u002Ffix.md\n   - **Result**: verified | partial | failed\n\n   ## Summary\n\n   \u003COne or two sentences: does the bug reproduce, did the fix hold, were any regressions found.>\n\n   ## Checks Performed\n\n   | Check | Command \u002F Action | Result | Notes |\n   |-------|------------------|--------|-------|\n   | Reproduction (post-fix) | \u003Ccommand or manual steps> | pass \u002F fail \u002F skipped \u002F not-run | \u003Cshort note> |\n   | New \u002F updated tests | `\u003Ccommand>` | pass \u002F fail | \u003Cshort note> |\n   | Regression suite | `\u003Ccommand>` | pass \u002F fail \u002F skipped | \u003Cshort note> |\n   | Lint \u002F type-check | `\u003Ccommand>` | pass \u002F fail \u002F skipped | \u003Cshort note> |\n\n   ## Output Excerpts\n\n   \u003CShort snippets of relevant output (e.g., final summary line of a test run, the failing assertion). Keep it tight — no full logs.>\n\n   ## Residual Risks\n\n   - \u003Cknown limitation, environment not covered, etc.>\n\n   ## Recommendation\n\n   \u003COne paragraph. Examples:>\n   - \"Close the bug — verified end-to-end.\"\n   - \"Hold — reproduction inconclusive; needs verification in staging.\"\n   - \"Reopen — symptom still reproduces; rerun `\u002Fspeckit-bug-assess`.\"\n   ```\n\n5. **Report back** with:\n   - The slug and `BUG_DIR\u002Ftest.md` path.\n   - The result (`verified`, `partial`, `failed`).\n   - If the result is `failed`, recommend re-running `\u002Fspeckit-bug-assess` with the new evidence captured in `test.md`.\n\n## Guardrails\n\n- This command MUST NOT modify source code. It only runs checks and writes inside `.specify\u002Fbugs\u002F\u003Cslug>\u002F`.\n- Never overwrite an existing `test.md` without confirmation.\n- Never mark a fix as `verified` based on tests alone if the original assessment listed a reproduction that you did not actually exercise — downgrade to `partial` and say so.","# Test Bug Fix\n\nValidate that the fix recorded by `\u002Fspeckit-bug-fix` actually resolves the bug described by `\u002Fspeckit-bug-assess`. The output is a verification report at `.specify\u002Fbugs\u002F\u003Cslug>\u002Ftest.md`.\n\n## User Input\n\n```text\n$ARGUMENTS\n```\n\nThe user input should identify the bug to validate. Accept any of:\n\n- `slug=\u003Cbug-slug>` or `--slug \u003Cbug-slug>` or a bare slug-like token.\n- A path that contains the slug (e.g. `.specify\u002Fbugs\u002Flogin-timeout\u002F`).\n- **Nothing** — fall back to context (see below).\n\n## Slug Resolution\n\nResolve `BUG_SLUG` in this order, stopping at the first match:\n\n1. **Explicit user input** — a slug passed in `$ARGUMENTS` (any of the forms above).\n2. **Conversation context** — if the current session has just run `\u002Fspeckit-bug-assess` or `\u002Fspeckit-bug-fix`, the slug it reported is the working slug. Reuse it without re-prompting. Confirm it by checking that `.specify\u002Fbugs\u002F\u003Cslug>\u002Ffix.md` exists; if it does not, fall through.\n3. **Single candidate on disk** — list `.specify\u002Fbugs\u002F*\u002Ffix.md`. If exactly one bug has a `fix.md`, use it.\n4. **Disambiguate**:\n   - **Interactive mode**: ask the user which bug to validate and list the candidates.\n   - **Automated mode**: stop with an error listing the candidates. Do not guess.\n\nOnce resolved, set `BUG_SLUG` and `BUG_DIR = .specify\u002Fbugs\u002F\u003CBUG_SLUG>`, and briefly state in your reply which resolution path was used (explicit \u002F from context \u002F single candidate \u002F asked).\n\n## Prerequisites\n\n- `BUG_DIR\u002Fassessment.md` MUST exist.\n- `BUG_DIR\u002Ffix.md` MUST exist. If not, stop and instruct the user to run `\u002Fspeckit-bug-fix` first.\n- If `BUG_DIR\u002Ftest.md` already exists, ask the user whether to overwrite it (interactive mode) or refuse (automated mode).\n- Read both `assessment.md` and `fix.md` in full so you know:\n  - The original symptom and reproduction steps (from `assessment.md`).\n  - The actual code changes and tests added (from `fix.md`).\n\n## Execution\n\n1. **Plan the validation**\n   - Decide which checks prove the bug is gone:\n     - Re-run the reproduction steps from the assessment (or their automated equivalent).\n     - Run the tests added or updated in the fix.\n     - Run any broader regression suite that touches the changed files.\n   - Decide which checks prove nothing was broken:\n     - Existing test suites for the changed modules.\n     - Lint \u002F type-check if the project uses them.\n\n2. **Run the checks**\n   - Execute each planned check. Capture command, exit status, and a short excerpt of relevant output (last few lines, or the failing assertion).\n   - If a check is destructive, network-dependent, or expensive, skip it and record it as `skipped` with a reason; do not run it without explicit user consent.\n   - If you cannot run a check at all (missing tooling, no test framework configured), record it as `not-run` with a reason instead of fabricating a result.\n\n3. **Judge the outcome**\n   - Mark the fix as:\n     - **verified** — all critical checks pass and the original symptom no longer reproduces.\n     - **partial** — the original symptom is gone but unrelated regressions appeared, or some checks are inconclusive.\n     - **failed** — the symptom still reproduces or the regression suite is broken by the fix.\n   - Do not over-claim. If reproduction was not actually performed (e.g., the bug required a production environment), say so explicitly.\n\n4. **Write the verification report**\n\n   Write to `BUG_DIR\u002Ftest.md` using this structure:\n\n   ```markdown\n   # Bug Verification: \u003Cshort title>\n\n   - **Slug**: \u003CBUG_SLUG>\n   - **Tested**: \u003CISO 8601 date>\n   - **Assessment**: .\u002Fassessment.md\n   - **Fix**: .\u002Ffix.md\n   - **Result**: verified | partial | failed\n\n   ## Summary\n\n   \u003COne or two sentences: does the bug reproduce, did the fix hold, were any regressions found.>\n\n   ## Checks Performed\n\n   | Check | Command \u002F Action | Result | Notes |\n   |-------|------------------|--------|-------|\n   | Reproduction (post-fix) | \u003Ccommand or manual steps> | pass \u002F fail \u002F skipped \u002F not-run | \u003Cshort note> |\n   | New \u002F updated tests | `\u003Ccommand>` | pass \u002F fail | \u003Cshort note> |\n   | Regression suite | `\u003Ccommand>` | pass \u002F fail \u002F skipped | \u003Cshort note> |\n   | Lint \u002F type-check | `\u003Ccommand>` | pass \u002F fail \u002F skipped | \u003Cshort note> |\n\n   ## Output Excerpts\n\n   \u003CShort snippets of relevant output (e.g., final summary line of a test run, the failing assertion). Keep it tight — no full logs.>\n\n   ## Residual Risks\n\n   - \u003Cknown limitation, environment not covered, etc.>\n\n   ## Recommendation\n\n   \u003COne paragraph. Examples:>\n   - \"Close the bug — verified end-to-end.\"\n   - \"Hold — reproduction inconclusive; needs verification in staging.\"\n   - \"Reopen — symptom still reproduces; rerun `\u002Fspeckit-bug-assess`.\"\n   ```\n\n5. **Report back** with:\n   - The slug and `BUG_DIR\u002Ftest.md` path.\n   - The result (`verified`, `partial`, `failed`).\n   - If the result is `failed`, recommend re-running `\u002Fspeckit-bug-assess` with the new evidence captured in `test.md`.\n\n## Guardrails\n\n- This command MUST NOT modify source code. It only runs checks and writes inside `.specify\u002Fbugs\u002F\u003Cslug>\u002F`.\n- Never overwrite an existing `test.md` without confirmation.\n- Never mark a fix as `verified` based on tests alone if the original assessment listed a reproduction that you did not actually exercise — downgrade to `partial` and say so.",{"name":5,"metadata":39,"description":7,"compatibility":42},{"author":40,"source":41},"spec-kit-core","bug:commands\u002Fspeckit.bug.test.md","Requires spec-kit project structure with .specify\u002F directory","develop","4af946ac9a2b3cfbbe9b2e8696cc436f1d16e2e2",".cursor\u002Fskills\u002Fspeckit-bug-test",0,"https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer","https:\u002F\u002Fapps.apple.com\u002Fus\u002Fapp\u002Frandom-tactical-timer\u002Fid6758355312","https:\u002F\u002Fgithub.com\u002FIgorGanapolsky","https:\u002F\u002Fwww.igorganapolsky.com","Forward Deploy AI Engineer. Automation specialist.\r\n","2026-11-09 23:14:20",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add IgorGanapolsky\u002FRandom-Timer --skill speckit-bug-test",{"tool":59,"command":60},"bunx","bunx skills add IgorGanapolsky\u002FRandom-Timer --skill speckit-bug-test",{"tool":62,"command":63},"pnpm","pnpm dlx skills add IgorGanapolsky\u002FRandom-Timer --skill speckit-bug-test","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer\u002Fblob\u002Fdevelop\u002F.cursor\u002Fskills\u002Fspeckit-bug-test\u002FSKILL.md",true,[],[68,87,106,116,128,139],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":82,"publishedAt":34},"01M6C3CEGAENG02BPG636N9WG6","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer\u002Fblob\u002Fdevelop\u002F.cursor\u002Fskills\u002Fwriting-plans\u002FSKILL.md",[74,77],{"categoryNo":75,"categoryName":76,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[83,84,27,85,86],"writing plans","writing","code","use",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":96,"publishedAt":34},"01M6C3CC40GJBTJQHQ5BF7CQN9","workflow-economics-lite","Escape AI pilot purgatory: require completion-loop workflows with one owner, baseline, economic metric, system-of-record integration, and audit trail. Block orphan chatbots and interest-as-ROI claims.","https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer\u002Fblob\u002Fdevelop\u002F.cursor\u002Fskills\u002Fworkflow-economics-lite\u002FSKILL.md",[93],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[97,98,99,100,101,102,103,104,105],"workflow economics lite","workflow","loop","roi","workflows","audit","integration","baseline","system",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":34},"01M6C3C9ESBW612NMMMBQDWSWR","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer\u002Fblob\u002Fdevelop\u002F.cursor\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[113,32,86,114,115],"verification before completion","evidence","work",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":34},"01M6C3C71DNQHJ6PGV0TN1R99N","value-center-lite","Apply InfoQ Rohrer value-center \u002F VSM five questions (agency + coherence). Use when planning work, shipping releases, or auditing agent autonomy claims. Fail closed on product-only slogans without WQTU\u002Fpaywall value.","https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer\u002Fblob\u002Fdevelop\u002F.cursor\u002Fskills\u002Fvalue-center-lite\u002FSKILL.md",[],[123,124,86,115,125,126,127],"value center lite","only","product","shipping","planning",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":34},"01M6C3C41Q0R2J49F3Q4CQ004J","using-superpowers","Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions","https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer\u002Fblob\u002Fdevelop\u002F.cursor\u002Fskills\u002Fusing-superpowers\u002FSKILL.md",[],[135,136,86,137,138],"superpowers","using superpowers","find","how",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":34},"01M6C3C1EBYXRVMNHZZE9N49PN","using-git-worktrees","Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback","https:\u002F\u002Fgithub.com\u002FIgorGanapolsky\u002FRandom-Timer\u002Fblob\u002Fdevelop\u002F.cursor\u002Fskills\u002Fusing-git-worktrees\u002FSKILL.md",[],[146,147,148,149,150,151,152,115,86],"git","using git worktrees","git worktrees","git worktree","Tools","worktree","workspace"]