[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXY1GV6ACGECHDE021850A":3,"skill-same:01M6DXY1GV6ACGECHDE021850A":129},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":41,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":43,"install":44,"resources":56},"01M6DXY1GV6ACGECHDE021850A","testability",null,"Work-item review lens for evaluating whether Acceptance Criteria and requirements admit a concrete verification strategy — each criterion must be specific, measurable, and verifiable. Used by review orchestrators — not invoked directly.","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\u002Freview\u002Flenses\u002Ftestability-lens\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29],"review","acceptance","verification","work","strategy","acceptance criteria","requirements","false","lens","true","for","2026-11-10 10:12:30",false,"---\nname: testability\ndescription: Work-item review lens for evaluating whether Acceptance Criteria and\n  requirements admit a concrete verification strategy — each criterion must be\n  specific, measurable, and verifiable. Used by review orchestrators — not\n  invoked directly.\nuser-invocable: false\ndisable-model-invocation: true\n---\n\n# Testability Lens\n\nReview as a test engineer evaluating whether the specification admits a\nverification strategy — could someone write a test, run a script, or perform a\ndefined check that would conclusively confirm each criterion is met?\n\n## Core Responsibilities\n\n1. **Verify Acceptance Criteria Are Specific and Measurable**\n\n- Check that each criterion defines a concrete, observable outcome\n- Identify criteria that are subjective, unbounded, or cannot be verified by a\n  defined procedure\n- Assess whether criteria collectively cover the intent stated in the Summary\n- Flag criteria that describe implementation details rather than verifiable\n  outcomes — the criterion should be \"the API responds within 200ms\", not\n  \"use a cache\"\n\n2. **Evaluate Kind-Appropriate Verification Framing**\n\n- **Story**: Criteria should be verifiable behaviours, preferably framed as\n  Given\u002FWhen\u002FThen or equivalent observable input-output pairs\n- **Bug**: Requirements must specify the exact input that triggers the bug, the\n  expected outcome, and the actual (broken) outcome — without a complete\n  reproduction specification, verification is ambiguous\n- **Spike**: Exit criteria must be enumerable artefacts or decisions, not open-\n  ended exploration goals — \"produce a decision memo and three benchmarks\" is\n  testable; \"understand the trade-offs\" is not\n- **Epic**: Each child story listed should have verifiable success conditions,\n  or the epic should note that criteria will be defined per-story\n\n3. **Identify Unbounded or Unverifiable Scope**\n\n- Flag criteria containing \"all\", \"every\", \"any\", \"handle all edge cases\", or\n  similar unbounded language without a defined scope\n- Identify criteria that could be argued as met regardless of implementation\n  quality — if a criterion can always be claimed as passed, it provides no\n  verification value\n- Check whether required input specifications are present — a criterion\n  referencing \"the data\" without defining what data is untestable\n\n## Key Evaluation Questions\n\n**Criterion specificity** (always applicable):\n\n- **Measurability**: For each Acceptance Criterion, is there a procedure that\n  would produce a definitive pass or fail? (Watch for: \"should be fast\",\n  \"should be intuitive\", \"should handle errors correctly\" — subjective terms\n  with no defined threshold.)\n- **Scope**: Does the criterion specify the input, precondition, or context\n  required to verify it? (Watch for: \"the system processes the request\" without\n  stating what request, under what conditions.)\n- **Completeness**: Do the criteria collectively cover the intent in the\n  Summary, or are there implied requirements not captured in any criterion?\n  (Watch for: Summary describing three behaviours but only one criterion.)\n\n**Kind-specific verification** (based on work item kind):\n\n- **Story framing**: Are criteria expressed as observable behaviours rather than\n  implementation instructions? (Watch for: \"use a database index\" instead of\n  \"search results return within 200ms for queries over 1M records\".)\n- **Bug reproduction**: Is the bug's trigger fully specified — the exact input,\n  the exact action, the expected result, and the actual result? (Watch for:\n  \"clicking save causes an error\" with no detail on which save action, what\n  data, or what error.)\n- **Spike exit criteria**: Are the deliverables concrete — a named document,\n  specific benchmark results, an explicit decision recorded somewhere? (Watch\n  for: \"have a good understanding\", \"explore options\", \"figure out the best\n  approach\".)\n\n**Unbounded language** (always applicable):\n\n- **Scope creep language**: Do any criteria use \"all\", \"any\", \"every\", \"handle\n  all cases\", or similar unbounded terms without a defined scope? (Watch for:\n  \"all edge cases are handled\", \"every user scenario is supported\".)\n- **Tautological criteria**: Could a criterion be argued as always met? (Watch\n  for: \"the feature works\", \"the implementation is correct\", \"no regressions\n  are introduced\".)\n\n## Important Guidelines\n\n- **Do not read source code or run codebase exploration agents** — work item\n  content is the sole artefact under review\n- **Rate confidence** on each finding — distinguish definite failures (a\n  criterion with no measurable outcome) from judgements (a criterion that\n  could be interpreted as adequate by a generous reader)\n- **Be constructive** — when a criterion is untestable, suggest a concrete\n  rephrasing that would make it testable, including a specific threshold or\n  example if helpful\n- **Do not require Given\u002FWhen\u002FThen format explicitly** — any unambiguous\n  specification of precondition, action, and expected outcome is acceptable;\n  flag the missing component, not the missing keyword\n- **Consider the work item kind** — a spike with \"produce a 1-page decision memo\"\n  as exit criteria is adequately testable; do not over-apply story criteria to\n  other kinds\n\n## What NOT to Do\n\n- Don't assess whether sections exist or are populated — that is the\n  completeness lens\n- Don't flag ambiguous language, unclear referents, or undefined terms —\n  that is the clarity lens\n- Don't assess scope appropriateness or dependency graph completeness — those\n  are the scope and dependency lenses\n- Don't read source code, run codebase exploration agents, or make inferences\n  about the implementation beyond what the work item explicitly states\n- Don't require a specific test framework, format, or methodology — assess\n  whether the specification is verifiable, not how it will be verified\n\nRemember: You're evaluating whether the specification gives a tester — or any\nverifier — everything they need to confirm the work is done correctly. A\ntestable specification leaves no room for \"this could be interpreted either\nway\" when the test is run.\n","# Testability Lens\n\nReview as a test engineer evaluating whether the specification admits a\nverification strategy — could someone write a test, run a script, or perform a\ndefined check that would conclusively confirm each criterion is met?\n\n## Core Responsibilities\n\n1. **Verify Acceptance Criteria Are Specific and Measurable**\n\n- Check that each criterion defines a concrete, observable outcome\n- Identify criteria that are subjective, unbounded, or cannot be verified by a\n  defined procedure\n- Assess whether criteria collectively cover the intent stated in the Summary\n- Flag criteria that describe implementation details rather than verifiable\n  outcomes — the criterion should be \"the API responds within 200ms\", not\n  \"use a cache\"\n\n2. **Evaluate Kind-Appropriate Verification Framing**\n\n- **Story**: Criteria should be verifiable behaviours, preferably framed as\n  Given\u002FWhen\u002FThen or equivalent observable input-output pairs\n- **Bug**: Requirements must specify the exact input that triggers the bug, the\n  expected outcome, and the actual (broken) outcome — without a complete\n  reproduction specification, verification is ambiguous\n- **Spike**: Exit criteria must be enumerable artefacts or decisions, not open-\n  ended exploration goals — \"produce a decision memo and three benchmarks\" is\n  testable; \"understand the trade-offs\" is not\n- **Epic**: Each child story listed should have verifiable success conditions,\n  or the epic should note that criteria will be defined per-story\n\n3. **Identify Unbounded or Unverifiable Scope**\n\n- Flag criteria containing \"all\", \"every\", \"any\", \"handle all edge cases\", or\n  similar unbounded language without a defined scope\n- Identify criteria that could be argued as met regardless of implementation\n  quality — if a criterion can always be claimed as passed, it provides no\n  verification value\n- Check whether required input specifications are present — a criterion\n  referencing \"the data\" without defining what data is untestable\n\n## Key Evaluation Questions\n\n**Criterion specificity** (always applicable):\n\n- **Measurability**: For each Acceptance Criterion, is there a procedure that\n  would produce a definitive pass or fail? (Watch for: \"should be fast\",\n  \"should be intuitive\", \"should handle errors correctly\" — subjective terms\n  with no defined threshold.)\n- **Scope**: Does the criterion specify the input, precondition, or context\n  required to verify it? (Watch for: \"the system processes the request\" without\n  stating what request, under what conditions.)\n- **Completeness**: Do the criteria collectively cover the intent in the\n  Summary, or are there implied requirements not captured in any criterion?\n  (Watch for: Summary describing three behaviours but only one criterion.)\n\n**Kind-specific verification** (based on work item kind):\n\n- **Story framing**: Are criteria expressed as observable behaviours rather than\n  implementation instructions? (Watch for: \"use a database index\" instead of\n  \"search results return within 200ms for queries over 1M records\".)\n- **Bug reproduction**: Is the bug's trigger fully specified — the exact input,\n  the exact action, the expected result, and the actual result? (Watch for:\n  \"clicking save causes an error\" with no detail on which save action, what\n  data, or what error.)\n- **Spike exit criteria**: Are the deliverables concrete — a named document,\n  specific benchmark results, an explicit decision recorded somewhere? (Watch\n  for: \"have a good understanding\", \"explore options\", \"figure out the best\n  approach\".)\n\n**Unbounded language** (always applicable):\n\n- **Scope creep language**: Do any criteria use \"all\", \"any\", \"every\", \"handle\n  all cases\", or similar unbounded terms without a defined scope? (Watch for:\n  \"all edge cases are handled\", \"every user scenario is supported\".)\n- **Tautological criteria**: Could a criterion be argued as always met? (Watch\n  for: \"the feature works\", \"the implementation is correct\", \"no regressions\n  are introduced\".)\n\n## Important Guidelines\n\n- **Do not read source code or run codebase exploration agents** — work item\n  content is the sole artefact under review\n- **Rate confidence** on each finding — distinguish definite failures (a\n  criterion with no measurable outcome) from judgements (a criterion that\n  could be interpreted as adequate by a generous reader)\n- **Be constructive** — when a criterion is untestable, suggest a concrete\n  rephrasing that would make it testable, including a specific threshold or\n  example if helpful\n- **Do not require Given\u002FWhen\u002FThen format explicitly** — any unambiguous\n  specification of precondition, action, and expected outcome is acceptable;\n  flag the missing component, not the missing keyword\n- **Consider the work item kind** — a spike with \"produce a 1-page decision memo\"\n  as exit criteria is adequately testable; do not over-apply story criteria to\n  other kinds\n\n## What NOT to Do\n\n- Don't assess whether sections exist or are populated — that is the\n  completeness lens\n- Don't flag ambiguous language, unclear referents, or undefined terms —\n  that is the clarity lens\n- Don't assess scope appropriateness or dependency graph completeness — those\n  are the scope and dependency lenses\n- Don't read source code, run codebase exploration agents, or make inferences\n  about the implementation beyond what the work item explicitly states\n- Don't require a specific test framework, format, or methodology — assess\n  whether the specification is verifiable, not how it will be verified\n\nRemember: You're evaluating whether the specification gives a tester — or any\nverifier — everything they need to confirm the work is done correctly. A\ntestable specification leaves no room for \"this could be interpreted either\nway\" when the test is run.\n",{"name":5,"description":7,"user-invocable":31,"disable-model-invocation":35},true,"main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Freview\u002Flenses\u002Ftestability-lens",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":45,"prompt":55,"zipAvailable":35},[46,49,52],{"tool":47,"command":48},"npx","npx skills add atomicinnovation\u002Faccelerator --skill testability",{"tool":50,"command":51},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill testability",{"tool":53,"command":54},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill testability","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002FSKILL.md",[57,63,67,71,75,79,83,87,91,95,99,103,107,111,117,121,125],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"docs\u002Flocal-data-sources.md","REFERENCE","参考文档",7676,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__ArtemXTech--wispr-flow\u002Fdocs\u002Flocal-data-sources.md",{"path":64,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":65,"sourceHtmlUrl":66},"docs\u002Fschema.md",2547,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__ArtemXTech--wispr-flow\u002Fdocs\u002Fschema.md",{"path":68,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":69,"sourceHtmlUrl":70},"docs\u002Fspace-management.md",1644,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__ArtemXTech--wispr-flow\u002Fdocs\u002Fspace-management.md",{"path":72,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":73,"sourceHtmlUrl":74},"docs\u002Ftroubleshooting.md",1669,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__ArtemXTech--wispr-flow\u002Fdocs\u002Ftroubleshooting.md",{"path":76,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":77,"sourceHtmlUrl":78},"evals\u002Fbenchmark.json",16661,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Fbenchmark.json",{"path":80,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":81,"sourceHtmlUrl":82},"evals\u002Fboundary_benchmark.json",4161,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Fboundary_benchmark.json",{"path":84,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":85,"sourceHtmlUrl":86},"evals\u002Fboundary_evals.json",2420,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Fboundary_evals.json",{"path":88,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":89,"sourceHtmlUrl":90},"evals\u002Fevals.json",5533,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Fevals.json",{"path":92,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":93,"sourceHtmlUrl":94},"evals\u002Ffiles\u002Fbug-incomplete-repro-spec\u002Fwork-item.md",1053,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Ffiles\u002Fbug-incomplete-repro-spec\u002Fwork-item.md",{"path":96,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":97,"sourceHtmlUrl":98},"evals\u002Ffiles\u002Fclean-work-item\u002Fwork-item.md",2139,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Ffiles\u002Fclean-work-item\u002Fwork-item.md",{"path":100,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":101,"sourceHtmlUrl":102},"evals\u002Ffiles\u002Fspike-open-ended-exit\u002Fwork-item.md",1141,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Ffiles\u002Fspike-open-ended-exit\u002Fwork-item.md",{"path":104,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":105,"sourceHtmlUrl":106},"evals\u002Ffiles\u002Ftautological-ac\u002Fwork-item.md",1287,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Ffiles\u002Ftautological-ac\u002Fwork-item.md",{"path":108,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":109,"sourceHtmlUrl":110},"evals\u002Ffiles\u002Fvague-unmeasurable-ac\u002Fwork-item.md",1186,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Ftestability-lens\u002Fevals\u002Ffiles\u002Fvague-unmeasurable-ac\u002Fwork-item.md",{"path":112,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Fcreate-dashboard.py","SCRIPT","脚本",8029,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__ArtemXTech--wispr-flow\u002Fscripts\u002Fcreate-dashboard.py",{"path":118,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":119,"sourceHtmlUrl":120},"scripts\u002Fexport-data.py",4589,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__ArtemXTech--wispr-flow\u002Fscripts\u002Fexport-data.py",{"path":122,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":123,"sourceHtmlUrl":124},"scripts\u002Fget-stats.py",5081,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__ArtemXTech--wispr-flow\u002Fscripts\u002Fget-stats.py",{"path":126,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":127,"sourceHtmlUrl":128},"scripts\u002Fsearch-history.py",2690,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__ArtemXTech--wispr-flow\u002Fscripts\u002Fsearch-history.py",[130,166,190,212,227,250],{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":146,"publishedAt":30},"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",[136,141],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,19,164,165],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","when","number","URL","Bash","code","architecture","reviewer","notes","change",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":30},"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",[],[22,173,174,175,176,177,178,160,165,179,180,181,182,183,184,185,186,187,188,189],"update","update work item","work item","enforcement","manage","use","config","edit","validate","status","transition","frontmatter","Existing","tags","changes","fields","op",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":30},"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",[],[22,197,198,199,200,201,202,160,203,165,204,205,206,207,208,209,210,179,211,184,157],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":218,"publishedAt":30},"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",[],[219,22,220,197,198,221,29,222,223,224,28,26,225,226],"sync work items recovery","recovery","work-items","terminal","read","person","orders","pending",{"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":236,"publishedAt":30},"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",[233],{"categoryNo":234,"categoryName":235,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000008","测试与质量",[237,238,22,239,175,240,241,242,243,244,20,160,24,245,179,181,246,247,248,158,249,184],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","dependencies","implementation","grilling","user","gaps",{"skillNo":251,"name":252,"nameZh":6,"description":253,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":254,"categories":255,"keywords":256,"publishedAt":30},"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",[],[19,22,257,175,258,259,178,160,260,261,179,181,246,248,262,157,263,264,184,265],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path"]