[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXWMNMFXPC0X9SYXYDHFYZ":3,"skill-same:01M6DXWMNMFXPC0X9SYXYDHFYZ":97},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":43,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":45,"install":46,"resources":58},"01M6DXWMNMFXPC0X9SYXYDHFYZ","completeness",null,"Work-item review lens for evaluating structural and informational completeness — section presence, content density, kind-appropriate content, and frontmatter integrity. 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\u002Fcompleteness-lens\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31],"review","content","integrity","work","structural","false","lens","presence","kind","true","for","frontmatter","section","2026-11-10 10:12:30",false,"---\nname: completeness\ndescription: Work-item review lens for evaluating structural and informational\n  completeness — section presence, content density, kind-appropriate content,\n  and frontmatter integrity. Used by review orchestrators — not invoked directly.\nuser-invocable: false\ndisable-model-invocation: true\n---\n\n# Completeness Lens\n\nReview as a work item completeness specialist ensuring that every section contains\nthe information a reader needs to understand and act on the work item without\nfollow-up questions.\n\n## Core Responsibilities\n\n1. **Assess Section Presence and Content Density**\n\n- Verify all expected sections exist and contain substantive content\n- Identify sections that are present but empty, placeholder-only, or too sparse\n  to be useful\n- Check that the Summary provides a clear, unambiguous statement of intent\n- Verify Acceptance Criteria exist and contain at least one specific criterion\n\n2. **Evaluate Kind-Appropriate Content**\n\n- Confirm the work item contains the content its `kind` demands:\n  - **Bug**: reproduction steps (input, action, expected outcome, actual outcome)\n  - **Story**: context explaining why the feature is wanted, plus criteria that\n    define when the story is done\n  - **Spike**: a scoped question, time-box or effort constraint, and enumerable\n    exit criteria (deliverables or decisions to be made)\n  - **Epic**: a list of constituent child stories or a decomposition strategy\n  - **Chore \u002F Task**: clear definition of the work to be done\n- For unknown or absent `kind`, treat the work item as a generic work item and\n  assess based on available fields\n\n3. **Check Context, Assumptions, and Section Population**\n\n- Assess whether the Context section explains the forces behind the work item\n- Check whether Dependencies, Assumptions, and Open Questions are populated\n  where relevant (empty sections are acceptable only when the content is\n  genuinely not applicable)\n- Note missing *sections* whose absence makes the work item under-specified for\n  its kind (e.g., a story with no Context section, an epic with no Stories\n  list). Do not reason about *content* within a present section —\n  implied-but-uncaptured couplings (blockers, consumers, external systems,\n  ordering) are the `dependency` lens's domain; unmeasurable criteria within\n  a present Acceptance Criteria section are the `testability` lens's domain\n\n4. **Verify Frontmatter Integrity**\n\n- Confirm `kind` is present and set to a recognised value\n- Check `status`, `priority`, and other required frontmatter fields are present\n- Flag absent or clearly incorrect frontmatter values\n\n## Key Evaluation Questions\n\n**Structural completeness** (always applicable):\n\n- **Summary**: Does the Summary state what is being done or built as a single,\n  unambiguous noun phrase or action statement? (Watch for: vague titles like\n  \"Fix stuff\", missing the subject of the work.)\n- **Acceptance Criteria**: Are there at least two specific, testable criteria\n  that define what \"done\" means? (Watch for: absent section, single vague\n  criterion like \"the feature works\", criteria with no measurable outcome.)\n- **Context**: Does the Context explain *why* this work is needed — the\n  motivation, the problem being solved, or the opportunity being captured?\n  (Watch for: empty context, context that only restates the summary.)\n- **Requirements**: Are the requirements specific enough that an implementer\n  could start work without asking for clarification? (Watch for: requirements\n  that describe desired outcomes but not the actual work, requirements that\n  duplicate acceptance criteria without adding detail.)\n\n**Kind-specific content** (based on work item kind):\n\n- **Bug**: Are reproduction steps present — does the work item include the specific\n  input, the action taken, the expected outcome, and the actual outcome? (Watch\n  for: \"it crashes\" with no steps, no environment details when relevant.)\n  Treat these four elements as a single logical unit: if any are absent, report\n  them together in one finding — not as separate findings for \"missing expected\n  outcome\" and \"missing actual outcome\".\n- **Story**: Is the user or system whose need is being met identified? Are all\n  criteria specific enough to verify? (Watch for: criteria describing\n  implementation details rather than outcomes, missing \"for whom\".)\n- **Spike**: Is the scoped question explicit? Are the exit criteria enumerable\n  artefacts or decisions rather than vague \"understand X\"? (Watch for: spikes\n  with open-ended exit criteria, no time-box or effort constraint.)\n- **Epic**: Is there a decomposition strategy — a list of child stories or a\n  description of how the epic will be broken down? (Watch for: epics with a\n  summary and nothing else.)\n\n**Frontmatter integrity** (always applicable):\n\n- **Kind field**: Is `kind` present and set to a recognised value? (Watch for:\n  absent `kind`, values like `unknown` or `tbd`.)\n- **Status field**: Is `status` present and appropriate for a work item in its\n  current state?\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 gaps (section\n  absent) from judgement calls (context deemed insufficient)\n- **Be proportional** — a spike requires less detail than an epic; a chore\n  requires less than a story; flag missing content relative to the work item kind\n- **Treat empty-but-optional sections fairly** — an empty Dependencies section\n  on a standalone chore is not a finding; an empty Dependencies section on a\n  feature with obvious external coupling may be flagged as potentially sparse.\n  If you flag it, note only that the section appears sparse relative to the\n  work item's content — do not name which external systems or services are implied.\n  Identifying specific implied couplings is the `dependency` lens's job.\n- **Focus on actionability** — flag gaps that would cause confusion, rework, or\n  delay during implementation; do not flag trivially resolvable gaps\n\n## What NOT to Do\n\n- Don't evaluate whether Acceptance Criteria are measurable or verifiable —\n  that is the testability lens\n- Don't flag ambiguous language, unclear referents, or jargon — that is the\n  clarity lens\n- Don't assess scope appropriateness or dependency graph completeness — those\n  are the scope and dependency lenses\n- Don't flag missing scenarios, edge cases, error-handling paths, default\n  behaviours, or unstated non-functional requirements — the lens measures\n  whether sections are present and substantively populated, not whether every\n  conceivable scenario is enumerated. What the work item doesn't mention may be\n  intentionally left to implementation judgment.\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 penalise a work item for lacking content that is genuinely not applicable\n  to its kind or context\n- Don't apply a rigid checklist regardless of work item kind — assess what the\n  kind requires\n\nRemember: You're evaluating whether the work item gives a reader everything they\nneed to understand the work and take action without asking the author follow-up\nquestions. A complete work item makes the right information present in the right\nplace.\n","# Completeness Lens\n\nReview as a work item completeness specialist ensuring that every section contains\nthe information a reader needs to understand and act on the work item without\nfollow-up questions.\n\n## Core Responsibilities\n\n1. **Assess Section Presence and Content Density**\n\n- Verify all expected sections exist and contain substantive content\n- Identify sections that are present but empty, placeholder-only, or too sparse\n  to be useful\n- Check that the Summary provides a clear, unambiguous statement of intent\n- Verify Acceptance Criteria exist and contain at least one specific criterion\n\n2. **Evaluate Kind-Appropriate Content**\n\n- Confirm the work item contains the content its `kind` demands:\n  - **Bug**: reproduction steps (input, action, expected outcome, actual outcome)\n  - **Story**: context explaining why the feature is wanted, plus criteria that\n    define when the story is done\n  - **Spike**: a scoped question, time-box or effort constraint, and enumerable\n    exit criteria (deliverables or decisions to be made)\n  - **Epic**: a list of constituent child stories or a decomposition strategy\n  - **Chore \u002F Task**: clear definition of the work to be done\n- For unknown or absent `kind`, treat the work item as a generic work item and\n  assess based on available fields\n\n3. **Check Context, Assumptions, and Section Population**\n\n- Assess whether the Context section explains the forces behind the work item\n- Check whether Dependencies, Assumptions, and Open Questions are populated\n  where relevant (empty sections are acceptable only when the content is\n  genuinely not applicable)\n- Note missing *sections* whose absence makes the work item under-specified for\n  its kind (e.g., a story with no Context section, an epic with no Stories\n  list). Do not reason about *content* within a present section —\n  implied-but-uncaptured couplings (blockers, consumers, external systems,\n  ordering) are the `dependency` lens's domain; unmeasurable criteria within\n  a present Acceptance Criteria section are the `testability` lens's domain\n\n4. **Verify Frontmatter Integrity**\n\n- Confirm `kind` is present and set to a recognised value\n- Check `status`, `priority`, and other required frontmatter fields are present\n- Flag absent or clearly incorrect frontmatter values\n\n## Key Evaluation Questions\n\n**Structural completeness** (always applicable):\n\n- **Summary**: Does the Summary state what is being done or built as a single,\n  unambiguous noun phrase or action statement? (Watch for: vague titles like\n  \"Fix stuff\", missing the subject of the work.)\n- **Acceptance Criteria**: Are there at least two specific, testable criteria\n  that define what \"done\" means? (Watch for: absent section, single vague\n  criterion like \"the feature works\", criteria with no measurable outcome.)\n- **Context**: Does the Context explain *why* this work is needed — the\n  motivation, the problem being solved, or the opportunity being captured?\n  (Watch for: empty context, context that only restates the summary.)\n- **Requirements**: Are the requirements specific enough that an implementer\n  could start work without asking for clarification? (Watch for: requirements\n  that describe desired outcomes but not the actual work, requirements that\n  duplicate acceptance criteria without adding detail.)\n\n**Kind-specific content** (based on work item kind):\n\n- **Bug**: Are reproduction steps present — does the work item include the specific\n  input, the action taken, the expected outcome, and the actual outcome? (Watch\n  for: \"it crashes\" with no steps, no environment details when relevant.)\n  Treat these four elements as a single logical unit: if any are absent, report\n  them together in one finding — not as separate findings for \"missing expected\n  outcome\" and \"missing actual outcome\".\n- **Story**: Is the user or system whose need is being met identified? Are all\n  criteria specific enough to verify? (Watch for: criteria describing\n  implementation details rather than outcomes, missing \"for whom\".)\n- **Spike**: Is the scoped question explicit? Are the exit criteria enumerable\n  artefacts or decisions rather than vague \"understand X\"? (Watch for: spikes\n  with open-ended exit criteria, no time-box or effort constraint.)\n- **Epic**: Is there a decomposition strategy — a list of child stories or a\n  description of how the epic will be broken down? (Watch for: epics with a\n  summary and nothing else.)\n\n**Frontmatter integrity** (always applicable):\n\n- **Kind field**: Is `kind` present and set to a recognised value? (Watch for:\n  absent `kind`, values like `unknown` or `tbd`.)\n- **Status field**: Is `status` present and appropriate for a work item in its\n  current state?\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 gaps (section\n  absent) from judgement calls (context deemed insufficient)\n- **Be proportional** — a spike requires less detail than an epic; a chore\n  requires less than a story; flag missing content relative to the work item kind\n- **Treat empty-but-optional sections fairly** — an empty Dependencies section\n  on a standalone chore is not a finding; an empty Dependencies section on a\n  feature with obvious external coupling may be flagged as potentially sparse.\n  If you flag it, note only that the section appears sparse relative to the\n  work item's content — do not name which external systems or services are implied.\n  Identifying specific implied couplings is the `dependency` lens's job.\n- **Focus on actionability** — flag gaps that would cause confusion, rework, or\n  delay during implementation; do not flag trivially resolvable gaps\n\n## What NOT to Do\n\n- Don't evaluate whether Acceptance Criteria are measurable or verifiable —\n  that is the testability lens\n- Don't flag ambiguous language, unclear referents, or jargon — that is the\n  clarity lens\n- Don't assess scope appropriateness or dependency graph completeness — those\n  are the scope and dependency lenses\n- Don't flag missing scenarios, edge cases, error-handling paths, default\n  behaviours, or unstated non-functional requirements — the lens measures\n  whether sections are present and substantively populated, not whether every\n  conceivable scenario is enumerated. What the work item doesn't mention may be\n  intentionally left to implementation judgment.\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 penalise a work item for lacking content that is genuinely not applicable\n  to its kind or context\n- Don't apply a rigid checklist regardless of work item kind — assess what the\n  kind requires\n\nRemember: You're evaluating whether the work item gives a reader everything they\nneed to understand the work and take action without asking the author follow-up\nquestions. A complete work item makes the right information present in the right\nplace.\n",{"name":5,"description":7,"user-invocable":33,"disable-model-invocation":37},true,"main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Freview\u002Flenses\u002Fcompleteness-lens",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-13 03:45:46",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":37},[48,51,54],{"tool":49,"command":50},"npx","npx skills add atomicinnovation\u002Faccelerator --skill completeness",{"tool":52,"command":53},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill completeness",{"tool":55,"command":56},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill completeness","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002FSKILL.md",[59,65,69,73,77,81,85,89,93],{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"evals\u002Fbenchmark.json","REFERENCE","参考文档",16515,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Fbenchmark.json",{"path":66,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":67,"sourceHtmlUrl":68},"evals\u002Fboundary_benchmark.json",4226,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Fboundary_benchmark.json",{"path":70,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":71,"sourceHtmlUrl":72},"evals\u002Fboundary_evals.json",2497,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Fboundary_evals.json",{"path":74,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":75,"sourceHtmlUrl":76},"evals\u002Fevals.json",5564,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Fevals.json",{"path":78,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":79,"sourceHtmlUrl":80},"evals\u002Ffiles\u002Fbug-missing-repro-steps\u002Fwork-item.md",1829,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Ffiles\u002Fbug-missing-repro-steps\u002Fwork-item.md",{"path":82,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":83,"sourceHtmlUrl":84},"evals\u002Ffiles\u002Fclean-work-item\u002Fwork-item.md",3061,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Ffiles\u002Fclean-work-item\u002Fwork-item.md",{"path":86,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":87,"sourceHtmlUrl":88},"evals\u002Ffiles\u002Fepic-no-decomposition\u002Fwork-item.md",1411,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Ffiles\u002Fepic-no-decomposition\u002Fwork-item.md",{"path":90,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":91,"sourceHtmlUrl":92},"evals\u002Ffiles\u002Fmissing-acceptance-criteria\u002Fwork-item.md",1819,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Ffiles\u002Fmissing-acceptance-criteria\u002Fwork-item.md",{"path":94,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":95,"sourceHtmlUrl":96},"evals\u002Ffiles\u002Fsparse-context-implied-deps\u002Fwork-item.md",1767,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcompleteness-lens\u002Fevals\u002Ffiles\u002Fsparse-context-implied-deps\u002Fwork-item.md",[98,134,157,179,194,219],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":114,"publishedAt":32},"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",[104,109],{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,19,132,133],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","when","number","URL","Bash","code","architecture","reviewer","notes","change",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":32},"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,141,142,143,144,145,146,128,133,147,148,149,150,151,30,152,153,154,155,156],"update","update work item","work item","enforcement","manage","use","config","edit","validate","status","transition","Existing","tags","changes","fields","op",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":32},"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,164,165,166,167,168,169,128,170,133,171,172,173,174,175,176,177,147,178,30,125],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":32},"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",[],[186,22,187,164,165,188,29,189,190,191,28,24,192,193],"sync work items recovery","recovery","work-items","terminal","read","person","orders","pending",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":203,"publishedAt":32},"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",[200],{"categoryNo":201,"categoryName":202,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000008","测试与质量",[204,205,22,206,143,207,208,209,210,211,212,128,213,214,147,149,215,216,217,126,218,30],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","user","gaps",{"skillNo":220,"name":221,"nameZh":6,"description":222,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":223,"categories":224,"keywords":225,"publishedAt":32},"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,226,143,227,228,146,128,229,230,147,149,215,217,231,125,232,233,30,234],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path"]