[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXZ9NFRANRJX8ANC24ECHP":3,"skill-same:01M6DXZ9NFRANRJX8ANC24ECHP":383},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6DXZ9NFRANRJX8ANC24ECHP","refine-work-item",null,"Interactively refine a work item by decomposing it into children, enriching it with codebase context, sharpening its acceptance criteria, sizing it, or linking it to dependencies. Use after a work item has been drafted and before planning begins.","atomicinnovation\u002Faccelerator","atomicinnovation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F65866524?v=4","01M6DXP513JV585FN2QPNR6079","Atomic","01M6DXP55MPK99YVZ2HGMEN991",34,"MIT","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"work item","work","refine","refine work item","dependencies","codebase context","codebase","linking","frontmatter","path","number","with","validate","acceptance criteria","use","context","Bash","acceptance","planning","config","2026-11-10 10:12:30",false,"---\nname: refine-work-item\ndescription: Interactively refine a work item by decomposing it into children,\n  enriching it with codebase context, sharpening its acceptance criteria,\n  sizing it, or linking it to dependencies. Use after a work item has been\n  drafted and before planning begins.\nargument-hint: \"[work item number or path]\"\nallowed-tools:\n  - Bash(accelerator config *)\n  - Bash(accelerator work *)\n  - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Refine Work Item\n\n!`accelerator config context --skill refine-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**Active integration**: !`accelerator config work integration --fail-safe`\n**ID pattern**: !`accelerator config work id_pattern --fail-safe`\n\nWhen **ID pattern** is `{tracker}`, the tracker owns every item's `id`, so\ndecompose never allocates numbers: it creates each child as a **draft**\nthrough `accelerator work create` (see \"Under `{tracker}`\" in 4a), and\n`\u002Fsync-work-items` promotes the drafts later.\n\n## Work Item Template\n\nThe template below defines the sections and frontmatter fields that every\nwork item must contain. Read it now — use it to know valid kinds, statuses,\npriorities, and section names without re-reading the file at runtime.\n\n!`accelerator config template work-item --fail-safe`\n\nYou are tasked with refining a work item through one or more of five operations:\ndecompose it into child work items, enrich it with codebase context, sharpen\nvague acceptance criteria, add a t-shirt size indicator, or populate its\ndependencies. Every operation is interactive and targeted — you propose, the\nuser approves, and the Edit tool makes the minimum change needed.\n\n## Step 0 — Parameter Check\n\n**If no work item path or number was provided**, respond with:\n\n```\nI'll help you refine a work item. Please provide the path or work item number.\n\nExample: `\u002Frefine-work-item {work_dir}\u002F0042-user-auth.md`\nOr by number: `\u002Frefine-work-item 42`\n\nRun `\u002Flist-work-items` to see available work items.\n```\n\nThen wait for the user's input.\n\n**If a path or number was provided**: proceed to Step 1.\n\nAccepted forms:\n- A path (e.g. `meta\u002Fwork\u002F0042-user-auth.md`)\n- A bare work item number (e.g. `0042` or `42`, resolved against `{work_dir}`)\n\nIf the resolved path does not exist, report:\n```\nNo work item file at \u003Cpath> — run `\u002Flist-work-items` to see available work items.\n```\nand exit without reading any other file, spawning any agent, or writing anything.\n\nIf the YAML frontmatter cannot be parsed (missing closing `---` or syntax\nerror), report:\n```\nCould not parse frontmatter in \u003Cpath> — the file may be corrupted. Re-open it\nand check that the YAML frontmatter is bracketed by two `---` lines and\ncontains all nine required fields, or run `\u002Fupdate-work-item \u003Cpath>` which\nsurfaces the same diagnostic with field-level detail.\n```\nand exit without editing the file or spawning agents.\n\n## Step 1 — Read Target and Context\n\nRead the target work item fully. If the `parent` field is non-empty, also read\nthe parent work item. The work item template (loaded above) tells you the valid\nkinds, statuses, and priorities — do not re-read it at runtime.\n\n## Step 2 — Analyse (mandatory parallel agents)\n\nSpawn BOTH agents in the same tool-use turn (parallel, not sequential):\n\n- **{codebase locator agent}**: find files relevant to the work item's\n  Requirements and Summary\n- **{codebase analyser agent}**: analyse how the relevant components\n  currently work\n\nWait for both before presenting the menu. Even if the work item seems\nstraightforward, always spawn these agents — the menu previews depend\non their findings.\n\n## Step 3 — Present Refinement Menu\n\nPresent the five operations with one-line descriptions. Reference agent\nfindings in the previews so the user can pick informed:\n\n1. **decompose** — split into child work items (epic→stories, story→tasks);\n   e.g. \"Requirements suggest 3 child stories (R1, R2, R3)\"\n2. **enrich** — add Technical Notes from codebase analysis;\n   e.g. \"4 relevant files identified (src\u002Fauth\u002Fsession.ts, …)\"\n3. **sharpen** — tighten vague acceptance criteria;\n   e.g. \"2 vague criteria detected (AC3, AC5)\" or \"all criteria already testable\"\n4. **size** — append a t-shirt size indicator with rationale;\n   e.g. \"estimate M based on files in auth\u002F and session\u002F\"\n5. **link** — populate Dependencies from related work items;\n   e.g. \"1 potential blocker found (0031)\" or \"no related work items found\"\n\nOperations that have nothing to do should be marked as such (e.g.\n\"sharpen — all criteria already testable\").\n\nUser can select one, multiple, or \"all relevant\". Regardless of selection\norder, always execute in canonical order: **decompose → enrich → sharpen\n→ size → link**. This ensures Technical Notes content is in place before\nsize's `**Size**:` line is prepended, and decompose's children exist before\nany link operation references them.\n\n## Step 4 — Execute Operations\n\n### 4a. Decompose\n\nPropose 2–5 candidate children (2–4 for story decomposing to tasks) with\ndraft titles and one-line Summaries derived from the Requirements section.\n\n**Bug\u002Fspike challenge**: if the work item kind is `bug` or `spike`, first use\nthe `AskUserQuestion` tool with two options:\n\n1. **Yes, proceed anyway** — continue with decompose\n2. **No, cancel** — exit decompose and return to the menu\n\n**Existing children**: if the Requirements section already contains a\n`### Child work items` subsection, offer:\n```\nappend (add new children to the existing list) \u002F skip (do not decompose further) \u002F cancel\n```\nNever replace the existing list silently. For the append path, use the\nanchor described below under \"append to existing `### Child work items`\".\n\n**Approval grammar**: each proposal MUST include a one-line grammar legend\nimmediately under the numbered child list:\n```\nCommands: approve all | edit N: \u003Ctitle> | drop N | add: \u003Ctitle> | regenerate | cancel\n```\n\nThe legend appears on every proposal turn — the first proposal and after\nevery grammar iteration.\n\nProcess user input:\n- `approve all`, `yes`, `lgtm` → proceed to the pre-write warning\n- `edit N: \u003Cnew title>` → update child N's title, re-show updated proposal\n  with legend restated. Do NOT write.\n- `drop N` → remove child N, renumber remaining children 1…M, re-show\n  with legend. Do NOT write.\n- `add: \u003Ctitle>` → append a new child with that title, re-show with legend.\n  Do NOT write.\n- `regenerate` → discard current proposal, generate a fresh set of 2–5\n  candidates from the same Requirements. Do NOT write.\n- `cancel`, `abort` → print \"decompose cancelled — no children written\"\n  and return to the menu. No numbers allocated.\n- Any other input → print \"unrecognised command\", restate the legend, and\n  re-show the unchanged proposal unchanged. Do NOT treat as approval.\n\n**Pre-write warning**: before writing, use the `AskUserQuestion` tool with two\noptions. State the allocation count and warn about partial state:\n\n1. **Yes, proceed** — allocate N numbers and write N files (partial state is\n   possible if aborted mid-write; delete the newly-written child file(s) to\n   recover)\n2. **No, cancel** — cancel without writing\n\n**A re-key in progress.** `accelerator work next-number` and\n`accelerator work create` refuse before reading or writing anything while an\n`accelerator work rekey` run is unfinished. Before any other branch on a\nnon-zero exit from one of them, check its stderr for these codes; in every\ncase nothing was written:\n\n- `E_REKEY_IN_PROGRESS` (exit 4) — tell the user a re-key is unfinished:\n  run `\u002Frekey-work-items` to finish or undo it. Stop.\n- `E_REKEY_PLAN_UNREADABLE` (exit 4) — relay the printed remedy as is, never\n  suggesting the re-key be finished. Stop.\n- `E_IDENTITY_RUN_BUSY` (exit 1) — another identity command is still running;\n  retry once it ends.\n\n**On approval** under `{tracker}`: do not call `accelerator work\nnext-number` and do not write children with the `Write` tool. For each\nchild, write its body (H1 through the remaining template sections, with the\n`NNNN` placeholder left literally in place) to a scratch file and run:\n\n```\naccelerator work create \"\u003Cchild title>\" \u003Ckind> \u003Cpriority> \\\n  --status draft --author \"\u003Cresolved author>\" --producer refine-work-item \\\n  --parent \"work-item:\u003Cparent id>\" --body-file \u003Cscratch-file> \\\n  [--tag \u003Cvalue>]...\n```\n\nwith no `--push`, so each child is saved as a draft. Its stdout is the\ndraft's path; the draft's `id` is the `draft-` prefix of its filename, and\nthat is the ID the parent's `### Child work items` links and the ledger\nname. If a call exits non-zero, stop, relay its stderr, and list the\nchildren already written. Then continue at step 3 below. The pre-write\nwarning says \"create N drafts\" rather than \"allocate N numbers\".\n\n**On approval** under every other pattern:\n\n1. Call `accelerator work next-number --count N`\n   exactly once to allocate N consecutive numbers.\n\n2. For each child, write `NNNN-kebab-slug.md`, populating every unified\n   frontmatter field as specified under **Populate frontmatter** below.\n\n   Immediately before writing each child, verify the computed filename does\n   not already exist. If it does, abort with:\n   ```\n   Collision: \u003Cpath> already exists (concurrent session?). Aborting.\n   Allocated: NNNN, NNNN, …; Wrote: N-1 files (list them).\n   Delete the newly-written child file(s).\n   ```\n\n   Child body includes: Summary (from proposal), Context (linking to\n   parent with \"Child of NNNN — \u003Cparent title>\"), Requirements (minimal\n   but substantive; no `[bracketed placeholder]` text), Acceptance Criteria\n   (minimal but substantive; sharpen can tighten these later), Dependencies\n   (blank), and remaining template sections.\n\n3. **Append `### Child work items` to the parent's Requirements section**:\n\n   After all children are written successfully:\n   - Read the parent file\n   - Locate `\\n## Requirements\\n` and `\\n## Acceptance Criteria\\n`\n   - Extract the last non-empty line of Requirements (the line immediately\n     before the blank-line transition to Acceptance Criteria); call this\n     `\u003Creq_tail>`\n   - Build: `old_string` = `\u003Creq_tail>\\n\\n## Acceptance Criteria\\n`\n   - Build: `new_string` = `\u003Creq_tail>\\n\\n### Child work items\\n\\n- NNNN — title\\n…\\n\\n## Acceptance Criteria\\n`\n   - Edge case — empty Requirements: use `## Requirements\\n\\n## Acceptance Criteria\\n`\n     as `old_string` and insert `### Child work items` between them.\n   - Pre-Edit, count occurrences of `old_string` in the parent file. If not\n     exactly 1, abort the parent update with:\n     ```\n     Could not locate a unique '## Acceptance Criteria' anchor in \u003Cpath>\n     (matches found: \u003CN>). Parent not updated.\n     Children NNNN, NNNN, NNNN remain on disk; add their links manually,\n     or delete the newly-written child file(s) and re-run decompose.\n     ```\n     Children already written remain on disk.\n\n   **Append to existing `### Child work items`** (re-decompose path):\n   - Locate `### Child work items` subsection, find its last `- NNNN — title`\n     line; call this `\u003Clast_link>`\n   - Build: `old_string` = `\u003Clast_link>\\n\\n## Acceptance Criteria\\n`\n   - Build: `new_string` = `\u003Clast_link>\\n- NNNN — title\\n…\\n\\n## Acceptance Criteria\\n`\n   - Same uniqueness pre-check; same abort diagnostic if not exactly 1.\n\n4. Print a completion ledger, one line per child:\n   ```\n   Wrote NNNN — title\n   Wrote NNNN — title\n   Allocated 3 numbers, wrote 3 files.\n   ```\n   On aborted or partial write, show allocated vs. written counts and\n   list any written filenames.\n\nAfter a successful decompose, proceed to Step 5 (hierarchy display) before\nrunning any remaining operations.\n\n#### Populate frontmatter\n\nWhen writing each child (step 2 above), **substitute** every field below\nwith the indicated value:\n\n- `type:` ← `work-item`\n- `id:` ← from the script, zero-padded four-digit string\n  (own-identity; legacy files use `work_item_id`)\n- `title:` ← per-child proposal title; body H1 matches exactly\n- `date:` ← current UTC timestamp via `date -u +%Y-%m-%dT%H:%M:%S+00:00`\n- `author:` ← first match in chain: parent work item's `author` field →\n  configured `author` value (from context config) → the session's VCS user\n  identity (the user-identity idiom in the SessionStart VCS Command Reference,\n  which falls back to the git identity when the jj identity is unset, so\n  git-only and colocated repositories both resolve) → ask the user once and\n  apply to all children\n- `producer:` ← `refine-work-item`\n- `kind:` ← derived: `epic → story`, `story → task`, `bug`\u002F`spike` → ask\n  user to confirm before proceeding (already done in the challenge step),\n  any other kind → `story` with a one-line notice\n- `status:` ← literal `draft`\n- `priority:` ← inherit from parent; if parent has none, ask once and\n  apply to every child written in this session\n- `tags:` ← verbatim copy of the parent's `tags` array (empty array `[]`\n  if the parent has none)\n- `last_updated:` ← same UTC timestamp as `date`\n- `last_updated_by:` ← same author value resolved above\n- `schema_version:` ← `1`\n\nOptional linkage\u002Fforeign-ref keys are omit-by-default: the template shows\neach as `\"\"`\u002F`[]`, but write a key into the artifact **only** when it has a\nvalue, and omit it entirely otherwise (do not carry the empty placeholder\nthrough).\n\n- `parent:` ← the parent work item's ID as a typed-linkage ref `\"work-item:NNNN\"`,\n  where NNNN is the parent's `id` field — from `id` on unified files,\n  or `work_item_id` on legacy files — canonicalised to the configured\n  pattern's full-ID shape, e.g. `\"1\"` → `\"work-item:0001\"`. Always\n  fill — every decomposed child has a parent.\n- `blocks:` ← list of typed-linkage refs to work items this child\n  blocks (`[\"work-item:NNNN\", ...]`). Fill when blocking edges are\n  explicit; otherwise omit the key.\n- `blocked_by:` ← list of typed-linkage refs to work items that block\n  this child. Prefer writing the canonical `blocks:` on the other\n  side; emit `blocked_by:` only when the canonical side cannot be\n  written, and omit it otherwise.\n- `derived_from:` ← list of typed-linkage refs to artifacts this child\n  is derived from (`[\"plan:NNNN\", ...]`). Fill when derivation is\n  explicit; otherwise omit the key.\n- `relates_to:` ← list of typed-linkage refs to related artifacts.\n  Fill when relationships are explicit; otherwise omit the key.\n- `source:` ← typed-linkage ref to the originating source artifact\n  (`\"issue-research:NNNN\"`). Fill when the source is explicit;\n  otherwise omit the key.\n- `external_id:` ← cross-system pointer (e.g. a Jira\u002FLinear key). Fill\n  when propagated from the parent or linked to an external tracker;\n  otherwise omit the key.\n\n### 4b. Enrich\n\nRead the target work item's existing Technical Notes content.\n\nIf the codebase agents returned nothing concrete (no specific files or\ncomponents identified), report:\n```\nno enrichment could be grounded in code — skipping enrich\n```\nand make no Edit.\n\nOtherwise propose Technical Notes content with specific `path:line`\nreferences drawn from agent results. Do not invent references.\n\nIf non-trivial Technical Notes content already exists (anything beyond a\n`**Size**:` line), ask:\n```\nreplace (deletes existing Technical Notes) \u002F append (add after existing content) \u002F skip?\n```\n- `replace` → show a unified diff (old struck, new added) and require an\n  explicit second `y\u002Fn` confirmation before invoking Edit\n- `append` → add new content after existing content. Preserve any leading\n  `**Size**:` line placed by a prior size operation — never overwrite it\n- `skip` → make no Edit\n\nOn approval via Edit: modify only the Technical Notes section. Do not touch\nRequirements, Acceptance Criteria, Summary, or any frontmatter field.\n\n### 4c. Sharpen\n\nRead the target work item's Acceptance Criteria. Identify criteria that are\nvague or untestable (non-measurable phrases like \"should be fast\", \"handles\nerrors gracefully\", \"works correctly\").\n\nIf every criterion is already specific and testable, report:\n```\nall acceptance criteria already testable — nothing to sharpen\n```\nand make no Edit.\n\nOtherwise, for each vague criterion propose a specific, measurable rewrite\n(e.g. \"p95 latency under 200ms under default benchmark dataset\"). Skip\ncriteria that are already testable — only propose rewrites for vague ones.\nIterate with the user until each proposed rewrite is agreed.\n\nOn approval via Edit: modify only the Acceptance Criteria section with the\nagreed rewrites. Preserve criteria that were not sharpened byte-for-byte.\n\n### 4d. Size\n\nRead the target work item's Technical Notes. Check whether a `**Size**:` line\nalready exists as the first line.\n\nPropose a t-shirt size (`XS`, `S`, `M`, `L`, `XL`) with a rationale\nreferencing specific files or subsystems from agent results. Iterate with\nthe user.\n\nOn approval:\n- **No existing `**Size**:` line**: insert `**Size**: \u003Cvalue> — \u003Crationale>`\n  as the FIRST line of Technical Notes, followed by a blank line separating\n  it from any existing content. Do NOT add as a frontmatter key.\n- **Existing `**Size**:` line, proposed value AND rationale match byte-for-byte**\n  (ignoring leading\u002Ftrailing whitespace): report \"size unchanged — \u003Cvalue>\"\n  and make no Edit.\n- **Existing `**Size**:` line with a different value or rationale**: show a\n  unified diff of the proposed change (existing line struck, new line added)\n  then use the `AskUserQuestion` tool with two options:\n  1. **Yes, apply size change** — replace the line in place\n  2. **No, cancel** — make no Edit\n\n### 4e. Link\n\nCount `NNNN-*.md` files in `{work_dir}` using a single Glob invocation.\n\n- **Count ≤ 30**: read them directly via batched Read\n- **Count > 30**: spawn **{documents locator agent}** scoped to `{work_dir}`\n\nPropose `Blocked by:` and\u002For `Blocks:` entries in Dependencies, referencing\nonly real work item numbers (verify each proposed number exists before\nincluding it). If no related work items are found, print:\n```\nno related work items found — link skipped\n```\nand make no Edit.\n\nIf Dependencies already has non-empty content, ask:\n```\nreplace (overwrites existing entries) \u002F append (add new entries after existing) \u002F skip?\n```\n- `replace` → show a unified diff and require a second `y\u002Fn` confirmation\n- `append` → add only net-new entries, skipping any that duplicate existing\n  entries\n- `skip` → make no Edit\n\nOn approval via Edit: modify only the Dependencies section.\n\n**Validate the frontmatter**: after editing the work item, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cthe refined 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## Step 5 — Display Hierarchy\n\nRun immediately after decompose writes at least one child (skip if decompose\nwas cancelled, declined by user, or the parent Edit failed).\n\nRender the parent → children tree using the format pinned in `\u002Flist-work-items`:\nUnicode box-drawing characters, two-space indent per depth level, `├── ` for\nall children except the last, `└── ` for the last child. The canonical fence\nbelow MUST appear verbatim in this step's prose so the hierarchy-format guard\ncan verify byte-equality with the matching fence in\n`list-work-items\u002FSKILL.md`:\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\nConcrete work item IDs and titles replace the placeholders in the actual\noutput (e.g. `0042 — User Auth Rework (kind: epic)`). The status field\nof the parent is omitted only if blank; all present fields are shown.\n\nStep 5 runs inline after decompose completes, before enrich, sharpen, size,\nand link operate on the parent. The hierarchy is not re-rendered after\nsubsequent operations.\n\n## Step 6 — Offer Review\n\nAfter the entire selected operation set completes, use the `AskUserQuestion`\ntool with two options:\n\n1. **Yes, run review** — run `\u002Freview-work-item` on this work item now (and\n   each child if decompose was in the selection)\n2. **No, done** — exit without running review\n\nDo NOT invoke `\u002Freview-work-item` automatically — wait for the user's choice.\n\n## Important Guidelines\n\n- **Mandatory agents at Step 2**: always spawn both codebase agents in\n  parallel before presenting the menu, even for simple work items.\n- **Canonical operation order**: decompose → enrich → sharpen → size → link,\n  regardless of the order the user selected them.\n- **Each operation owns its sections only**:\n  - decompose: writes new child files and appends `### Child work items` to\n    the parent's Requirements (never touching existing Requirements prose)\n  - enrich: owns Technical Notes prose content\n  - sharpen: owns Acceptance Criteria\n  - size: owns the single `**Size**: \u003Cvalue> — \u003Crationale>` line, always as\n    the FIRST line of Technical Notes; replace in place on re-run\n  - link: owns Dependencies\n- **Never modify any frontmatter field** of the target work item\n  (`type`, `id` (or `work_item_id` on legacy files), `title`, `date`,\n  `author`, `producer`, `kind`, `status`, `priority`, `parent`,\n  `external_id`, `tags`, `last_updated`, `last_updated_by`,\n  `schema_version`) — those transitions are `\u002Fupdate-work-item`'s\n  concern. Children of decompose are new work items getting their\n  initial frontmatter.\n- **Destructive paths require two-step confirmation**: replace mode for\n  enrich, replace mode for link, clobbering an existing `**Size**:` line —\n  each must show a unified diff and require a second `y\u002Fn` confirmation.\n- **Edit failure path**: if an Edit's target string cannot be matched (file\n  changed between read and edit), abort that specific edit with a clear\n  diagnostic and continue with remaining approved edits. For decompose: write\n  all children first, update the parent last; if the parent Edit fails,\n  children stay on disk and work item numbers are printed for manual linking.\n- **Numbering is consumed eagerly** on decompose with no rollback; the skill\n  assumes a single-session invocation.\n- **Canonicalise parent field** to zero-padded four-digit string (same as\n  `\u002Fupdate-work-item`), e.g. `\"1\"` → `\"0001\"`.\n- **Idempotent on re-run**: every operation checks existing content before\n  proposing additions.\n\n## Relationship to Other Commands\n\n1. `\u002Fcreate-work-item` or `\u002Fextract-work-items` — create the work item\n2. `\u002Frefine-work-item` — decompose and enrich (this command)\n3. `\u002Freview-work-item` — automated multi-lens quality review\n4. `\u002Fstress-test-work-item` — interactive adversarial examination\n5. `\u002Fupdate-work-item` — status\u002Fmetadata transitions (not this skill's concern)\n6. `\u002Fcreate-plan` — plan implementation from an approved work item\n\n!`accelerator config instructions refine-work-item --fail-safe`\n","# Refine Work Item\n\n!`accelerator config context --skill refine-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**Active integration**: !`accelerator config work integration --fail-safe`\n**ID pattern**: !`accelerator config work id_pattern --fail-safe`\n\nWhen **ID pattern** is `{tracker}`, the tracker owns every item's `id`, so\ndecompose never allocates numbers: it creates each child as a **draft**\nthrough `accelerator work create` (see \"Under `{tracker}`\" in 4a), and\n`\u002Fsync-work-items` promotes the drafts later.\n\n## Work Item Template\n\nThe template below defines the sections and frontmatter fields that every\nwork item must contain. Read it now — use it to know valid kinds, statuses,\npriorities, and section names without re-reading the file at runtime.\n\n!`accelerator config template work-item --fail-safe`\n\nYou are tasked with refining a work item through one or more of five operations:\ndecompose it into child work items, enrich it with codebase context, sharpen\nvague acceptance criteria, add a t-shirt size indicator, or populate its\ndependencies. Every operation is interactive and targeted — you propose, the\nuser approves, and the Edit tool makes the minimum change needed.\n\n## Step 0 — Parameter Check\n\n**If no work item path or number was provided**, respond with:\n\n```\nI'll help you refine a work item. Please provide the path or work item number.\n\nExample: `\u002Frefine-work-item {work_dir}\u002F0042-user-auth.md`\nOr by number: `\u002Frefine-work-item 42`\n\nRun `\u002Flist-work-items` to see available work items.\n```\n\nThen wait for the user's input.\n\n**If a path or number was provided**: proceed to Step 1.\n\nAccepted forms:\n- A path (e.g. `meta\u002Fwork\u002F0042-user-auth.md`)\n- A bare work item number (e.g. `0042` or `42`, resolved against `{work_dir}`)\n\nIf the resolved path does not exist, report:\n```\nNo work item file at \u003Cpath> — run `\u002Flist-work-items` to see available work items.\n```\nand exit without reading any other file, spawning any agent, or writing anything.\n\nIf the YAML frontmatter cannot be parsed (missing closing `---` or syntax\nerror), report:\n```\nCould not parse frontmatter in \u003Cpath> — the file may be corrupted. Re-open it\nand check that the YAML frontmatter is bracketed by two `---` lines and\ncontains all nine required fields, or run `\u002Fupdate-work-item \u003Cpath>` which\nsurfaces the same diagnostic with field-level detail.\n```\nand exit without editing the file or spawning agents.\n\n## Step 1 — Read Target and Context\n\nRead the target work item fully. If the `parent` field is non-empty, also read\nthe parent work item. The work item template (loaded above) tells you the valid\nkinds, statuses, and priorities — do not re-read it at runtime.\n\n## Step 2 — Analyse (mandatory parallel agents)\n\nSpawn BOTH agents in the same tool-use turn (parallel, not sequential):\n\n- **{codebase locator agent}**: find files relevant to the work item's\n  Requirements and Summary\n- **{codebase analyser agent}**: analyse how the relevant components\n  currently work\n\nWait for both before presenting the menu. Even if the work item seems\nstraightforward, always spawn these agents — the menu previews depend\non their findings.\n\n## Step 3 — Present Refinement Menu\n\nPresent the five operations with one-line descriptions. Reference agent\nfindings in the previews so the user can pick informed:\n\n1. **decompose** — split into child work items (epic→stories, story→tasks);\n   e.g. \"Requirements suggest 3 child stories (R1, R2, R3)\"\n2. **enrich** — add Technical Notes from codebase analysis;\n   e.g. \"4 relevant files identified (src\u002Fauth\u002Fsession.ts, …)\"\n3. **sharpen** — tighten vague acceptance criteria;\n   e.g. \"2 vague criteria detected (AC3, AC5)\" or \"all criteria already testable\"\n4. **size** — append a t-shirt size indicator with rationale;\n   e.g. \"estimate M based on files in auth\u002F and session\u002F\"\n5. **link** — populate Dependencies from related work items;\n   e.g. \"1 potential blocker found (0031)\" or \"no related work items found\"\n\nOperations that have nothing to do should be marked as such (e.g.\n\"sharpen — all criteria already testable\").\n\nUser can select one, multiple, or \"all relevant\". Regardless of selection\norder, always execute in canonical order: **decompose → enrich → sharpen\n→ size → link**. This ensures Technical Notes content is in place before\nsize's `**Size**:` line is prepended, and decompose's children exist before\nany link operation references them.\n\n## Step 4 — Execute Operations\n\n### 4a. Decompose\n\nPropose 2–5 candidate children (2–4 for story decomposing to tasks) with\ndraft titles and one-line Summaries derived from the Requirements section.\n\n**Bug\u002Fspike challenge**: if the work item kind is `bug` or `spike`, first use\nthe `AskUserQuestion` tool with two options:\n\n1. **Yes, proceed anyway** — continue with decompose\n2. **No, cancel** — exit decompose and return to the menu\n\n**Existing children**: if the Requirements section already contains a\n`### Child work items` subsection, offer:\n```\nappend (add new children to the existing list) \u002F skip (do not decompose further) \u002F cancel\n```\nNever replace the existing list silently. For the append path, use the\nanchor described below under \"append to existing `### Child work items`\".\n\n**Approval grammar**: each proposal MUST include a one-line grammar legend\nimmediately under the numbered child list:\n```\nCommands: approve all | edit N: \u003Ctitle> | drop N | add: \u003Ctitle> | regenerate | cancel\n```\n\nThe legend appears on every proposal turn — the first proposal and after\nevery grammar iteration.\n\nProcess user input:\n- `approve all`, `yes`, `lgtm` → proceed to the pre-write warning\n- `edit N: \u003Cnew title>` → update child N's title, re-show updated proposal\n  with legend restated. Do NOT write.\n- `drop N` → remove child N, renumber remaining children 1…M, re-show\n  with legend. Do NOT write.\n- `add: \u003Ctitle>` → append a new child with that title, re-show with legend.\n  Do NOT write.\n- `regenerate` → discard current proposal, generate a fresh set of 2–5\n  candidates from the same Requirements. Do NOT write.\n- `cancel`, `abort` → print \"decompose cancelled — no children written\"\n  and return to the menu. No numbers allocated.\n- Any other input → print \"unrecognised command\", restate the legend, and\n  re-show the unchanged proposal unchanged. Do NOT treat as approval.\n\n**Pre-write warning**: before writing, use the `AskUserQuestion` tool with two\noptions. State the allocation count and warn about partial state:\n\n1. **Yes, proceed** — allocate N numbers and write N files (partial state is\n   possible if aborted mid-write; delete the newly-written child file(s) to\n   recover)\n2. **No, cancel** — cancel without writing\n\n**A re-key in progress.** `accelerator work next-number` and\n`accelerator work create` refuse before reading or writing anything while an\n`accelerator work rekey` run is unfinished. Before any other branch on a\nnon-zero exit from one of them, check its stderr for these codes; in every\ncase nothing was written:\n\n- `E_REKEY_IN_PROGRESS` (exit 4) — tell the user a re-key is unfinished:\n  run `\u002Frekey-work-items` to finish or undo it. Stop.\n- `E_REKEY_PLAN_UNREADABLE` (exit 4) — relay the printed remedy as is, never\n  suggesting the re-key be finished. Stop.\n- `E_IDENTITY_RUN_BUSY` (exit 1) — another identity command is still running;\n  retry once it ends.\n\n**On approval** under `{tracker}`: do not call `accelerator work\nnext-number` and do not write children with the `Write` tool. For each\nchild, write its body (H1 through the remaining template sections, with the\n`NNNN` placeholder left literally in place) to a scratch file and run:\n\n```\naccelerator work create \"\u003Cchild title>\" \u003Ckind> \u003Cpriority> \\\n  --status draft --author \"\u003Cresolved author>\" --producer refine-work-item \\\n  --parent \"work-item:\u003Cparent id>\" --body-file \u003Cscratch-file> \\\n  [--tag \u003Cvalue>]...\n```\n\nwith no `--push`, so each child is saved as a draft. Its stdout is the\ndraft's path; the draft's `id` is the `draft-` prefix of its filename, and\nthat is the ID the parent's `### Child work items` links and the ledger\nname. If a call exits non-zero, stop, relay its stderr, and list the\nchildren already written. Then continue at step 3 below. The pre-write\nwarning says \"create N drafts\" rather than \"allocate N numbers\".\n\n**On approval** under every other pattern:\n\n1. Call `accelerator work next-number --count N`\n   exactly once to allocate N consecutive numbers.\n\n2. For each child, write `NNNN-kebab-slug.md`, populating every unified\n   frontmatter field as specified under **Populate frontmatter** below.\n\n   Immediately before writing each child, verify the computed filename does\n   not already exist. If it does, abort with:\n   ```\n   Collision: \u003Cpath> already exists (concurrent session?). Aborting.\n   Allocated: NNNN, NNNN, …; Wrote: N-1 files (list them).\n   Delete the newly-written child file(s).\n   ```\n\n   Child body includes: Summary (from proposal), Context (linking to\n   parent with \"Child of NNNN — \u003Cparent title>\"), Requirements (minimal\n   but substantive; no `[bracketed placeholder]` text), Acceptance Criteria\n   (minimal but substantive; sharpen can tighten these later), Dependencies\n   (blank), and remaining template sections.\n\n3. **Append `### Child work items` to the parent's Requirements section**:\n\n   After all children are written successfully:\n   - Read the parent file\n   - Locate `\\n## Requirements\\n` and `\\n## Acceptance Criteria\\n`\n   - Extract the last non-empty line of Requirements (the line immediately\n     before the blank-line transition to Acceptance Criteria); call this\n     `\u003Creq_tail>`\n   - Build: `old_string` = `\u003Creq_tail>\\n\\n## Acceptance Criteria\\n`\n   - Build: `new_string` = `\u003Creq_tail>\\n\\n### Child work items\\n\\n- NNNN — title\\n…\\n\\n## Acceptance Criteria\\n`\n   - Edge case — empty Requirements: use `## Requirements\\n\\n## Acceptance Criteria\\n`\n     as `old_string` and insert `### Child work items` between them.\n   - Pre-Edit, count occurrences of `old_string` in the parent file. If not\n     exactly 1, abort the parent update with:\n     ```\n     Could not locate a unique '## Acceptance Criteria' anchor in \u003Cpath>\n     (matches found: \u003CN>). Parent not updated.\n     Children NNNN, NNNN, NNNN remain on disk; add their links manually,\n     or delete the newly-written child file(s) and re-run decompose.\n     ```\n     Children already written remain on disk.\n\n   **Append to existing `### Child work items`** (re-decompose path):\n   - Locate `### Child work items` subsection, find its last `- NNNN — title`\n     line; call this `\u003Clast_link>`\n   - Build: `old_string` = `\u003Clast_link>\\n\\n## Acceptance Criteria\\n`\n   - Build: `new_string` = `\u003Clast_link>\\n- NNNN — title\\n…\\n\\n## Acceptance Criteria\\n`\n   - Same uniqueness pre-check; same abort diagnostic if not exactly 1.\n\n4. Print a completion ledger, one line per child:\n   ```\n   Wrote NNNN — title\n   Wrote NNNN — title\n   Allocated 3 numbers, wrote 3 files.\n   ```\n   On aborted or partial write, show allocated vs. written counts and\n   list any written filenames.\n\nAfter a successful decompose, proceed to Step 5 (hierarchy display) before\nrunning any remaining operations.\n\n#### Populate frontmatter\n\nWhen writing each child (step 2 above), **substitute** every field below\nwith the indicated value:\n\n- `type:` ← `work-item`\n- `id:` ← from the script, zero-padded four-digit string\n  (own-identity; legacy files use `work_item_id`)\n- `title:` ← per-child proposal title; body H1 matches exactly\n- `date:` ← current UTC timestamp via `date -u +%Y-%m-%dT%H:%M:%S+00:00`\n- `author:` ← first match in chain: parent work item's `author` field →\n  configured `author` value (from context config) → the session's VCS user\n  identity (the user-identity idiom in the SessionStart VCS Command Reference,\n  which falls back to the git identity when the jj identity is unset, so\n  git-only and colocated repositories both resolve) → ask the user once and\n  apply to all children\n- `producer:` ← `refine-work-item`\n- `kind:` ← derived: `epic → story`, `story → task`, `bug`\u002F`spike` → ask\n  user to confirm before proceeding (already done in the challenge step),\n  any other kind → `story` with a one-line notice\n- `status:` ← literal `draft`\n- `priority:` ← inherit from parent; if parent has none, ask once and\n  apply to every child written in this session\n- `tags:` ← verbatim copy of the parent's `tags` array (empty array `[]`\n  if the parent has none)\n- `last_updated:` ← same UTC timestamp as `date`\n- `last_updated_by:` ← same author value resolved above\n- `schema_version:` ← `1`\n\nOptional linkage\u002Fforeign-ref keys are omit-by-default: the template shows\neach as `\"\"`\u002F`[]`, but write a key into the artifact **only** when it has a\nvalue, and omit it entirely otherwise (do not carry the empty placeholder\nthrough).\n\n- `parent:` ← the parent work item's ID as a typed-linkage ref `\"work-item:NNNN\"`,\n  where NNNN is the parent's `id` field — from `id` on unified files,\n  or `work_item_id` on legacy files — canonicalised to the configured\n  pattern's full-ID shape, e.g. `\"1\"` → `\"work-item:0001\"`. Always\n  fill — every decomposed child has a parent.\n- `blocks:` ← list of typed-linkage refs to work items this child\n  blocks (`[\"work-item:NNNN\", ...]`). Fill when blocking edges are\n  explicit; otherwise omit the key.\n- `blocked_by:` ← list of typed-linkage refs to work items that block\n  this child. Prefer writing the canonical `blocks:` on the other\n  side; emit `blocked_by:` only when the canonical side cannot be\n  written, and omit it otherwise.\n- `derived_from:` ← list of typed-linkage refs to artifacts this child\n  is derived from (`[\"plan:NNNN\", ...]`). Fill when derivation is\n  explicit; otherwise omit the key.\n- `relates_to:` ← list of typed-linkage refs to related artifacts.\n  Fill when relationships are explicit; otherwise omit the key.\n- `source:` ← typed-linkage ref to the originating source artifact\n  (`\"issue-research:NNNN\"`). Fill when the source is explicit;\n  otherwise omit the key.\n- `external_id:` ← cross-system pointer (e.g. a Jira\u002FLinear key). Fill\n  when propagated from the parent or linked to an external tracker;\n  otherwise omit the key.\n\n### 4b. Enrich\n\nRead the target work item's existing Technical Notes content.\n\nIf the codebase agents returned nothing concrete (no specific files or\ncomponents identified), report:\n```\nno enrichment could be grounded in code — skipping enrich\n```\nand make no Edit.\n\nOtherwise propose Technical Notes content with specific `path:line`\nreferences drawn from agent results. Do not invent references.\n\nIf non-trivial Technical Notes content already exists (anything beyond a\n`**Size**:` line), ask:\n```\nreplace (deletes existing Technical Notes) \u002F append (add after existing content) \u002F skip?\n```\n- `replace` → show a unified diff (old struck, new added) and require an\n  explicit second `y\u002Fn` confirmation before invoking Edit\n- `append` → add new content after existing content. Preserve any leading\n  `**Size**:` line placed by a prior size operation — never overwrite it\n- `skip` → make no Edit\n\nOn approval via Edit: modify only the Technical Notes section. Do not touch\nRequirements, Acceptance Criteria, Summary, or any frontmatter field.\n\n### 4c. Sharpen\n\nRead the target work item's Acceptance Criteria. Identify criteria that are\nvague or untestable (non-measurable phrases like \"should be fast\", \"handles\nerrors gracefully\", \"works correctly\").\n\nIf every criterion is already specific and testable, report:\n```\nall acceptance criteria already testable — nothing to sharpen\n```\nand make no Edit.\n\nOtherwise, for each vague criterion propose a specific, measurable rewrite\n(e.g. \"p95 latency under 200ms under default benchmark dataset\"). Skip\ncriteria that are already testable — only propose rewrites for vague ones.\nIterate with the user until each proposed rewrite is agreed.\n\nOn approval via Edit: modify only the Acceptance Criteria section with the\nagreed rewrites. Preserve criteria that were not sharpened byte-for-byte.\n\n### 4d. Size\n\nRead the target work item's Technical Notes. Check whether a `**Size**:` line\nalready exists as the first line.\n\nPropose a t-shirt size (`XS`, `S`, `M`, `L`, `XL`) with a rationale\nreferencing specific files or subsystems from agent results. Iterate with\nthe user.\n\nOn approval:\n- **No existing `**Size**:` line**: insert `**Size**: \u003Cvalue> — \u003Crationale>`\n  as the FIRST line of Technical Notes, followed by a blank line separating\n  it from any existing content. Do NOT add as a frontmatter key.\n- **Existing `**Size**:` line, proposed value AND rationale match byte-for-byte**\n  (ignoring leading\u002Ftrailing whitespace): report \"size unchanged — \u003Cvalue>\"\n  and make no Edit.\n- **Existing `**Size**:` line with a different value or rationale**: show a\n  unified diff of the proposed change (existing line struck, new line added)\n  then use the `AskUserQuestion` tool with two options:\n  1. **Yes, apply size change** — replace the line in place\n  2. **No, cancel** — make no Edit\n\n### 4e. Link\n\nCount `NNNN-*.md` files in `{work_dir}` using a single Glob invocation.\n\n- **Count ≤ 30**: read them directly via batched Read\n- **Count > 30**: spawn **{documents locator agent}** scoped to `{work_dir}`\n\nPropose `Blocked by:` and\u002For `Blocks:` entries in Dependencies, referencing\nonly real work item numbers (verify each proposed number exists before\nincluding it). If no related work items are found, print:\n```\nno related work items found — link skipped\n```\nand make no Edit.\n\nIf Dependencies already has non-empty content, ask:\n```\nreplace (overwrites existing entries) \u002F append (add new entries after existing) \u002F skip?\n```\n- `replace` → show a unified diff and require a second `y\u002Fn` confirmation\n- `append` → add only net-new entries, skipping any that duplicate existing\n  entries\n- `skip` → make no Edit\n\nOn approval via Edit: modify only the Dependencies section.\n\n**Validate the frontmatter**: after editing the work item, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cthe refined 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## Step 5 — Display Hierarchy\n\nRun immediately after decompose writes at least one child (skip if decompose\nwas cancelled, declined by user, or the parent Edit failed).\n\nRender the parent → children tree using the format pinned in `\u002Flist-work-items`:\nUnicode box-drawing characters, two-space indent per depth level, `├── ` for\nall children except the last, `└── ` for the last child. The canonical fence\nbelow MUST appear verbatim in this step's prose so the hierarchy-format guard\ncan verify byte-equality with the matching fence in\n`list-work-items\u002FSKILL.md`:\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\nConcrete work item IDs and titles replace the placeholders in the actual\noutput (e.g. `0042 — User Auth Rework (kind: epic)`). The status field\nof the parent is omitted only if blank; all present fields are shown.\n\nStep 5 runs inline after decompose completes, before enrich, sharpen, size,\nand link operate on the parent. The hierarchy is not re-rendered after\nsubsequent operations.\n\n## Step 6 — Offer Review\n\nAfter the entire selected operation set completes, use the `AskUserQuestion`\ntool with two options:\n\n1. **Yes, run review** — run `\u002Freview-work-item` on this work item now (and\n   each child if decompose was in the selection)\n2. **No, done** — exit without running review\n\nDo NOT invoke `\u002Freview-work-item` automatically — wait for the user's choice.\n\n## Important Guidelines\n\n- **Mandatory agents at Step 2**: always spawn both codebase agents in\n  parallel before presenting the menu, even for simple work items.\n- **Canonical operation order**: decompose → enrich → sharpen → size → link,\n  regardless of the order the user selected them.\n- **Each operation owns its sections only**:\n  - decompose: writes new child files and appends `### Child work items` to\n    the parent's Requirements (never touching existing Requirements prose)\n  - enrich: owns Technical Notes prose content\n  - sharpen: owns Acceptance Criteria\n  - size: owns the single `**Size**: \u003Cvalue> — \u003Crationale>` line, always as\n    the FIRST line of Technical Notes; replace in place on re-run\n  - link: owns Dependencies\n- **Never modify any frontmatter field** of the target work item\n  (`type`, `id` (or `work_item_id` on legacy files), `title`, `date`,\n  `author`, `producer`, `kind`, `status`, `priority`, `parent`,\n  `external_id`, `tags`, `last_updated`, `last_updated_by`,\n  `schema_version`) — those transitions are `\u002Fupdate-work-item`'s\n  concern. Children of decompose are new work items getting their\n  initial frontmatter.\n- **Destructive paths require two-step confirmation**: replace mode for\n  enrich, replace mode for link, clobbering an existing `**Size**:` line —\n  each must show a unified diff and require a second `y\u002Fn` confirmation.\n- **Edit failure path**: if an Edit's target string cannot be matched (file\n  changed between read and edit), abort that specific edit with a clear\n  diagnostic and continue with remaining approved edits. For decompose: write\n  all children first, update the parent last; if the parent Edit fails,\n  children stay on disk and work item numbers are printed for manual linking.\n- **Numbering is consumed eagerly** on decompose with no rollback; the skill\n  assumes a single-session invocation.\n- **Canonicalise parent field** to zero-padded four-digit string (same as\n  `\u002Fupdate-work-item`), e.g. `\"1\"` → `\"0001\"`.\n- **Idempotent on re-run**: every operation checks existing content before\n  proposing additions.\n\n## Relationship to Other Commands\n\n1. `\u002Fcreate-work-item` or `\u002Fextract-work-items` — create the work item\n2. `\u002Frefine-work-item` — decompose and enrich (this command)\n3. `\u002Freview-work-item` — automated multi-lens quality review\n4. `\u002Fstress-test-work-item` — interactive adversarial examination\n5. `\u002Fupdate-work-item` — status\u002Fmetadata transitions (not this skill's concern)\n6. `\u002Fcreate-plan` — plan implementation from an approved work item\n\n!`accelerator config instructions refine-work-item --fail-safe`\n",{"name":5,"description":7,"allowed-tools":44,"argument-hint":48},[45,46,47],"Bash(accelerator config *)","Bash(accelerator work *)","Bash(accelerator corpus frontmatter validate *)","[work item number or path]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fwork\u002Frefine-work-item",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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add atomicinnovation\u002Faccelerator --skill refine-work-item",{"tool":63,"command":64},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill refine-work-item",{"tool":66,"command":67},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill refine-work-item","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002FSKILL.md",true,[71,77,81,85,89,93,97,101,105,108,111,114,117,120,123,126,129,133,136,139,142,145,148,151,154,157,160,163,166,169,172,175,178,181,184,187,190,193,196,199,202,205,208,212,215,218,221,224,227,230,233,236,239,242,245,248,251,254,257,260,263,266,269,272,275,278,281,284,287,290,293,296,299,302,306,310,314,317,321,325,329,333,337,341,345,349,353,357,361,364,368,372,376,379],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"evals\u002Fbenchmark.json","REFERENCE","参考文档",32023,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Fbenchmark.json",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"evals\u002Fevals.json",53361,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Fevals.json",{"path":82,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":84},"evals\u002Ffiles\u002Fscenario-10\u002Fwork-item.md",1045,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-10\u002Fwork-item.md",{"path":86,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":87,"sourceHtmlUrl":88},"evals\u002Ffiles\u002Fscenario-10a\u002Fwork-item.md",1047,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-10a\u002Fwork-item.md",{"path":90,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":91,"sourceHtmlUrl":92},"evals\u002Ffiles\u002Fscenario-11\u002Fwork-item.md",1362,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11\u002Fwork-item.md",{"path":94,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":95,"sourceHtmlUrl":96},"evals\u002Ffiles\u002Fscenario-11a\u002Fwork-item.md",1144,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11a\u002Fwork-item.md",{"path":98,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":99,"sourceHtmlUrl":100},"evals\u002Ffiles\u002Fscenario-11b\u002Ftarget-work-item.md",911,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Ftarget-work-item.md",{"path":102,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":104},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0001-stub-work-item-1.md",319,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0001-stub-work-item-1.md",{"path":106,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":107},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0002-stub-work-item-2.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0002-stub-work-item-2.md",{"path":109,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":110},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0003-stub-work-item-3.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0003-stub-work-item-3.md",{"path":112,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":113},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0004-stub-work-item-4.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0004-stub-work-item-4.md",{"path":115,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":116},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0005-stub-work-item-5.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0005-stub-work-item-5.md",{"path":118,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":119},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0006-stub-work-item-6.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0006-stub-work-item-6.md",{"path":121,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":122},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0007-stub-work-item-7.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0007-stub-work-item-7.md",{"path":124,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":125},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0008-stub-work-item-8.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0008-stub-work-item-8.md",{"path":127,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":128},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0009-stub-work-item-9.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0009-stub-work-item-9.md",{"path":130,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":132},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0010-stub-work-item-10.md",321,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0010-stub-work-item-10.md",{"path":134,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":135},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0011-stub-work-item-11.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0011-stub-work-item-11.md",{"path":137,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":138},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0012-stub-work-item-12.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0012-stub-work-item-12.md",{"path":140,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":141},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0013-stub-work-item-13.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0013-stub-work-item-13.md",{"path":143,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":144},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0014-stub-work-item-14.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0014-stub-work-item-14.md",{"path":146,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":147},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0015-stub-work-item-15.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0015-stub-work-item-15.md",{"path":149,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":150},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0016-stub-work-item-16.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0016-stub-work-item-16.md",{"path":152,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":153},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0017-stub-work-item-17.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0017-stub-work-item-17.md",{"path":155,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":156},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0018-stub-work-item-18.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0018-stub-work-item-18.md",{"path":158,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":159},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0019-stub-work-item-19.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0019-stub-work-item-19.md",{"path":161,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":162},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0020-stub-work-item-20.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0020-stub-work-item-20.md",{"path":164,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":165},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0021-stub-work-item-21.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0021-stub-work-item-21.md",{"path":167,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":168},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0022-stub-work-item-22.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0022-stub-work-item-22.md",{"path":170,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":171},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0023-stub-work-item-23.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0023-stub-work-item-23.md",{"path":173,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":174},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0024-stub-work-item-24.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0024-stub-work-item-24.md",{"path":176,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":177},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0025-stub-work-item-25.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0025-stub-work-item-25.md",{"path":179,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":180},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0026-stub-work-item-26.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0026-stub-work-item-26.md",{"path":182,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":183},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0027-stub-work-item-27.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0027-stub-work-item-27.md",{"path":185,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":186},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0028-stub-work-item-28.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0028-stub-work-item-28.md",{"path":188,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":189},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0029-stub-work-item-29.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0029-stub-work-item-29.md",{"path":191,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":192},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0030-stub-work-item-30.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0030-stub-work-item-30.md",{"path":194,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":195},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0031-stub-work-item-31.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0031-stub-work-item-31.md",{"path":197,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":198},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0032-stub-work-item-32.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0032-stub-work-item-32.md",{"path":200,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":201},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0033-stub-work-item-33.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0033-stub-work-item-33.md",{"path":203,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":204},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0034-stub-work-item-34.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0034-stub-work-item-34.md",{"path":206,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":207},"evals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0035-stub-work-item-35.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11b\u002Fwork-items\u002F0035-stub-work-item-35.md",{"path":209,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":210,"sourceHtmlUrl":211},"evals\u002Ffiles\u002Fscenario-11c\u002Ftarget-work-item.md",785,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Ftarget-work-item.md",{"path":213,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":214},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0001-stub-work-item-1.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0001-stub-work-item-1.md",{"path":216,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":217},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0002-stub-work-item-2.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0002-stub-work-item-2.md",{"path":219,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":220},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0003-stub-work-item-3.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0003-stub-work-item-3.md",{"path":222,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":223},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0004-stub-work-item-4.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0004-stub-work-item-4.md",{"path":225,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":226},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0005-stub-work-item-5.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0005-stub-work-item-5.md",{"path":228,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":229},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0006-stub-work-item-6.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0006-stub-work-item-6.md",{"path":231,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":232},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0007-stub-work-item-7.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0007-stub-work-item-7.md",{"path":234,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":235},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0008-stub-work-item-8.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0008-stub-work-item-8.md",{"path":237,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":238},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0009-stub-work-item-9.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0009-stub-work-item-9.md",{"path":240,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":241},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0010-stub-work-item-10.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0010-stub-work-item-10.md",{"path":243,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":244},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0011-stub-work-item-11.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0011-stub-work-item-11.md",{"path":246,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":247},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0012-stub-work-item-12.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0012-stub-work-item-12.md",{"path":249,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":250},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0013-stub-work-item-13.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0013-stub-work-item-13.md",{"path":252,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":253},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0014-stub-work-item-14.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0014-stub-work-item-14.md",{"path":255,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":256},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0015-stub-work-item-15.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0015-stub-work-item-15.md",{"path":258,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":259},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0016-stub-work-item-16.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0016-stub-work-item-16.md",{"path":261,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":262},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0017-stub-work-item-17.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0017-stub-work-item-17.md",{"path":264,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":265},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0018-stub-work-item-18.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0018-stub-work-item-18.md",{"path":267,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":268},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0019-stub-work-item-19.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0019-stub-work-item-19.md",{"path":270,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":271},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0020-stub-work-item-20.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0020-stub-work-item-20.md",{"path":273,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":274},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0021-stub-work-item-21.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0021-stub-work-item-21.md",{"path":276,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":277},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0022-stub-work-item-22.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0022-stub-work-item-22.md",{"path":279,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":280},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0023-stub-work-item-23.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0023-stub-work-item-23.md",{"path":282,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":283},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0024-stub-work-item-24.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0024-stub-work-item-24.md",{"path":285,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":286},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0025-stub-work-item-25.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0025-stub-work-item-25.md",{"path":288,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":289},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0026-stub-work-item-26.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0026-stub-work-item-26.md",{"path":291,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":292},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0027-stub-work-item-27.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0027-stub-work-item-27.md",{"path":294,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":295},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0028-stub-work-item-28.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0028-stub-work-item-28.md",{"path":297,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":298},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0029-stub-work-item-29.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0029-stub-work-item-29.md",{"path":300,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":131,"sourceHtmlUrl":301},"evals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0030-stub-work-item-30.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-11c\u002Fwork-items\u002F0030-stub-work-item-30.md",{"path":303,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":304,"sourceHtmlUrl":305},"evals\u002Ffiles\u002Fscenario-12\u002Fwork-item.md",967,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-12\u002Fwork-item.md",{"path":307,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":308,"sourceHtmlUrl":309},"evals\u002Ffiles\u002Fscenario-13\u002Fwork-item.md",899,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-13\u002Fwork-item.md",{"path":311,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":312,"sourceHtmlUrl":313},"evals\u002Ffiles\u002Fscenario-14\u002Fwork-item.md",1190,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-14\u002Fwork-item.md",{"path":315,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":304,"sourceHtmlUrl":316},"evals\u002Ffiles\u002Fscenario-16\u002Fwork-item.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-16\u002Fwork-item.md",{"path":318,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":319,"sourceHtmlUrl":320},"evals\u002Ffiles\u002Fscenario-18\u002Fwork-item.md",312,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-18\u002Fwork-item.md",{"path":322,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":323,"sourceHtmlUrl":324},"evals\u002Ffiles\u002Fscenario-19\u002Fwork-item.md",1184,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-19\u002Fwork-item.md",{"path":326,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":327,"sourceHtmlUrl":328},"evals\u002Ffiles\u002Fscenario-2\u002Fwork-item.md",1163,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-2\u002Fwork-item.md",{"path":330,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":331,"sourceHtmlUrl":332},"evals\u002Ffiles\u002Fscenario-20\u002Fwork-item.md",1043,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-20\u002Fwork-item.md",{"path":334,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":335,"sourceHtmlUrl":336},"evals\u002Ffiles\u002Fscenario-21\u002Fwork-item.md",1512,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-21\u002Fwork-item.md",{"path":338,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":339,"sourceHtmlUrl":340},"evals\u002Ffiles\u002Fscenario-22\u002Fwork-item.md",1082,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-22\u002Fwork-item.md",{"path":342,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":343,"sourceHtmlUrl":344},"evals\u002Ffiles\u002Fscenario-23\u002Fwork-item.md",946,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-23\u002Fwork-item.md",{"path":346,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":347,"sourceHtmlUrl":348},"evals\u002Ffiles\u002Fscenario-24a\u002Fwork-item-before-edit.md",738,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-24a\u002Fwork-item-before-edit.md",{"path":350,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":351,"sourceHtmlUrl":352},"evals\u002Ffiles\u002Fscenario-24a\u002Fwork-item-during-edit.md",748,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-24a\u002Fwork-item-during-edit.md",{"path":354,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":355,"sourceHtmlUrl":356},"evals\u002Ffiles\u002Fscenario-24b\u002Fparent-with-duplicate-heading.md",855,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-24b\u002Fparent-with-duplicate-heading.md",{"path":358,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":359,"sourceHtmlUrl":360},"evals\u002Ffiles\u002Fscenario-3\u002Fwork-item.md",1443,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-3\u002Fwork-item.md",{"path":362,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":363},"evals\u002Ffiles\u002Fscenario-4\u002Fwork-item.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-4\u002Fwork-item.md",{"path":365,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":366,"sourceHtmlUrl":367},"evals\u002Ffiles\u002Fscenario-5\u002Fexpected-parent.md",1158,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-5\u002Fexpected-parent.md",{"path":369,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":370,"sourceHtmlUrl":371},"evals\u002Ffiles\u002Fscenario-5\u002Fwork-item.md",1028,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-5\u002Fwork-item.md",{"path":373,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":374,"sourceHtmlUrl":375},"evals\u002Ffiles\u002Fscenario-6\u002Fwork-item.md",1133,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-6\u002Fwork-item.md",{"path":377,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":378},"evals\u002Ffiles\u002Fscenario-8\u002Fwork-item.md","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-8\u002Fwork-item.md",{"path":380,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":381,"sourceHtmlUrl":382},"evals\u002Ffiles\u002Fscenario-9\u002Fwork-item.md",1022,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frefine-work-item\u002Fevals\u002Ffiles\u002Fscenario-9\u002Fwork-item.md",[384,419,438,460,478,500],{"skillNo":385,"name":386,"nameZh":6,"description":387,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":388,"categories":389,"keywords":400,"publishedAt":39},"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",[390,395],{"categoryNo":391,"categoryName":392,"taxonomyType":393,"taxonomyTypeDesc":394},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":396,"categoryName":397,"taxonomyType":398,"taxonomyTypeDesc":399},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[401,402,403,404,405,406,407,408,409,410,411,29,412,35,413,414,415,416,417,418],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","when","URL","code","architecture","reviewer","review","notes","change",{"skillNo":420,"name":421,"nameZh":6,"description":422,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":423,"categories":424,"keywords":425,"publishedAt":39},"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",[],[20,426,427,19,428,429,33,35,418,38,430,31,431,432,27,433,434,435,436,437],"update","update work item","enforcement","manage","edit","status","transition","Existing","tags","changes","fields","op",{"skillNo":439,"name":440,"nameZh":6,"description":441,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":442,"categories":443,"keywords":444,"publishedAt":39},"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",[],[20,445,446,447,448,449,450,35,451,418,452,453,454,455,456,457,458,38,459,27,411],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":461,"name":462,"nameZh":6,"description":463,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":464,"categories":465,"keywords":466,"publishedAt":39},"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",[],[467,20,468,445,446,469,470,471,472,473,474,475,476,477],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":479,"name":480,"nameZh":6,"description":481,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":482,"categories":483,"keywords":487,"publishedAt":39},"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",[484],{"categoryNo":485,"categoryName":486,"taxonomyType":393,"taxonomyTypeDesc":394},"01JBSEEDCAT000000000000008","测试与质量",[488,489,20,490,19,491,492,493,494,495,36,35,32,23,38,31,496,497,498,29,499,27],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","implementation","grilling","user","gaps",{"skillNo":501,"name":502,"nameZh":6,"description":503,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":504,"categories":505,"keywords":506,"publishedAt":39},"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",[],[416,20,507,19,508,509,33,35,510,511,38,31,496,498,512,411,513,514,27,28],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate"]