[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXYWPCJ8WATMSAJFG40CTQ":3,"skill-same:01M6DXYWPCJ8WATMSAJFG40CTQ":116},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M6DXYWPCJ8WATMSAJFG40CTQ","create-work-item",null,"Interactively create a well-formed work item. Use when capturing a feature, bug, task, spike, or epic as a structured work item in meta\u002Fwork\u002F.","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\u002Fcreate-work-item\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"work item","create","work","create work item","structured","when","Existing","frontmatter","path","number","EPIC","as","feature","spike","task","bug","use","Bash","Meta","metadata","config","validate","2026-11-10 10:12:30",false,"---\nname: create-work-item\ndescription: Interactively create a well-formed work item. Use when capturing a\n  feature, bug, task, spike, or epic as a structured work item in meta\u002Fwork\u002F.\nargument-hint: \"[topic or existing work item path\u002Fnumber]\"\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# Create Work Item\n\n!`accelerator config context --skill create-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\nThe **Active integration** line gates the post-draft push offer (Step 5). The\n`accelerator config work integration` command above prints an **empty line**\nwhen no integration is configured, so branch on the **string**: a non-empty value means\n*integration configured* (offer the push); an empty value means *not configured*\n(no push offer — behave exactly as today). This is the single resolution of the\nactive tracker for this invocation; the push dispatcher is told which tracker to\nuse from **this** value, so the gate and the route cannot diverge.\n\nWhen **ID pattern** is `{tracker}`, the tracker owns every item's `id`: a\npushed item takes the issue's key as its `id`, and an item no tracker has\nconfirmed is saved as a **draft** in `drafts\u002F` under a provisional `draft-`\nID, which `\u002Fsync-work-items` promotes 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 guide what information you gather\nin Step 1 and what structure you produce in Steps 3–4.\n\n!`accelerator config template work-item --fail-safe`\n\nYou are tasked with guiding the user through creating a well-formed work item —\na structured document capturing a feature, bug, task, spike, or epic for\ntracking and implementation. This is a collaborative, challenging conversation:\nthe model contributes its own knowledge and research alongside the user's input\nrather than simply transcribing what the user says. The goal is a work item that\nis well-reasoned and well-specified — one that would stand on its own without\nneeding the author present to explain it.\n\nThe work item template has three sections that look similar but capture\ndifferent things — populate each deliberately:\n\n- **Assumptions** are interpretations you made that affect what gets built.\n  Flag one only when using the wrong interpretation would lead someone to\n  build something different. Example: *\"Treating 'users' as end users\n  rather than internal staff — if wrong, scope changes.\"*\n- **Open Questions** are genuine unknowns a reader or implementer needs\n  resolved before work can proceed. Example: *\"What does 'better results'\n  mean — improved relevance, faster delivery, or both?\"*\n- **Drafting Notes** capture interpretations you made while filling out the\n  work item — business-context calls, scope decisions, or technical choices\n  that someone should review if they turn out to be wrong. Actively\n  populate this section. If you inferred who the stakeholders are, what a\n  vague term means, where the scope boundary sits, or which technical\n  approach is implied, write it down. Routine field selections (kind,\n  priority, tags) don't need an entry unless the choice reflects a\n  substantive scope or meaning interpretation a reviewer should be aware\n  of.\n\n## Step 0: Parameter Check\n\nWhen this command is invoked:\n\n1. **If an argument was provided**:\n\n   First, **try to resolve the argument as a reference to an existing\n   work item** by invoking the resolver:\n\n   ```\n   accelerator work resolve \u003Cargument>\n   ```\n\n   The resolver respects `work.id_pattern` and accepts paths, full IDs\n   (`PROJ-0042`), legacy bare numbers (`0042`), and short numbers (`42`,\n   resolved against `work.key` when set).\n\n   - **Exit 0** (single match): the resolver echoes the absolute path on\n     stdout. Continue to frontmatter validation below.\n   - **Exit 1** (input invalid — neither path, full ID, nor bare number):\n     proceed to topic-string handling below; treat the argument as a\n     topic.\n   - **Exit 2** (ambiguous match): the resolver lists every candidate\n     with a source-category tag (`legacy`, `project-prepended`,\n     `pattern-shape`, or a project code). Present the list to the user\n     and ask them to disambiguate by re-running with a full ID (e.g.\n     `PROJ-0042`) or a path.\n   - **Exit 3** (no match): print\n     `\"No work item matching \u003Cargument> — interpreting as topic string.\n     If that's wrong, abort and re-run with a different argument (or\n     \u002Flist-work-items to find a valid reference).\"` and proceed to\n     topic-string handling below.\n   - **Exit 6** (path outside the work directory): the argument names a\n     real file that lies outside the managed work directory, so it is not\n     a topic string. Stop, print the resolver's error, and offer to run\n     `\u002Flist-work-items`.\n\n   **Frontmatter validation** (only reached after a file was successfully\n   resolved). Run:\n\n   ```\n   accelerator work show \u003Cpath> --field id\n   ```\n\n   The own-identity field is `id` on unified-shape files and\n   `work_item_id` on legacy files; `work show` resolves both\n   transparently, so either key name passed here would return the\n   same value.\n\n   If it exits non-zero (frontmatter missing or unclosed), print:\n\n   ```\n   Could not parse frontmatter in \u003Cpath> — the file may be corrupted.\n   Re-open it and check that the YAML frontmatter is bracketed by two\n   `---` lines and contains all nine required fields.\n   ```\n\n   and exit without spawning agents or writing any file. (The file clearly\n   resolved, so the user intended a path — no fallback applies.)\n\n   If validation passes, read the file fully (frontmatter and body) and\n   cache the identity fields in conversation state:\n   `id` (or `work_item_id` on legacy files), `date`, `author`, `status`,\n   `title`, `kind`, `priority`, `parent`, `tags`. For any missing\n   optional field, use the template default — do not abort. Set the conversation into\n   **enrich-existing mode** with `existing_work_item_path` cached, and\n   skip directly to Step 1 in that mode — do not run the vagueness check.\n\n   **Topic-string handling**: if no resolution succeeded (discriminators\n   did not trigger, or they triggered with a fallback warning), check\n   whether the argument is too vague (no clear deliverable or subject).\n   - Vague examples: \"improve things\", \"fix the API\", \"add more features\"\n   - Clear examples: \"add full-text search to the docs index page\",\n     \"fix login timeout after password reset\"\n   - If vague, ask at least one clarifying question and wait for a more\n     specific description before proceeding to Step 1.\n   - If clear, proceed directly to Step 1.\n\n2. **If no argument was provided**, respond with:\n\n```\nI'll help you create a well-specified work item through a collaborative conversation.\n\nTo get started, describe what you want to achieve — what's the problem or goal?\nFor example: \"add full-text search to the docs index page\", or \"users can't log in after resetting their password\"\n\nI'll ask a few questions to understand the problem space, do some research, then\nwork with you to shape a thoroughly reasoned work item.\n```\n\nThen wait for the user's input. Apply the same vagueness check to their\nresponse — if still vague, ask a clarifying question before proceeding to\nStep 1.\n\n## Step 1: Gather Business Context\n\nOnce the topic is clear, ask 3–5 open questions to understand the business\ncontext before investigating. Consult the work item template sections above to\nunderstand what the work item will need — use them to guide which questions are\nworth asking. Tailor the questions to the topic, but cover:\n\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- Does the user have a solution or approach in mind? If so, surface it and\n  ask whether it's a constraint or a preference to be explored further.\n- Are there any constraints, deadlines, or dependencies worth knowing?\n- For bug topics: what is the impact, and is it a blocker?\n- Is there anything you are uncertain about, or that I should research?\n\nAsk all relevant questions at once rather than one at a time. Wait for the\nuser's answers before proceeding to Step 2.\n\n### In enrich-existing mode\n\nDo not ask the broad discovery questions above. Instead:\n\n1. Identify which body sections of the existing file are **substantive** (real\n   content beyond `[bracketed placeholder]` text) and which are **gaps** (empty,\n   placeholder-only, or missing entirely). Tag each gap with **exactly one** of\n   the literal tokens:\n   - `empty` — section is absent or contains no content\n   - `placeholder-only` — section contains only template `[...]` blocks\n   - `instructional-prose` — section contains the template's instructional\n     prose carried over verbatim (e.g. \"Describe the business value of this\n     work item here…\")\n   - `partial` — section contains one or more substantive sentences alongside\n     residual placeholders\n\n   Use the literal token; do not paraphrase. The eval grader pattern-matches\n   on these exact strings.\n\n2. Present the gap analysis briefly:\n\n   ```\n   I've read the existing work item (\u003Cresolved path>). Here's what looks\n   complete and what still needs work:\n\n   Complete: [section list, or \"none\"]\n   Gaps:\n     - \u003CSection> (\u003Ctag>)\n     - ...\n\n   I'll ask targeted questions about the gaps.\n   ```\n\n3. Ask only questions that address the identified gaps. Do not re-ask\n   questions whose answers are already substantively present in the file.\n\n4. If the existing content is rich enough that no obvious gaps remain,\n   briefly confirm this and ask what the user wants to add or improve, then\n   proceed to Step 2.\n\n## Step 2: Investigate\n\nUsing the topic and business context from Step 1, run investigation agents\nin parallel:\n\n1. **Spawn {documents locator agent}** to search `{work_dir}` only —\n   look for existing work items with similar titles, descriptions, or scope.\n   Do not search research documents, plans, or other directories — work items\n   capture business requirements, not implementation details.\n\n2. **Spawn {web-search-researcher agent}** when there is uncertainty or a need\n   for richer context about any aspect of the topic — business rules, domain\n   concepts, competitive landscape, industry standards, external technology, or\n   anything the model lacks confidence on. Skip this agent only when the topic\n   is entirely self-contained and well-understood from the user's description.\n   When in doubt, prefer to spawn research — over-asking is cheaper than\n   producing a vague or poorly-grounded proposal.\n\nRun both agents in parallel where both are warranted.\n\nOnce agents complete, synthesise findings — what the model knows from training,\nwhat research turned up, what prior work items exist — as the foundation for Step 3.\n\n**If a similar existing work item is found**: Check its status.\n- If the status is `done`, `abandoned`, or `superseded` — mention the work item\n  briefly and note it is already closed, then continue creating the new one.\n- Otherwise — surface the work item and offer the user numbered options, for\n  example:\n  1. Proceed with a new work item (if the scope genuinely differs)\n  2. Exit and update the existing work item instead (use `\u002Fupdate-work-item` once\n     available; for now, update it manually)\n  3. Continue creating a new work item linked to the existing one as a parent\n\n  Adapt the options to what makes sense given the work item's kind and status.\n  Do not silently continue or modify the existing work item inline. Wait for\n  the user's choice before proceeding.\n\n**In enrich-existing mode**: exclude the resolved input file from the\nsimilarity scan. The {documents locator agent} search of `{work_dir}` will\nfind the file being enriched; do not surface it as a \"potential duplicate\" of\nitself. Other near-duplicates discovered are handled per the unchanged rules\nabove.\n\n## Step 3: Propose and Refine\n\nUsing the business context and investigation synthesis, the model leads with\na structured proposal. Do not ask the user to generate requirements or\nacceptance criteria from scratch — propose them and invite challenge.\n\n1. **Recommend a work item kind** with a brief rationale. Valid kinds come from\n   the work item template's `kind` field (loaded at the top of this skill) — do\n   not hardcode the list. Default to `story` when the kind is genuinely\n   ambiguous.\n2. **Draft requirements** drawn from the business context and research.\n3. **Draft acceptance criteria** — specific and testable; prefer Given\u002FWhen\u002FThen\n   format for story\u002Ftask. Draw on domain knowledge and research to make these\n   thorough, not just what the user explicitly mentioned.\n4. **Surface interpretations and gaps** using the right section:\n   - Put scope-changing interpretations you made in `Assumptions` and invite\n     the user to confirm or correct them.\n   - Put genuine unknowns that block progress in `Open Questions`.\n   - Put every meaningful drafting-time interpretation (who stakeholders are,\n     what vague terms mean, scope boundaries, implied technical approach) in\n     `Drafting Notes` so a reviewer can challenge them.\n\nPresent as a structured proposal:\n\n```\nBased on what you've told me and my research, here's what I think this work item needs:\n\n**Suggested kind**: [kind]\n**Rationale**: [one sentence]\n\n**Requirements I'd suggest**:\n- [requirement]\n\n**Out of scope** (explicitly not captured here):\n- [item]\n\n**Acceptance criteria I'd suggest**:\n- Given\u002FWhen\u002FThen...\n\n**Assumptions I've made** (scope-changing calls — confirm or correct):\n- [assumption]\n\n**Drafting Notes** (interpretations a reviewer should see):\n- [interpretation — e.g. who stakeholders are, what a vague term means,\n  scope boundary, implied technical approach]\n\n**Open questions** (unknowns to resolve before work begins):\n- [anything the user should clarify before drafting]\n```\n\nWait for the user to validate, push back, or refine. Challenge vague or\nuntestable responses — if an acceptance criterion is not measurable (e.g.,\n\"it works correctly\"), first ask a clarifying question to understand the\nintent (\"what would a passing test actually look like here?\"). Only after\nunderstanding the intent should you help reformulate it into something\ntestable. Do not accept vague criteria into the draft. Iterate until the\nproposal is well-specified and agreed.\n\n### In enrich-existing mode\n\nDo not lead with a from-scratch proposal. Instead present a section-by-section\nreview and augmentation:\n\n```\nHere's how the existing work item reads against my research, with proposed\nadditions for the gaps:\n\n**[Section name]** — [complete | needs improvement: \u003Creason> | missing]\n[existing content excerpt or note that it is missing]\n[proposed addition or replacement, when applicable]\n\n[repeat per section]\n\n**Title**: [keep \u002F propose new title with rationale]\n**Kind**: [keep existing \u003Ckind> \u002F propose change to \u003Ckind> with rationale]\n**Priority**: [keep \u002F propose change with rationale]\n**Parent**: [keep \u002F propose change]\n**Tags**: [keep \u002F propose additions]\n**Status**: [keep \u003Ccached> — say so if you'd like to transition it]\n```\n\nApply the canonical Identity Field Rules (see Quality Guidelines): propose\nonly the fields marked Proposable; never propose changes to immutable fields;\nsurface a status transition only if the user makes a direct explicit request\nfor one (the listing offers the affordance but never proposes a change\nunsolicited).\n\nThe refinement loop in this step (challenging untestable criteria, vague\nrequirements, etc.) applies equally to existing and proposed content.\n\n## Step 4: Draft Work Item\n\n1. **Draft a complete work item** from the agreed proposal using the template\n   structure loaded at the top of this skill. Use `NNNN` as the placeholder\n   work item number throughout. Do NOT call `accelerator work next-number` at this step.\n\n2. **Kind-specific content placement**:\n   - story\u002Fepic: open the `Summary` section with a user story statement —\n     \"As a [role], I want [goal], so that [benefit].\" — before the\n     descriptive sentences\n   - bug reproduction steps, expected\u002Factual behaviour → `Requirements` section\n   - spike research questions, time-box, exit criteria → `Requirements` section\n   - epic initial stories → `Requirements` section as a list\n   - Do not rename or add sections beyond those defined in the work item template\n\n3. **Populate the `References` section** with any external material that\n   informed the work item — research artefacts surfaced by the web researcher,\n   related work items found in Step 2, design docs, or source specs. Leave it\n   empty if nothing external was consulted; do not invent references.\n\n4. **Populate the `Drafting Notes` section** with the interpretations\n   carried over from the agreed proposal. If there were none (the user\n   confirmed every call), the section may be omitted or left as an empty\n   list — but do not leave placeholder bracketed text in it.\n\n5. **Present the full draft** to the user:\n\n```\nHere's my draft work item. Please review and let me know if you'd like any\nchanges before I write it to disk:\n\n[draft content]\n```\n\n6. **Continue to challenge** during the review loop — flag untestable criteria,\n   vague requirements, or gaps surfaced by research that remain unaddressed.\n   Iterate until the user explicitly approves. **`accelerator work\n   next-number` is never called during this loop.**\n\n### In enrich-existing mode\n\n1. Produce a complete updated draft incorporating the existing content plus the\n   additions approved in Step 3.\n2. Apply the canonical Identity Field Rules (see Quality Guidelines) when\n   filling frontmatter — the rules are the single source of truth for which\n   fields are immutable, preserved, or proposable.\n3. Apply the H1 sync rule (see Quality Guidelines).\n4. Apply the Script avoidance rule (see Quality Guidelines).\n5. Present the full updated draft, framed as an update preview:\n\n   ```\n   Here's the updated work item. The Step 5 confirmation will name the file\n   path and ask for explicit approval before any write:\n\n   [draft content]\n   ```\n\n6. Continue to challenge during review — apply the same rules as the\n   normal-path Step 4. Iterate the draft until the user is happy with it. Do\n   **not** treat a \"looks good\" mid-iteration as approval to write — that\n   approval is gated by Step 5's single confirmation.\n\n## Step 5: Write Work Item\n\n**A re-key in progress.** `accelerator work next-number` and\n`accelerator work create` (with or without `--push`) refuse before reading or\nwriting anything while an `accelerator work rekey` run is unfinished. Before\nany other branch on a non-zero exit from one of them, check its stderr for\nthese codes; in every 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\nUnder `{tracker}`, skip steps 1–3: there is no projected ID. The tracker\nassigns the key on a push, and `accelerator work create` mints the draft ID\nitself, so its first stdout line is the only path to report.\n\n1. **Call `accelerator work next-number`** to get the next full ID under the\n   configured pattern:\n\n```\naccelerator work next-number\n```\n\nThe output is the full ID (`0001` under default `{number:04d}`,\n`PROJ-0001` under `{key}-{number:04d}` with\n`work.key: \"PROJ\"`). The allocator reads the pattern and local ID prefix\nfrom configuration; pass `--project CODE` if the user explicitly wants a\nnon-default prefix for this one call.\n\nIf the command exits non-zero (e.g., overflow, missing project value),\nabort immediately and surface the error message verbatim — do not\nproceed.\n\n2. **Resolve the target path**: `{work_dir}\u002F\u003Cfull-id>-kebab-slug.md`\n   where `\u003Cfull-id>` is the allocator's output and the slug is a\n   meaningful kebab-case summary of the title (not raw input text).\n\n3. **Check that the target path does not already exist**. If it does, abort:\n\n```\nPath {path} already exists — another session may have written a work item\nconcurrently. Please re-run \u002Fcreate-work-item.\n```\n\n4. **Create the work items directory** if it does not exist.\n\n5. **Resolve `author`**: configuration if present, then the current git\u002Fjj\n   user identity, then — only if both fail — ask the user once. Never pass\n   a placeholder. This value feeds both branches below.\n\n6. **No integration configured — write via `accelerator work create`.**\n   Skip this step (go to step 7) when an integration *is* configured; the\n   push state machine in step 8 governs that case's single write instead.\n\n   1. Write the drafted body (H1 through References, everything approved\n      across Steps 1–4) to a scratch file, with the `NNNN` placeholder\n      still literally present everywhere it appears (the H1 line and\n      anywhere else) — do **not** substitute it yourself. `work create`\n      performs the one real `NNNN` → allocated-ID substitution as part of\n      the same atomic write that decides the ID, so the approved content\n      can never end up with an id\u002FH1 mismatch.\n   2. Call the dispatcher directly:\n\n   ```\n   accelerator work create \"\u003Ctitle>\" \u003Ckind> \u003Cpriority> \\\n     --status draft \\\n     --author \"\u003Cresolved author>\" \\\n     --producer create-work-item \\\n     --body-file \u003Cscratch-file> \\\n     [--parent \"work-item:NNNN\"] \\\n     [--tag \u003Cvalue>]... [--block \"work-item:NNNN\"]... \\\n     [--blocked-by \"work-item:NNNN\"]... \\\n     [--derived-from \"plan:NNNN\"]... [--relates-to \u003Cref>]... \\\n     [--source \"issue-research:NNNN\"] [--project \u003Ccode>]\n   ```\n\n      Include each bracketed flag only when that field has a value —\n      `work create` itself omits the corresponding frontmatter key when\n      the flag is absent, matching the template's own omit-when-empty\n      convention, so no separate omission logic is needed here. `--tag`\u002F\n      `--block`\u002F`--blocked-by`\u002F`--derived-from`\u002F`--relates-to` are each\n      repeatable for multiple values. `external_id` has no flag — `work\n      create` never writes it (nothing to sync yet); this matches today's\n      behaviour of omitting it from a fresh draft.\n   3. If the command exits non-zero, surface its stderr message verbatim\n      and abort — do not retry and do not attempt a manual `Write`.\n      Otherwise its stdout is the path of the written file. Skip to\n      step 8.\n\n7. **Push state machine** (only when **Active integration** is non-empty;\n   otherwise this whole step is skipped and the file was already written in\n   step 6). The drafted frontmatter is held **in memory** — no file exists yet.\n\n   1. **Offer the push** using the fail-safe gate. Preview the fields the push\n      would resolve **through the dispatcher's own dry-run** so the single\n      keystroke maps to an understood, non-destructive result. Write the\n      drafted body to a temp file and run:\n\n      ```\n      accelerator work create \"\u003Ctitle>\" \u003Ckind> \u003Cpriority> \\\n        --push --dry-run --body-file \u003Cbody-tmp>\n      ```\n\n      It resolves the tracker from **Active integration**, contacts it to\n      resolve the fields, writes **nothing**, and creates **no** remote issue.\n      Branch on its exit and the line it prints on stdout:\n\n      - **Exit 0, jira** → `jira\\t\u003Cissue type>\\t\u003Ctype source>\\t\u003Cproject>\\t\u003Cproject source>`.\n        Render the type and project with their sources. A `\u003Cproject source>` of\n        `unresolvable` means the configured `jira.project_key` names a\n        project the tracker does not hold — surface that as a pre-create\n        failure **before** the gate (name `jira.project_key`) and do\n        **not** offer the push; save locally instead, through the step 6\n        call (no `--push`). A `default` source is a benign fallback, not a\n        failure.\n      - **Exit 0, linear** → `linear\\t(no user-resolvable type\u002Fproject fields)`\n        (the team and issue-type catalogue are fixed by `\u002Finit-linear`).\n        Offer the push.\n      - **Exit 70** → the tracker was **unreachable** (distinct from an\n        unresolvable value). Do **not** hard-block: tell the user the preview\n        could not be resolved and offer to save locally now, or retry the\n        preview. The push itself carries its own retry (below), so a transient\n        outage here must not strand the draft.\n      - **Any other non-zero exit** → the tracker is not usable for a push\n        (not available, unrecognised, or unconfigured). Relay the stderr\n        message and save locally.\n\n      Every \"save locally\" above is the step 6 `accelerator work create`\n      call with no `--push`, so under `{tracker}` it writes a draft that\n      `\u002Fsync-work-items` promotes later. Never write the file with the\n      `Write` tool, and never call `accelerator work next-number` for it.\n\n      Then, when a push is still on the table:\n\n      Use the `AskUserQuestion` tool with two options:\n\n      1. **Yes, push to [tracker] now** — create the remote issue and save\n         locally\n      2. **No, save locally only** — save as unsynced; push it later with\n         `\u002Fsync-work-items` (it offers to create unsynced local drafts on the\n         remote), which shares this `external_id` contract.\n\n      Under `{tracker}` the second option reads **No, save as draft** —\n      save it as a draft in `drafts\u002F`; `\u002Fsync-work-items` promotes it onto\n      a tracker key later.\n\n   2. **On decline** → write the file now with `external_id` omitted (unsynced)\n      via the `accelerator work create` call from step 6 (no `--push`), then go\n      to step 8. Under `{tracker}` that call writes a draft.\n\n   3. **On accept** → run the **same** `accelerator work create` call with\n      `--push` added (never a re-derived tracker — the CLI reads **Active\n      integration** itself):\n\n      ```\n      accelerator work create \"\u003Ctitle>\" \u003Ckind> \u003Cpriority> \\\n        --status draft --author \"\u003Cresolved author>\" --producer create-work-item \\\n        --push --body-file \u003Cbody-tmp> [--parent …] [--tag …]… [linkage flags…]\n      ```\n\n      This is **one** call that creates the remote issue and writes the local\n      file atomically — the retryable\u002Fterminal decision, the retry, and the\n      duplicate-create guard all live inside `work create --push`; do **not**\n      drive a retry loop yourself. On stdout it prints the written path on the\n      first line and `\u003Ckeyword>\\t\u003Cexternal_id>` on the second, where the keyword\n      is one of `write-once`, `local-save`, `loud-terminal`, `rejected`,\n      `created-blocked`, `created-unwritten` or `retirement-incomplete`. The\n      first line is empty only for a `created-unwritten` under a numeric ID\n      pattern, where no file exists. Render per the table below.\n\n      Under `{tracker}` the call first saves the item as a draft, then creates\n      the issue and promotes the draft onto its key, so the written path is\n      `\u003CKEY>-\u003Cslug>.md` on success and the draft's path otherwise. If it exits\n      `4` with `E_PUSH_PENDING` or `E_DRAFT_EXISTS` on stderr, an earlier\n      create of the same content is still pending and nothing was sent: relay\n      the named draft and the recovery the message gives, and do **not**\n      re-run the create.\n\n   **Outcome table** (`work create --push` returns the keyword; you render the\n   message). The 70-retryable \u002F 71-terminal \u002F 75-rejected contract the keywords\n   derive from is documented in `exit_codes` and cross-referenced by\n   `work create --help`:\n\n   | Second-line keyword | Exit | Action |\n   |---|---|---|\n   | `write-once` | 0 | The remote issue was created and the file written with its `external_id`. Confirm success (step 8), echoing the returned identifier. |\n   | `local-save` | 0 | The push could not be sent (the tracker is unreachable, retryable and retried once, or not available\u002Frecognised\u002Fconfigured) and nothing left the machine — the file was written **unsynced**. Tell the user it saved unsynced and can be pushed later via `\u002Fsync-work-items`; but 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. |\n   | `loud-terminal` | 71 | A terminal failure **at or after** the create — a remote issue **may already exist**. Print loud non-idempotent guidance naming the saved path: do **not** blindly re-run `\u002Fcreate-work-item`. Under a numeric ID pattern the file was saved unsynced: check the tracker, and if the issue exists reconcile via `\u002Fsync-work-items` **or** set `external_id: \u003CKEY>` by hand. Under `{tracker}` the item is a draft whose ID is the `draft-` prefix of its filename: check the tracker, then run `accelerator work promote \u003Cdraft-id> --adopt \u003CKEY>` if the issue exists, otherwise `accelerator work promote \u003Cdraft-id> --create`; never set `external_id` by hand on a draft. |\n| `rejected` | 75 | The client refused the request as invalid before sending it, so **no remote issue exists**, but re-sending the same request would be refused again. The file was saved unsynced (a draft under `{tracker}`). Relay the cause printed on stderr and tell the user the request must change (for example, the body) before it is pushed via `\u002Fsync-work-items`. |\n| `created-blocked` | 4 | The remote issue **exists**, but a local item already claims its key. The draft is kept. Relay the holder and the remedy printed on stderr; the user resolves the collision, then runs `accelerator work promote \u003Cdraft>`. |\n| `created-unwritten` | 71 | The remote issue **exists** and no local item carries it yet. The next `\u002Fsync-work-items` links it (under `{tracker}`, by promoting the draft onto it). Do **not** re-run the create. |\n| `retirement-incomplete` | 71 | The remote issue **exists**, and moving the draft onto its key could not restore every file it had written. Relay the paths and the recovery directory printed on stderr; the user restores them, then runs `\u002Fsync-work-items`. |\n| `E_PUSH_PENDING` (stderr) | 4 | An earlier create of the same content is still pending. Relay the named draft and the stage-specific recovery the message gives. |\n| `E_DRAFT_EXISTS` (stderr) | 4 | The same draft already exists. Tell the user to run `accelerator work promote \u003Cdraft>` or `\u002Fsync-work-items`. |\n\n   Under `{tracker}`, `local-save` and `rejected` leave the item as a draft,\n   and `loud-terminal` leaves the draft with a record that a create may have\n   reached the tracker.\n\n   Because the create and the local write are one atomic CLI operation, there\n   is no in-skill window where a remote issue exists but no file does — that\n   window, and its `pending_push` recovery marker, are handled inside the CLI.\n   The pre-create preview is a **live, credentialed** round-trip now, so a clean\n   preview does not guarantee the push succeeds; the authoritative outcome is\n   the keyword above.\n\n8. **Print a confirmation**:\n\n```\nWork item created: `\u003Cpath>`\n```\n\n   `\u003Cpath>` is always the first stdout line of the `accelerator work create`\n   call that wrote the file — whether step 6 (no integration) or step 7\n   (`--push`) — since its slugification is authoritative; do not re-derive it\n   or assume it matches step 2's preview path. When the item was saved unsynced\n   (decline, `local-save`, or `loud-terminal`), say so: `Work item created\n   (unsynced): … — push later with \u002Fsync-work-items`, or, when a\n   `warning: -: configure failed:` line came with a `local-save`, `Work item\n   created (unsynced): … — fix \u003Ccause> before syncing`. Under `{tracker}`,\n   report the tracker key on `write-once` (`Work item created: \u003CKEY> at\n   \u003Cpath>`), and otherwise the draft path and why it is still a draft (`Work\n   item saved as draft: \u003Cpath> — \u003Creason>; \u002Fsync-work-items promotes it`),\n   where the reason is \"push declined\", \"tracker unreachable\", or the outcome\n   table's cause; with that warning it ends `— fix \u003Ccause> before syncing`\n   instead.\n\n### In enrich-existing mode\n\n1. Do **not** call `accelerator work next-number`. The target path is the\n   resolved `existing_work_item_path` cached in Step 0.\n\n2. **At-write identity-swap check** (best-effort guard): immediately before\n   the confirmation prompt, re-read the target file's own identity from\n   disk via:\n\n   ```\n   accelerator work show \u003Cexisting_work_item_path> --field id\n   ```\n\n   (This returns the value of `id:` on unified-shape files and falls\n   back to `work_item_id:` on legacy files.)\n\n   - If the command exits non-zero (file gone or frontmatter unparseable since\n     Step 0), abort with:\n     `\"Error: \u003Cpath> is no longer present or its frontmatter is unparseable.\n     Your proposed draft is below — copy it before re-running\n     \u002Fcreate-work-item: \u003Cdraft>\"`\n   - If the on-disk identity differs from the value cached in Step 0,\n     abort with:\n     `\"Error: \u003Cpath> changed identity since Step 0 (was \u003Ccached>, now\n     \u003Ccurrent>). Your proposed draft is below — copy it before re-running\n     \u002Fcreate-work-item to refresh: \u003Cdraft>\"`\n\n3. **Single confirmation gate**: present the path and a per-section change\n   summary, then require explicit y\u002Fn approval before any write:\n\n   ```\n   I'm about to overwrite \u003Cexisting_work_item_path>.\n\n   Sections changed:\n     Added:    [...]\n     Modified: [...]\n\n   Frontmatter changed:\n     \u003Cfield>: \u003Ccached> → \u003Cnew>     # repeated per modified field\n     (status: \u003Ccached> unchanged)  # always show status explicitly\n\n   Sections preserved verbatim: \u003Ccount> (\u003Cterse list or \"none\">)\n   Frontmatter fields preserved verbatim: id, date, author\n     [+ any unmodified proposable fields]\n\n   ```\n\n   Then use the `AskUserQuestion` tool with two options:\n\n   1. **Yes, proceed** — overwrite the work item with the changes shown\n   2. **No, cancel** — make no changes\n\n4. **Confirmation interpretation** (fail-safe):\n   - Exactly `y` or `Y` (after trimming whitespace): proceed to step 5.\n   - Exactly `n` or `N`: go to step 8.\n   - Anything else (empty input, \"yes\", \"go ahead\", \"looks good but also...\",\n     paragraph of feedback): treat as `n`. Print:\n     `\"Did not recognise \u003Cresponse> as y\u002Fn — staying in review. What change\n     would you like before I overwrite?\"` and go to step 8.\n\n5. **On `y` — substitute cached immutable fields, then write**: immediately\n   before invoking the Write tool, re-read the cached immutable identity fields\n   (`id`, `date`, `author`) from conversation state and overwrite the\n   corresponding frontmatter lines in the draft text with those exact values,\n   even if they appear unchanged. Also write `last_updated:` to the current\n   `Current Date\u002FTime (UTC):` value and `last_updated_by:` to the resolved\n   author. This textual substitution defends against drift during Step 4\n   iteration.\n\n6. Write the file to `existing_work_item_path`. The path-existence guard from\n   the normal flow does not apply — overwrite is the intended behaviour.\n\n7. Print:\n\n   ```\n   Work item updated: \u003Cexisting_work_item_path>\n   ```\n\n8. **On `n` or unrecognised**: stay in Step 4 \u002F Step 5 review and iterate.\n   Do not re-run the identity-swap check until the next `y`; do not write.\n\n**Validate the frontmatter**: after the work item is written, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cwritten 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## Quality Guidelines\n\n- Never write a file without explicit user approval.\n- Never call `accelerator work next-number` before the user approves the draft.\n- The slug must be a meaningful kebab-case title, not raw input text.\n- Work item kind must come from the work item template's `kind` field (loaded at\n  the top of this skill), not a hardcoded list. Default to `story` when the\n  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 (a quoted YAML string — see contract below), `title`\n  matching the user-approved title, `date`, `author`, `producer`\n  (`create-work-item`), `status` (`draft`), `kind`, `priority` (medium\n  unless the user specified otherwise), `parent` (empty string unless a\n  parent was established), `external_id` (empty unless set), `tags` (a\n  YAML array, possibly empty), `last_updated`, `last_updated_by`, and\n  `schema_version: 1`. No field may contain unfilled placeholder text\n  like `[author]` or `NNNN`. The body H1 format is `# \u003Cfull-id>: \u003Ctitle>`\n  where `\u003Cfull-id>` is whatever the configured `work.id_pattern`\n  produces — kept in sync with the frontmatter `title:` field.\n\n- **`id` frontmatter type contract**: the own-identity field is\n  **always a quoted YAML string**, regardless of the configured\n  pattern. Files created under default `{number:04d}` write\n  `id: \"0001\"`; files created under `{project}-{number:04d}` write\n  `id: \"PROJ-0001\"`. This contract is uniform so consumers can read\n  the field as a string without coercion. See\n  `skills\u002Fconfig\u002Fconfigure\u002FSKILL.md > work` for the full contract.\n  Legacy files carry the same value under `work_item_id:`; `work show`\n  returns either key transparently so consumers do not need to know\n  which shape is on disk.\n\n**Identity Field Rules** (apply in enrich-existing mode):\n\n- **Immutable** — `id` (or `work_item_id` on legacy files), `date`,\n  `author`. Cached from the source file in Step 0; never proposed for\n  change; the model substitutes the cached values back into the draft\n  frontmatter at write time (Step 5 step 5) as a defence against drift\n  during Step 4 iteration. This is a textual substitution the model\n  performs — the eval suite verifies the written file's values match\n  the cached values, which is the strongest guarantee the grader-\n  mediated harness can provide.\n- **Preserved unless explicitly changed** — `status`. Defaults to the cached\n  value. May only change if the user makes an explicit, direct request during\n  the conversation (e.g. \"set status to in-progress\"). The model must not\n  propose a status change unsolicited; if the user makes only an oblique\n  reference (e.g. \"this is now in flight\"), the model asks a clarifying\n  question rather than infer the transition. A proposed transition is shown\n  explicitly (e.g. \"draft → in-progress\") and requires confirmation in Step 3\n  before acceptance. The `status: draft` default applies only to\n  newly-created work items, not to enrichment.\n- **Proposable in Step 3** — `title`, `kind`, `priority`, `parent`, `tags`.\n  Default to the cached values; can be replaced after explicit user agreement\n  in Step 3's augmentation review.\n\n**H1 sync** (enrich-existing mode): the body H1 is `# \u003Cid>: \u003Ctitle>`,\nusing the cached immutable `id` (the full ID produced by the configured\npattern, never a placeholder; sourced from `work_item_id` on legacy\nfiles) and the title as confirmed or replaced in Step 3.\n\n**Script avoidance** (enrich-existing mode): `accelerator work\nnext-number` is never called. The number is already cached. The path-existence guard in Step 5\ndoes not apply — overwrite is the intended behaviour once the at-write\nidentity-swap check passes.\n\n- `date` must use the work item template's `YYYY-MM-DDTHH:MM:SS+00:00` format\n  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  current git\u002Fjj user identity, then — only if both fail — ask the user\n  once before writing the file. Never write `[author]` or any placeholder.\n- `Summary` and `Requirements` must have substantive content — no\n  `[bracketed placeholder text]` in the final written file. The same\n  applies to every other body section that is populated: if a section\n  would only contain a bracketed placeholder, remove the placeholder and\n  leave the section empty (or omit optional sections entirely).\n- Acceptance criteria must be specific and testable; prefer Given\u002FWhen\u002FThen\n  format. Challenge any criterion that is not measurable before accepting it.\n- Populate `Drafting Notes` with every meaningful interpretation made while\n  filling out the work item — who stakeholders are, what a vague term means,\n  where scope boundaries sit, which technical approach is implied. Use\n  `Assumptions` for scope-changing calls the user should confirm. Use\n  `Open Questions` for genuine unknowns that block progress. These three\n  sections serve different purposes; don't collapse them.\n- Populate `References` with any external material that informed the\n  work item — research artefacts, related work items, design docs, source specs.\n  Leave it empty if nothing external was consulted; do not invent\n  references.\n- The model must contribute its own knowledge and research to the proposal —\n  not simply transcribe the user's answers. Bring domain expertise, surfaced\n  research, and reasoned suggestions to every work item.\n- Restrict `{documents locator agent}` to `{work_dir}` only. Do not search\n  research documents, plans, or the codebase — work items are about business\n  requirements, not implementation details.\n- Spawn `{web-search-researcher agent}` whenever there is uncertainty about any\n  aspect of the topic — business rules, domain concepts, competitive landscape,\n  industry standards, external technology, or otherwise. When in doubt,\n  prefer to spawn research — over-asking is cheaper than producing a\n  vague or poorly-grounded proposal.\n- If `accelerator work next-number` exits non-zero, abort and surface the\n  error message verbatim.\n\n!`accelerator config instructions create-work-item --fail-safe`\n","# Create Work Item\n\n!`accelerator config context --skill create-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\nThe **Active integration** line gates the post-draft push offer (Step 5). The\n`accelerator config work integration` command above prints an **empty line**\nwhen no integration is configured, so branch on the **string**: a non-empty value means\n*integration configured* (offer the push); an empty value means *not configured*\n(no push offer — behave exactly as today). This is the single resolution of the\nactive tracker for this invocation; the push dispatcher is told which tracker to\nuse from **this** value, so the gate and the route cannot diverge.\n\nWhen **ID pattern** is `{tracker}`, the tracker owns every item's `id`: a\npushed item takes the issue's key as its `id`, and an item no tracker has\nconfirmed is saved as a **draft** in `drafts\u002F` under a provisional `draft-`\nID, which `\u002Fsync-work-items` promotes 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 guide what information you gather\nin Step 1 and what structure you produce in Steps 3–4.\n\n!`accelerator config template work-item --fail-safe`\n\nYou are tasked with guiding the user through creating a well-formed work item —\na structured document capturing a feature, bug, task, spike, or epic for\ntracking and implementation. This is a collaborative, challenging conversation:\nthe model contributes its own knowledge and research alongside the user's input\nrather than simply transcribing what the user says. The goal is a work item that\nis well-reasoned and well-specified — one that would stand on its own without\nneeding the author present to explain it.\n\nThe work item template has three sections that look similar but capture\ndifferent things — populate each deliberately:\n\n- **Assumptions** are interpretations you made that affect what gets built.\n  Flag one only when using the wrong interpretation would lead someone to\n  build something different. Example: *\"Treating 'users' as end users\n  rather than internal staff — if wrong, scope changes.\"*\n- **Open Questions** are genuine unknowns a reader or implementer needs\n  resolved before work can proceed. Example: *\"What does 'better results'\n  mean — improved relevance, faster delivery, or both?\"*\n- **Drafting Notes** capture interpretations you made while filling out the\n  work item — business-context calls, scope decisions, or technical choices\n  that someone should review if they turn out to be wrong. Actively\n  populate this section. If you inferred who the stakeholders are, what a\n  vague term means, where the scope boundary sits, or which technical\n  approach is implied, write it down. Routine field selections (kind,\n  priority, tags) don't need an entry unless the choice reflects a\n  substantive scope or meaning interpretation a reviewer should be aware\n  of.\n\n## Step 0: Parameter Check\n\nWhen this command is invoked:\n\n1. **If an argument was provided**:\n\n   First, **try to resolve the argument as a reference to an existing\n   work item** by invoking the resolver:\n\n   ```\n   accelerator work resolve \u003Cargument>\n   ```\n\n   The resolver respects `work.id_pattern` and accepts paths, full IDs\n   (`PROJ-0042`), legacy bare numbers (`0042`), and short numbers (`42`,\n   resolved against `work.key` when set).\n\n   - **Exit 0** (single match): the resolver echoes the absolute path on\n     stdout. Continue to frontmatter validation below.\n   - **Exit 1** (input invalid — neither path, full ID, nor bare number):\n     proceed to topic-string handling below; treat the argument as a\n     topic.\n   - **Exit 2** (ambiguous match): the resolver lists every candidate\n     with a source-category tag (`legacy`, `project-prepended`,\n     `pattern-shape`, or a project code). Present the list to the user\n     and ask them to disambiguate by re-running with a full ID (e.g.\n     `PROJ-0042`) or a path.\n   - **Exit 3** (no match): print\n     `\"No work item matching \u003Cargument> — interpreting as topic string.\n     If that's wrong, abort and re-run with a different argument (or\n     \u002Flist-work-items to find a valid reference).\"` and proceed to\n     topic-string handling below.\n   - **Exit 6** (path outside the work directory): the argument names a\n     real file that lies outside the managed work directory, so it is not\n     a topic string. Stop, print the resolver's error, and offer to run\n     `\u002Flist-work-items`.\n\n   **Frontmatter validation** (only reached after a file was successfully\n   resolved). Run:\n\n   ```\n   accelerator work show \u003Cpath> --field id\n   ```\n\n   The own-identity field is `id` on unified-shape files and\n   `work_item_id` on legacy files; `work show` resolves both\n   transparently, so either key name passed here would return the\n   same value.\n\n   If it exits non-zero (frontmatter missing or unclosed), print:\n\n   ```\n   Could not parse frontmatter in \u003Cpath> — the file may be corrupted.\n   Re-open it and check that the YAML frontmatter is bracketed by two\n   `---` lines and contains all nine required fields.\n   ```\n\n   and exit without spawning agents or writing any file. (The file clearly\n   resolved, so the user intended a path — no fallback applies.)\n\n   If validation passes, read the file fully (frontmatter and body) and\n   cache the identity fields in conversation state:\n   `id` (or `work_item_id` on legacy files), `date`, `author`, `status`,\n   `title`, `kind`, `priority`, `parent`, `tags`. For any missing\n   optional field, use the template default — do not abort. Set the conversation into\n   **enrich-existing mode** with `existing_work_item_path` cached, and\n   skip directly to Step 1 in that mode — do not run the vagueness check.\n\n   **Topic-string handling**: if no resolution succeeded (discriminators\n   did not trigger, or they triggered with a fallback warning), check\n   whether the argument is too vague (no clear deliverable or subject).\n   - Vague examples: \"improve things\", \"fix the API\", \"add more features\"\n   - Clear examples: \"add full-text search to the docs index page\",\n     \"fix login timeout after password reset\"\n   - If vague, ask at least one clarifying question and wait for a more\n     specific description before proceeding to Step 1.\n   - If clear, proceed directly to Step 1.\n\n2. **If no argument was provided**, respond with:\n\n```\nI'll help you create a well-specified work item through a collaborative conversation.\n\nTo get started, describe what you want to achieve — what's the problem or goal?\nFor example: \"add full-text search to the docs index page\", or \"users can't log in after resetting their password\"\n\nI'll ask a few questions to understand the problem space, do some research, then\nwork with you to shape a thoroughly reasoned work item.\n```\n\nThen wait for the user's input. Apply the same vagueness check to their\nresponse — if still vague, ask a clarifying question before proceeding to\nStep 1.\n\n## Step 1: Gather Business Context\n\nOnce the topic is clear, ask 3–5 open questions to understand the business\ncontext before investigating. Consult the work item template sections above to\nunderstand what the work item will need — use them to guide which questions are\nworth asking. Tailor the questions to the topic, but cover:\n\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- Does the user have a solution or approach in mind? If so, surface it and\n  ask whether it's a constraint or a preference to be explored further.\n- Are there any constraints, deadlines, or dependencies worth knowing?\n- For bug topics: what is the impact, and is it a blocker?\n- Is there anything you are uncertain about, or that I should research?\n\nAsk all relevant questions at once rather than one at a time. Wait for the\nuser's answers before proceeding to Step 2.\n\n### In enrich-existing mode\n\nDo not ask the broad discovery questions above. Instead:\n\n1. Identify which body sections of the existing file are **substantive** (real\n   content beyond `[bracketed placeholder]` text) and which are **gaps** (empty,\n   placeholder-only, or missing entirely). Tag each gap with **exactly one** of\n   the literal tokens:\n   - `empty` — section is absent or contains no content\n   - `placeholder-only` — section contains only template `[...]` blocks\n   - `instructional-prose` — section contains the template's instructional\n     prose carried over verbatim (e.g. \"Describe the business value of this\n     work item here…\")\n   - `partial` — section contains one or more substantive sentences alongside\n     residual placeholders\n\n   Use the literal token; do not paraphrase. The eval grader pattern-matches\n   on these exact strings.\n\n2. Present the gap analysis briefly:\n\n   ```\n   I've read the existing work item (\u003Cresolved path>). Here's what looks\n   complete and what still needs work:\n\n   Complete: [section list, or \"none\"]\n   Gaps:\n     - \u003CSection> (\u003Ctag>)\n     - ...\n\n   I'll ask targeted questions about the gaps.\n   ```\n\n3. Ask only questions that address the identified gaps. Do not re-ask\n   questions whose answers are already substantively present in the file.\n\n4. If the existing content is rich enough that no obvious gaps remain,\n   briefly confirm this and ask what the user wants to add or improve, then\n   proceed to Step 2.\n\n## Step 2: Investigate\n\nUsing the topic and business context from Step 1, run investigation agents\nin parallel:\n\n1. **Spawn {documents locator agent}** to search `{work_dir}` only —\n   look for existing work items with similar titles, descriptions, or scope.\n   Do not search research documents, plans, or other directories — work items\n   capture business requirements, not implementation details.\n\n2. **Spawn {web-search-researcher agent}** when there is uncertainty or a need\n   for richer context about any aspect of the topic — business rules, domain\n   concepts, competitive landscape, industry standards, external technology, or\n   anything the model lacks confidence on. Skip this agent only when the topic\n   is entirely self-contained and well-understood from the user's description.\n   When in doubt, prefer to spawn research — over-asking is cheaper than\n   producing a vague or poorly-grounded proposal.\n\nRun both agents in parallel where both are warranted.\n\nOnce agents complete, synthesise findings — what the model knows from training,\nwhat research turned up, what prior work items exist — as the foundation for Step 3.\n\n**If a similar existing work item is found**: Check its status.\n- If the status is `done`, `abandoned`, or `superseded` — mention the work item\n  briefly and note it is already closed, then continue creating the new one.\n- Otherwise — surface the work item and offer the user numbered options, for\n  example:\n  1. Proceed with a new work item (if the scope genuinely differs)\n  2. Exit and update the existing work item instead (use `\u002Fupdate-work-item` once\n     available; for now, update it manually)\n  3. Continue creating a new work item linked to the existing one as a parent\n\n  Adapt the options to what makes sense given the work item's kind and status.\n  Do not silently continue or modify the existing work item inline. Wait for\n  the user's choice before proceeding.\n\n**In enrich-existing mode**: exclude the resolved input file from the\nsimilarity scan. The {documents locator agent} search of `{work_dir}` will\nfind the file being enriched; do not surface it as a \"potential duplicate\" of\nitself. Other near-duplicates discovered are handled per the unchanged rules\nabove.\n\n## Step 3: Propose and Refine\n\nUsing the business context and investigation synthesis, the model leads with\na structured proposal. Do not ask the user to generate requirements or\nacceptance criteria from scratch — propose them and invite challenge.\n\n1. **Recommend a work item kind** with a brief rationale. Valid kinds come from\n   the work item template's `kind` field (loaded at the top of this skill) — do\n   not hardcode the list. Default to `story` when the kind is genuinely\n   ambiguous.\n2. **Draft requirements** drawn from the business context and research.\n3. **Draft acceptance criteria** — specific and testable; prefer Given\u002FWhen\u002FThen\n   format for story\u002Ftask. Draw on domain knowledge and research to make these\n   thorough, not just what the user explicitly mentioned.\n4. **Surface interpretations and gaps** using the right section:\n   - Put scope-changing interpretations you made in `Assumptions` and invite\n     the user to confirm or correct them.\n   - Put genuine unknowns that block progress in `Open Questions`.\n   - Put every meaningful drafting-time interpretation (who stakeholders are,\n     what vague terms mean, scope boundaries, implied technical approach) in\n     `Drafting Notes` so a reviewer can challenge them.\n\nPresent as a structured proposal:\n\n```\nBased on what you've told me and my research, here's what I think this work item needs:\n\n**Suggested kind**: [kind]\n**Rationale**: [one sentence]\n\n**Requirements I'd suggest**:\n- [requirement]\n\n**Out of scope** (explicitly not captured here):\n- [item]\n\n**Acceptance criteria I'd suggest**:\n- Given\u002FWhen\u002FThen...\n\n**Assumptions I've made** (scope-changing calls — confirm or correct):\n- [assumption]\n\n**Drafting Notes** (interpretations a reviewer should see):\n- [interpretation — e.g. who stakeholders are, what a vague term means,\n  scope boundary, implied technical approach]\n\n**Open questions** (unknowns to resolve before work begins):\n- [anything the user should clarify before drafting]\n```\n\nWait for the user to validate, push back, or refine. Challenge vague or\nuntestable responses — if an acceptance criterion is not measurable (e.g.,\n\"it works correctly\"), first ask a clarifying question to understand the\nintent (\"what would a passing test actually look like here?\"). Only after\nunderstanding the intent should you help reformulate it into something\ntestable. Do not accept vague criteria into the draft. Iterate until the\nproposal is well-specified and agreed.\n\n### In enrich-existing mode\n\nDo not lead with a from-scratch proposal. Instead present a section-by-section\nreview and augmentation:\n\n```\nHere's how the existing work item reads against my research, with proposed\nadditions for the gaps:\n\n**[Section name]** — [complete | needs improvement: \u003Creason> | missing]\n[existing content excerpt or note that it is missing]\n[proposed addition or replacement, when applicable]\n\n[repeat per section]\n\n**Title**: [keep \u002F propose new title with rationale]\n**Kind**: [keep existing \u003Ckind> \u002F propose change to \u003Ckind> with rationale]\n**Priority**: [keep \u002F propose change with rationale]\n**Parent**: [keep \u002F propose change]\n**Tags**: [keep \u002F propose additions]\n**Status**: [keep \u003Ccached> — say so if you'd like to transition it]\n```\n\nApply the canonical Identity Field Rules (see Quality Guidelines): propose\nonly the fields marked Proposable; never propose changes to immutable fields;\nsurface a status transition only if the user makes a direct explicit request\nfor one (the listing offers the affordance but never proposes a change\nunsolicited).\n\nThe refinement loop in this step (challenging untestable criteria, vague\nrequirements, etc.) applies equally to existing and proposed content.\n\n## Step 4: Draft Work Item\n\n1. **Draft a complete work item** from the agreed proposal using the template\n   structure loaded at the top of this skill. Use `NNNN` as the placeholder\n   work item number throughout. Do NOT call `accelerator work next-number` at this step.\n\n2. **Kind-specific content placement**:\n   - story\u002Fepic: open the `Summary` section with a user story statement —\n     \"As a [role], I want [goal], so that [benefit].\" — before the\n     descriptive sentences\n   - bug reproduction steps, expected\u002Factual behaviour → `Requirements` section\n   - spike research questions, time-box, exit criteria → `Requirements` section\n   - epic initial stories → `Requirements` section as a list\n   - Do not rename or add sections beyond those defined in the work item template\n\n3. **Populate the `References` section** with any external material that\n   informed the work item — research artefacts surfaced by the web researcher,\n   related work items found in Step 2, design docs, or source specs. Leave it\n   empty if nothing external was consulted; do not invent references.\n\n4. **Populate the `Drafting Notes` section** with the interpretations\n   carried over from the agreed proposal. If there were none (the user\n   confirmed every call), the section may be omitted or left as an empty\n   list — but do not leave placeholder bracketed text in it.\n\n5. **Present the full draft** to the user:\n\n```\nHere's my draft work item. Please review and let me know if you'd like any\nchanges before I write it to disk:\n\n[draft content]\n```\n\n6. **Continue to challenge** during the review loop — flag untestable criteria,\n   vague requirements, or gaps surfaced by research that remain unaddressed.\n   Iterate until the user explicitly approves. **`accelerator work\n   next-number` is never called during this loop.**\n\n### In enrich-existing mode\n\n1. Produce a complete updated draft incorporating the existing content plus the\n   additions approved in Step 3.\n2. Apply the canonical Identity Field Rules (see Quality Guidelines) when\n   filling frontmatter — the rules are the single source of truth for which\n   fields are immutable, preserved, or proposable.\n3. Apply the H1 sync rule (see Quality Guidelines).\n4. Apply the Script avoidance rule (see Quality Guidelines).\n5. Present the full updated draft, framed as an update preview:\n\n   ```\n   Here's the updated work item. The Step 5 confirmation will name the file\n   path and ask for explicit approval before any write:\n\n   [draft content]\n   ```\n\n6. Continue to challenge during review — apply the same rules as the\n   normal-path Step 4. Iterate the draft until the user is happy with it. Do\n   **not** treat a \"looks good\" mid-iteration as approval to write — that\n   approval is gated by Step 5's single confirmation.\n\n## Step 5: Write Work Item\n\n**A re-key in progress.** `accelerator work next-number` and\n`accelerator work create` (with or without `--push`) refuse before reading or\nwriting anything while an `accelerator work rekey` run is unfinished. Before\nany other branch on a non-zero exit from one of them, check its stderr for\nthese codes; in every 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\nUnder `{tracker}`, skip steps 1–3: there is no projected ID. The tracker\nassigns the key on a push, and `accelerator work create` mints the draft ID\nitself, so its first stdout line is the only path to report.\n\n1. **Call `accelerator work next-number`** to get the next full ID under the\n   configured pattern:\n\n```\naccelerator work next-number\n```\n\nThe output is the full ID (`0001` under default `{number:04d}`,\n`PROJ-0001` under `{key}-{number:04d}` with\n`work.key: \"PROJ\"`). The allocator reads the pattern and local ID prefix\nfrom configuration; pass `--project CODE` if the user explicitly wants a\nnon-default prefix for this one call.\n\nIf the command exits non-zero (e.g., overflow, missing project value),\nabort immediately and surface the error message verbatim — do not\nproceed.\n\n2. **Resolve the target path**: `{work_dir}\u002F\u003Cfull-id>-kebab-slug.md`\n   where `\u003Cfull-id>` is the allocator's output and the slug is a\n   meaningful kebab-case summary of the title (not raw input text).\n\n3. **Check that the target path does not already exist**. If it does, abort:\n\n```\nPath {path} already exists — another session may have written a work item\nconcurrently. Please re-run \u002Fcreate-work-item.\n```\n\n4. **Create the work items directory** if it does not exist.\n\n5. **Resolve `author`**: configuration if present, then the current git\u002Fjj\n   user identity, then — only if both fail — ask the user once. Never pass\n   a placeholder. This value feeds both branches below.\n\n6. **No integration configured — write via `accelerator work create`.**\n   Skip this step (go to step 7) when an integration *is* configured; the\n   push state machine in step 8 governs that case's single write instead.\n\n   1. Write the drafted body (H1 through References, everything approved\n      across Steps 1–4) to a scratch file, with the `NNNN` placeholder\n      still literally present everywhere it appears (the H1 line and\n      anywhere else) — do **not** substitute it yourself. `work create`\n      performs the one real `NNNN` → allocated-ID substitution as part of\n      the same atomic write that decides the ID, so the approved content\n      can never end up with an id\u002FH1 mismatch.\n   2. Call the dispatcher directly:\n\n   ```\n   accelerator work create \"\u003Ctitle>\" \u003Ckind> \u003Cpriority> \\\n     --status draft \\\n     --author \"\u003Cresolved author>\" \\\n     --producer create-work-item \\\n     --body-file \u003Cscratch-file> \\\n     [--parent \"work-item:NNNN\"] \\\n     [--tag \u003Cvalue>]... [--block \"work-item:NNNN\"]... \\\n     [--blocked-by \"work-item:NNNN\"]... \\\n     [--derived-from \"plan:NNNN\"]... [--relates-to \u003Cref>]... \\\n     [--source \"issue-research:NNNN\"] [--project \u003Ccode>]\n   ```\n\n      Include each bracketed flag only when that field has a value —\n      `work create` itself omits the corresponding frontmatter key when\n      the flag is absent, matching the template's own omit-when-empty\n      convention, so no separate omission logic is needed here. `--tag`\u002F\n      `--block`\u002F`--blocked-by`\u002F`--derived-from`\u002F`--relates-to` are each\n      repeatable for multiple values. `external_id` has no flag — `work\n      create` never writes it (nothing to sync yet); this matches today's\n      behaviour of omitting it from a fresh draft.\n   3. If the command exits non-zero, surface its stderr message verbatim\n      and abort — do not retry and do not attempt a manual `Write`.\n      Otherwise its stdout is the path of the written file. Skip to\n      step 8.\n\n7. **Push state machine** (only when **Active integration** is non-empty;\n   otherwise this whole step is skipped and the file was already written in\n   step 6). The drafted frontmatter is held **in memory** — no file exists yet.\n\n   1. **Offer the push** using the fail-safe gate. Preview the fields the push\n      would resolve **through the dispatcher's own dry-run** so the single\n      keystroke maps to an understood, non-destructive result. Write the\n      drafted body to a temp file and run:\n\n      ```\n      accelerator work create \"\u003Ctitle>\" \u003Ckind> \u003Cpriority> \\\n        --push --dry-run --body-file \u003Cbody-tmp>\n      ```\n\n      It resolves the tracker from **Active integration**, contacts it to\n      resolve the fields, writes **nothing**, and creates **no** remote issue.\n      Branch on its exit and the line it prints on stdout:\n\n      - **Exit 0, jira** → `jira\\t\u003Cissue type>\\t\u003Ctype source>\\t\u003Cproject>\\t\u003Cproject source>`.\n        Render the type and project with their sources. A `\u003Cproject source>` of\n        `unresolvable` means the configured `jira.project_key` names a\n        project the tracker does not hold — surface that as a pre-create\n        failure **before** the gate (name `jira.project_key`) and do\n        **not** offer the push; save locally instead, through the step 6\n        call (no `--push`). A `default` source is a benign fallback, not a\n        failure.\n      - **Exit 0, linear** → `linear\\t(no user-resolvable type\u002Fproject fields)`\n        (the team and issue-type catalogue are fixed by `\u002Finit-linear`).\n        Offer the push.\n      - **Exit 70** → the tracker was **unreachable** (distinct from an\n        unresolvable value). Do **not** hard-block: tell the user the preview\n        could not be resolved and offer to save locally now, or retry the\n        preview. The push itself carries its own retry (below), so a transient\n        outage here must not strand the draft.\n      - **Any other non-zero exit** → the tracker is not usable for a push\n        (not available, unrecognised, or unconfigured). Relay the stderr\n        message and save locally.\n\n      Every \"save locally\" above is the step 6 `accelerator work create`\n      call with no `--push`, so under `{tracker}` it writes a draft that\n      `\u002Fsync-work-items` promotes later. Never write the file with the\n      `Write` tool, and never call `accelerator work next-number` for it.\n\n      Then, when a push is still on the table:\n\n      Use the `AskUserQuestion` tool with two options:\n\n      1. **Yes, push to [tracker] now** — create the remote issue and save\n         locally\n      2. **No, save locally only** — save as unsynced; push it later with\n         `\u002Fsync-work-items` (it offers to create unsynced local drafts on the\n         remote), which shares this `external_id` contract.\n\n      Under `{tracker}` the second option reads **No, save as draft** —\n      save it as a draft in `drafts\u002F`; `\u002Fsync-work-items` promotes it onto\n      a tracker key later.\n\n   2. **On decline** → write the file now with `external_id` omitted (unsynced)\n      via the `accelerator work create` call from step 6 (no `--push`), then go\n      to step 8. Under `{tracker}` that call writes a draft.\n\n   3. **On accept** → run the **same** `accelerator work create` call with\n      `--push` added (never a re-derived tracker — the CLI reads **Active\n      integration** itself):\n\n      ```\n      accelerator work create \"\u003Ctitle>\" \u003Ckind> \u003Cpriority> \\\n        --status draft --author \"\u003Cresolved author>\" --producer create-work-item \\\n        --push --body-file \u003Cbody-tmp> [--parent …] [--tag …]… [linkage flags…]\n      ```\n\n      This is **one** call that creates the remote issue and writes the local\n      file atomically — the retryable\u002Fterminal decision, the retry, and the\n      duplicate-create guard all live inside `work create --push`; do **not**\n      drive a retry loop yourself. On stdout it prints the written path on the\n      first line and `\u003Ckeyword>\\t\u003Cexternal_id>` on the second, where the keyword\n      is one of `write-once`, `local-save`, `loud-terminal`, `rejected`,\n      `created-blocked`, `created-unwritten` or `retirement-incomplete`. The\n      first line is empty only for a `created-unwritten` under a numeric ID\n      pattern, where no file exists. Render per the table below.\n\n      Under `{tracker}` the call first saves the item as a draft, then creates\n      the issue and promotes the draft onto its key, so the written path is\n      `\u003CKEY>-\u003Cslug>.md` on success and the draft's path otherwise. If it exits\n      `4` with `E_PUSH_PENDING` or `E_DRAFT_EXISTS` on stderr, an earlier\n      create of the same content is still pending and nothing was sent: relay\n      the named draft and the recovery the message gives, and do **not**\n      re-run the create.\n\n   **Outcome table** (`work create --push` returns the keyword; you render the\n   message). The 70-retryable \u002F 71-terminal \u002F 75-rejected contract the keywords\n   derive from is documented in `exit_codes` and cross-referenced by\n   `work create --help`:\n\n   | Second-line keyword | Exit | Action |\n   |---|---|---|\n   | `write-once` | 0 | The remote issue was created and the file written with its `external_id`. Confirm success (step 8), echoing the returned identifier. |\n   | `local-save` | 0 | The push could not be sent (the tracker is unreachable, retryable and retried once, or not available\u002Frecognised\u002Fconfigured) and nothing left the machine — the file was written **unsynced**. Tell the user it saved unsynced and can be pushed later via `\u002Fsync-work-items`; but 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. |\n   | `loud-terminal` | 71 | A terminal failure **at or after** the create — a remote issue **may already exist**. Print loud non-idempotent guidance naming the saved path: do **not** blindly re-run `\u002Fcreate-work-item`. Under a numeric ID pattern the file was saved unsynced: check the tracker, and if the issue exists reconcile via `\u002Fsync-work-items` **or** set `external_id: \u003CKEY>` by hand. Under `{tracker}` the item is a draft whose ID is the `draft-` prefix of its filename: check the tracker, then run `accelerator work promote \u003Cdraft-id> --adopt \u003CKEY>` if the issue exists, otherwise `accelerator work promote \u003Cdraft-id> --create`; never set `external_id` by hand on a draft. |\n| `rejected` | 75 | The client refused the request as invalid before sending it, so **no remote issue exists**, but re-sending the same request would be refused again. The file was saved unsynced (a draft under `{tracker}`). Relay the cause printed on stderr and tell the user the request must change (for example, the body) before it is pushed via `\u002Fsync-work-items`. |\n| `created-blocked` | 4 | The remote issue **exists**, but a local item already claims its key. The draft is kept. Relay the holder and the remedy printed on stderr; the user resolves the collision, then runs `accelerator work promote \u003Cdraft>`. |\n| `created-unwritten` | 71 | The remote issue **exists** and no local item carries it yet. The next `\u002Fsync-work-items` links it (under `{tracker}`, by promoting the draft onto it). Do **not** re-run the create. |\n| `retirement-incomplete` | 71 | The remote issue **exists**, and moving the draft onto its key could not restore every file it had written. Relay the paths and the recovery directory printed on stderr; the user restores them, then runs `\u002Fsync-work-items`. |\n| `E_PUSH_PENDING` (stderr) | 4 | An earlier create of the same content is still pending. Relay the named draft and the stage-specific recovery the message gives. |\n| `E_DRAFT_EXISTS` (stderr) | 4 | The same draft already exists. Tell the user to run `accelerator work promote \u003Cdraft>` or `\u002Fsync-work-items`. |\n\n   Under `{tracker}`, `local-save` and `rejected` leave the item as a draft,\n   and `loud-terminal` leaves the draft with a record that a create may have\n   reached the tracker.\n\n   Because the create and the local write are one atomic CLI operation, there\n   is no in-skill window where a remote issue exists but no file does — that\n   window, and its `pending_push` recovery marker, are handled inside the CLI.\n   The pre-create preview is a **live, credentialed** round-trip now, so a clean\n   preview does not guarantee the push succeeds; the authoritative outcome is\n   the keyword above.\n\n8. **Print a confirmation**:\n\n```\nWork item created: `\u003Cpath>`\n```\n\n   `\u003Cpath>` is always the first stdout line of the `accelerator work create`\n   call that wrote the file — whether step 6 (no integration) or step 7\n   (`--push`) — since its slugification is authoritative; do not re-derive it\n   or assume it matches step 2's preview path. When the item was saved unsynced\n   (decline, `local-save`, or `loud-terminal`), say so: `Work item created\n   (unsynced): … — push later with \u002Fsync-work-items`, or, when a\n   `warning: -: configure failed:` line came with a `local-save`, `Work item\n   created (unsynced): … — fix \u003Ccause> before syncing`. Under `{tracker}`,\n   report the tracker key on `write-once` (`Work item created: \u003CKEY> at\n   \u003Cpath>`), and otherwise the draft path and why it is still a draft (`Work\n   item saved as draft: \u003Cpath> — \u003Creason>; \u002Fsync-work-items promotes it`),\n   where the reason is \"push declined\", \"tracker unreachable\", or the outcome\n   table's cause; with that warning it ends `— fix \u003Ccause> before syncing`\n   instead.\n\n### In enrich-existing mode\n\n1. Do **not** call `accelerator work next-number`. The target path is the\n   resolved `existing_work_item_path` cached in Step 0.\n\n2. **At-write identity-swap check** (best-effort guard): immediately before\n   the confirmation prompt, re-read the target file's own identity from\n   disk via:\n\n   ```\n   accelerator work show \u003Cexisting_work_item_path> --field id\n   ```\n\n   (This returns the value of `id:` on unified-shape files and falls\n   back to `work_item_id:` on legacy files.)\n\n   - If the command exits non-zero (file gone or frontmatter unparseable since\n     Step 0), abort with:\n     `\"Error: \u003Cpath> is no longer present or its frontmatter is unparseable.\n     Your proposed draft is below — copy it before re-running\n     \u002Fcreate-work-item: \u003Cdraft>\"`\n   - If the on-disk identity differs from the value cached in Step 0,\n     abort with:\n     `\"Error: \u003Cpath> changed identity since Step 0 (was \u003Ccached>, now\n     \u003Ccurrent>). Your proposed draft is below — copy it before re-running\n     \u002Fcreate-work-item to refresh: \u003Cdraft>\"`\n\n3. **Single confirmation gate**: present the path and a per-section change\n   summary, then require explicit y\u002Fn approval before any write:\n\n   ```\n   I'm about to overwrite \u003Cexisting_work_item_path>.\n\n   Sections changed:\n     Added:    [...]\n     Modified: [...]\n\n   Frontmatter changed:\n     \u003Cfield>: \u003Ccached> → \u003Cnew>     # repeated per modified field\n     (status: \u003Ccached> unchanged)  # always show status explicitly\n\n   Sections preserved verbatim: \u003Ccount> (\u003Cterse list or \"none\">)\n   Frontmatter fields preserved verbatim: id, date, author\n     [+ any unmodified proposable fields]\n\n   ```\n\n   Then use the `AskUserQuestion` tool with two options:\n\n   1. **Yes, proceed** — overwrite the work item with the changes shown\n   2. **No, cancel** — make no changes\n\n4. **Confirmation interpretation** (fail-safe):\n   - Exactly `y` or `Y` (after trimming whitespace): proceed to step 5.\n   - Exactly `n` or `N`: go to step 8.\n   - Anything else (empty input, \"yes\", \"go ahead\", \"looks good but also...\",\n     paragraph of feedback): treat as `n`. Print:\n     `\"Did not recognise \u003Cresponse> as y\u002Fn — staying in review. What change\n     would you like before I overwrite?\"` and go to step 8.\n\n5. **On `y` — substitute cached immutable fields, then write**: immediately\n   before invoking the Write tool, re-read the cached immutable identity fields\n   (`id`, `date`, `author`) from conversation state and overwrite the\n   corresponding frontmatter lines in the draft text with those exact values,\n   even if they appear unchanged. Also write `last_updated:` to the current\n   `Current Date\u002FTime (UTC):` value and `last_updated_by:` to the resolved\n   author. This textual substitution defends against drift during Step 4\n   iteration.\n\n6. Write the file to `existing_work_item_path`. The path-existence guard from\n   the normal flow does not apply — overwrite is the intended behaviour.\n\n7. Print:\n\n   ```\n   Work item updated: \u003Cexisting_work_item_path>\n   ```\n\n8. **On `n` or unrecognised**: stay in Step 4 \u002F Step 5 review and iterate.\n   Do not re-run the identity-swap check until the next `y`; do not write.\n\n**Validate the frontmatter**: after the work item is written, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cwritten 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## Quality Guidelines\n\n- Never write a file without explicit user approval.\n- Never call `accelerator work next-number` before the user approves the draft.\n- The slug must be a meaningful kebab-case title, not raw input text.\n- Work item kind must come from the work item template's `kind` field (loaded at\n  the top of this skill), not a hardcoded list. Default to `story` when the\n  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 (a quoted YAML string — see contract below), `title`\n  matching the user-approved title, `date`, `author`, `producer`\n  (`create-work-item`), `status` (`draft`), `kind`, `priority` (medium\n  unless the user specified otherwise), `parent` (empty string unless a\n  parent was established), `external_id` (empty unless set), `tags` (a\n  YAML array, possibly empty), `last_updated`, `last_updated_by`, and\n  `schema_version: 1`. No field may contain unfilled placeholder text\n  like `[author]` or `NNNN`. The body H1 format is `# \u003Cfull-id>: \u003Ctitle>`\n  where `\u003Cfull-id>` is whatever the configured `work.id_pattern`\n  produces — kept in sync with the frontmatter `title:` field.\n\n- **`id` frontmatter type contract**: the own-identity field is\n  **always a quoted YAML string**, regardless of the configured\n  pattern. Files created under default `{number:04d}` write\n  `id: \"0001\"`; files created under `{project}-{number:04d}` write\n  `id: \"PROJ-0001\"`. This contract is uniform so consumers can read\n  the field as a string without coercion. See\n  `skills\u002Fconfig\u002Fconfigure\u002FSKILL.md > work` for the full contract.\n  Legacy files carry the same value under `work_item_id:`; `work show`\n  returns either key transparently so consumers do not need to know\n  which shape is on disk.\n\n**Identity Field Rules** (apply in enrich-existing mode):\n\n- **Immutable** — `id` (or `work_item_id` on legacy files), `date`,\n  `author`. Cached from the source file in Step 0; never proposed for\n  change; the model substitutes the cached values back into the draft\n  frontmatter at write time (Step 5 step 5) as a defence against drift\n  during Step 4 iteration. This is a textual substitution the model\n  performs — the eval suite verifies the written file's values match\n  the cached values, which is the strongest guarantee the grader-\n  mediated harness can provide.\n- **Preserved unless explicitly changed** — `status`. Defaults to the cached\n  value. May only change if the user makes an explicit, direct request during\n  the conversation (e.g. \"set status to in-progress\"). The model must not\n  propose a status change unsolicited; if the user makes only an oblique\n  reference (e.g. \"this is now in flight\"), the model asks a clarifying\n  question rather than infer the transition. A proposed transition is shown\n  explicitly (e.g. \"draft → in-progress\") and requires confirmation in Step 3\n  before acceptance. The `status: draft` default applies only to\n  newly-created work items, not to enrichment.\n- **Proposable in Step 3** — `title`, `kind`, `priority`, `parent`, `tags`.\n  Default to the cached values; can be replaced after explicit user agreement\n  in Step 3's augmentation review.\n\n**H1 sync** (enrich-existing mode): the body H1 is `# \u003Cid>: \u003Ctitle>`,\nusing the cached immutable `id` (the full ID produced by the configured\npattern, never a placeholder; sourced from `work_item_id` on legacy\nfiles) and the title as confirmed or replaced in Step 3.\n\n**Script avoidance** (enrich-existing mode): `accelerator work\nnext-number` is never called. The number is already cached. The path-existence guard in Step 5\ndoes not apply — overwrite is the intended behaviour once the at-write\nidentity-swap check passes.\n\n- `date` must use the work item template's `YYYY-MM-DDTHH:MM:SS+00:00` format\n  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  current git\u002Fjj user identity, then — only if both fail — ask the user\n  once before writing the file. Never write `[author]` or any placeholder.\n- `Summary` and `Requirements` must have substantive content — no\n  `[bracketed placeholder text]` in the final written file. The same\n  applies to every other body section that is populated: if a section\n  would only contain a bracketed placeholder, remove the placeholder and\n  leave the section empty (or omit optional sections entirely).\n- Acceptance criteria must be specific and testable; prefer Given\u002FWhen\u002FThen\n  format. Challenge any criterion that is not measurable before accepting it.\n- Populate `Drafting Notes` with every meaningful interpretation made while\n  filling out the work item — who stakeholders are, what a vague term means,\n  where scope boundaries sit, which technical approach is implied. Use\n  `Assumptions` for scope-changing calls the user should confirm. Use\n  `Open Questions` for genuine unknowns that block progress. These three\n  sections serve different purposes; don't collapse them.\n- Populate `References` with any external material that informed the\n  work item — research artefacts, related work items, design docs, source specs.\n  Leave it empty if nothing external was consulted; do not invent\n  references.\n- The model must contribute its own knowledge and research to the proposal —\n  not simply transcribe the user's answers. Bring domain expertise, surfaced\n  research, and reasoned suggestions to every work item.\n- Restrict `{documents locator agent}` to `{work_dir}` only. Do not search\n  research documents, plans, or the codebase — work items are about business\n  requirements, not implementation details.\n- Spawn `{web-search-researcher agent}` whenever there is uncertainty about any\n  aspect of the topic — business rules, domain concepts, competitive landscape,\n  industry standards, external technology, or otherwise. When in doubt,\n  prefer to spawn research — over-asking is cheaper than producing a\n  vague or poorly-grounded proposal.\n- If `accelerator work next-number` exits non-zero, abort and surface the\n  error message verbatim.\n\n!`accelerator config instructions create-work-item --fail-safe`\n",{"name":5,"description":7,"allowed-tools":46,"argument-hint":51},[47,48,49,50],"Bash(accelerator config *)","Bash(accelerator work *)","Bash(accelerator corpus metadata derive)","Bash(accelerator corpus frontmatter validate *)","[topic or existing work item path\u002Fnumber]","main","9a3f77a1c7a3b3d1db560d7848c8cb49ca6f19f2","skills\u002Fwork\u002Fcreate-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":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add atomicinnovation\u002Faccelerator --skill create-work-item",{"tool":66,"command":67},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill create-work-item",{"tool":69,"command":70},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill create-work-item","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002FSKILL.md",true,[74,80,84,88,92,96,100,104,108,112],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"evals\u002Fbenchmark.json","REFERENCE","参考文档",87937,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Fbenchmark.json",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"evals\u002Fbenchmark.md",5024,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Fbenchmark.md",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"evals\u002Fevals.json",62080,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Fevals.json",{"path":89,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":90,"sourceHtmlUrl":91},"evals\u002Ffiles\u002F0042-existing-instructional.md",1490,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Ffiles\u002F0042-existing-instructional.md",{"path":93,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":94,"sourceHtmlUrl":95},"evals\u002Ffiles\u002F0042-existing-mixed.md",1524,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Ffiles\u002F0042-existing-mixed.md",{"path":97,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":98,"sourceHtmlUrl":99},"evals\u002Ffiles\u002F0042-existing-rich.md",3625,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Ffiles\u002F0042-existing-rich.md",{"path":101,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":102,"sourceHtmlUrl":103},"evals\u002Ffiles\u002F0042-existing-sparse.md",1449,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Ffiles\u002F0042-existing-sparse.md",{"path":105,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":106,"sourceHtmlUrl":107},"evals\u002Ffiles\u002F0042-other-slug.md",866,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Ffiles\u002F0042-other-slug.md",{"path":109,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":110,"sourceHtmlUrl":111},"evals\u002Ffiles\u002F0099-broken-frontmatter.md",498,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Ffiles\u002F0099-broken-frontmatter.md",{"path":113,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":114,"sourceHtmlUrl":115},"evals\u002Ffiles\u002F0099-mismatched-id.md",1080,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fcreate-work-item\u002Fevals\u002Ffiles\u002F0099-mismatched-id.md",[117,151,169,189,207,232],{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":133,"publishedAt":41},"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",[123,128],{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[134,135,136,137,138,139,140,141,142,143,24,28,144,36,145,146,147,148,149,150],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","URL","code","architecture","reviewer","review","notes","change",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":41},"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,158,159,19,160,161,35,36,150,39,162,40,163,164,26,25,165,166,167,168],"update","update work item","enforcement","manage","edit","status","transition","tags","changes","fields","op",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":41},"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,176,177,178,37,179,180,36,181,150,182,183,184,185,186,20,187,39,188,26,24],"sync","sync work items","promote","local","only","preview","active","tracker","max","jira","remote","adopt","reconcile",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":41},"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",[],[196,21,197,176,177,198,199,200,201,202,203,204,205,206],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":216,"publishedAt":41},"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",[213],{"categoryNo":214,"categoryName":215,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000008","测试与质量",[217,218,21,219,19,220,221,222,223,224,225,36,226,227,39,40,228,229,230,28,231,26],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","user","gaps",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":238,"publishedAt":41},"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",[],[148,21,239,19,240,241,35,36,242,243,39,40,228,230,38,24,244,245,26,27],"review work item","review work","escalation","file","quality","iterate","evaluate"]