[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXZ6415HHBXY68ZCFMQEPJ":3,"skill-same:01M6DXZ6415HHBXY68ZCFMQEPJ":70},{"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":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":47,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6DXZ6415HHBXY68ZCFMQEPJ","list-work-items",null,"List and filter work items from the configured work directory. Use when discovering what work items exist, filtering by status\u002Fkind\u002Fpriority\u002Fparent\u002Ftag, or viewing the work item hierarchy.","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\u002Flist-work-items\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32],"work","list","list work items","directory","config","status","Bash","filtering","use","filter","kind","hierarchy","when","work item","2026-11-10 10:12:30",false,"---\nname: list-work-items\ndescription: List and filter work items from the configured work directory.\n  Use when discovering what work items exist, filtering by\n  status\u002Fkind\u002Fpriority\u002Fparent\u002Ftag, or viewing the work item hierarchy.\nargument-hint: \"[filter description]\"\nallowed-tools:\n  - Bash(accelerator config *)\n  - Bash(accelerator work *)\n---\n\n# List Work Items\n\n!`accelerator config context --skill list-work-items --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**Work item ID pattern**: !`accelerator config work id_pattern --fail-safe`\n**Local ID prefix**: !`accelerator config work key --fail-safe`\n**Active integration**: !`accelerator config work integration --fail-safe`\n\nThe reads above inform how you parse the filter argument. `accelerator work\nlist` owns the sync-status rendering itself: it adds the Sync column only when\na `last-sync.json` baseline exists for the configured `work.integration` or\nsome listed item is a draft, and degrades to presence-only when the remote is\nunreachable — you do not branch on the integration here.\n\n## Work Item Template\n\nThe following template defines the work item schema and field defaults.\n\n!`accelerator config template work-item --fail-safe`\n\n**Known kind values**: !`accelerator work template-hints kind`\n**Known status values**: !`accelerator work template-hints status`\n**Known priority values**: !`accelerator work template-hints priority`\n\nEach line above lists one value per line. Collect these into three sets:\nknown kinds, known statuses, and known priorities. These hints inform\nthe filter shorthand rules below but do not restrict what values may\nappear on work items — legacy values like `todo`, `done`, or\n`adr-creation-task` are matchable only via the explicit structured form\n(rule 2).\n\nYou are tasked with listing and filtering work items from the configured\nwork items directory. This is a **read-only** skill — never write any files\nand never spawn sub-agents. Your job is to parse the user's natural-language\nfilter into `accelerator work list`'s flags and present its output; the CLI\nowns the scan, filter, sync classification, and table\u002Fhierarchy rendering.\n\n## Step 1: Resolve Filter\n\nIf an argument was provided, parse it as a filter expression using the\nfollowing precedence rules (rules 3–4 use the known kind\u002Fstatus\u002Fpriority\nsets collected above). The first rule that matches wins.\n\n### Filter Precedence Rules\n\n**Rule 1 — Presentation keywords** (changes rendering, not filtering):\n`hierarchy`, `as a tree`, `show hierarchy`. These may combine with a\nfilter (e.g. `hierarchy under 0042`). Strip the keyword from the\nargument and continue parsing the remainder, if any, through rules 2–5.\n\n**Rule 2 — Explicit structured forms** (keyword identifies the field):\n- `tagged \u003Cvalue>` or `with tag \u003Cvalue>` → filter by tag\n- `under \u003Cvalue>` or `children of \u003Cvalue>` → filter by parent\n- `status \u003Cvalue>` → filter by status (matches any value on any work item)\n- `kind \u003Cvalue>` → filter by kind (matches any value on any work item)\n- `priority \u003Cvalue>` → filter by priority\n- `about \u003Ctext>` → free-text title search (case-insensitive substring)\n\n**Rule 3 — Multi-token template-value shorthand**: two or more tokens\nthat each match a known template-comment value in different fields.\nFor example, `bugs in review` → `kind: bug AND status: review` (after\nsingularising `bugs` to `bug` and recognising `in-progress`, `review`,\netc. as status values with filler words like `in`, `only`, `all`\nstripped). Both tokens must match values from distinct fields. If either\ntoken is ambiguous across fields, fall through to rule 5.\n\n**Rule 4 — Single-token template-value shorthand**: one token matching a\nknown kind, status, or priority value from the template comments. Map\ncommon plurals (`bugs`→`bug`, `epics`→`epic`, `stories`→`story`,\n`tasks`→`task`, `spikes`→`spike`) and common synonyms\n(`drafts`→`draft`). If the token matches values in more than one field,\nask the user for disambiguation rather than guessing.\n\n**Rule 5 — Free-text title search**: anything that does not match rules\n1–4 is treated as a case-insensitive substring search against the\n`title:` frontmatter field.\n\nIf no argument was provided: no filter — list every work item.\n\n### Translate the parsed filter into `work list` flags\n\nOnce the argument is parsed, map each recognised clause onto a concrete\nflag. This translation is the only work the skill does; the CLI applies the\nfilters and echoes the interpreted filter and match count itself, so do not\necho it separately.\n\n| Parsed clause | Flag |\n|---|---|\n| presentation keyword (`hierarchy`, `as a tree`) | `--hierarchy` |\n| `tagged X` \u002F `with tag X` (repeatable) | `--tag X` |\n| `under X` \u002F `children of X` | `--parent X` |\n| `status X`, or a status shorthand token | `--status X` |\n| `kind X`, or a kind shorthand token | `--kind X` |\n| `priority X` | `--priority X` |\n| `about X`, or free-text (rule 5) | positional `X` (last argument) |\n\nA multi-token shorthand (rule 3, e.g. `bugs in review`) becomes several\nflags (`--kind bug --status review`). Pass the canonical value the parse\nresolved (singularised, synonym-mapped); `--parent` is canonicalised by the\nCLI, so pass the bare form the user gave. Every flag is a conjunct — an item\nmust satisfy all of them.\n\n## Step 2: Run `work list` and present its output\n\nInvoke the CLI with the translated flags:\n\n```\naccelerator work list \\\n  [--status \u003Cs>] [--kind \u003Ck>] [--priority \u003Cp>] [--parent \u003Cref>] \\\n  [--tag \u003Ct>]... [--hierarchy] [\u003Ctitle-substring>]\n```\n\nThe CLI does everything the previous scan\u002Ffilter\u002Frender steps did, so there\nis nothing to reconstruct in prose:\n\n- **Scan and validity.** It reads every `*.md` file in the work directory\n  and in its `drafts\u002F` subdirectory, treats a file as a work item only when\n  it has closed frontmatter and a non-empty `id` (or legacy `work_item_id`),\n  silently excludes non-items, and warns\n  `\"\u003Cfilename>: skipped — no frontmatter\"` \u002F `\"… unclosed frontmatter\"` on\n  malformed files. The frontmatter `id` is the displayed ID.\n- **Drafts.** A draft item lives in `drafts\u002F` under a provisional\n  `draft-xxxxxx` ID because no tracker has confirmed it yet. Being a draft\n  item is unrelated to `status: draft`: a draft item can carry any status,\n  and a `status: draft` item need not be a draft item.\n- **Filter.** Each flag is applied as a conjunct; `--parent` canonicalises\n  both sides (short and long ID forms compare equal); the title term is a\n  case-insensitive substring. The CLI prints the interpreted filter and\n  match count itself (`Filter: status=draft (3 matches)`, `Children of 0042\n  (2 matches)`, or `All work items (29 total)`).\n- **Sync column.** It appends a **Sync** column when a `last-sync.json`\n  baseline exists for the configured `work.integration` or any listed item\n  is a draft, and omits it otherwise. A draft item always reads `? draft`.\n  With a baseline, every other item carries the five-state label vocabulary\n  (`? synced`, `⚪ unsynced`, `? locally modified`, `? remotely modified`,\n  `? conflict`), driven by one bulk remote read through the shared\n  classifier; without one it carries the presence-only label (`? synced`\n  when it has an `external_id`, else `⚪ unsynced`). If the remote is\n  unreachable it degrades to presence-only and still exits 0 — never\n  retrying or hanging.\n- **Hierarchy.** `--hierarchy` renders the parent\u002Fchild tree with Unicode\n  box-drawing characters, appends each line's sync label, marks an\n  out-of-set parent `(parent … not found)`, and detects cycles so rendering\n  always terminates.\n\n  The parent\u002Fchild tree renders as, for example:\n\n\u003C!-- canonical-tree-fence -->\nNNNN — parent title (kind: \u003Ckind>, status: \u003Cstatus>)\n  ├── NNNN — child 1 title (kind: \u003Ckind>, status: \u003Cstatus>)\n  ├── NNNN — child 2 title (kind: \u003Ckind>, status: \u003Cstatus>)\n  └── NNNN — last child title (kind: \u003Ckind>, status: \u003Cstatus>)\n\u003C!-- \u002Fcanonical-tree-fence -->\n\n- **Empty and missing.** A directory that does not exist prints the\n  `paths.work` guidance and exits 0; an empty directory prints `No work\n  items found in …`; a filter that matches nothing prints `No work items\n  matched: …` rather than an empty table.\n\nPrint the CLI's stdout to the user as-is (it is markdown-native — a table or\ntree the conversation renders directly), and surface any stderr warnings it\nemitted. Do not re-echo the filter or re-render the table.\n\n## Quality Guidelines\n\n- **Read-only**: never write any files. This skill only reads and\n  displays.\n- **No sub-agents**: never spawn sub-agents. All work is a natural-language\n  filter parse plus one `accelerator work list` invocation.\n- **No hardcoded field values**: never assume a specific set of status,\n  kind, or priority values. The template's comments list shipping\n  defaults, not a closed set. Users may override the template with\n  custom values.\n- **Explicit structured filters are universal**: `status \u003Cvalue>`,\n  `kind \u003Cvalue>`, etc. match any value present on any work item, not just\n  template defaults. This is how legacy values like `todo` or\n  `adr-creation-task` are reachable.\n- **Resilient to malformed work items**: missing or unclosed frontmatter\n  must not crash the listing — warn using the resolved filename and\n  continue. Warning phrasing should match `work show`'s own errors:\n  \"no frontmatter\" \u002F \"unclosed frontmatter\".\n- **Frontmatter `id` is authoritative**: the `id` field (or\n  `work_item_id` on legacy files) is the work item ID, even if the\n  filename prefix differs. This applies to legacy bare-number,\n  project-coded, tracker-keyed and draft items alike.\n- **Hierarchy safety**: hierarchy rendering must terminate in bounded\n  time even if parent cycles exist. Detect cycles and render affected\n  work items flat with a marker.\n\n!`accelerator config instructions list-work-items --fail-safe`\n","# List Work Items\n\n!`accelerator config context --skill list-work-items --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**Work item ID pattern**: !`accelerator config work id_pattern --fail-safe`\n**Local ID prefix**: !`accelerator config work key --fail-safe`\n**Active integration**: !`accelerator config work integration --fail-safe`\n\nThe reads above inform how you parse the filter argument. `accelerator work\nlist` owns the sync-status rendering itself: it adds the Sync column only when\na `last-sync.json` baseline exists for the configured `work.integration` or\nsome listed item is a draft, and degrades to presence-only when the remote is\nunreachable — you do not branch on the integration here.\n\n## Work Item Template\n\nThe following template defines the work item schema and field defaults.\n\n!`accelerator config template work-item --fail-safe`\n\n**Known kind values**: !`accelerator work template-hints kind`\n**Known status values**: !`accelerator work template-hints status`\n**Known priority values**: !`accelerator work template-hints priority`\n\nEach line above lists one value per line. Collect these into three sets:\nknown kinds, known statuses, and known priorities. These hints inform\nthe filter shorthand rules below but do not restrict what values may\nappear on work items — legacy values like `todo`, `done`, or\n`adr-creation-task` are matchable only via the explicit structured form\n(rule 2).\n\nYou are tasked with listing and filtering work items from the configured\nwork items directory. This is a **read-only** skill — never write any files\nand never spawn sub-agents. Your job is to parse the user's natural-language\nfilter into `accelerator work list`'s flags and present its output; the CLI\nowns the scan, filter, sync classification, and table\u002Fhierarchy rendering.\n\n## Step 1: Resolve Filter\n\nIf an argument was provided, parse it as a filter expression using the\nfollowing precedence rules (rules 3–4 use the known kind\u002Fstatus\u002Fpriority\nsets collected above). The first rule that matches wins.\n\n### Filter Precedence Rules\n\n**Rule 1 — Presentation keywords** (changes rendering, not filtering):\n`hierarchy`, `as a tree`, `show hierarchy`. These may combine with a\nfilter (e.g. `hierarchy under 0042`). Strip the keyword from the\nargument and continue parsing the remainder, if any, through rules 2–5.\n\n**Rule 2 — Explicit structured forms** (keyword identifies the field):\n- `tagged \u003Cvalue>` or `with tag \u003Cvalue>` → filter by tag\n- `under \u003Cvalue>` or `children of \u003Cvalue>` → filter by parent\n- `status \u003Cvalue>` → filter by status (matches any value on any work item)\n- `kind \u003Cvalue>` → filter by kind (matches any value on any work item)\n- `priority \u003Cvalue>` → filter by priority\n- `about \u003Ctext>` → free-text title search (case-insensitive substring)\n\n**Rule 3 — Multi-token template-value shorthand**: two or more tokens\nthat each match a known template-comment value in different fields.\nFor example, `bugs in review` → `kind: bug AND status: review` (after\nsingularising `bugs` to `bug` and recognising `in-progress`, `review`,\netc. as status values with filler words like `in`, `only`, `all`\nstripped). Both tokens must match values from distinct fields. If either\ntoken is ambiguous across fields, fall through to rule 5.\n\n**Rule 4 — Single-token template-value shorthand**: one token matching a\nknown kind, status, or priority value from the template comments. Map\ncommon plurals (`bugs`→`bug`, `epics`→`epic`, `stories`→`story`,\n`tasks`→`task`, `spikes`→`spike`) and common synonyms\n(`drafts`→`draft`). If the token matches values in more than one field,\nask the user for disambiguation rather than guessing.\n\n**Rule 5 — Free-text title search**: anything that does not match rules\n1–4 is treated as a case-insensitive substring search against the\n`title:` frontmatter field.\n\nIf no argument was provided: no filter — list every work item.\n\n### Translate the parsed filter into `work list` flags\n\nOnce the argument is parsed, map each recognised clause onto a concrete\nflag. This translation is the only work the skill does; the CLI applies the\nfilters and echoes the interpreted filter and match count itself, so do not\necho it separately.\n\n| Parsed clause | Flag |\n|---|---|\n| presentation keyword (`hierarchy`, `as a tree`) | `--hierarchy` |\n| `tagged X` \u002F `with tag X` (repeatable) | `--tag X` |\n| `under X` \u002F `children of X` | `--parent X` |\n| `status X`, or a status shorthand token | `--status X` |\n| `kind X`, or a kind shorthand token | `--kind X` |\n| `priority X` | `--priority X` |\n| `about X`, or free-text (rule 5) | positional `X` (last argument) |\n\nA multi-token shorthand (rule 3, e.g. `bugs in review`) becomes several\nflags (`--kind bug --status review`). Pass the canonical value the parse\nresolved (singularised, synonym-mapped); `--parent` is canonicalised by the\nCLI, so pass the bare form the user gave. Every flag is a conjunct — an item\nmust satisfy all of them.\n\n## Step 2: Run `work list` and present its output\n\nInvoke the CLI with the translated flags:\n\n```\naccelerator work list \\\n  [--status \u003Cs>] [--kind \u003Ck>] [--priority \u003Cp>] [--parent \u003Cref>] \\\n  [--tag \u003Ct>]... [--hierarchy] [\u003Ctitle-substring>]\n```\n\nThe CLI does everything the previous scan\u002Ffilter\u002Frender steps did, so there\nis nothing to reconstruct in prose:\n\n- **Scan and validity.** It reads every `*.md` file in the work directory\n  and in its `drafts\u002F` subdirectory, treats a file as a work item only when\n  it has closed frontmatter and a non-empty `id` (or legacy `work_item_id`),\n  silently excludes non-items, and warns\n  `\"\u003Cfilename>: skipped — no frontmatter\"` \u002F `\"… unclosed frontmatter\"` on\n  malformed files. The frontmatter `id` is the displayed ID.\n- **Drafts.** A draft item lives in `drafts\u002F` under a provisional\n  `draft-xxxxxx` ID because no tracker has confirmed it yet. Being a draft\n  item is unrelated to `status: draft`: a draft item can carry any status,\n  and a `status: draft` item need not be a draft item.\n- **Filter.** Each flag is applied as a conjunct; `--parent` canonicalises\n  both sides (short and long ID forms compare equal); the title term is a\n  case-insensitive substring. The CLI prints the interpreted filter and\n  match count itself (`Filter: status=draft (3 matches)`, `Children of 0042\n  (2 matches)`, or `All work items (29 total)`).\n- **Sync column.** It appends a **Sync** column when a `last-sync.json`\n  baseline exists for the configured `work.integration` or any listed item\n  is a draft, and omits it otherwise. A draft item always reads `? draft`.\n  With a baseline, every other item carries the five-state label vocabulary\n  (`? synced`, `⚪ unsynced`, `? locally modified`, `? remotely modified`,\n  `? conflict`), driven by one bulk remote read through the shared\n  classifier; without one it carries the presence-only label (`? synced`\n  when it has an `external_id`, else `⚪ unsynced`). If the remote is\n  unreachable it degrades to presence-only and still exits 0 — never\n  retrying or hanging.\n- **Hierarchy.** `--hierarchy` renders the parent\u002Fchild tree with Unicode\n  box-drawing characters, appends each line's sync label, marks an\n  out-of-set parent `(parent … not found)`, and detects cycles so rendering\n  always terminates.\n\n  The parent\u002Fchild tree renders as, for example:\n\n\u003C!-- canonical-tree-fence -->\nNNNN — parent title (kind: \u003Ckind>, status: \u003Cstatus>)\n  ├── NNNN — child 1 title (kind: \u003Ckind>, status: \u003Cstatus>)\n  ├── NNNN — child 2 title (kind: \u003Ckind>, status: \u003Cstatus>)\n  └── NNNN — last child title (kind: \u003Ckind>, status: \u003Cstatus>)\n\u003C!-- \u002Fcanonical-tree-fence -->\n\n- **Empty and missing.** A directory that does not exist prints the\n  `paths.work` guidance and exits 0; an empty directory prints `No work\n  items found in …`; a filter that matches nothing prints `No work items\n  matched: …` rather than an empty table.\n\nPrint the CLI's stdout to the user as-is (it is markdown-native — a table or\ntree the conversation renders directly), and surface any stderr warnings it\nemitted. Do not re-echo the filter or re-render the table.\n\n## Quality Guidelines\n\n- **Read-only**: never write any files. This skill only reads and\n  displays.\n- **No sub-agents**: never spawn sub-agents. All work is a natural-language\n  filter parse plus one `accelerator work list` invocation.\n- **No hardcoded field values**: never assume a specific set of status,\n  kind, or priority values. The template's comments list shipping\n  defaults, not a closed set. Users may override the template with\n  custom values.\n- **Explicit structured filters are universal**: `status \u003Cvalue>`,\n  `kind \u003Cvalue>`, etc. match any value present on any work item, not just\n  template defaults. This is how legacy values like `todo` or\n  `adr-creation-task` are reachable.\n- **Resilient to malformed work items**: missing or unclosed frontmatter\n  must not crash the listing — warn using the resolved filename and\n  continue. Warning phrasing should match `work show`'s own errors:\n  \"no frontmatter\" \u002F \"unclosed frontmatter\".\n- **Frontmatter `id` is authoritative**: the `id` field (or\n  `work_item_id` on legacy files) is the work item ID, even if the\n  filename prefix differs. This applies to legacy bare-number,\n  project-coded, tracker-keyed and draft items alike.\n- **Hierarchy safety**: hierarchy rendering must terminate in bounded\n  time even if parent cycles exist. Detect cycles and render affected\n  work items flat with a marker.\n\n!`accelerator config instructions list-work-items --fail-safe`\n",{"name":5,"description":7,"allowed-tools":38,"argument-hint":41},[39,40],"Bash(accelerator config *)","Bash(accelerator work *)","[filter description]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fwork\u002Flist-work-items",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":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add atomicinnovation\u002Faccelerator --skill list-work-items",{"tool":56,"command":57},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill list-work-items",{"tool":59,"command":60},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill list-work-items","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Flist-work-items\u002FSKILL.md",true,[64],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"scripts\u002Fwait_event.py","SCRIPT","脚本",21068,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fcoding-agents\u002Fskills\u002Fwait-for-event\u002Fscripts\u002Fwait_event.py",[71,106,126,148,166,191],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":87,"publishedAt":33},"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",[77,82],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[88,89,90,91,92,93,94,95,96,97,31,98,99,25,100,101,102,103,104,105],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","number","URL","code","architecture","reviewer","review","notes","change",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":33},"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",[],[19,113,114,32,115,116,27,25,105,23,117,118,24,119,120,121,122,123,124,125],"update","update work item","enforcement","manage","edit","validate","transition","frontmatter","Existing","tags","changes","fields","op",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":33},"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",[],[19,133,134,135,136,137,138,25,139,105,140,141,142,143,144,145,146,23,147,120,31],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":33},"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",[],[155,19,156,133,134,157,158,159,160,161,162,163,164,165],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"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":175,"publishedAt":33},"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",[172],{"categoryNo":173,"categoryName":174,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000008","测试与质量",[176,177,19,178,32,179,180,181,182,183,184,25,185,186,23,118,187,188,189,98,190,120],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","user","gaps",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":33},"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",[],[103,19,198,32,199,200,27,25,201,202,23,118,187,189,203,31,204,205,120,206],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path"]