[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXTNHZ0RT47G2JD9MVJXGQ":3,"skill-same:01M6DXTNHZ0RT47G2JD9MVJXGQ":117},{"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":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6DXTNHZ0RT47G2JD9MVJXGQ","stress-test-plan",null,"Interactively stress-test an implementation plan by grilling the user on decisions, edge cases, and assumptions to find issues, inconsistencies, and gaps before implementation begins.","atomicinnovation\u002Faccelerator","atomicinnovation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F65866524?v=4","01M6DXP513JV585FN2QPNR6079","Atomic","01M6DXP55MPK99YVZ2HGMEN991",34,"MIT","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fplanning\u002Fstress-test-plan\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"test","stress","test plan","stress test plan","plan","stress test","gaps","grilling","implementation plan","to plan","frontmatter","stress-test","implementation","user","decisions","find","Bash","edge","file","issues","config","validate","2026-11-10 10:12:30",false,"---\nname: stress-test-plan\ndescription: Interactively stress-test an implementation plan by grilling the user\n  on decisions, edge cases, and assumptions to find issues, inconsistencies, and gaps\n  before implementation begins.\nargument-hint: \"[path to plan file]\"\nallowed-tools:\n  - Bash(accelerator config *)\n  - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Stress-Test Plan\n\n!`accelerator config context --skill stress-test-plan --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:reviewer, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser,\naccelerator:web-search-researcher.\n\n**Plans directory**: !`accelerator config path plans --fail-safe`\n\nYou are tasked with stress-testing an implementation plan by interviewing the\nuser relentlessly about every aspect of it. Your goal is to find issues,\ninconsistencies, missing edge cases, flawed assumptions, and potential bugs\nbefore any code is written.\n\nThis is NOT an automated review — it is an interactive, adversarial conversation\nwhere you walk down every branch of the decision tree with the user, resolving\none thing at a time.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **If a plan path was provided**:\n\n- Read the plan file FULLY\n- Read any files the plan references — work items, research documents, key source\n  files mentioned\n- Spawn sub-agents to understand the current codebase context:\n  - Use the **{codebase locator agent}** agent to find files related to the plan's scope\n  - Use the **{codebase analyser agent}** agent to understand current implementation\n    details referenced in the plan\n- Wait for sub-agents to complete\n- Begin stress-testing (see process below)\n\n2. **If no plan path provided**, respond with:\n\n```\nI'll stress-test your implementation plan. Please provide the path to the plan file.\n\nExample: `\u002Fstress-test-plan {plans directory}\u002F2025-01-08-ENG-1478-feature.md`\n```\n\nThen wait for the user's input.\n\n## The Stress-Testing Process\n\n### How to Conduct the Interrogation\n\n1. **One question at a time** (or a small, tightly related cluster)\n\n- Do NOT dump a list of 10 questions — that defeats the purpose\n- Each question should build on the previous answer\n- Follow the thread to its conclusion before switching branches\n\n2. **Walk the decision tree depth-first**\n\n- When the plan makes a design choice, follow it to its implications\n- \"The plan says X — does that mean Y? What happens when Z?\"\n- Resolve dependencies between decisions before moving on\n- If a decision in Phase 1 affects Phase 3, call that out\n\n3. **Explore the codebase to self-answer when possible**\n\n- If a question about the plan could be answered by reading the actual code,\n  read the code or spawn a sub-agent instead of asking the user\n- Only ask the user questions that require human judgment: intent, priorities,\n  trade-offs, business logic, scope decisions\n\n4. **Be adversarial but constructive**\n\n- Challenge vague language: \"The plan says 'handle errors gracefully' — what\n  does that mean concretely?\"\n- Probe edge cases: \"What happens if this operation fails halfway through\n  Phase 2?\"\n- Question scope: \"The plan includes X — is this really needed for the first\n  iteration?\"\n- Surface contradictions: \"Phase 1 assumes Y, but Phase 3 does Z which\n  contradicts that\"\n- Test completeness: \"The plan doesn't mention what happens when [scenario] —\n  is that intentional?\"\n\n### What to Stress-Test\n\nWork through these areas as the conversation naturally leads to them. Do not\ntreat this as a checklist to run through mechanically.\n\n- **Assumptions**: What is the plan assuming about the current system that might\n  be wrong? Verify against the actual codebase.\n- **Edge cases**: What happens with empty inputs, concurrent access, partial\n  failures, network timeouts, large datasets, malformed data?\n- **Error handling**: Does the plan specify what happens when things go wrong at\n  each step? Are error paths tested?\n- **Integration points**: Where does this touch existing systems? Are those\n  contracts correctly understood? Will existing consumers break?\n- **Ordering dependencies**: Does Phase N depend on Phase M being done a\n  specific way? Are those dependencies explicit?\n- **Rollback**: If we ship Phase 1 and Phase 2 fails, can we undo? Is\n  the migration reversible?\n- **Performance**: Does the plan introduce hot paths, N+1 queries, unbounded\n  loops, or large memory allocations?\n- **Security**: Does the plan handle authentication, authorisation, input\n  validation, and data exposure correctly?\n- **Scope creep**: Is the plan trying to do too much? Are there items that\n  could be deferred?\n- **Missing steps**: Are there gaps between phases where something needs to\n  happen but isn't mentioned?\n- **Testing gaps**: Are the success criteria actually verifiable? Do they cover\n  the important cases?\n- **Consistency**: Do different sections of the plan agree with each other?\n  Do code snippets match the prose descriptions?\n\n### When to Stop\n\nStop stress-testing when:\n\n- All major branches of the decision tree have been explored\n- You cannot think of a realistic scenario that the plan fails to address\n- The user has confirmed their position on all identified ambiguities\n- Edge cases have been identified and decisions made about how to handle them\n\nDo NOT stop just because the user seems tired of questions. If there are genuine\nissues remaining, flag them:\n\n```\nI know this is thorough, but I want to flag that [specific issue] could cause\nproblems during implementation. Can we quickly resolve it?\n```\n\n## Capturing Changes\n\nAs you identify issues during the conversation, track them. Once the stress-\ntesting is complete:\n\n1. **Summarise all findings**:\n\n```\nHere's what we found during the stress test:\n\n**Issues to fix:**\n- [Issue]: [What needs to change in the plan]\n- [Issue]: [What needs to change in the plan]\n\n**Decisions confirmed:**\n- [Decision]: [User confirmed this is intentional]\n\n**Risks accepted:**\n- [Risk]: [User acknowledges this and accepts it]\n\n```\n\nUse the `AskUserQuestion` tool with two options:\n\n1. **Yes, update the plan** — apply the stress-test findings to the plan file\n2. **No, leave unchanged** — keep the plan as-is\n\n2. **If the user agrees, edit the plan**:\n\n- Use the Edit tool to modify the plan file directly\n- Make targeted edits — don't rewrite sections unnecessarily\n- Add missing edge case handling, error paths, and clarifications\n- Update success criteria if gaps were found\n- Add a note about accepted risks where appropriate\n\n3. **After editing, summarise changes made**:\n\n```\nI've updated the plan at `[path]`. Changes made:\n- [Change 1] — addressing [issue]\n- [Change 2] — addressing [issue]\n- [Noted as accepted risk] — [risk description]\n```\n\n**Validate the frontmatter**: after writing, run `corpus frontmatter\nvalidate` over each file you edited:\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cpath>\n```\n\nIf it exits non-zero, the edited document violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n## Important Guidelines\n\n1. **This is a conversation, not a report**: The value is in the back-and-forth.\n   Don't just list problems — dig into each one with the user until it's\n   resolved.\n\n2. **Don't redesign the plan**: Your job is to find problems, not to propose a\n   different architecture. If you think the approach is fundamentally wrong,\n   raise it as a concern and let the user decide.\n\n3. **Verify against reality**: Use sub-agents freely to check whether the plan's\n   assumptions about the codebase are correct. The most valuable findings come\n   from discovering that the code doesn't work the way the plan assumes.\n\n4. **Depth over breadth**: It's better to thoroughly stress-test the riskiest\n   parts of the plan than to superficially cover everything.\n\n5. **Track what you've covered**: Use TodoWrite to track which areas of the plan\n   you've stress-tested and which remain. This helps you know when you're\n   genuinely done.\n\n6. **Respect confirmed decisions**: If the user has explained their reasoning\n   and confirmed a decision, don't circle back to it. Move on.\n\n7. **Edit conservatively**: When updating the plan, make the minimum changes\n   needed. Don't restructure or rewrite beyond what the stress test revealed.\n\n## Relationship to Other Commands\n\nThis skill sits in the plan lifecycle between review and implementation:\n\n1. `\u002Fcreate-plan` — Create the implementation plan interactively\n2. `\u002Freview-plan` — Automated multi-lens quality review\n3. `\u002Fstress-test-plan` — Interactive adversarial stress-testing (this command)\n4. `\u002Fimplement-plan` — Execute the approved plan\n5. `\u002Fvalidate-plan` — Verify implementation matches the plan\n\n`\u002Freview-plan` and `\u002Fstress-test-plan` are complementary:\n\n- `\u002Freview-plan` gives broad, automated coverage through multiple quality lenses\n  — good for catching structural issues, security gaps, and standards violations\n- `\u002Fstress-test-plan` goes deep through interactive conversation — good for\n  finding logical inconsistencies, missing edge cases, flawed assumptions, and\n  gaps that only surface when you trace through scenarios step by step\n\n!`accelerator config instructions stress-test-plan --fail-safe`\n","# Stress-Test Plan\n\n!`accelerator config context --skill stress-test-plan --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:reviewer, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser,\naccelerator:web-search-researcher.\n\n**Plans directory**: !`accelerator config path plans --fail-safe`\n\nYou are tasked with stress-testing an implementation plan by interviewing the\nuser relentlessly about every aspect of it. Your goal is to find issues,\ninconsistencies, missing edge cases, flawed assumptions, and potential bugs\nbefore any code is written.\n\nThis is NOT an automated review — it is an interactive, adversarial conversation\nwhere you walk down every branch of the decision tree with the user, resolving\none thing at a time.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **If a plan path was provided**:\n\n- Read the plan file FULLY\n- Read any files the plan references — work items, research documents, key source\n  files mentioned\n- Spawn sub-agents to understand the current codebase context:\n  - Use the **{codebase locator agent}** agent to find files related to the plan's scope\n  - Use the **{codebase analyser agent}** agent to understand current implementation\n    details referenced in the plan\n- Wait for sub-agents to complete\n- Begin stress-testing (see process below)\n\n2. **If no plan path provided**, respond with:\n\n```\nI'll stress-test your implementation plan. Please provide the path to the plan file.\n\nExample: `\u002Fstress-test-plan {plans directory}\u002F2025-01-08-ENG-1478-feature.md`\n```\n\nThen wait for the user's input.\n\n## The Stress-Testing Process\n\n### How to Conduct the Interrogation\n\n1. **One question at a time** (or a small, tightly related cluster)\n\n- Do NOT dump a list of 10 questions — that defeats the purpose\n- Each question should build on the previous answer\n- Follow the thread to its conclusion before switching branches\n\n2. **Walk the decision tree depth-first**\n\n- When the plan makes a design choice, follow it to its implications\n- \"The plan says X — does that mean Y? What happens when Z?\"\n- Resolve dependencies between decisions before moving on\n- If a decision in Phase 1 affects Phase 3, call that out\n\n3. **Explore the codebase to self-answer when possible**\n\n- If a question about the plan could be answered by reading the actual code,\n  read the code or spawn a sub-agent instead of asking the user\n- Only ask the user questions that require human judgment: intent, priorities,\n  trade-offs, business logic, scope decisions\n\n4. **Be adversarial but constructive**\n\n- Challenge vague language: \"The plan says 'handle errors gracefully' — what\n  does that mean concretely?\"\n- Probe edge cases: \"What happens if this operation fails halfway through\n  Phase 2?\"\n- Question scope: \"The plan includes X — is this really needed for the first\n  iteration?\"\n- Surface contradictions: \"Phase 1 assumes Y, but Phase 3 does Z which\n  contradicts that\"\n- Test completeness: \"The plan doesn't mention what happens when [scenario] —\n  is that intentional?\"\n\n### What to Stress-Test\n\nWork through these areas as the conversation naturally leads to them. Do not\ntreat this as a checklist to run through mechanically.\n\n- **Assumptions**: What is the plan assuming about the current system that might\n  be wrong? Verify against the actual codebase.\n- **Edge cases**: What happens with empty inputs, concurrent access, partial\n  failures, network timeouts, large datasets, malformed data?\n- **Error handling**: Does the plan specify what happens when things go wrong at\n  each step? Are error paths tested?\n- **Integration points**: Where does this touch existing systems? Are those\n  contracts correctly understood? Will existing consumers break?\n- **Ordering dependencies**: Does Phase N depend on Phase M being done a\n  specific way? Are those dependencies explicit?\n- **Rollback**: If we ship Phase 1 and Phase 2 fails, can we undo? Is\n  the migration reversible?\n- **Performance**: Does the plan introduce hot paths, N+1 queries, unbounded\n  loops, or large memory allocations?\n- **Security**: Does the plan handle authentication, authorisation, input\n  validation, and data exposure correctly?\n- **Scope creep**: Is the plan trying to do too much? Are there items that\n  could be deferred?\n- **Missing steps**: Are there gaps between phases where something needs to\n  happen but isn't mentioned?\n- **Testing gaps**: Are the success criteria actually verifiable? Do they cover\n  the important cases?\n- **Consistency**: Do different sections of the plan agree with each other?\n  Do code snippets match the prose descriptions?\n\n### When to Stop\n\nStop stress-testing when:\n\n- All major branches of the decision tree have been explored\n- You cannot think of a realistic scenario that the plan fails to address\n- The user has confirmed their position on all identified ambiguities\n- Edge cases have been identified and decisions made about how to handle them\n\nDo NOT stop just because the user seems tired of questions. If there are genuine\nissues remaining, flag them:\n\n```\nI know this is thorough, but I want to flag that [specific issue] could cause\nproblems during implementation. Can we quickly resolve it?\n```\n\n## Capturing Changes\n\nAs you identify issues during the conversation, track them. Once the stress-\ntesting is complete:\n\n1. **Summarise all findings**:\n\n```\nHere's what we found during the stress test:\n\n**Issues to fix:**\n- [Issue]: [What needs to change in the plan]\n- [Issue]: [What needs to change in the plan]\n\n**Decisions confirmed:**\n- [Decision]: [User confirmed this is intentional]\n\n**Risks accepted:**\n- [Risk]: [User acknowledges this and accepts it]\n\n```\n\nUse the `AskUserQuestion` tool with two options:\n\n1. **Yes, update the plan** — apply the stress-test findings to the plan file\n2. **No, leave unchanged** — keep the plan as-is\n\n2. **If the user agrees, edit the plan**:\n\n- Use the Edit tool to modify the plan file directly\n- Make targeted edits — don't rewrite sections unnecessarily\n- Add missing edge case handling, error paths, and clarifications\n- Update success criteria if gaps were found\n- Add a note about accepted risks where appropriate\n\n3. **After editing, summarise changes made**:\n\n```\nI've updated the plan at `[path]`. Changes made:\n- [Change 1] — addressing [issue]\n- [Change 2] — addressing [issue]\n- [Noted as accepted risk] — [risk description]\n```\n\n**Validate the frontmatter**: after writing, run `corpus frontmatter\nvalidate` over each file you edited:\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cpath>\n```\n\nIf it exits non-zero, the edited document violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n## Important Guidelines\n\n1. **This is a conversation, not a report**: The value is in the back-and-forth.\n   Don't just list problems — dig into each one with the user until it's\n   resolved.\n\n2. **Don't redesign the plan**: Your job is to find problems, not to propose a\n   different architecture. If you think the approach is fundamentally wrong,\n   raise it as a concern and let the user decide.\n\n3. **Verify against reality**: Use sub-agents freely to check whether the plan's\n   assumptions about the codebase are correct. The most valuable findings come\n   from discovering that the code doesn't work the way the plan assumes.\n\n4. **Depth over breadth**: It's better to thoroughly stress-test the riskiest\n   parts of the plan than to superficially cover everything.\n\n5. **Track what you've covered**: Use TodoWrite to track which areas of the plan\n   you've stress-tested and which remain. This helps you know when you're\n   genuinely done.\n\n6. **Respect confirmed decisions**: If the user has explained their reasoning\n   and confirmed a decision, don't circle back to it. Move on.\n\n7. **Edit conservatively**: When updating the plan, make the minimum changes\n   needed. Don't restructure or rewrite beyond what the stress test revealed.\n\n## Relationship to Other Commands\n\nThis skill sits in the plan lifecycle between review and implementation:\n\n1. `\u002Fcreate-plan` — Create the implementation plan interactively\n2. `\u002Freview-plan` — Automated multi-lens quality review\n3. `\u002Fstress-test-plan` — Interactive adversarial stress-testing (this command)\n4. `\u002Fimplement-plan` — Execute the approved plan\n5. `\u002Fvalidate-plan` — Verify implementation matches the plan\n\n`\u002Freview-plan` and `\u002Fstress-test-plan` are complementary:\n\n- `\u002Freview-plan` gives broad, automated coverage through multiple quality lenses\n  — good for catching structural issues, security gaps, and standards violations\n- `\u002Fstress-test-plan` goes deep through interactive conversation — good for\n  finding logical inconsistencies, missing edge cases, flawed assumptions, and\n  gaps that only surface when you trace through scenarios step by step\n\n!`accelerator config instructions stress-test-plan --fail-safe`\n",{"name":5,"description":7,"allowed-tools":51,"argument-hint":54},[52,53],"Bash(accelerator config *)","Bash(accelerator corpus frontmatter validate *)","[path to plan file]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fplanning\u002Fstress-test-plan",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-13 08:45:04",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add atomicinnovation\u002Faccelerator --skill stress-test-plan",{"tool":69,"command":70},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill stress-test-plan",{"tool":72,"command":73},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill stress-test-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fplanning\u002Fstress-test-plan\u002FSKILL.md",true,[77,83,87,91,95,99,103,109,113],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"AGENTS.md","REFERENCE","参考文档",52308,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002FAGENTS.md",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"metadata.json",1709,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002Fmetadata.json",{"path":88,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":89,"sourceHtmlUrl":90},"README.md",3334,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002FREADME.md",{"path":92,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fautomation-and-incentives.md",9477,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002Freferences\u002Fautomation-and-incentives.md",{"path":96,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fcritical-gotchas.md",12787,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002Freferences\u002Fcritical-gotchas.md",{"path":100,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fhistorical-hacks.md",11643,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002Freferences\u002Fhistorical-hacks.md",{"path":104,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fcheck-gotchas.sh","SCRIPT","脚本",6469,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002Fscripts\u002Fcheck-gotchas.sh",{"path":110,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Finit-project.sh",4291,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002Fscripts\u002Finit-project.sh",{"path":114,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Fsetup-cursor.sh",1087,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__0x70626a--monad-wingman\u002Fscripts\u002Fsetup-cursor.sh",[118,152,174,196,214,227],{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":132,"publishedAt":46},"01M70S7PFGVATJREBFEGPJB718","explore-pr","Build an interactive, design-first and picture-first exploration page for a pull request — its architecture, abstractions and design decisions drawn as diagrams, a guided tour in reading order with code as the evidence, an attention map of where the risk sits, a ledger of its riskiest operations, prior review findings re-checked against the code, and simulations specific to the PR — with the reviewer's verdicts and notes saved. Use when the user wants to explore, understand or review a large pull request or its design, asks for a review page, walkthrough or visual explanation of a PR, or is struggling to review a big change.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fexplore-pr\u002FSKILL.md",[124,127],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[133,134,135,136,137,138,139,140,141,142,143,144,145,40,146,147,148,149,150,151],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","when","number","URL","code","architecture","reviewer","review","notes","change",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":46},"01M6DY04WBTMFV96JMBP5ZXVFX","update-work-item","Update fields (status, priority, tags, parent, etc.) of an existing work item. Use to transition status, change priority, manage tags, or edit any frontmatter field. No transition enforcement — arbitrary changes are allowed.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002FSKILL.md",[],[159,160,161,162,163,164,165,40,151,44,166,45,167,168,34,169,170,171,172,173],"work","update","update work item","work item","enforcement","manage","use","edit","status","transition","Existing","tags","changes","fields","op",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":46},"01M6DY0106CF15CYEJHZM14GBZ","sync-work-items","Reconcile local work items in meta\u002Fwork\u002F with the active remote tracker named by work.integration. Use when the user wants to sync, push, or pull work items to or from Jira or Linear, preview what a sync would change, or reconcile divergent local and remote state.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items\u002FSKILL.md",[],[159,181,182,183,184,185,186,40,187,151,188,189,190,191,192,193,194,44,195,34,143],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":46},"01M6HNF86984S4XK21Q26VZA21","sync-work-items-recovery","Recovery procedures for work sync failures that need a person — terminal rows, refused pending pushes and refused orders. Read by sync-work-items — not invoked directly.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items-recovery\u002FSKILL.md",[],[203,159,204,181,182,205,206,207,208,209,210,211,212,213],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":215,"name":216,"nameZh":6,"description":217,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":218,"categories":219,"keywords":221,"publishedAt":46},"01M6DXZWH7PR72VCEXSSD4XNK4","stress-test-work-item","Interactively stress-test a work item by grilling the user on scope, assumptions, acceptance criteria, edge cases, and dependencies to surface issues, gaps, and flawed assumptions before implementation is planned.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002FSKILL.md",[220],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[29,24,159,222,162,25,223,43,41,35,224,40,225,226,44,45,36,31,37,144,30,34],"stress test work item","scope","acceptance","acceptance criteria","dependencies",{"skillNo":228,"name":229,"nameZh":6,"description":230,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":231,"categories":232,"keywords":233,"publishedAt":46},"01M6DXZRQWHTWV1G9PTTHCGGYA","review-work-item","Review a work item through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a work item before implementation or escalation.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",[],[149,159,234,162,235,236,165,40,42,237,44,45,36,37,238,143,239,240,34,241],"review work item","review work","escalation","quality","metadata","iterate","evaluate","path"]