[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DY04WBTMFV96JMBP5ZXVFX":3,"skill-same:01M6DY04WBTMFV96JMBP5ZXVFX":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6DY04WBTMFV96JMBP5ZXVFX","update-work-item",null,"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.","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\u002Fupdate-work-item\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"work item","update","work","update work item","manage","fields","transition","Existing","changes","frontmatter","op","tags","change","enforcement","use","edit","Bash","status","config","validate","2026-11-10 10:12:30",false,"---\nname: update-work-item\ndescription: Update fields (status, priority, tags, parent, etc.) of an\n  existing work item. Use to transition status, change priority, manage tags,\n  or edit any frontmatter field. No transition enforcement — arbitrary\n  changes are allowed.\nargument-hint: \"[work-item-ref] [field-op...]\"\nallowed-tools:\n  - Bash(accelerator config *)\n  - Bash(accelerator work *)\n  - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Update Work Item\n\n!`accelerator config context --skill update-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\n## Work Item Template\n\nThe following template defines the work item schema and field defaults.\nHint values are extracted at runtime via `work template-hints`.\n\n!`accelerator config template work-item --fail-safe`\n\nYou are tasked with updating frontmatter fields on an existing work item.\nThis skill supports status transitions, priority changes, tag management,\nparent assignment, title changes, and any other frontmatter field edit.\nNo status transition logic is enforced — the user decides what's valid.\nA future feature may add user-configurable transition graphs; this skill\npredates that feature.\n\n## Step 1: Identify Target Work Item\n\nParse the first argument and resolve via the configured pattern's\nresolver:\n\n```\naccelerator work resolve \u003Cargument>\n```\n\nThe resolver respects `work.id_pattern` and accepts paths, full IDs\n(`PROJ-0042`), and bare numbers (legacy or pattern-shape).\n\n- **Exit 0**: stdout is the absolute path; use it.\n- **Exit 1**: input was unrecognised. Print\n  `\"Unrecognised input '\u003Cargument>' — pass a path, a full ID, or a\n  bare number.\"` and exit.\n- **Exit 2**: ambiguous match. The resolver lists every candidate with\n  a source-category tag. Show the list and ask the user to\n  disambiguate by re-running with a full ID or path.\n- **Exit 3**: no match. Print `\"No work item matching \u003Cargument>.\"` and\n  exit.\n- **Exit 6**: the argument names a real file outside the managed work\n  directory. Print the resolver's error, offer to run\n  `\u002Flist-work-items`, and exit.\n- **No argument**: ask the user which work item to update. Accept the\n  response and run the resolver against it.\n\n## Step 2: Read Current Frontmatter\n\nRead the target file. Extract frontmatter between `---` delimiters.\n\n- If the first line is not `---`: print `\"Error: \u003Cfilename> has no YAML\n  frontmatter. Add a '---' line as the first line of the file, then\n  re-run.\"` and exit. Use the resolved filename, not a glob pattern.\n- If `---` opens but never closes: print `\"Error: \u003Cfilename> has\n  unclosed YAML frontmatter. Add a '---' line after the last\n  frontmatter key, then re-run.\"` and exit.\n\nParse field\u002Fvalue pairs from the frontmatter. Preserve the original key\norder for diff rendering in Step 4.\n\n## Step 3: Interpret Operation\n\nParse the remaining arguments (after the work item reference) as one or\nmore field operations. If no operation arguments were provided, show the\ncurrent frontmatter and ask which field(s) to change.\n\nEach recognised operation is recorded as a pending `work update` flag\n(`--set`, `--add-tag`, `--remove-tag`, `--append`, or `--remove`) rather\nthan applied immediately — Step 4 previews the combined effect, and\nStep 5 issues the single `work update` call that actually writes.\n\nArguments are parsed left-to-right using these rules:\n\n### 3.1 Tag operations\n`add tag \u003Cvalue>` \u002F `remove tag \u003Cvalue>` — record a pending\n`--add-tag \u003Cvalue>` \u002F `--remove-tag \u003Cvalue>` flag. Preview the effect\nagainst the current `tags` list already read in Step 2 (add: append if\nabsent; remove: drop if present). The \"No-op detection\" rule below\napplies the same way as for any other field.\n\n### 3.2 List-field operations\n`add \u003Cfield> \u003Cvalue>` \u002F `remove \u003Cfield> \u003Cvalue>` where `\u003Cfield>` is one\nof `blocks`, `blocked_by`, `derived_from`, `relates_to` — record a\npending `--append \u003Cfield>=\u003Cvalue>` \u002F `--remove \u003Cfield>=\u003Cvalue>` flag.\nPreview against the current list already read in Step 2, the same way\nas tag operations.\n\n### 3.3 Structured field operations\n`\u003Cfield> \u003Cvalue>` where `\u003Cfield>` is a known **scalar** frontmatter\nfield name from the template (e.g. `status ready`, `priority high`,\n`parent 0001`, `title \"New title\"`) — record a pending\n`--set \u003Cfield>=\u003Cvalue>` flag. The next token after the field name is\nconsumed as the value. Quoted strings are treated as a single value.\n\n### 3.4 Field-only hint elicitation\nA known field name as the **last token** with no following value\ntriggers hint elicitation. Call `work template-hints`:\n\n```\naccelerator work template-hints \u003Cfield>\n```\n\nPresent the returned values as examples: \"Common statuses: draft,\nready, in-progress, review, done, blocked, abandoned. What would you\nlike to set?\" Accept any value the user provides, including values not\nin the hint list. If the command returns no hints, skip the hint list\nand simply ask for a value.\n\n### 3.5 Natural language\nAnything that does not match rules 3.1–3.4 (e.g. \"mark as done\",\n\"set priority to high\", \"add backend tag\") — interpret into one of the\nstructured shapes above and echo the interpretation explicitly:\n`\"Interpreted as: status → done\"` so the user can correct before\nconfirming.\n\n### Disambiguation\nIf the token sequence is ambiguous, ask the user for clarification\nrather than guessing. Present the possible interpretations and let the\nuser choose.\n\n### Special field rules\n\n**`id` (own-identity) — hard-blocked**: recognise an attempted edit to\n`id` (or the legacy `work_item_id` alias) before gathering a diff\npreview. Run `accelerator work update \u003Cpath> --set id=\u003Cvalue>`\ndirectly and print its stderr verbatim — the CLI rejects it with the\nown-identity error, pointing to file rename (`jj mv`) as the correct\napproach. No diff, no confirmation prompt.\n\n**`date` — warned**: inform the user that `date` records the work item's\ncreation time and is typically not edited, then use the `AskUserQuestion` tool\nwith two options:\n\n1. **Yes, proceed anyway** — proceed through the normal diff-and-confirm flow\n2. **No, cancel** — print \"No changes applied.\" and exit\n\n**`parent` — canonicalised**: normalise the value via\n\n```\naccelerator work canonicalise-id \u003Cinput>\n```\n\nbefore writing. The canonicaliser produces the full ID under the\nconfigured pattern, quoted as a string. Examples:\n\n- Default `{number:04d}`: `1` → `\"0001\"`, `42` → `\"0042\"`.\n- `{key}-{number:04d}` with `key: PROJ`:\n  `1` → `\"PROJ-0001\"`, `PROJ-0042` → `\"PROJ-0042\"`,\n  `0042` (legacy) → `\"PROJ-0042\"` (canonical form).\n\n### No-op detection\nIf the computed new value equals the current value:\n- **Single-op**: print `\"No change needed: \u003Cfield> is already\n  '\u003Cvalue>'.\"` and exit. No diff, no write.\n- **Multi-op**: note the no-op field informally (`\"status is already\n  'ready' — skipping\"`), exclude it from the diff, and continue with\n  the remaining changes. If ALL operations are no-ops, print the\n  combined \"no change needed\" message and exit.\n\n### Non-template values\nIf a value is not one of the template's default hints, add a\nsingle-line informational note above the diff: `\"Note: '\u003Cvalue>' is not\none of the template's default statuses; proceeding anyway.\"` No\nenforcement — the user confirms, the skill writes.\n\n## Step 4: Preview and Confirm\n\nProduce a diff showing only the lines that change, before and after:\n```\n-status: draft\n+status: ready\n-priority: medium\n+priority: high\n```\n\n### Body label sync\n\nWhen a field that has a corresponding body label changes, scan the body\nfor the first line outside any code fence (between ` ``` ` delimiters)\nwhose text starts with the matching label. If found, include the body\nline change in the diff preview. If no such line exists, do not inject\none.\n\nField-to-label mapping:\n- `status` ↔ `**Status**: `\n- `kind` ↔ `**Kind**: `\n- `priority` ↔ `**Priority**: `\n- `author` ↔ `**Author**: `\n\nConvert the frontmatter value to display text using this deterministic\nrule: replace hyphens with spaces and apply title case (capitalise each\nword, keeping small words lowercase unless they open the phrase). Small\nwords: `a, an, and, as, at, but, by, for, in, nor, of, on, or, so,\nthe, to, up, vs, yet`. Single words are simply capitalised\n(`draft` → `Draft`). Multi-word hyphenated values become spaced title\ncase (`waiting-on-legal` → `Waiting on Legal`,\n`in-progress` → `In Progress`).\n\n### Title sync\n\nIf the title is changing, include the body H1 change in the diff too.\nThe H1 is the first `# ` line in the body after the frontmatter.\nPreserve any prefix before the first `: ` in the existing H1 (e.g.\n`# 0042: Old title` or `# ADR Work item: Old title`) and substitute\nthe new title after the prefix:\n```\n-# 0042: Old title\n+# 0042: New title\n```\nIf the existing H1 has no `: ` separator, replace the full heading text\nafter `# ` with the new title. Only the first H1 is touched.\n\n### Confirmation prompt\n\nPrint the diff, then use the `AskUserQuestion` tool with two options:\n\n1. **Yes, apply changes** — write the changes to disk\n2. **No, cancel** — print \"No changes applied.\" and exit without writing\n\n### Field insertion preview\n\nWhen a field does not exist in the target work item's frontmatter (e.g.\nadding `priority:` to a legacy work item), the diff preview shows a pure\naddition: `+priority: high`.\n\n## Step 5: Write\n\n1. **Frontmatter changes first** — issue one call assembling every\n   pending operation accumulated in Step 3:\n\n   ```\n   accelerator work update \u003Cpath> \\\n     --set \u003Cfield>=\u003Cvalue> ... \\\n     --add-tag \u003Cvalue> ... --remove-tag \u003Cvalue> ... \\\n     --append \u003Cfield>=\u003Cvalue> ... --remove \u003Cfield>=\u003Cvalue> ...\n   ```\n\n   Omit any flag category with no pending operations. A non-zero exit\n   means nothing was written (the CLI validates every key before\n   applying any of them) — print the stderr message and exit.\n2. **Body label syncs second** — update the matching body lines using\n   the Edit tool. `work update` only ever touches frontmatter.\n3. **Title H1 sync** — if the title changed, update the body H1 using\n   the Edit tool.\n\nIf a body sync Edit fails after frontmatter was already written, print:\n`\"Warning: frontmatter updated but body sync failed for **\u003CLabel>**: —\ncheck the file manually. To revert, run: jj restore \u003Cfilename>\"`. Do\nnot attempt to revert the frontmatter change.\n\nAfter writing, print a confirmation:\n```\nUpdated \u003Cfilename>:\n  status: draft → ready\n```\n\n**Validate the frontmatter**: after writing, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cfilename>\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- **Confirmation required**: never write without explicit user\n  confirmation via the y\u002Fn prompt.\n- **No transition enforcement**: any status value the user supplies is\n  acceptable. Arbitrary transitions (draft → done, skipping\n  intermediate states) are allowed without warning.\n- **Hint values are suggestions, not constraints**: when surfacing\n  field hints via `work template-hints`, present them as examples.\n  Accept any value the user provides.\n- **Own-identity is immutable**: hard-block edits to `id` (or to\n  `work_item_id` on legacy files) before gathering a diff preview, and\n  let `work update`'s own exit-1 error surface directly.\n- **`date` is guarded**: warn before editing the creation timestamp;\n  allow if the user confirms.\n- **All frontmatter mutation via `work update`**: scalar fields,\n  tags, and typed-linkage lists are all applied in the single Step 5\n  `work update` call, which owns parsing, mutation, and canonical\n  re-serialisation. A non-zero exit means nothing was written — print\n  stderr and exit.\n- **Body label sync scope**: only update the first non-code-fence\n  occurrence of `**Status**:`, `**Kind**:`, `**Priority**:`, or\n  `**Author**:`. Do not inject labels into work items that lack them.\n  Do not update occurrences inside code fences.\n- **Resilient to malformed frontmatter**: abort cleanly on missing or\n  unclosed frontmatter. Error messages use the resolved filename and\n  match `work show`'s phrasing.\n- **Legacy work items supported**: work items with unusual kind or status\n  values (e.g. `kind: adr-creation-task`, `status: todo`) are fully\n  updatable. No migration is offered or required.\n- **Ambiguous globs**: if multiple work items match a number glob, list\n  them and ask the user to choose. Never silently pick one.\n- **No file renaming**: own-identity edits (`id`, or `work_item_id` on\n  legacy files) are hard-blocked. Point the user to `jj mv` + manual\n  frontmatter edit for renumbering.\n\n!`accelerator config instructions update-work-item --fail-safe`\n","# Update Work Item\n\n!`accelerator config context --skill update-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\n## Work Item Template\n\nThe following template defines the work item schema and field defaults.\nHint values are extracted at runtime via `work template-hints`.\n\n!`accelerator config template work-item --fail-safe`\n\nYou are tasked with updating frontmatter fields on an existing work item.\nThis skill supports status transitions, priority changes, tag management,\nparent assignment, title changes, and any other frontmatter field edit.\nNo status transition logic is enforced — the user decides what's valid.\nA future feature may add user-configurable transition graphs; this skill\npredates that feature.\n\n## Step 1: Identify Target Work Item\n\nParse the first argument and resolve via the configured pattern's\nresolver:\n\n```\naccelerator work resolve \u003Cargument>\n```\n\nThe resolver respects `work.id_pattern` and accepts paths, full IDs\n(`PROJ-0042`), and bare numbers (legacy or pattern-shape).\n\n- **Exit 0**: stdout is the absolute path; use it.\n- **Exit 1**: input was unrecognised. Print\n  `\"Unrecognised input '\u003Cargument>' — pass a path, a full ID, or a\n  bare number.\"` and exit.\n- **Exit 2**: ambiguous match. The resolver lists every candidate with\n  a source-category tag. Show the list and ask the user to\n  disambiguate by re-running with a full ID or path.\n- **Exit 3**: no match. Print `\"No work item matching \u003Cargument>.\"` and\n  exit.\n- **Exit 6**: the argument names a real file outside the managed work\n  directory. Print the resolver's error, offer to run\n  `\u002Flist-work-items`, and exit.\n- **No argument**: ask the user which work item to update. Accept the\n  response and run the resolver against it.\n\n## Step 2: Read Current Frontmatter\n\nRead the target file. Extract frontmatter between `---` delimiters.\n\n- If the first line is not `---`: print `\"Error: \u003Cfilename> has no YAML\n  frontmatter. Add a '---' line as the first line of the file, then\n  re-run.\"` and exit. Use the resolved filename, not a glob pattern.\n- If `---` opens but never closes: print `\"Error: \u003Cfilename> has\n  unclosed YAML frontmatter. Add a '---' line after the last\n  frontmatter key, then re-run.\"` and exit.\n\nParse field\u002Fvalue pairs from the frontmatter. Preserve the original key\norder for diff rendering in Step 4.\n\n## Step 3: Interpret Operation\n\nParse the remaining arguments (after the work item reference) as one or\nmore field operations. If no operation arguments were provided, show the\ncurrent frontmatter and ask which field(s) to change.\n\nEach recognised operation is recorded as a pending `work update` flag\n(`--set`, `--add-tag`, `--remove-tag`, `--append`, or `--remove`) rather\nthan applied immediately — Step 4 previews the combined effect, and\nStep 5 issues the single `work update` call that actually writes.\n\nArguments are parsed left-to-right using these rules:\n\n### 3.1 Tag operations\n`add tag \u003Cvalue>` \u002F `remove tag \u003Cvalue>` — record a pending\n`--add-tag \u003Cvalue>` \u002F `--remove-tag \u003Cvalue>` flag. Preview the effect\nagainst the current `tags` list already read in Step 2 (add: append if\nabsent; remove: drop if present). The \"No-op detection\" rule below\napplies the same way as for any other field.\n\n### 3.2 List-field operations\n`add \u003Cfield> \u003Cvalue>` \u002F `remove \u003Cfield> \u003Cvalue>` where `\u003Cfield>` is one\nof `blocks`, `blocked_by`, `derived_from`, `relates_to` — record a\npending `--append \u003Cfield>=\u003Cvalue>` \u002F `--remove \u003Cfield>=\u003Cvalue>` flag.\nPreview against the current list already read in Step 2, the same way\nas tag operations.\n\n### 3.3 Structured field operations\n`\u003Cfield> \u003Cvalue>` where `\u003Cfield>` is a known **scalar** frontmatter\nfield name from the template (e.g. `status ready`, `priority high`,\n`parent 0001`, `title \"New title\"`) — record a pending\n`--set \u003Cfield>=\u003Cvalue>` flag. The next token after the field name is\nconsumed as the value. Quoted strings are treated as a single value.\n\n### 3.4 Field-only hint elicitation\nA known field name as the **last token** with no following value\ntriggers hint elicitation. Call `work template-hints`:\n\n```\naccelerator work template-hints \u003Cfield>\n```\n\nPresent the returned values as examples: \"Common statuses: draft,\nready, in-progress, review, done, blocked, abandoned. What would you\nlike to set?\" Accept any value the user provides, including values not\nin the hint list. If the command returns no hints, skip the hint list\nand simply ask for a value.\n\n### 3.5 Natural language\nAnything that does not match rules 3.1–3.4 (e.g. \"mark as done\",\n\"set priority to high\", \"add backend tag\") — interpret into one of the\nstructured shapes above and echo the interpretation explicitly:\n`\"Interpreted as: status → done\"` so the user can correct before\nconfirming.\n\n### Disambiguation\nIf the token sequence is ambiguous, ask the user for clarification\nrather than guessing. Present the possible interpretations and let the\nuser choose.\n\n### Special field rules\n\n**`id` (own-identity) — hard-blocked**: recognise an attempted edit to\n`id` (or the legacy `work_item_id` alias) before gathering a diff\npreview. Run `accelerator work update \u003Cpath> --set id=\u003Cvalue>`\ndirectly and print its stderr verbatim — the CLI rejects it with the\nown-identity error, pointing to file rename (`jj mv`) as the correct\napproach. No diff, no confirmation prompt.\n\n**`date` — warned**: inform the user that `date` records the work item's\ncreation time and is typically not edited, then use the `AskUserQuestion` tool\nwith two options:\n\n1. **Yes, proceed anyway** — proceed through the normal diff-and-confirm flow\n2. **No, cancel** — print \"No changes applied.\" and exit\n\n**`parent` — canonicalised**: normalise the value via\n\n```\naccelerator work canonicalise-id \u003Cinput>\n```\n\nbefore writing. The canonicaliser produces the full ID under the\nconfigured pattern, quoted as a string. Examples:\n\n- Default `{number:04d}`: `1` → `\"0001\"`, `42` → `\"0042\"`.\n- `{key}-{number:04d}` with `key: PROJ`:\n  `1` → `\"PROJ-0001\"`, `PROJ-0042` → `\"PROJ-0042\"`,\n  `0042` (legacy) → `\"PROJ-0042\"` (canonical form).\n\n### No-op detection\nIf the computed new value equals the current value:\n- **Single-op**: print `\"No change needed: \u003Cfield> is already\n  '\u003Cvalue>'.\"` and exit. No diff, no write.\n- **Multi-op**: note the no-op field informally (`\"status is already\n  'ready' — skipping\"`), exclude it from the diff, and continue with\n  the remaining changes. If ALL operations are no-ops, print the\n  combined \"no change needed\" message and exit.\n\n### Non-template values\nIf a value is not one of the template's default hints, add a\nsingle-line informational note above the diff: `\"Note: '\u003Cvalue>' is not\none of the template's default statuses; proceeding anyway.\"` No\nenforcement — the user confirms, the skill writes.\n\n## Step 4: Preview and Confirm\n\nProduce a diff showing only the lines that change, before and after:\n```\n-status: draft\n+status: ready\n-priority: medium\n+priority: high\n```\n\n### Body label sync\n\nWhen a field that has a corresponding body label changes, scan the body\nfor the first line outside any code fence (between ` ``` ` delimiters)\nwhose text starts with the matching label. If found, include the body\nline change in the diff preview. If no such line exists, do not inject\none.\n\nField-to-label mapping:\n- `status` ↔ `**Status**: `\n- `kind` ↔ `**Kind**: `\n- `priority` ↔ `**Priority**: `\n- `author` ↔ `**Author**: `\n\nConvert the frontmatter value to display text using this deterministic\nrule: replace hyphens with spaces and apply title case (capitalise each\nword, keeping small words lowercase unless they open the phrase). Small\nwords: `a, an, and, as, at, but, by, for, in, nor, of, on, or, so,\nthe, to, up, vs, yet`. Single words are simply capitalised\n(`draft` → `Draft`). Multi-word hyphenated values become spaced title\ncase (`waiting-on-legal` → `Waiting on Legal`,\n`in-progress` → `In Progress`).\n\n### Title sync\n\nIf the title is changing, include the body H1 change in the diff too.\nThe H1 is the first `# ` line in the body after the frontmatter.\nPreserve any prefix before the first `: ` in the existing H1 (e.g.\n`# 0042: Old title` or `# ADR Work item: Old title`) and substitute\nthe new title after the prefix:\n```\n-# 0042: Old title\n+# 0042: New title\n```\nIf the existing H1 has no `: ` separator, replace the full heading text\nafter `# ` with the new title. Only the first H1 is touched.\n\n### Confirmation prompt\n\nPrint the diff, then use the `AskUserQuestion` tool with two options:\n\n1. **Yes, apply changes** — write the changes to disk\n2. **No, cancel** — print \"No changes applied.\" and exit without writing\n\n### Field insertion preview\n\nWhen a field does not exist in the target work item's frontmatter (e.g.\nadding `priority:` to a legacy work item), the diff preview shows a pure\naddition: `+priority: high`.\n\n## Step 5: Write\n\n1. **Frontmatter changes first** — issue one call assembling every\n   pending operation accumulated in Step 3:\n\n   ```\n   accelerator work update \u003Cpath> \\\n     --set \u003Cfield>=\u003Cvalue> ... \\\n     --add-tag \u003Cvalue> ... --remove-tag \u003Cvalue> ... \\\n     --append \u003Cfield>=\u003Cvalue> ... --remove \u003Cfield>=\u003Cvalue> ...\n   ```\n\n   Omit any flag category with no pending operations. A non-zero exit\n   means nothing was written (the CLI validates every key before\n   applying any of them) — print the stderr message and exit.\n2. **Body label syncs second** — update the matching body lines using\n   the Edit tool. `work update` only ever touches frontmatter.\n3. **Title H1 sync** — if the title changed, update the body H1 using\n   the Edit tool.\n\nIf a body sync Edit fails after frontmatter was already written, print:\n`\"Warning: frontmatter updated but body sync failed for **\u003CLabel>**: —\ncheck the file manually. To revert, run: jj restore \u003Cfilename>\"`. Do\nnot attempt to revert the frontmatter change.\n\nAfter writing, print a confirmation:\n```\nUpdated \u003Cfilename>:\n  status: draft → ready\n```\n\n**Validate the frontmatter**: after writing, run\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cfilename>\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- **Confirmation required**: never write without explicit user\n  confirmation via the y\u002Fn prompt.\n- **No transition enforcement**: any status value the user supplies is\n  acceptable. Arbitrary transitions (draft → done, skipping\n  intermediate states) are allowed without warning.\n- **Hint values are suggestions, not constraints**: when surfacing\n  field hints via `work template-hints`, present them as examples.\n  Accept any value the user provides.\n- **Own-identity is immutable**: hard-block edits to `id` (or to\n  `work_item_id` on legacy files) before gathering a diff preview, and\n  let `work update`'s own exit-1 error surface directly.\n- **`date` is guarded**: warn before editing the creation timestamp;\n  allow if the user confirms.\n- **All frontmatter mutation via `work update`**: scalar fields,\n  tags, and typed-linkage lists are all applied in the single Step 5\n  `work update` call, which owns parsing, mutation, and canonical\n  re-serialisation. A non-zero exit means nothing was written — print\n  stderr and exit.\n- **Body label sync scope**: only update the first non-code-fence\n  occurrence of `**Status**:`, `**Kind**:`, `**Priority**:`, or\n  `**Author**:`. Do not inject labels into work items that lack them.\n  Do not update occurrences inside code fences.\n- **Resilient to malformed frontmatter**: abort cleanly on missing or\n  unclosed frontmatter. Error messages use the resolved filename and\n  match `work show`'s phrasing.\n- **Legacy work items supported**: work items with unusual kind or status\n  values (e.g. `kind: adr-creation-task`, `status: todo`) are fully\n  updatable. No migration is offered or required.\n- **Ambiguous globs**: if multiple work items match a number glob, list\n  them and ask the user to choose. Never silently pick one.\n- **No file renaming**: own-identity edits (`id`, or `work_item_id` on\n  legacy files) are hard-blocked. Point the user to `jj mv` + manual\n  frontmatter edit for renumbering.\n\n!`accelerator config instructions update-work-item --fail-safe`\n",{"name":5,"description":7,"allowed-tools":44,"argument-hint":48},[45,46,47],"Bash(accelerator config *)","Bash(accelerator work *)","Bash(accelerator corpus frontmatter validate *)","[work-item-ref] [field-op...]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fwork\u002Fupdate-work-item",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-12 04:07:28",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add atomicinnovation\u002Faccelerator --skill update-work-item",{"tool":63,"command":64},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill update-work-item",{"tool":66,"command":67},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill update-work-item","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002FSKILL.md",true,[71,77],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"evals\u002Fbenchmark.json","REFERENCE","参考文档",2279,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002Fevals\u002Fbenchmark.json",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"evals\u002Fevals.json",3364,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002Fevals\u002Fevals.json",[82,117,139,157,182,198],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":98,"publishedAt":39},"01M70S7PFGVATJREBFEGPJB718","explore-pr","Build an interactive, design-first and picture-first exploration page for a pull request — its architecture, abstractions and design decisions drawn as diagrams, a guided tour in reading order with code as the evidence, an attention map of where the risk sits, a ledger of its riskiest operations, prior review findings re-checked against the code, and simulations specific to the PR — with the reviewer's verdicts and notes saved. Use when the user wants to explore, understand or review a large pull request or its design, asks for a review page, walkthrough or visual explanation of a PR, or is struggling to review a big change.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fexplore-pr\u002FSKILL.md",[88,93],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[99,100,101,102,103,104,105,106,107,108,109,110,111,35,112,113,114,115,116,31],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","when","number","URL","code","architecture","reviewer","review","notes",{"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":123,"publishedAt":39},"01M6DY0106CF15CYEJHZM14GBZ","sync-work-items","Reconcile local work items in meta\u002Fwork\u002F with the active remote tracker named by work.integration. Use when the user wants to sync, push, or pull work items to or from Jira or Linear, preview what a sync would change, or reconcile divergent local and remote state.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items\u002FSKILL.md",[],[21,124,125,126,127,128,129,35,130,31,131,132,133,134,135,136,137,37,138,28,109],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":39},"01M6HNF86984S4XK21Q26VZA21","sync-work-items-recovery","Recovery procedures for work sync failures that need a person — terminal rows, refused pending pushes and refused orders. Read by sync-work-items — not invoked directly.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items-recovery\u002FSKILL.md",[],[146,21,147,124,125,148,149,150,151,152,153,154,155,156],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":166,"publishedAt":39},"01M6DXZWH7PR72VCEXSSD4XNK4","stress-test-work-item","Interactively stress-test a work item by grilling the user on scope, assumptions, acceptance criteria, edge cases, and dependencies to surface issues, gaps, and flawed assumptions before implementation is planned.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002FSKILL.md",[163],{"categoryNo":164,"categoryName":165,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000008","测试与质量",[167,168,21,169,19,170,171,172,173,174,175,35,176,177,37,38,178,179,180,110,181,28],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","user","gaps",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":39},"01M6DXZRQWHTWV1G9PTTHCGGYA","review-work-item","Review a work item through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a work item before implementation or escalation.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",[],[115,21,189,19,190,191,33,35,192,193,37,38,178,180,194,109,195,196,28,197],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":39},"01M6DXZMY4QJXX8V72CMWR2MZ1","rekey-work-items","Converge every work item's ID onto the configured work.id_pattern, renaming files and rewriting references across meta\u002F. Use after changing work.id_pattern or work.key, when existing work items should take IDs in the new shape, or to finish or undo an interrupted re-key.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Frekey-work-items\u002FSKILL.md",[],[21,205,206,127,207,33,35,208,209,210,211,37,212,213,38,214,215,19,104,216,26,109],"rekey work items","ids","files","across","id","references","shape","pattern","take","finish","converge","new"]