[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXZWH7PR72VCEXSSD4XNK4":3,"skill-same:01M6DXZWH7PR72VCEXSSD4XNK4":111},{"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},"01M6DXZWH7PR72VCEXSSD4XNK4","stress-test-work-item",null,"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.","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\u002Fwork\u002Fstress-test-work-item\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","work item","stress","stress test work item","stress test","work","edge","Bash","acceptance","user","issues","implementation","acceptance criteria","dependencies","stress-test","scope","config","validate","number","frontmatter","gaps","grilling","2026-11-10 10:12:30",false,"---\nname: stress-test-work-item\ndescription: Interactively stress-test a work item by grilling the user\n  on scope, assumptions, acceptance criteria, edge cases, and\n  dependencies to surface issues, gaps, and flawed assumptions before\n  implementation is planned.\nargument-hint: \"[work item number or path]\"\nallowed-tools:\n  - Bash(accelerator config *)\n  - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Stress-Test Work Item\n\n!`accelerator config context --skill stress-test-work-item --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**Work items directory**: !`accelerator config path work --fail-safe`\n\nYou are tasked with stress-testing a work item by interviewing the user\nrelentlessly about every aspect of it. Your goal is to find issues,\ninconsistencies, missing edge cases, flawed assumptions, and vague acceptance\ncriteria before implementation is planned.\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 work item path or number was provided**:\n\n   - Accepted forms: a path (e.g. `meta\u002Fwork\u002F0042-user-auth.md`) or a bare\n     work item number (e.g. `0042` or `42`, resolved against `{work_dir}`)\n   - If the resolved path does not exist: report \"No work item file at \u003Cpath>\"\n     and exit without reading any other file or starting questioning\n   - Read the work item file FULLY\n   - If the work item has a non-empty `parent` field, read the parent work item too\n   - Optionally spawn codebase agents ({codebase locator agent},\n     {codebase analyser agent}) if the work item makes specific technical claims\n     that the agents can verify — do NOT spawn them reflexively for every work item\n   - Wait for any spawned agents to complete before asking the first question\n   - Begin stress-testing (see process below)\n\n2. **If no work item path or number provided**, respond with:\n\n   ```\n   I'll stress-test your work item. Please provide the path or work item number.\n\n   Example: `\u002Fstress-test-work-item {work_dir}\u002F0042-user-auth.md`\n   Or by number: `\u002Fstress-test-work-item 42`\n\n   Run `\u002Flist-work-items` to see available work items.\n   ```\n\n   Then 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 bulleted list of all issues — 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 you find a vague term or missing detail, follow it to its implications\n   - \"The work item says X — does that mean Y? What happens when Z?\"\n   - Resolve one ambiguity completely before moving to the next\n\n3. **Self-answer from the codebase when possible**\n\n   - If a question about the work item could be answered by reading the actual code,\n     spawn a codebase agent instead of asking the user\n   - Only ask the user questions that require human judgment: intent, priorities,\n     trade-offs, scope decisions\n\n4. **Be adversarial but constructive**\n\n   - Challenge vague acceptance criteria: \"'Handle errors gracefully' — what\n     does that mean concretely? What would a failing test assert?\"\n   - Probe edge cases: \"What happens when the input is empty? Malformed? Too large?\"\n   - Question scope: \"These five acceptance criteria cover unrelated concerns —\n     should this work item be decomposed?\"\n   - Surface contradictions: \"The Summary says X, but the Requirements say Y\"\n   - Test completeness: \"The Dependencies section is empty but Requirements imply\n     a database schema change — 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 work item assuming about the system that might\n  be wrong? Verify against the actual codebase where applicable.\n- **Acceptance criteria**: Are they testable, specific, and measurable? Do\n  they cover failure paths, not just the happy path? Would a passing test\n  be unambiguous?\n- **Scope**: Too big? Too small? Does it try to do too much in one work item?\n  Are there items that belong in a separate work item?\n- **Edge cases**: What happens with empty data, concurrent access, partial\n  failures, malformed input, timeouts, large datasets — whichever are\n  relevant to this work item's domain.\n- **Dependencies**: What must exist before this work? What does this work\n  block? Are there schema or data changes that must precede this? Is the\n  Dependencies section accurate?\n- **Non-functional concerns**: Performance, security, accessibility,\n  observability — do the requirements address these where applicable?\n- **Definition of done**: Are the completion criteria clear and verifiable?\n  Is it obvious when this work item is truly done?\n- **Consistency**: Do the sections agree with each other? Does the Summary\n  match the Requirements? Do the Requirements match the Acceptance Criteria?\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 work item 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 explicitly before wrapping up.\n\n## Capturing Changes\n\nAs you identify issues during the conversation, track them. Once the\nstress-testing 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 work item]\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 work item** — apply the stress-test findings to the work\n   item body\n2. **No, leave unchanged** — keep the work item as-is\n\n2. **If the user chooses option 1, edit the work item**:\n\n   - Use the Edit tool to apply targeted modifications to the body sections\n     **Acceptance Criteria**, **Dependencies**, **Assumptions**, or\n     **Technical Notes** ONLY\n   - Never modify any frontmatter field (`work_item_id`, `title`, `date`,\n     `author`, `kind`, `status`, `priority`, `parent`, `tags`) nor the body\n     `**Kind**:`, `**Status**:`, `**Priority**:`, or `**Author**:` labels —\n     those transitions are `\u002Fupdate-work-item`'s concern\n   - Do NOT rewrite sections beyond what was agreed in the conversation\n   - If an Edit target string cannot be matched (the section content differs\n     from what was read), abort that specific edit with a clear diagnostic and\n     continue with the remaining agreed edits\n\n3. **After editing, summarise changes made**\n\n**Validate the frontmatter**: after any edit to the work item, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cthe work item path>\n```\n\nIf it exits non-zero, the 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 resolved.\n\n2. **Don't redesign the work item**: Your job is to find problems, not to propose\n   a different architecture. If you think the approach is fundamentally wrong,\n   raise it as a concern and let the user decide. Do not rewrite Requirements\n   to reflect an alternative approach.\n\n3. **Verify against reality**: Use codebase agents to check whether the work item's\n   technical assumptions are correct. The most valuable findings come from\n   discovering that the code doesn't work the way the work item assumes.\n\n4. **Depth over breadth**: It's better to thoroughly stress-test the riskiest\n   parts of the work item than to superficially cover everything.\n\n5. **Respect confirmed decisions**: If the user has explained their reasoning\n   and confirmed a decision, don't circle back to it. Move on.\n\n6. **Edit conservatively**: When updating the work item, make the minimum changes\n   needed to address what was agreed.\n\n## Relationship to Other Commands\n\nThis skill sits in the work item lifecycle between review and planning:\n\n1. `\u002Fcreate-work-item` or `\u002Fextract-work-items` — create the work item\n2. `\u002Frefine-work-item` — decompose and enrich\n3. `\u002Freview-work-item` — automated multi-lens quality review\n4. `\u002Fstress-test-work-item` — interactive adversarial examination (this command)\n5. `\u002Fcreate-plan` — plan implementation from an approved work item\n\n`\u002Freview-work-item` and `\u002Fstress-test-work-item` are complementary:\n\n- `\u002Freview-work-item` gives broad, automated coverage through multiple quality lenses\n  — good for catching structural issues and standards violations\n- `\u002Fstress-test-work-item` 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-work-item --fail-safe`\n","# Stress-Test Work Item\n\n!`accelerator config context --skill stress-test-work-item --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**Work items directory**: !`accelerator config path work --fail-safe`\n\nYou are tasked with stress-testing a work item by interviewing the user\nrelentlessly about every aspect of it. Your goal is to find issues,\ninconsistencies, missing edge cases, flawed assumptions, and vague acceptance\ncriteria before implementation is planned.\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 work item path or number was provided**:\n\n   - Accepted forms: a path (e.g. `meta\u002Fwork\u002F0042-user-auth.md`) or a bare\n     work item number (e.g. `0042` or `42`, resolved against `{work_dir}`)\n   - If the resolved path does not exist: report \"No work item file at \u003Cpath>\"\n     and exit without reading any other file or starting questioning\n   - Read the work item file FULLY\n   - If the work item has a non-empty `parent` field, read the parent work item too\n   - Optionally spawn codebase agents ({codebase locator agent},\n     {codebase analyser agent}) if the work item makes specific technical claims\n     that the agents can verify — do NOT spawn them reflexively for every work item\n   - Wait for any spawned agents to complete before asking the first question\n   - Begin stress-testing (see process below)\n\n2. **If no work item path or number provided**, respond with:\n\n   ```\n   I'll stress-test your work item. Please provide the path or work item number.\n\n   Example: `\u002Fstress-test-work-item {work_dir}\u002F0042-user-auth.md`\n   Or by number: `\u002Fstress-test-work-item 42`\n\n   Run `\u002Flist-work-items` to see available work items.\n   ```\n\n   Then 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 bulleted list of all issues — 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 you find a vague term or missing detail, follow it to its implications\n   - \"The work item says X — does that mean Y? What happens when Z?\"\n   - Resolve one ambiguity completely before moving to the next\n\n3. **Self-answer from the codebase when possible**\n\n   - If a question about the work item could be answered by reading the actual code,\n     spawn a codebase agent instead of asking the user\n   - Only ask the user questions that require human judgment: intent, priorities,\n     trade-offs, scope decisions\n\n4. **Be adversarial but constructive**\n\n   - Challenge vague acceptance criteria: \"'Handle errors gracefully' — what\n     does that mean concretely? What would a failing test assert?\"\n   - Probe edge cases: \"What happens when the input is empty? Malformed? Too large?\"\n   - Question scope: \"These five acceptance criteria cover unrelated concerns —\n     should this work item be decomposed?\"\n   - Surface contradictions: \"The Summary says X, but the Requirements say Y\"\n   - Test completeness: \"The Dependencies section is empty but Requirements imply\n     a database schema change — 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 work item assuming about the system that might\n  be wrong? Verify against the actual codebase where applicable.\n- **Acceptance criteria**: Are they testable, specific, and measurable? Do\n  they cover failure paths, not just the happy path? Would a passing test\n  be unambiguous?\n- **Scope**: Too big? Too small? Does it try to do too much in one work item?\n  Are there items that belong in a separate work item?\n- **Edge cases**: What happens with empty data, concurrent access, partial\n  failures, malformed input, timeouts, large datasets — whichever are\n  relevant to this work item's domain.\n- **Dependencies**: What must exist before this work? What does this work\n  block? Are there schema or data changes that must precede this? Is the\n  Dependencies section accurate?\n- **Non-functional concerns**: Performance, security, accessibility,\n  observability — do the requirements address these where applicable?\n- **Definition of done**: Are the completion criteria clear and verifiable?\n  Is it obvious when this work item is truly done?\n- **Consistency**: Do the sections agree with each other? Does the Summary\n  match the Requirements? Do the Requirements match the Acceptance Criteria?\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 work item 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 explicitly before wrapping up.\n\n## Capturing Changes\n\nAs you identify issues during the conversation, track them. Once the\nstress-testing 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 work item]\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 work item** — apply the stress-test findings to the work\n   item body\n2. **No, leave unchanged** — keep the work item as-is\n\n2. **If the user chooses option 1, edit the work item**:\n\n   - Use the Edit tool to apply targeted modifications to the body sections\n     **Acceptance Criteria**, **Dependencies**, **Assumptions**, or\n     **Technical Notes** ONLY\n   - Never modify any frontmatter field (`work_item_id`, `title`, `date`,\n     `author`, `kind`, `status`, `priority`, `parent`, `tags`) nor the body\n     `**Kind**:`, `**Status**:`, `**Priority**:`, or `**Author**:` labels —\n     those transitions are `\u002Fupdate-work-item`'s concern\n   - Do NOT rewrite sections beyond what was agreed in the conversation\n   - If an Edit target string cannot be matched (the section content differs\n     from what was read), abort that specific edit with a clear diagnostic and\n     continue with the remaining agreed edits\n\n3. **After editing, summarise changes made**\n\n**Validate the frontmatter**: after any edit to the work item, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cthe work item path>\n```\n\nIf it exits non-zero, the 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 resolved.\n\n2. **Don't redesign the work item**: Your job is to find problems, not to propose\n   a different architecture. If you think the approach is fundamentally wrong,\n   raise it as a concern and let the user decide. Do not rewrite Requirements\n   to reflect an alternative approach.\n\n3. **Verify against reality**: Use codebase agents to check whether the work item's\n   technical assumptions are correct. The most valuable findings come from\n   discovering that the code doesn't work the way the work item assumes.\n\n4. **Depth over breadth**: It's better to thoroughly stress-test the riskiest\n   parts of the work item than to superficially cover everything.\n\n5. **Respect confirmed decisions**: If the user has explained their reasoning\n   and confirmed a decision, don't circle back to it. Move on.\n\n6. **Edit conservatively**: When updating the work item, make the minimum changes\n   needed to address what was agreed.\n\n## Relationship to Other Commands\n\nThis skill sits in the work item lifecycle between review and planning:\n\n1. `\u002Fcreate-work-item` or `\u002Fextract-work-items` — create the work item\n2. `\u002Frefine-work-item` — decompose and enrich\n3. `\u002Freview-work-item` — automated multi-lens quality review\n4. `\u002Fstress-test-work-item` — interactive adversarial examination (this command)\n5. `\u002Fcreate-plan` — plan implementation from an approved work item\n\n`\u002Freview-work-item` and `\u002Fstress-test-work-item` are complementary:\n\n- `\u002Freview-work-item` gives broad, automated coverage through multiple quality lenses\n  — good for catching structural issues and standards violations\n- `\u002Fstress-test-work-item` 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-work-item --fail-safe`\n",{"name":5,"description":7,"allowed-tools":51,"argument-hint":54},[52,53],"Bash(accelerator config *)","Bash(accelerator corpus frontmatter validate *)","[work item number or path]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fwork\u002Fstress-test-work-item",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-10 21:05:37",{"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-work-item",{"tool":69,"command":70},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill stress-test-work-item",{"tool":72,"command":73},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill stress-test-work-item","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002FSKILL.md",true,[77,83,87,91,95,99,103,107],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"evals\u002Fbenchmark.json","REFERENCE","参考文档",28978,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002Fevals\u002Fbenchmark.json",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"evals\u002Fevals.json",22092,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002Fevals\u002Fevals.json",{"path":88,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":89,"sourceHtmlUrl":90},"evals\u002Ffiles\u002Fempty-deps\u002Fwork-item.md",2552,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002Fevals\u002Ffiles\u002Fempty-deps\u002Fwork-item.md",{"path":92,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":93,"sourceHtmlUrl":94},"evals\u002Ffiles\u002Fhappy-path-only\u002Fwork-item.md",2377,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002Fevals\u002Ffiles\u002Fhappy-path-only\u002Fwork-item.md",{"path":96,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":97,"sourceHtmlUrl":98},"evals\u002Ffiles\u002Fover-scoped\u002Fwork-item.md",2584,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002Fevals\u002Ffiles\u002Fover-scoped\u002Fwork-item.md",{"path":100,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":101,"sourceHtmlUrl":102},"evals\u002Ffiles\u002Fscenario-15\u002Fexpected-target.md",2473,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002Fevals\u002Ffiles\u002Fscenario-15\u002Fexpected-target.md",{"path":104,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":105,"sourceHtmlUrl":106},"evals\u002Ffiles\u002Fscenario-15\u002Fwork-item.md",1785,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002Fevals\u002Ffiles\u002Fscenario-15\u002Fwork-item.md",{"path":108,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":109,"sourceHtmlUrl":110},"evals\u002Ffiles\u002Fweak-acs\u002Fwork-item.md",1926,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002Fevals\u002Ffiles\u002Fweak-acs\u002Fwork-item.md",[112,145,165,187,205,221],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":126,"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",[118,121],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[127,128,129,130,131,132,133,134,135,136,137,42,138,31,139,140,141,142,143,144],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","when","URL","code","architecture","reviewer","review","notes","change",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"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",[],[29,152,153,25,154,155,156,31,144,40,157,41,158,159,43,160,161,162,163,164],"update","update work item","enforcement","manage","use","edit","status","transition","Existing","tags","changes","fields","op",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"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",[],[29,172,173,174,175,176,177,31,178,144,179,180,181,182,183,184,185,40,186,43,137],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"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",[],[194,29,195,172,173,196,197,198,199,200,201,202,203,204],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"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",[],[142,29,212,25,213,214,156,31,215,216,40,41,35,33,217,137,218,219,43,220],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":227,"publishedAt":46},"01M6DXZMY4QJXX8V72CMWR2MZ1","rekey-work-items","Converge every work item's ID onto the configured work.id_pattern, renaming files and rewriting references across meta\u002F. Use after changing work.id_pattern or work.key, when existing work items should take IDs in the new shape, or to finish or undo an interrupted re-key.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frekey-work-items\u002FSKILL.md",[],[29,228,229,175,230,156,31,231,232,233,234,40,235,236,41,237,238,25,132,239,160,137],"rekey work items","ids","files","across","id","references","shape","pattern","take","finish","converge","new"]