[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXZ1DMMEAP2X9HRT2EB3CV":3,"skill-same:01M6DXZ1DMMEAP2X9HRT2EB3CV":102},{"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":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6DXZ1DMMEAP2X9HRT2EB3CV","extract-work-items",null,"Extract work items in batch from existing documents (specs, PRDs, research, plans, meeting notes, design docs). Use whenever the user wants to capture, pull out, or convert requirements, work items, user stories, bug reports, or actionable tasks from existing files into structured work items in meta\u002Fwork\u002F — even if they don't say \"extract\" explicitly.","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\u002Fextract-work-items\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"extract work items","extract","work","user stories","frontmatter","actionable","meeting notes","design docs","paths","bug","config","notes","reports","batch","tasks","Bash","documents","files","design","Meta","2026-11-10 10:12:30",false,"---\nname: extract-work-items\ndescription: Extract work items in batch from existing documents (specs, PRDs,\n research, plans, meeting notes, design docs). Use whenever the user wants\n to capture, pull out, or convert requirements, work items, user stories,\n bug reports, or actionable tasks from existing files into structured\n work items in meta\u002Fwork\u002F — even if they don't say \"extract\" explicitly.\nargument-hint: \"[document paths...] or leave empty to scan all\"\nallowed-tools:\n - Bash(accelerator config *)\n - Bash(accelerator work *)\n - Bash(accelerator corpus metadata derive)\n - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Extract Work Items from Meta Documents\n\n!`accelerator config context --skill extract-work-items --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:reviewer, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser,\naccelerator:web-search-researcher.\n\n**Work items directory**: !`accelerator config path work --fail-safe`\n**Codebase research directory**: !`accelerator config path research_codebase --fail-safe`\n**Plans directory**: !`accelerator config path plans --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`: an\nitem takes its issue's key once the tracker creates it, and one no tracker\nhas confirmed is saved as a **draft** under a provisional `draft-` ID, which\n`\u002Fsync-work-items` promotes later. Step 4 then creates the whole batch\nthrough `accelerator work create-batch` (see \"Step 4 under `{tracker}`\").\nUnder every other pattern, Step 4 allocates numbers and writes the files as\ndescribed there.\n\n## Work Item Template\n\nThe template below defines the sections and frontmatter fields that every\nwork item must contain. Read it now — the valid work item kinds live in the `kind`\nfield (not a hardcoded list elsewhere in this skill), and every written file\nmust populate every frontmatter field.\n\n!`accelerator config template work-item --fail-safe`\n\nYou are tasked with identifying requirements, work items, and actionable\ntasks within existing meta documents and helping the user capture them as\nformal work items. Source documents typically tell you *what* work items should\nexist but rarely give the full business context, testable acceptance\ncriteria, dependencies, and assumptions a good work item needs. The model,\nthe user, and web research fill those gaps.\n\nExtraction therefore proceeds in two layers:\n\n- **Source-derived content stays faithful.** Anything you draw from the\n source documents must reflect what they actually say — do not silently\n invent requirements that are not there.\n- **Business-context gaps are surfaced.** The `Assumptions`, `Open Questions`\n and `Drafting Notes` sections serve different purposes when present, and all \n matter:\n - **Assumptions** are interpretations you made that affect the work item's\n meaning. Flag one only when using the wrong interpretation would lead\n someone to build something different. Example: *\"Interpreted 'users' as\n end users rather than internal staff — if wrong, scope changes.\"*\n - **Open Questions** are genuine unknowns the source raises but leaves\n unanswered that a reader or implementer needs resolved before work can\n proceed. Example: *\"What does 'better results' mean — improved relevance, \n faster delivery, or both?\"*\n - **Drafting Notes** capture interpretations you made while filling out\n the work item — business-context calls, scope decisions, or technical\n choices that someone should review if they turn out to be wrong.\n Actively populate this section. If you inferred who the stakeholders\n are, what a vague term means, what the scope boundary is, or which\n technical approach the source implies, write it down.\n Examples: *\"Treated this as a spike because no acceptance criteria are \n defined — if implementation is already expected, kind and scope both \n change.\"* Routine field selections (kind, priority, tags) don't need an \n entry unless the choice reflects a substantive scope or meaning \n interpretation that a reviewer should be aware of.\n\nFor each selected candidate, you offer the user the choice between\n*enriching* the work item interactively (with model knowledge, web research,\nand a few focused questions, similar to `\u002Fcreate-work-item`) or *accepting\nthe source-derived skeleton as-is* and refining later. The enrichment\nloop is per candidate, not pre-generated, so the work the model invests\nmatches the depth the user wants for each work item.\n\n## Initial Setup\n\nWhen this command is invoked:\n\n1. **Check if parameters were provided**:\n\n- If one or more file paths were provided, note them as the target documents\n- If no parameters provided, ask conversationally and helpfully which\n documents to work with. Give the user enough context to respond easily:\n briefly explain what kinds of sources work (specific files, planning docs,\n meeting notes, research, specs), mention that you can also scan all\n documents in the configured directories, and invite them to direct.\n Helpful examples matter more here than brevity — aim for something\n welcoming and informative rather than a single terse question.\n\nWait for user input.\n\n## Process Steps\n\n### Step 1: Identify Source Documents\n\n1. If specific files were provided, read them FULLY. Before reading,\n verify each path exists. If any path does not exist, report which\n paths are missing and ask the user to correct or remove them — do not\n silently skip them or proceed with an empty set.\n2. If scanning all meta documents:\n - Spawn a **{documents locator agent}** agent to find all documents in the\n configured research and plans directories (shown above)\n - Present the discovered documents and let the user select which to scan:\n ```\n I found the following documents:\n\n **Research:**\n - `{research directory}\u002F2026-04-08-topic.md` — Topic research\n - ...\n\n **Plans:**\n - `{plans directory}\u002F2026-04-19-feature.md` — Feature plan\n - ...\n\n Which documents should I scan for work items? (enter numbers, \"all\", or\n specific paths)\n ```\n - Wait for user selection.\n\n### Step 2: Analyse Documents for Work Items\n\n1. **Spawn {documents analyser agent} agents** (one per document, in parallel)\n with instructions to identify requirements and actionable work items.\n Look for:\n - Explicit requirements (\"The system must...\", \"Users need to...\",\n \"We need to implement...\")\n - User stories (\"As a..., I want..., so that...\")\n - Feature descriptions and acceptance criteria\n - Bug reports with symptoms and expected behaviour\n - Open-ended investigations or unknowns requiring research\n - Multi-deliverable themes that span several stories\n - One-off tasks (migrations, infrastructure work, documentation)\n\n2. **Wait for all agents to complete.**\n\n3. **Deduplicate**: Where the same work item appears across multiple\n documents, merge the entries and record all source documents it came from.\n\n4. **Present discovered candidates** as a numbered list:\n\n```\nI found the following actionable items across the scanned documents:\n\n1. **[Short title]** — [one-line description]\n Source: `{research directory}\u002F2026-04-08-topic.md`\n\n2. **[Short title]** — [one-line description]\n Source: `{plans directory}\u002F2026-04-19-feature.md`, `{research directory}\u002F2026-04-08-topic.md`\n\n3. ...\n\nWhich items would you like to create work items for? (enter numbers, \"all\",\nor \"none\")\n```\n\nIf no actionable items are found across all documents, inform the user:\n\"No actionable items found in the provided documents.\" and exit cleanly.\n\nWait for user selection. If the user selects \"none\", exit cleanly without\nwriting any files.\n\n### Step 3: Enrich and Approve (Per Candidate)\n\nFor each selected candidate, in original presented order, build a\nsource-derived skeleton, present it, and let the user choose how much\nenrichment to invest. Do NOT pre-generate drafts for the entire batch\nin advance — enrichment can change a draft significantly, so generation\nhappens per candidate inside this loop.\n\n#### 3.1 Build the source-derived skeleton\n\nFor the current candidate:\n\n- Infer the work item kind from its content using kinds read from the\n work item template's `kind` field:\n - clear bug reports with symptoms and expected\u002Factual behaviour → `bug`\n - open-ended investigations with specific questions → `spike`\n - broad multi-deliverable themes → `epic`\n - specific single deliverables → `story`\n - one-off technical or operational tasks → `task`\n - Default to `story` for items where the kind is genuinely ambiguous.\n- Draft a complete work item from the source content alone, using `XXXX`\n as the placeholder work item number.\n- Kind-specific content placement:\n - bug: reproduction steps, expected\u002Factual behaviour → `Requirements` section\n - spike: research questions, time-box, exit criteria → `Requirements` section\n - epic: initial story decomposition → `Requirements` section as a list\n - Do not rename or add sections beyond those in the work item template.\n- Surface business-context gaps using the right section: put your\n interpretation in `Assumptions` (when you made a call and the wrong call\n changes what gets built). Put unanswered questions in `Open Questions` when \n you genuinely cannot tell from the source. Populate `Open Questions` with \n anything that would materially change scope, approach, or acceptance \n criteria if resolved differently. Add a `Drafting Notes` entry for every \n meaningful interpretation you made (scope boundaries, who\n stakeholders are, what vague terms mean, which technical approach is implied).\n- Include all source documents for this item in the `References` section.\n\n#### 3.2 Present the skeleton with options\n\n```\nCandidate #N of M: [title]\nKind (proposed): [kind]\nSource: [paths]\n\n[work item content with XXXX placeholder, including Drafting Notes section]\n\n```\n\nUse the `AskUserQuestion` tool with four options:\n\n1. **Enrich** — interactive Q&A, web research where useful, then approve\n2. **Accept as-is** — write this skeleton as a thin draft for later refinement\n3. **Skip** — exclude from this batch\n4. **Accept all remaining** — fast-path every remaining candidate as a thin draft\n\nWait for the user's choice. If the user enters free-form text via the \"Other\"\ninput, treat it as **Enrich** seeded with those instructions: enter the\nenrichment loop in 3.3 using the supplied text as the first round of revision\nguidance, skipping the question phase if the instructions are already\nsubstantive.\n\n#### 3.3 enrich — interactive enrichment\n\nTreat this as a focused, per-candidate version of the `\u002Fcreate-work-item`\nflow, seeded with the skeleton above:\n\n1. **Ask 1–3 focused business-context questions** tailored to this\n candidate. Fewer than `\u002Fcreate-work-item`'s 3–5 because the source\n already provides some context. Cover whichever of the following are\n not already clear from the source:\n - What pain point or problem does this address, and who experiences it?\n - What is the desired outcome — what changes for people once this is done?\n - Are there constraints, deadlines, or dependencies worth knowing?\n - For bugs: what is the impact, and is it a blocker?\n - Anything you are uncertain about, or that should be researched?\n\n2. **Spawn `{web-search-researcher agent}`** when there is uncertainty\n about any aspect of this candidate the model lacks confidence on —\n business rules, domain concepts, competitive landscape, industry\n standards, external technology. Skip only when the candidate is\n self-contained and well-understood from the source plus user answers.\n When in doubt, prefer to spawn research — over-asking is cheaper\n than producing a vague enriched draft.\n\n3. **Update the draft** combining source content, user answers, model\n knowledge, and research findings. Re-present it as a structured\n proposal that:\n - Confirms or revises the kind\n - Lists requirements drawn from source + enrichment\n - Proposes specific, testable acceptance criteria — prefer\n Given\u002FWhen\u002FThen for story\u002Ftask; draw on domain knowledge and\n research to make them thorough\n - Lists dependencies (blocking and blocked) where known\n - Keeps a `Drafting Notes` section for any interpretations still\n unresolved so the user can challenge them\n - Lists remaining open questions in the `Open Questions` section\n\n Then use the `AskUserQuestion` tool with four options:\n\n 1. **Approve** — accept this draft and move on to the next candidate\n 2. **Revise** — update the draft with additional instructions (prompted after\n via plain-text — do NOT use `AskUserQuestion` for the instructions)\n 3. **Skip** — discard this candidate entirely\n 4. **Accept as-is** — discard enrichment and use the original source-only skeleton\n\n4. **Iterate on the same candidate.** Challenge weak or untestable\n acceptance criteria — when a criterion is not measurable, ask what a\n passing test would look like and reformulate together. Do not accept\n vague criteria into the draft. The candidate position (e.g. \"Candidate\n #N of M\") does NOT advance during iteration: re-present the updated\n draft for the same candidate and accept further free-form revision\n instructions, looping as many times as needed. Only `approve` (or one\n of the interrupts below) advances to candidate N+1. Once the user\n explicitly approves, mark the candidate **approved (enriched)** and\n advance to the next candidate.\n\nThe user may switch out of enrichment at any point by saying:\n\n- `skip` — exclude this candidate entirely. Discard any partial\n enrichment work — questions answered, drafts re-proposed — and never\n approve it later, even if `accept remaining as-is` is invoked on a\n subsequent candidate.\n- `accept as-is` — replace the in-flight enriched draft with the\n original 3.1 source-derived skeleton (NOT the partially enriched\n state) and apply the 3.4 thin-draft assumptions note. The user is\n saying \"stop enriching this one; take the source-only version\".\n\nHonour these interrupts immediately on the turn they are received.\n\n#### 3.4 accept as-is — thin draft\n\nTake the source-derived skeleton from 3.1 as the final draft for this\ncandidate. Append (or extend) the `Drafting Notes` section with the\nfollowing note **verbatim** (so future tooling like `\u002Frefine-work-item`\nand human reviewers can detect thin drafts deterministically):\n\n> Extracted from source documents without interactive enrichment.\n> Acceptance criteria, dependencies, and kind may need refinement before\n> promoting from `draft` to `ready`.\n\nIf the candidate already has source-derived drafting notes, keep them\nand add the verbatim note as a separate paragraph beneath.\nKeep any `Open Questions` from the 3.1 skeleton — these are genuine\nbusiness unknowns that need resolution regardless of whether enrichment\nhappened. Mark the candidate **approved (thin)** and advance to the next.\n\n#### 3.5 skip\n\nExclude this candidate from the batch and advance to the next. Skipped\ncandidates never become approved later, even if a subsequent\n`accept remaining as-is` is used.\n\n#### 3.6 accept remaining as-is — fast-path\n\nMark every remaining *unreviewed* candidate as **approved (thin)**,\napplying the same skeleton + assumptions note as 3.4. Do not ask\nfurther questions. Already-skipped candidates stay skipped. Jump to\nStep 4.\n\n#### 3.7 No `accelerator work next-number` calls in Step 3\n\n`accelerator work next-number` is not called at any point during Step 3,\nregardless of which option the user picks. Writing happens exclusively\nin Step 4 after all approvals — enriched and thin — are collected.\n\n### Step 4: Write Work Items\n\n**A re-key in progress.** `accelerator work next-number` and\n`accelerator work create-batch` refuse before reading or writing anything\nwhile an `accelerator work rekey` run is unfinished. Before any other branch\non a non-zero exit from one of them, check its stderr for these codes; in\nevery case 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\nWhen **ID pattern** is `{tracker}`, follow \"Step 4 under `{tracker}`\" below\ninstead of this step.\n\n1. **Count approved (non-skipped) items: N.**\n\n2. **If N is 0**: print \"No work items approved — nothing written.\" and exit\n cleanly. Do NOT call `accelerator work next-number`.\n\n3. **Otherwise**:\n\n a. **Compute target slugs** — for each approved draft, derive a meaningful\n kebab-case slug from its title.\n\n b. **Read configuration.** Invoke each script by its bare path and use the\n command's stdout as the named value — do **not** wrap the call in a `VAR=$(…)`\n assignment, as the assignment (not the path) would become the command and escape\n the rule:\n\n - Run `accelerator config work id_pattern` and use its\n stdout as `PATTERN`.\n - Run `accelerator config work key` and use its stdout as\n `KEY_PREFIX` (the local ID prefix).\n\n Run the bare path **directly** as an executable;\n never prefix it with `bash`\u002F`sh`\u002F`env` (a wrapper prefix escapes the skill's\n `allowed-tools` permission and forces an unnecessary prompt).\n\n c. **Suggest projected IDs**: if `PATTERN` references the `{key}` prefix\n token (or the deprecated `{project}` synonym), the default prefix for each\n row is `KEY_PREFIX` (warn and require user amendment if `KEY_PREFIX` is\n empty). If `PATTERN` has no prefix token, no project column is shown.\n\n Compute *display-only* projected IDs by calling, per distinct\n project code:\n ```\n accelerator work next-number --project \u003Ccode> --count \u003Ccount-for-that-project>\n ```\n These calls do not commit numbers; the same call is re-issued after\n every amendment to keep the table accurate.\n\n d. **Present an amendment table**:\n\n ```\n | # | Slug | Project | Projected ID |\n | 1 | add-foo | PROJ | PROJ-0001 |\n | 2 | fix-bar | PROJ | PROJ-0002 |\n | 3 | update-baz | PROJ | PROJ-0003 |\n\n Amend any rows? (`\u003Crows> \u003CPROJECT>` to set, `\u003Crows> -` to revert to\n default, `?` for help, `q` to cancel, blank to confirm.)\n ```\n\n When `PATTERN` has no prefix token, omit the `Project` column and\n render only `| # | Slug | Projected ID |`. The amendment prompt is\n not shown in that case — proceed directly to confirmation.\n\n **Amendment grammar** (canonical — same wording in every state):\n\n - `\u003Crows>`: one row number (`2`) or comma-separated list (`2,3,7`).\n Whitespace around commas is permitted (`2, 3, 7`) and trimmed.\n - `\u003CPROJECT>`: a project code matching `[A-Za-z][A-Za-z0-9]*`.\n - `\u003Crows> -`: revert the named rows to the default project code\n (or to \"no project\" when no default is set).\n - `?`: re-display the amendment grammar reference plus the\n unchanged table; no state change.\n - `q`: cancel the entire flow with no files written and no numbers\n allocated.\n - Blank input: confirms the current table state.\n\n **Validation**: out-of-range row numbers re-prompt with\n `error: row N — out of range (valid: 1-M)` without applying any\n other amendments in the same input. Invalid project codes\n re-prompt with `error: row N — project value \"\u003Cvalue>\" must\n match [A-Za-z][A-Za-z0-9]*` and discard the entire input\n (no partial application). Unrecognised commands re-prompt with\n `error: unrecognised input. Type ? for help.` On any rejection\n the table reverts to its last valid state.\n\n After every accepted amendment, recompute projected IDs by\n re-issuing the per-project allocator calls (display only).\n\n e. **Project-aware slug-collision check** before any allocation. For\n each row, glob:\n - When the pattern has `{project}`:\n `{work_dir}\u002F\u003Cproject>-*-\u003Cslug>.md` for the row's project — a\n same-slug file under the *same* project is a real collision.\n - Always (legacy fallback):\n `{work_dir}\u002F[0-9][0-9][0-9][0-9]-\u003Cslug>.md` — a same-slug legacy\n file shadows the new file regardless of project.\n\n Within the same batch, two amendments to the same project with\n the same slug are also a collision. Same slug under different\n projects (`PROJ-0001-add-foo.md` and `OTHER-0001-add-foo.md`) is\n legitimate and not a collision.\n\n If any collision is detected, report which slugs collide and\n which existing files they match, abort without calling the\n allocator, and ask the user to resolve the collision before\n re-running.\n\n f. **Allocate per distinct project code**, in original presentation\n order:\n ```\n accelerator work next-number --project \u003Ccode> --count \u003Ccount>\n ```\n One call per distinct project code; `--project` is omitted when\n the pattern lacks `{project}`. If any allocator call exits\n non-zero, abort immediately and surface the error verbatim — do\n not write any files. The whole batch fails atomically.\n\n g. **Substitute the allocated full IDs** into approved drafts in\n their original presented order. Within a single project, the\n first row in presentation order takes the first allocated\n number; multiple projects each preserve their own ordering. The\n `id` frontmatter is **always quoted** (`\"PROJ-0001\"`).\n\n h. **Populate frontmatter** for every approved draft. Before writing\n each file, capture metadata and substitute the unified base\n fields into the template's frontmatter block:\n\n 1. Invoke\n `accelerator corpus metadata derive`\n once for the batch to obtain `Current Date\u002FTime (UTC):`,\n `Current Revision:`, and `Repository Name:`.\n 2. For each approved draft, **substitute** every field below\n with the indicated value:\n - `type:` ← `work-item`\n - `id:` ← the allocated full ID, always quoted as a YAML\n string (e.g. `id: \"PROJ-0001\"`)\n - `title:` ← the draft's H1 title\n - `date:` ← the `Current Date\u002FTime (UTC):` value\n - `author:` ← the author value resolved per the rules in\n `create-work-item\u002FSKILL.md > author` (config → VCS user →\n prompt)\n - `producer:` ← `extract-work-items`\n - `status:` ← `draft`\n - `last_updated:` ← the same `Current Date\u002FTime (UTC):` value\n - `last_updated_by:` ← the same value resolved for `author`\n - `schema_version:` ← `1` (bare integer, not quoted)\n\n Optional linkage\u002Fforeign-ref keys are omit-by-default:\n the template shows each as `\"\"`\u002F`[]`, but write a\n key into the artifact **only** when it has a value, and omit it\n entirely otherwise (do not carry the empty placeholder\n through). By default a freshly extracted draft names none of\n them.\n\n - `parent:` ← the parent work item's ID as a typed-linkage ref\n (`\"work-item:NNNN\"`). Fill when the source names a parent;\n otherwise omit the key entirely.\n - `blocks:` ← list of typed-linkage refs to work items this\n item blocks (`[\"work-item:NNNN\", ...]`). Fill when blocking\n edges are explicit in the source; otherwise omit the key.\n - `blocked_by:` ← list of typed-linkage refs to work items that\n block this one. Prefer writing the canonical `blocks:` on the\n other side; emit `blocked_by:` only when the canonical side\n cannot be written, and omit it otherwise.\n - `derived_from:` ← list of typed-linkage refs to artifacts this\n item is derived from (`[\"plan:NNNN\", ...]`). Fill when\n derivation is explicit; otherwise omit the key.\n - `relates_to:` ← list of typed-linkage refs to related\n artifacts. Fill when relationships are explicit; otherwise\n omit the key.\n - `source:` ← typed-linkage ref to the originating source\n artifact (`\"issue-research:NNNN\"`). Fill when the source is a\n meta artifact with an id; otherwise omit the key.\n - `external_id:` ← cross-system pointer (e.g. a Jira\u002FLinear\n key). Fill when the item is linked to an external tracker;\n otherwise omit the key.\n\n i. **Write all N work item files**. Each work item's `References`\n section must include all source document paths the item was\n extracted from. For deduplicated items that appeared in multiple\n documents, list every contributing source under `References`,\n one per line.\n\n j. If a write error occurs mid-batch: report which numbers were\n allocated, which files were written successfully, and which were\n not — so the user can manually write the missing files with\n their pre-assigned IDs. Do not retry writes silently and do not\n call the allocator again to re-allocate; the original allocation\n stands. The user needs to know the exact state.\n\n4. **Print a summary table**:\n\n```\nCreated the following work items:\n| ID | Title | File |\n|------------|---------|--------------------------------------|\n| PROJ-0001 | [title] | `{work_dir}\u002FPROJ-0001-slug.md` |\n| OTHER-0001 | [title] | `{work_dir}\u002FOTHER-0001-slug.md` |\n...\n```\n\nUnder the default `{number:04d}` pattern the ID column shows\n`0001`, `0002`, etc., and no project amendment table appears.\n\n**Validate the frontmatter**: after writing, run the validator on each work\nitem written this batch\n\n```bash\naccelerator corpus frontmatter validate --file \u003Ceach written work item path>\n```\n\nIf any invocation exits non-zero, the document violates the canonical\nfrontmatter standard; report the emitted violation and fix the frontmatter\nbefore completing.\n\n### Step 4 under `{tracker}`: Create the Batch\n\n1. **Count approved (non-skipped) items: N.** If N is 0, print \"No work\n items approved — nothing written.\" and exit cleanly.\n\n2. **Build the manifest.** Give each approved draft a short unique `ref`\n (its slug will do). For each, write the drafted body (H1 through\n References) to a scratch file with the `NNNN` placeholder left literally\n in place, then write one JSON array to a scratch manifest file, one\n entry per draft in presentation order:\n\n ```json\n [\n {\"ref\": \"add-foo\", \"title\": \"Add foo\", \"kind\": \"epic\",\n \"priority\": \"high\", \"body_file\": \"add-foo.md\",\n \"derived_from\": [\"plan:2026-01-01-foo\"]},\n {\"ref\": \"foo-api\", \"title\": \"Foo API\", \"kind\": \"story\",\n \"priority\": \"medium\", \"body_file\": \"foo-api.md\",\n \"parent\": {\"ref\": \"add-foo\"}}\n ]\n ```\n\n - `parent` is `{\"ref\": \"\u003Cref>\"}` when the approved hierarchy places the\n item under another draft of this batch, or a typed reference such as\n `\"work-item:0042\"` when its parent already exists. Omit it otherwise.\n - `tags`, `blocks`, `blocked_by`, `relates_to`, `derived_from` and\n `source` follow the same omit-when-empty rules as the frontmatter in\n Step 4 h. `body_file` is relative to the manifest's directory.\n - Do not call `accelerator work next-number`, and never write an item\n with the `Write` tool: `create-batch` mints every ID and writes every\n file.\n\n3. **Make one push offer for the whole batch** (when **Active integration**\n is non-empty). Use the `AskUserQuestion` tool with two options:\n\n 1. **Yes, push all N to [tracker] now** — create every issue and take\n its key as the item's ID\n 2. **No, save as drafts** — save every item as a draft; `\u002Fsync-work-items`\n promotes them later\n\n Never ask per item.\n\n4. **Create the batch** with one call, adding `--push` only when the push\n was accepted:\n\n ```\n accelerator work create-batch --manifest \u003Cmanifest-file> \\\n --producer extract-work-items --author \"\u003Cresolved author>\" [--push]\n ```\n\n It creates parents before their children and writes each child's\n `parent` as the ID its parent actually took, so a child of an item left\n as a draft links to that draft (promotion rewrites the link later).\n\n5. **Read the output.** Each item prints one line,\n `\u003Cref>\\t\u003Cpath>\\t\u003Ckeyword>\\t\u003Ckey>`, in the order the items were created.\n After them come `#\\tdetail\\t\u003Cref>\\t\u003Csource>\\t\u003Cpath>[\\t\u003Crecovery-dir>]`\n lines; match each to its item by `\u003Cref>`, never by position. A\n `holder` source names the item already claiming the key; `vcs` and\n `recovery` sources name paths to restore, the latter from\n `\u003Crecovery-dir>`.\n\n6. **Print a summary table**, one row per item line in printed order:\n\n ```\n | Item | Outcome | File |\n |---------|--------------------------|---------------------------------|\n | Add foo | created ENG-42 | `meta\u002Fwork\u002FENG-42-add-foo.md` |\n | Foo API | draft — push declined | `meta\u002Fwork\u002Fdrafts\u002Fdraft-…` |\n ```\n\n The Outcome column renders the keyword:\n\n | Keyword | Outcome |\n |---|---|\n | `write-once` | `created \u003CKEY>` |\n | `created-unwritten` | `created \u003CKEY> — local write failed` |\n | `declined` | `draft — push declined` |\n | `local-save` | `draft — tracker unreachable` |\n | `local-save` with a `warning: -: configure failed:` line | `draft — sync refused (configuration)` |\n | `loud-terminal` | `draft — remote issue may exist` |\n | `rejected` | `draft — request rejected` |\n | `retirement-incomplete` | `created \u003CKEY> — local write incomplete; restore from VCS or \u003Crecovery-dir>` |\n | `created-blocked` | `created \u003CKEY> — blocked by \u003Cholder>; resolve it, then promote` |\n | `pending` | `draft — already pending as \u003Cdraft>; run work sync` |\n\n `\u003Cholder>` and `\u003Crecovery-dir>` come from the item's detail lines, and\n `\u003Cdraft>` is the item line's path. The path is empty when no local file\n carries the item: a `created-unwritten` item, and a `pending` item whose\n earlier create an older binary recorded without a draft. Render the File\n cell as `—`, and a `pending` item's Outcome as `draft — already pending;\n run work sync`. After the table, relay each `Error: \u003Cref>: …` line from\n stderr under its item, with the recovery for its outcome. A draft's ID\n is the `draft-` prefix of its filename.\n\n | Keyword | Recovery |\n |---|---|\n | `declined`, `local-save` | none; `\u002Fsync-work-items` promotes the draft |\n | `local-save` with a `warning: -: configure failed:` line | if stderr carries a `warning: -: configure failed:` line, relay its cause; the draft cannot be pushed or promoted until it is fixed, and sync will refuse until then. The batch prints each distinct warning once, so it is relayed once, not under each item |\n | `loud-terminal` | check the tracker, then `accelerator work promote \u003Cdraft-id> --adopt \u003CKEY>` if the issue exists, otherwise `accelerator work promote \u003Cdraft-id> --create` |\n | `rejected` | edit the draft to remove the cause stderr names, then `accelerator work promote \u003Cdraft-id>` or `\u002Fsync-work-items` |\n | `created-unwritten` | none; the next `\u002Fsync-work-items` links the issue |\n | `created-blocked` | resolve the collision stderr describes, then `accelerator work promote \u003Cdraft-id>` |\n | `retirement-incomplete` | restore the paths the detail lines name, then `\u002Fsync-work-items` |\n | `pending` | `accelerator work promote \u003Cdraft-id>` or `\u002Fsync-work-items`; with an empty path, `\u002Fsync-work-items` |\n\n Never re-run `create-batch` to recover an item. With `--push`, every\n item it reported already has a draft or an issue, so a rerun changes\n nothing for it; without `--push`, a rerun writes every item again.\n\n7. **Branch on the exit code.** 0, 4, 70, 71, 74 and 75 all mean the batch\n ran; the table above is the report. 2 means the manifest was refused\n or its parents form a cycle, and nothing was written: relay the\n message, fix the manifest, and call again. 1 means an item could not be\n created: the items printed before it were; relay the error, and once it\n is fixed call `create-batch` again. With `--push`, pass the same\n manifest: a pushed batch creates only the entries it never reached.\n Without `--push`, a rerun writes every entry again, so pass a manifest\n of only the entries no item line printed, with each `{\"ref\": …}`\n parent naming a printed entry replaced by `\"work-item:\u003Cid>\"` from that\n entry's line.\n\n8. **Validate the frontmatter** of every item whose line names a path:\n\n ```bash\n accelerator corpus frontmatter validate --file \u003Cpath>\n ```\n\n## Quality Guidelines\n\n- Under `{tracker}`, Step 4 under `{tracker}` replaces Step 4: the\n `accelerator work next-number` rules below apply only to other patterns.\n\n- Never call `accelerator work next-number` before all approvals are collected.\n The number space is shared and finite; consuming numbers for drafts the\n user might still skip creates gaps that are impossible to clean up later.\n- Never call `accelerator work next-number` when N=0. An all-skipped session must\n exit cleanly with no side effects.\n- If `accelerator work next-number` exits non-zero, abort immediately and surface\n the script's error output verbatim — even if it emitted some numbers on\n stdout before failing, treat the entire batch as failed.\n- Verify all target slugs are free BEFORE calling `accelerator work next-number` —\n collision checks happen before number allocation, by slug pattern, since\n numbers are not yet known. Under a `{project}` pattern the collision\n check is **project-aware**: the same slug under two different project\n codes (`PROJ-0001-add-foo.md` and `OTHER-0001-add-foo.md`) is\n legitimate. Same-slug legacy `NNNN-{slug}.md` files always count as a\n collision.\n- Under a `{project}` pattern, the amendment table prompts the user\n to assign or override project codes per row before allocation. The\n display-only projected IDs are recomputed after every amendment.\n No numbers are committed until the user confirms with blank input.\n- Numbers are assigned to approved drafts in their original presented\n order, not in approval timestamp order. This makes outputs deterministic\n and matches the order the user reviewed.\n- Every written work item MUST include all source document paths in its\n `References` section. For deduplicated items that appeared in multiple\n documents, list every contributing source.\n- Do not extract structural or navigational content (table of contents\n entries, section headings with no requirements content, agenda items\n with no actionable outcome) as candidate work items. If a heading just\n organises content rather than describing work, skip it.\n- Work item kind inference must use kinds read from the work item template\n frontmatter (loaded at the top of this skill), not a hardcoded list.\n Default to `story` for items where the kind is genuinely ambiguous.\n- All frontmatter fields defined in the work item template must be populated\n in every written work item — `type` (`work-item`), `id` matching the\n assigned full ID, `title` matching the work item's title, `date`,\n `author`, `producer` (`extract-work-items`), `status` (`draft`),\n `kind`, `priority` (medium unless the source implies otherwise),\n `parent` (empty string unless the source establishes a parent),\n `external_id` (empty unless set), `tags` (a YAML array, possibly\n empty), `last_updated`, `last_updated_by`, and `schema_version: 1`.\n No field may contain unfilled placeholder text like `[author]` or\n `NNNN`. The body H1 format is `# \u003Cfull-id>: \u003Ctitle>` — kept in sync\n with the frontmatter `title:` field.\n- `date` must use the work item template's `YYYY-MM-DDTHH:MM:SS+00:00`\n format in UTC (e.g. obtained via `date -u +%Y-%m-%dT%H:%M:%S+00:00`).\n- `author` is sourced in this order: configuration if present, then the\n source document's author\u002Fowner field if named, then the current git\u002Fjj\n user identity, then — only if all of those fail — ask the user once\n before writing the batch. Never write `[author]` or any placeholder.\n- \"Accept remaining as-is\" only marks unreviewed candidates as approved\n (thin) — it does not resurrect skipped candidates, and writing still\n happens exclusively in Step 4 after the single `accelerator work next-number`\n call.\n- Source-derived content stays faithful to what the source documents say.\n Do not silently invent requirements. When you make an interpretation while\n filling out the work item — about scope, stakeholders, terminology, or implied\n approach — capture it in `Drafting Notes`. Use `Open Questions` for genuine\n unknowns the source leaves unanswered. A Drafting Note is worth writing\n whenever the wrong interpretation would send someone in a meaningfully\n different direction.\n- The enrichment loop (3.3) is per candidate. Do not pre-generate enriched\n drafts for the whole batch — enrichment depends on the user's answers\n and the model's research, both of which differ per candidate. Build the\n source-derived skeleton (3.1), present it (3.2), then enrich one\n candidate at a time.\n- Web research (`{web-search-researcher agent}`) is a first-class step\n inside enrichment. Spawn it whenever there is uncertainty about\n domain, business, competitive, or technical aspects of the candidate.\n Skip only when the candidate is self-contained and well-understood.\n- Thin drafts (accepted as-is) and enriched drafts coexist in the same\n work items directory. Thin drafts must carry the verbatim `Drafting Notes`\n entry recording non-enrichment so a future `\u002Frefine-work-item` invocation (or\n manual review) can identify them as needing follow-up before promotion\n from `draft` to `ready`.\n- Acceptance criteria in enriched drafts must be specific and testable;\n prefer Given\u002FWhen\u002FThen for story\u002Ftask. Challenge any criterion that\n is not measurable before accepting it into the draft.\n\n!`accelerator config instructions extract-work-items --fail-safe`\n","# Extract Work Items from Meta Documents\n\n!`accelerator config context --skill extract-work-items --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:reviewer, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser,\naccelerator:web-search-researcher.\n\n**Work items directory**: !`accelerator config path work --fail-safe`\n**Codebase research directory**: !`accelerator config path research_codebase --fail-safe`\n**Plans directory**: !`accelerator config path plans --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`: an\nitem takes its issue's key once the tracker creates it, and one no tracker\nhas confirmed is saved as a **draft** under a provisional `draft-` ID, which\n`\u002Fsync-work-items` promotes later. Step 4 then creates the whole batch\nthrough `accelerator work create-batch` (see \"Step 4 under `{tracker}`\").\nUnder every other pattern, Step 4 allocates numbers and writes the files as\ndescribed there.\n\n## Work Item Template\n\nThe template below defines the sections and frontmatter fields that every\nwork item must contain. Read it now — the valid work item kinds live in the `kind`\nfield (not a hardcoded list elsewhere in this skill), and every written file\nmust populate every frontmatter field.\n\n!`accelerator config template work-item --fail-safe`\n\nYou are tasked with identifying requirements, work items, and actionable\ntasks within existing meta documents and helping the user capture them as\nformal work items. Source documents typically tell you *what* work items should\nexist but rarely give the full business context, testable acceptance\ncriteria, dependencies, and assumptions a good work item needs. The model,\nthe user, and web research fill those gaps.\n\nExtraction therefore proceeds in two layers:\n\n- **Source-derived content stays faithful.** Anything you draw from the\n source documents must reflect what they actually say — do not silently\n invent requirements that are not there.\n- **Business-context gaps are surfaced.** The `Assumptions`, `Open Questions`\n and `Drafting Notes` sections serve different purposes when present, and all \n matter:\n - **Assumptions** are interpretations you made that affect the work item's\n meaning. Flag one only when using the wrong interpretation would lead\n someone to build something different. Example: *\"Interpreted 'users' as\n end users rather than internal staff — if wrong, scope changes.\"*\n - **Open Questions** are genuine unknowns the source raises but leaves\n unanswered that a reader or implementer needs resolved before work can\n proceed. Example: *\"What does 'better results' mean — improved relevance, \n faster delivery, or both?\"*\n - **Drafting Notes** capture interpretations you made while filling out\n the work item — business-context calls, scope decisions, or technical\n choices that someone should review if they turn out to be wrong.\n Actively populate this section. If you inferred who the stakeholders\n are, what a vague term means, what the scope boundary is, or which\n technical approach the source implies, write it down.\n Examples: *\"Treated this as a spike because no acceptance criteria are \n defined — if implementation is already expected, kind and scope both \n change.\"* Routine field selections (kind, priority, tags) don't need an \n entry unless the choice reflects a substantive scope or meaning \n interpretation that a reviewer should be aware of.\n\nFor each selected candidate, you offer the user the choice between\n*enriching* the work item interactively (with model knowledge, web research,\nand a few focused questions, similar to `\u002Fcreate-work-item`) or *accepting\nthe source-derived skeleton as-is* and refining later. The enrichment\nloop is per candidate, not pre-generated, so the work the model invests\nmatches the depth the user wants for each work item.\n\n## Initial Setup\n\nWhen this command is invoked:\n\n1. **Check if parameters were provided**:\n\n- If one or more file paths were provided, note them as the target documents\n- If no parameters provided, ask conversationally and helpfully which\n documents to work with. Give the user enough context to respond easily:\n briefly explain what kinds of sources work (specific files, planning docs,\n meeting notes, research, specs), mention that you can also scan all\n documents in the configured directories, and invite them to direct.\n Helpful examples matter more here than brevity — aim for something\n welcoming and informative rather than a single terse question.\n\nWait for user input.\n\n## Process Steps\n\n### Step 1: Identify Source Documents\n\n1. If specific files were provided, read them FULLY. Before reading,\n verify each path exists. If any path does not exist, report which\n paths are missing and ask the user to correct or remove them — do not\n silently skip them or proceed with an empty set.\n2. If scanning all meta documents:\n - Spawn a **{documents locator agent}** agent to find all documents in the\n configured research and plans directories (shown above)\n - Present the discovered documents and let the user select which to scan:\n ```\n I found the following documents:\n\n **Research:**\n - `{research directory}\u002F2026-04-08-topic.md` — Topic research\n - ...\n\n **Plans:**\n - `{plans directory}\u002F2026-04-19-feature.md` — Feature plan\n - ...\n\n Which documents should I scan for work items? (enter numbers, \"all\", or\n specific paths)\n ```\n - Wait for user selection.\n\n### Step 2: Analyse Documents for Work Items\n\n1. **Spawn {documents analyser agent} agents** (one per document, in parallel)\n with instructions to identify requirements and actionable work items.\n Look for:\n - Explicit requirements (\"The system must...\", \"Users need to...\",\n \"We need to implement...\")\n - User stories (\"As a..., I want..., so that...\")\n - Feature descriptions and acceptance criteria\n - Bug reports with symptoms and expected behaviour\n - Open-ended investigations or unknowns requiring research\n - Multi-deliverable themes that span several stories\n - One-off tasks (migrations, infrastructure work, documentation)\n\n2. **Wait for all agents to complete.**\n\n3. **Deduplicate**: Where the same work item appears across multiple\n documents, merge the entries and record all source documents it came from.\n\n4. **Present discovered candidates** as a numbered list:\n\n```\nI found the following actionable items across the scanned documents:\n\n1. **[Short title]** — [one-line description]\n Source: `{research directory}\u002F2026-04-08-topic.md`\n\n2. **[Short title]** — [one-line description]\n Source: `{plans directory}\u002F2026-04-19-feature.md`, `{research directory}\u002F2026-04-08-topic.md`\n\n3. ...\n\nWhich items would you like to create work items for? (enter numbers, \"all\",\nor \"none\")\n```\n\nIf no actionable items are found across all documents, inform the user:\n\"No actionable items found in the provided documents.\" and exit cleanly.\n\nWait for user selection. If the user selects \"none\", exit cleanly without\nwriting any files.\n\n### Step 3: Enrich and Approve (Per Candidate)\n\nFor each selected candidate, in original presented order, build a\nsource-derived skeleton, present it, and let the user choose how much\nenrichment to invest. Do NOT pre-generate drafts for the entire batch\nin advance — enrichment can change a draft significantly, so generation\nhappens per candidate inside this loop.\n\n#### 3.1 Build the source-derived skeleton\n\nFor the current candidate:\n\n- Infer the work item kind from its content using kinds read from the\n work item template's `kind` field:\n - clear bug reports with symptoms and expected\u002Factual behaviour → `bug`\n - open-ended investigations with specific questions → `spike`\n - broad multi-deliverable themes → `epic`\n - specific single deliverables → `story`\n - one-off technical or operational tasks → `task`\n - Default to `story` for items where the kind is genuinely ambiguous.\n- Draft a complete work item from the source content alone, using `XXXX`\n as the placeholder work item number.\n- Kind-specific content placement:\n - bug: reproduction steps, expected\u002Factual behaviour → `Requirements` section\n - spike: research questions, time-box, exit criteria → `Requirements` section\n - epic: initial story decomposition → `Requirements` section as a list\n - Do not rename or add sections beyond those in the work item template.\n- Surface business-context gaps using the right section: put your\n interpretation in `Assumptions` (when you made a call and the wrong call\n changes what gets built). Put unanswered questions in `Open Questions` when \n you genuinely cannot tell from the source. Populate `Open Questions` with \n anything that would materially change scope, approach, or acceptance \n criteria if resolved differently. Add a `Drafting Notes` entry for every \n meaningful interpretation you made (scope boundaries, who\n stakeholders are, what vague terms mean, which technical approach is implied).\n- Include all source documents for this item in the `References` section.\n\n#### 3.2 Present the skeleton with options\n\n```\nCandidate #N of M: [title]\nKind (proposed): [kind]\nSource: [paths]\n\n[work item content with XXXX placeholder, including Drafting Notes section]\n\n```\n\nUse the `AskUserQuestion` tool with four options:\n\n1. **Enrich** — interactive Q&A, web research where useful, then approve\n2. **Accept as-is** — write this skeleton as a thin draft for later refinement\n3. **Skip** — exclude from this batch\n4. **Accept all remaining** — fast-path every remaining candidate as a thin draft\n\nWait for the user's choice. If the user enters free-form text via the \"Other\"\ninput, treat it as **Enrich** seeded with those instructions: enter the\nenrichment loop in 3.3 using the supplied text as the first round of revision\nguidance, skipping the question phase if the instructions are already\nsubstantive.\n\n#### 3.3 enrich — interactive enrichment\n\nTreat this as a focused, per-candidate version of the `\u002Fcreate-work-item`\nflow, seeded with the skeleton above:\n\n1. **Ask 1–3 focused business-context questions** tailored to this\n candidate. Fewer than `\u002Fcreate-work-item`'s 3–5 because the source\n already provides some context. Cover whichever of the following are\n not already clear from the source:\n - What pain point or problem does this address, and who experiences it?\n - What is the desired outcome — what changes for people once this is done?\n - Are there constraints, deadlines, or dependencies worth knowing?\n - For bugs: what is the impact, and is it a blocker?\n - Anything you are uncertain about, or that should be researched?\n\n2. **Spawn `{web-search-researcher agent}`** when there is uncertainty\n about any aspect of this candidate the model lacks confidence on —\n business rules, domain concepts, competitive landscape, industry\n standards, external technology. Skip only when the candidate is\n self-contained and well-understood from the source plus user answers.\n When in doubt, prefer to spawn research — over-asking is cheaper\n than producing a vague enriched draft.\n\n3. **Update the draft** combining source content, user answers, model\n knowledge, and research findings. Re-present it as a structured\n proposal that:\n - Confirms or revises the kind\n - Lists requirements drawn from source + enrichment\n - Proposes specific, testable acceptance criteria — prefer\n Given\u002FWhen\u002FThen for story\u002Ftask; draw on domain knowledge and\n research to make them thorough\n - Lists dependencies (blocking and blocked) where known\n - Keeps a `Drafting Notes` section for any interpretations still\n unresolved so the user can challenge them\n - Lists remaining open questions in the `Open Questions` section\n\n Then use the `AskUserQuestion` tool with four options:\n\n 1. **Approve** — accept this draft and move on to the next candidate\n 2. **Revise** — update the draft with additional instructions (prompted after\n via plain-text — do NOT use `AskUserQuestion` for the instructions)\n 3. **Skip** — discard this candidate entirely\n 4. **Accept as-is** — discard enrichment and use the original source-only skeleton\n\n4. **Iterate on the same candidate.** Challenge weak or untestable\n acceptance criteria — when a criterion is not measurable, ask what a\n passing test would look like and reformulate together. Do not accept\n vague criteria into the draft. The candidate position (e.g. \"Candidate\n #N of M\") does NOT advance during iteration: re-present the updated\n draft for the same candidate and accept further free-form revision\n instructions, looping as many times as needed. Only `approve` (or one\n of the interrupts below) advances to candidate N+1. Once the user\n explicitly approves, mark the candidate **approved (enriched)** and\n advance to the next candidate.\n\nThe user may switch out of enrichment at any point by saying:\n\n- `skip` — exclude this candidate entirely. Discard any partial\n enrichment work — questions answered, drafts re-proposed — and never\n approve it later, even if `accept remaining as-is` is invoked on a\n subsequent candidate.\n- `accept as-is` — replace the in-flight enriched draft with the\n original 3.1 source-derived skeleton (NOT the partially enriched\n state) and apply the 3.4 thin-draft assumptions note. The user is\n saying \"stop enriching this one; take the source-only version\".\n\nHonour these interrupts immediately on the turn they are received.\n\n#### 3.4 accept as-is — thin draft\n\nTake the source-derived skeleton from 3.1 as the final draft for this\ncandidate. Append (or extend) the `Drafting Notes` section with the\nfollowing note **verbatim** (so future tooling like `\u002Frefine-work-item`\nand human reviewers can detect thin drafts deterministically):\n\n> Extracted from source documents without interactive enrichment.\n> Acceptance criteria, dependencies, and kind may need refinement before\n> promoting from `draft` to `ready`.\n\nIf the candidate already has source-derived drafting notes, keep them\nand add the verbatim note as a separate paragraph beneath.\nKeep any `Open Questions` from the 3.1 skeleton — these are genuine\nbusiness unknowns that need resolution regardless of whether enrichment\nhappened. Mark the candidate **approved (thin)** and advance to the next.\n\n#### 3.5 skip\n\nExclude this candidate from the batch and advance to the next. Skipped\ncandidates never become approved later, even if a subsequent\n`accept remaining as-is` is used.\n\n#### 3.6 accept remaining as-is — fast-path\n\nMark every remaining *unreviewed* candidate as **approved (thin)**,\napplying the same skeleton + assumptions note as 3.4. Do not ask\nfurther questions. Already-skipped candidates stay skipped. Jump to\nStep 4.\n\n#### 3.7 No `accelerator work next-number` calls in Step 3\n\n`accelerator work next-number` is not called at any point during Step 3,\nregardless of which option the user picks. Writing happens exclusively\nin Step 4 after all approvals — enriched and thin — are collected.\n\n### Step 4: Write Work Items\n\n**A re-key in progress.** `accelerator work next-number` and\n`accelerator work create-batch` refuse before reading or writing anything\nwhile an `accelerator work rekey` run is unfinished. Before any other branch\non a non-zero exit from one of them, check its stderr for these codes; in\nevery case 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\nWhen **ID pattern** is `{tracker}`, follow \"Step 4 under `{tracker}`\" below\ninstead of this step.\n\n1. **Count approved (non-skipped) items: N.**\n\n2. **If N is 0**: print \"No work items approved — nothing written.\" and exit\n cleanly. Do NOT call `accelerator work next-number`.\n\n3. **Otherwise**:\n\n a. **Compute target slugs** — for each approved draft, derive a meaningful\n kebab-case slug from its title.\n\n b. **Read configuration.** Invoke each script by its bare path and use the\n command's stdout as the named value — do **not** wrap the call in a `VAR=$(…)`\n assignment, as the assignment (not the path) would become the command and escape\n the rule:\n\n - Run `accelerator config work id_pattern` and use its\n stdout as `PATTERN`.\n - Run `accelerator config work key` and use its stdout as\n `KEY_PREFIX` (the local ID prefix).\n\n Run the bare path **directly** as an executable;\n never prefix it with `bash`\u002F`sh`\u002F`env` (a wrapper prefix escapes the skill's\n `allowed-tools` permission and forces an unnecessary prompt).\n\n c. **Suggest projected IDs**: if `PATTERN` references the `{key}` prefix\n token (or the deprecated `{project}` synonym), the default prefix for each\n row is `KEY_PREFIX` (warn and require user amendment if `KEY_PREFIX` is\n empty). If `PATTERN` has no prefix token, no project column is shown.\n\n Compute *display-only* projected IDs by calling, per distinct\n project code:\n ```\n accelerator work next-number --project \u003Ccode> --count \u003Ccount-for-that-project>\n ```\n These calls do not commit numbers; the same call is re-issued after\n every amendment to keep the table accurate.\n\n d. **Present an amendment table**:\n\n ```\n | # | Slug | Project | Projected ID |\n | 1 | add-foo | PROJ | PROJ-0001 |\n | 2 | fix-bar | PROJ | PROJ-0002 |\n | 3 | update-baz | PROJ | PROJ-0003 |\n\n Amend any rows? (`\u003Crows> \u003CPROJECT>` to set, `\u003Crows> -` to revert to\n default, `?` for help, `q` to cancel, blank to confirm.)\n ```\n\n When `PATTERN` has no prefix token, omit the `Project` column and\n render only `| # | Slug | Projected ID |`. The amendment prompt is\n not shown in that case — proceed directly to confirmation.\n\n **Amendment grammar** (canonical — same wording in every state):\n\n - `\u003Crows>`: one row number (`2`) or comma-separated list (`2,3,7`).\n Whitespace around commas is permitted (`2, 3, 7`) and trimmed.\n - `\u003CPROJECT>`: a project code matching `[A-Za-z][A-Za-z0-9]*`.\n - `\u003Crows> -`: revert the named rows to the default project code\n (or to \"no project\" when no default is set).\n - `?`: re-display the amendment grammar reference plus the\n unchanged table; no state change.\n - `q`: cancel the entire flow with no files written and no numbers\n allocated.\n - Blank input: confirms the current table state.\n\n **Validation**: out-of-range row numbers re-prompt with\n `error: row N — out of range (valid: 1-M)` without applying any\n other amendments in the same input. Invalid project codes\n re-prompt with `error: row N — project value \"\u003Cvalue>\" must\n match [A-Za-z][A-Za-z0-9]*` and discard the entire input\n (no partial application). Unrecognised commands re-prompt with\n `error: unrecognised input. Type ? for help.` On any rejection\n the table reverts to its last valid state.\n\n After every accepted amendment, recompute projected IDs by\n re-issuing the per-project allocator calls (display only).\n\n e. **Project-aware slug-collision check** before any allocation. For\n each row, glob:\n - When the pattern has `{project}`:\n `{work_dir}\u002F\u003Cproject>-*-\u003Cslug>.md` for the row's project — a\n same-slug file under the *same* project is a real collision.\n - Always (legacy fallback):\n `{work_dir}\u002F[0-9][0-9][0-9][0-9]-\u003Cslug>.md` — a same-slug legacy\n file shadows the new file regardless of project.\n\n Within the same batch, two amendments to the same project with\n the same slug are also a collision. Same slug under different\n projects (`PROJ-0001-add-foo.md` and `OTHER-0001-add-foo.md`) is\n legitimate and not a collision.\n\n If any collision is detected, report which slugs collide and\n which existing files they match, abort without calling the\n allocator, and ask the user to resolve the collision before\n re-running.\n\n f. **Allocate per distinct project code**, in original presentation\n order:\n ```\n accelerator work next-number --project \u003Ccode> --count \u003Ccount>\n ```\n One call per distinct project code; `--project` is omitted when\n the pattern lacks `{project}`. If any allocator call exits\n non-zero, abort immediately and surface the error verbatim — do\n not write any files. The whole batch fails atomically.\n\n g. **Substitute the allocated full IDs** into approved drafts in\n their original presented order. Within a single project, the\n first row in presentation order takes the first allocated\n number; multiple projects each preserve their own ordering. The\n `id` frontmatter is **always quoted** (`\"PROJ-0001\"`).\n\n h. **Populate frontmatter** for every approved draft. Before writing\n each file, capture metadata and substitute the unified base\n fields into the template's frontmatter block:\n\n 1. Invoke\n `accelerator corpus metadata derive`\n once for the batch to obtain `Current Date\u002FTime (UTC):`,\n `Current Revision:`, and `Repository Name:`.\n 2. For each approved draft, **substitute** every field below\n with the indicated value:\n - `type:` ← `work-item`\n - `id:` ← the allocated full ID, always quoted as a YAML\n string (e.g. `id: \"PROJ-0001\"`)\n - `title:` ← the draft's H1 title\n - `date:` ← the `Current Date\u002FTime (UTC):` value\n - `author:` ← the author value resolved per the rules in\n `create-work-item\u002FSKILL.md > author` (config → VCS user →\n prompt)\n - `producer:` ← `extract-work-items`\n - `status:` ← `draft`\n - `last_updated:` ← the same `Current Date\u002FTime (UTC):` value\n - `last_updated_by:` ← the same value resolved for `author`\n - `schema_version:` ← `1` (bare integer, not quoted)\n\n Optional linkage\u002Fforeign-ref keys are omit-by-default:\n the template shows each as `\"\"`\u002F`[]`, but write a\n key into the artifact **only** when it has a value, and omit it\n entirely otherwise (do not carry the empty placeholder\n through). By default a freshly extracted draft names none of\n them.\n\n - `parent:` ← the parent work item's ID as a typed-linkage ref\n (`\"work-item:NNNN\"`). Fill when the source names a parent;\n otherwise omit the key entirely.\n - `blocks:` ← list of typed-linkage refs to work items this\n item blocks (`[\"work-item:NNNN\", ...]`). Fill when blocking\n edges are explicit in the source; otherwise omit the key.\n - `blocked_by:` ← list of typed-linkage refs to work items that\n block this one. Prefer writing the canonical `blocks:` on the\n other side; emit `blocked_by:` only when the canonical side\n cannot be written, and omit it otherwise.\n - `derived_from:` ← list of typed-linkage refs to artifacts this\n item is derived from (`[\"plan:NNNN\", ...]`). Fill when\n derivation is explicit; otherwise omit the key.\n - `relates_to:` ← list of typed-linkage refs to related\n artifacts. Fill when relationships are explicit; otherwise\n omit the key.\n - `source:` ← typed-linkage ref to the originating source\n artifact (`\"issue-research:NNNN\"`). Fill when the source is a\n meta artifact with an id; otherwise omit the key.\n - `external_id:` ← cross-system pointer (e.g. a Jira\u002FLinear\n key). Fill when the item is linked to an external tracker;\n otherwise omit the key.\n\n i. **Write all N work item files**. Each work item's `References`\n section must include all source document paths the item was\n extracted from. For deduplicated items that appeared in multiple\n documents, list every contributing source under `References`,\n one per line.\n\n j. If a write error occurs mid-batch: report which numbers were\n allocated, which files were written successfully, and which were\n not — so the user can manually write the missing files with\n their pre-assigned IDs. Do not retry writes silently and do not\n call the allocator again to re-allocate; the original allocation\n stands. The user needs to know the exact state.\n\n4. **Print a summary table**:\n\n```\nCreated the following work items:\n| ID | Title | File |\n|------------|---------|--------------------------------------|\n| PROJ-0001 | [title] | `{work_dir}\u002FPROJ-0001-slug.md` |\n| OTHER-0001 | [title] | `{work_dir}\u002FOTHER-0001-slug.md` |\n...\n```\n\nUnder the default `{number:04d}` pattern the ID column shows\n`0001`, `0002`, etc., and no project amendment table appears.\n\n**Validate the frontmatter**: after writing, run the validator on each work\nitem written this batch\n\n```bash\naccelerator corpus frontmatter validate --file \u003Ceach written work item path>\n```\n\nIf any invocation exits non-zero, the document violates the canonical\nfrontmatter standard; report the emitted violation and fix the frontmatter\nbefore completing.\n\n### Step 4 under `{tracker}`: Create the Batch\n\n1. **Count approved (non-skipped) items: N.** If N is 0, print \"No work\n items approved — nothing written.\" and exit cleanly.\n\n2. **Build the manifest.** Give each approved draft a short unique `ref`\n (its slug will do). For each, write the drafted body (H1 through\n References) to a scratch file with the `NNNN` placeholder left literally\n in place, then write one JSON array to a scratch manifest file, one\n entry per draft in presentation order:\n\n ```json\n [\n {\"ref\": \"add-foo\", \"title\": \"Add foo\", \"kind\": \"epic\",\n \"priority\": \"high\", \"body_file\": \"add-foo.md\",\n \"derived_from\": [\"plan:2026-01-01-foo\"]},\n {\"ref\": \"foo-api\", \"title\": \"Foo API\", \"kind\": \"story\",\n \"priority\": \"medium\", \"body_file\": \"foo-api.md\",\n \"parent\": {\"ref\": \"add-foo\"}}\n ]\n ```\n\n - `parent` is `{\"ref\": \"\u003Cref>\"}` when the approved hierarchy places the\n item under another draft of this batch, or a typed reference such as\n `\"work-item:0042\"` when its parent already exists. Omit it otherwise.\n - `tags`, `blocks`, `blocked_by`, `relates_to`, `derived_from` and\n `source` follow the same omit-when-empty rules as the frontmatter in\n Step 4 h. `body_file` is relative to the manifest's directory.\n - Do not call `accelerator work next-number`, and never write an item\n with the `Write` tool: `create-batch` mints every ID and writes every\n file.\n\n3. **Make one push offer for the whole batch** (when **Active integration**\n is non-empty). Use the `AskUserQuestion` tool with two options:\n\n 1. **Yes, push all N to [tracker] now** — create every issue and take\n its key as the item's ID\n 2. **No, save as drafts** — save every item as a draft; `\u002Fsync-work-items`\n promotes them later\n\n Never ask per item.\n\n4. **Create the batch** with one call, adding `--push` only when the push\n was accepted:\n\n ```\n accelerator work create-batch --manifest \u003Cmanifest-file> \\\n --producer extract-work-items --author \"\u003Cresolved author>\" [--push]\n ```\n\n It creates parents before their children and writes each child's\n `parent` as the ID its parent actually took, so a child of an item left\n as a draft links to that draft (promotion rewrites the link later).\n\n5. **Read the output.** Each item prints one line,\n `\u003Cref>\\t\u003Cpath>\\t\u003Ckeyword>\\t\u003Ckey>`, in the order the items were created.\n After them come `#\\tdetail\\t\u003Cref>\\t\u003Csource>\\t\u003Cpath>[\\t\u003Crecovery-dir>]`\n lines; match each to its item by `\u003Cref>`, never by position. A\n `holder` source names the item already claiming the key; `vcs` and\n `recovery` sources name paths to restore, the latter from\n `\u003Crecovery-dir>`.\n\n6. **Print a summary table**, one row per item line in printed order:\n\n ```\n | Item | Outcome | File |\n |---------|--------------------------|---------------------------------|\n | Add foo | created ENG-42 | `meta\u002Fwork\u002FENG-42-add-foo.md` |\n | Foo API | draft — push declined | `meta\u002Fwork\u002Fdrafts\u002Fdraft-…` |\n ```\n\n The Outcome column renders the keyword:\n\n | Keyword | Outcome |\n |---|---|\n | `write-once` | `created \u003CKEY>` |\n | `created-unwritten` | `created \u003CKEY> — local write failed` |\n | `declined` | `draft — push declined` |\n | `local-save` | `draft — tracker unreachable` |\n | `local-save` with a `warning: -: configure failed:` line | `draft — sync refused (configuration)` |\n | `loud-terminal` | `draft — remote issue may exist` |\n | `rejected` | `draft — request rejected` |\n | `retirement-incomplete` | `created \u003CKEY> — local write incomplete; restore from VCS or \u003Crecovery-dir>` |\n | `created-blocked` | `created \u003CKEY> — blocked by \u003Cholder>; resolve it, then promote` |\n | `pending` | `draft — already pending as \u003Cdraft>; run work sync` |\n\n `\u003Cholder>` and `\u003Crecovery-dir>` come from the item's detail lines, and\n `\u003Cdraft>` is the item line's path. The path is empty when no local file\n carries the item: a `created-unwritten` item, and a `pending` item whose\n earlier create an older binary recorded without a draft. Render the File\n cell as `—`, and a `pending` item's Outcome as `draft — already pending;\n run work sync`. After the table, relay each `Error: \u003Cref>: …` line from\n stderr under its item, with the recovery for its outcome. A draft's ID\n is the `draft-` prefix of its filename.\n\n | Keyword | Recovery |\n |---|---|\n | `declined`, `local-save` | none; `\u002Fsync-work-items` promotes the draft |\n | `local-save` with a `warning: -: configure failed:` line | if stderr carries a `warning: -: configure failed:` line, relay its cause; the draft cannot be pushed or promoted until it is fixed, and sync will refuse until then. The batch prints each distinct warning once, so it is relayed once, not under each item |\n | `loud-terminal` | check the tracker, then `accelerator work promote \u003Cdraft-id> --adopt \u003CKEY>` if the issue exists, otherwise `accelerator work promote \u003Cdraft-id> --create` |\n | `rejected` | edit the draft to remove the cause stderr names, then `accelerator work promote \u003Cdraft-id>` or `\u002Fsync-work-items` |\n | `created-unwritten` | none; the next `\u002Fsync-work-items` links the issue |\n | `created-blocked` | resolve the collision stderr describes, then `accelerator work promote \u003Cdraft-id>` |\n | `retirement-incomplete` | restore the paths the detail lines name, then `\u002Fsync-work-items` |\n | `pending` | `accelerator work promote \u003Cdraft-id>` or `\u002Fsync-work-items`; with an empty path, `\u002Fsync-work-items` |\n\n Never re-run `create-batch` to recover an item. With `--push`, every\n item it reported already has a draft or an issue, so a rerun changes\n nothing for it; without `--push`, a rerun writes every item again.\n\n7. **Branch on the exit code.** 0, 4, 70, 71, 74 and 75 all mean the batch\n ran; the table above is the report. 2 means the manifest was refused\n or its parents form a cycle, and nothing was written: relay the\n message, fix the manifest, and call again. 1 means an item could not be\n created: the items printed before it were; relay the error, and once it\n is fixed call `create-batch` again. With `--push`, pass the same\n manifest: a pushed batch creates only the entries it never reached.\n Without `--push`, a rerun writes every entry again, so pass a manifest\n of only the entries no item line printed, with each `{\"ref\": …}`\n parent naming a printed entry replaced by `\"work-item:\u003Cid>\"` from that\n entry's line.\n\n8. **Validate the frontmatter** of every item whose line names a path:\n\n ```bash\n accelerator corpus frontmatter validate --file \u003Cpath>\n ```\n\n## Quality Guidelines\n\n- Under `{tracker}`, Step 4 under `{tracker}` replaces Step 4: the\n `accelerator work next-number` rules below apply only to other patterns.\n\n- Never call `accelerator work next-number` before all approvals are collected.\n The number space is shared and finite; consuming numbers for drafts the\n user might still skip creates gaps that are impossible to clean up later.\n- Never call `accelerator work next-number` when N=0. An all-skipped session must\n exit cleanly with no side effects.\n- If `accelerator work next-number` exits non-zero, abort immediately and surface\n the script's error output verbatim — even if it emitted some numbers on\n stdout before failing, treat the entire batch as failed.\n- Verify all target slugs are free BEFORE calling `accelerator work next-number` —\n collision checks happen before number allocation, by slug pattern, since\n numbers are not yet known. Under a `{project}` pattern the collision\n check is **project-aware**: the same slug under two different project\n codes (`PROJ-0001-add-foo.md` and `OTHER-0001-add-foo.md`) is\n legitimate. Same-slug legacy `NNNN-{slug}.md` files always count as a\n collision.\n- Under a `{project}` pattern, the amendment table prompts the user\n to assign or override project codes per row before allocation. The\n display-only projected IDs are recomputed after every amendment.\n No numbers are committed until the user confirms with blank input.\n- Numbers are assigned to approved drafts in their original presented\n order, not in approval timestamp order. This makes outputs deterministic\n and matches the order the user reviewed.\n- Every written work item MUST include all source document paths in its\n `References` section. For deduplicated items that appeared in multiple\n documents, list every contributing source.\n- Do not extract structural or navigational content (table of contents\n entries, section headings with no requirements content, agenda items\n with no actionable outcome) as candidate work items. If a heading just\n organises content rather than describing work, skip it.\n- Work item kind inference must use kinds read from the work item template\n frontmatter (loaded at the top of this skill), not a hardcoded list.\n Default to `story` for items where the kind is genuinely ambiguous.\n- All frontmatter fields defined in the work item template must be populated\n in every written work item — `type` (`work-item`), `id` matching the\n assigned full ID, `title` matching the work item's title, `date`,\n `author`, `producer` (`extract-work-items`), `status` (`draft`),\n `kind`, `priority` (medium unless the source implies otherwise),\n `parent` (empty string unless the source establishes a parent),\n `external_id` (empty unless set), `tags` (a YAML array, possibly\n empty), `last_updated`, `last_updated_by`, and `schema_version: 1`.\n No field may contain unfilled placeholder text like `[author]` or\n `NNNN`. The body H1 format is `# \u003Cfull-id>: \u003Ctitle>` — kept in sync\n with the frontmatter `title:` field.\n- `date` must use the work item template's `YYYY-MM-DDTHH:MM:SS+00:00`\n format in UTC (e.g. obtained via `date -u +%Y-%m-%dT%H:%M:%S+00:00`).\n- `author` is sourced in this order: configuration if present, then the\n source document's author\u002Fowner field if named, then the current git\u002Fjj\n user identity, then — only if all of those fail — ask the user once\n before writing the batch. Never write `[author]` or any placeholder.\n- \"Accept remaining as-is\" only marks unreviewed candidates as approved\n (thin) — it does not resurrect skipped candidates, and writing still\n happens exclusively in Step 4 after the single `accelerator work next-number`\n call.\n- Source-derived content stays faithful to what the source documents say.\n Do not silently invent requirements. When you make an interpretation while\n filling out the work item — about scope, stakeholders, terminology, or implied\n approach — capture it in `Drafting Notes`. Use `Open Questions` for genuine\n unknowns the source leaves unanswered. A Drafting Note is worth writing\n whenever the wrong interpretation would send someone in a meaningfully\n different direction.\n- The enrichment loop (3.3) is per candidate. Do not pre-generate enriched\n drafts for the whole batch — enrichment depends on the user's answers\n and the model's research, both of which differ per candidate. Build the\n source-derived skeleton (3.1), present it (3.2), then enrich one\n candidate at a time.\n- Web research (`{web-search-researcher agent}`) is a first-class step\n inside enrichment. Spawn it whenever there is uncertainty about\n domain, business, competitive, or technical aspects of the candidate.\n Skip only when the candidate is self-contained and well-understood.\n- Thin drafts (accepted as-is) and enriched drafts coexist in the same\n work items directory. Thin drafts must carry the verbatim `Drafting Notes`\n entry recording non-enrichment so a future `\u002Frefine-work-item` invocation (or\n manual review) can identify them as needing follow-up before promotion\n from `draft` to `ready`.\n- Acceptance criteria in enriched drafts must be specific and testable;\n prefer Given\u002FWhen\u002FThen for story\u002Ftask. Challenge any criterion that\n is not measurable before accepting it into the draft.\n\n!`accelerator config instructions extract-work-items --fail-safe`\n",{"name":5,"description":7,"allowed-tools":44,"argument-hint":49},[45,46,47,48],"Bash(accelerator config *)","Bash(accelerator work *)","Bash(accelerator corpus metadata derive)","Bash(accelerator corpus frontmatter validate *)","[document paths...] or leave empty to scan all","main","9a3f77a1c7a3b3d1db560d7848c8cb49ca6f19f2","skills\u002Fwork\u002Fextract-work-items",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-10 21:05:37",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add atomicinnovation\u002Faccelerator --skill extract-work-items",{"tool":64,"command":65},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill extract-work-items",{"tool":67,"command":68},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill extract-work-items","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fextract-work-items\u002FSKILL.md",true,[72,78,82,86,90,94,98],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"evals\u002Fbenchmark.json","REFERENCE","参考文档",20175,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fextract-work-items\u002Fevals\u002Fbenchmark.json",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Fevals.json",27011,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fextract-work-items\u002Fevals\u002Fevals.json",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Ffixtures\u002Fmixed-project-batch.md",879,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fextract-work-items\u002Fevals\u002Ffixtures\u002Fmixed-project-batch.md",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Ffixtures\u002Fmixed-requirements.md",2448,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fextract-work-items\u002Fevals\u002Ffixtures\u002Fmixed-requirements.md",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"evals\u002Ffixtures\u002Fsimple-story.md",440,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fextract-work-items\u002Fevals\u002Ffixtures\u002Fsimple-story.md",{"path":95,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":96,"sourceHtmlUrl":97},"evals\u002Ffixtures\u002Fsparse-feature.md",146,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fextract-work-items\u002Fevals\u002Ffixtures\u002Fsparse-feature.md",{"path":99,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":100,"sourceHtmlUrl":101},"evals\u002Ffixtures\u002Fstructural-content.md",906,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fextract-work-items\u002Fevals\u002Ffixtures\u002Fstructural-content.md",[103,137,159,180,198,223],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":119,"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",[109,114],{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[120,121,122,123,124,125,126,127,37,128,129,130,131,34,132,133,134,135,30,136],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","map","when","number","URL","code","architecture","reviewer","review","change",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"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",[],[21,144,145,146,147,148,149,34,136,29,150,151,152,153,23,154,155,156,157,158],"update","update work item","work item","enforcement","manage","use","edit","validate","status","transition","Existing","tags","changes","fields","op",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"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",[],[21,166,167,168,38,169,170,34,171,136,172,173,174,175,176,177,178,29,179,23,129],"sync","sync work items","promote","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"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",[],[187,21,188,166,167,189,190,191,192,193,194,195,196,197],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":207,"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",[204],{"categoryNo":205,"categoryName":206,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000008","测试与质量",[208,209,21,210,146,211,212,213,214,215,216,34,217,218,29,151,219,220,221,130,222,23],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","user","gaps",{"skillNo":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":229,"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",[],[135,21,230,146,231,232,149,34,233,234,29,151,219,221,235,129,236,237,23,238],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path"]