From accelerator
Guides users through creating a structured work item (feature, bug, task, spike, or epic) with collaborative research and reasoning.
How this skill is triggered — by the user, by Claude, or both
Slash command
/accelerator:create-work-item [topic or existing work item path/number][topic or existing work item path/number]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
!`${CLAUDE_PLUGIN_ROOT}/scripts/config-read-context.sh`
!${CLAUDE_PLUGIN_ROOT}/scripts/config-read-context.sh
!${CLAUDE_PLUGIN_ROOT}/scripts/config-read-skill-context.sh create-work-item
!${CLAUDE_PLUGIN_ROOT}/scripts/config-read-agents.sh
If no "Agent Names" section appears above, use these defaults: accelerator:reviewer, accelerator:codebase-locator, accelerator:codebase-analyser, accelerator:codebase-pattern-finder, accelerator:documents-locator, accelerator:documents-analyser, accelerator:web-search-researcher.
Work items directory: !${CLAUDE_PLUGIN_ROOT}/scripts/config-read-path.sh work
Active integration: !${CLAUDE_PLUGIN_ROOT}/scripts/config-read-work.sh integration
The Active integration line gates the post-draft push offer (Step 5).
config-read-work.sh integration exits 0 with an empty line when no
integration is configured, so branch on the string: a non-empty value means
integration configured (offer the push); an empty value means not configured
(no push offer — behave exactly as today). This is the single resolution of the
active tracker for this invocation; the push dispatcher is told which tracker to
use from this value, so the gate and the route cannot diverge.
The template below defines the sections and frontmatter fields that every work item must contain. Read it now — use it to guide what information you gather in Step 1 and what structure you produce in Steps 3–4.
!${CLAUDE_PLUGIN_ROOT}/scripts/config-read-template.sh work-item
You are tasked with guiding the user through creating a well-formed work item — a structured document capturing a feature, bug, task, spike, or epic for tracking and implementation. This is a collaborative, challenging conversation: the model contributes its own knowledge and research alongside the user's input rather than simply transcribing what the user says. The goal is a work item that is well-reasoned and well-specified — one that would stand on its own without needing the author present to explain it.
The work item template has three sections that look similar but capture different things — populate each deliberately:
When this command is invoked:
If an argument was provided:
First, try to resolve the argument as a reference to an existing work item by invoking the resolver:
${CLAUDE_PLUGIN_ROOT}/skills/work/scripts/work-item-resolve-id.sh <argument>
The resolver respects work.id_pattern and accepts paths, full IDs
(PROJ-0042), legacy bare numbers (0042), and short numbers (42,
resolved against work.default_project_code when set).
legacy, project-prepended,
pattern-shape, or a project code). Present the list to the user
and ask them to disambiguate by re-running with a full ID (e.g.
PROJ-0042) or a path."No work item matching <argument> — interpreting as topic string. If that's wrong, abort and re-run with a different argument (or /list-work-items to find a valid reference)." and proceed to
topic-string handling below.Frontmatter validation (only reached after a file was successfully resolved). Run:
bash ${CLAUDE_PLUGIN_ROOT}/skills/work/scripts/work-item-read-field.sh id <path>
The own-identity field is id on unified-shape files and
work_item_id on legacy files; work-item-read-field.sh resolves
both transparently, so either key name passed here would return the
same value.
If it exits non-zero (frontmatter missing or unclosed), print:
Could not parse frontmatter in <path> — the file may be corrupted.
Re-open it and check that the YAML frontmatter is bracketed by two
`---` lines and contains all nine required fields.
and exit without spawning agents or writing any file. (The file clearly resolved, so the user intended a path — no fallback applies.)
If validation passes, read the file fully (frontmatter and body) and
cache the identity fields in conversation state:
id (or work_item_id on legacy files), date, author, status,
title, kind, priority, parent, tags. For any missing
optional field, use the template default — do not abort. Set the conversation into
enrich-existing mode with existing_work_item_path cached, and
skip directly to Step 1 in that mode — do not run the vagueness check.
Topic-string handling: if no resolution succeeded (discriminators did not trigger, or they triggered with a fallback warning), check whether the argument is too vague (no clear deliverable or subject).
If no argument was provided, respond with:
I'll help you create a well-specified work item through a collaborative conversation.
To get started, describe what you want to achieve — what's the problem or goal?
For example: "add full-text search to the docs index page", or "users can't log in after resetting their password"
I'll ask a few questions to understand the problem space, do some research, then
work with you to shape a thoroughly reasoned work item.
Then wait for the user's input. Apply the same vagueness check to their response — if still vague, ask a clarifying question before proceeding to Step 1.
Once the topic is clear, ask 3–5 open questions to understand the business context before investigating. Consult the work item template sections above to understand what the work item will need — use them to guide which questions are worth asking. Tailor the questions to the topic, but cover:
Ask all relevant questions at once rather than one at a time. Wait for the user's answers before proceeding to Step 2.
Do not ask the broad discovery questions above. Instead:
Identify which body sections of the existing file are substantive (real
content beyond [bracketed placeholder] text) and which are gaps (empty,
placeholder-only, or missing entirely). Tag each gap with exactly one of
the literal tokens:
empty — section is absent or contains no contentplaceholder-only — section contains only template [...] blocksinstructional-prose — section contains the template's instructional
prose carried over verbatim (e.g. "Describe the business value of this
work item here…")partial — section contains one or more substantive sentences alongside
residual placeholdersUse the literal token; do not paraphrase. The eval grader pattern-matches on these exact strings.
Present the gap analysis briefly:
I've read the existing work item (<resolved path>). Here's what looks
complete and what still needs work:
Complete: [section list, or "none"]
Gaps:
- <Section> (<tag>)
- ...
I'll ask targeted questions about the gaps.
Ask only questions that address the identified gaps. Do not re-ask questions whose answers are already substantively present in the file.
If the existing content is rich enough that no obvious gaps remain, briefly confirm this and ask what the user wants to add or improve, then proceed to Step 2.
Using the topic and business context from Step 1, run investigation agents in parallel:
Spawn {documents locator agent} to search {work_dir} only —
look for existing work items with similar titles, descriptions, or scope.
Do not search research documents, plans, or other directories — work items
capture business requirements, not implementation details.
Spawn {web-search-researcher agent} when there is uncertainty or a need for richer context about any aspect of the topic — business rules, domain concepts, competitive landscape, industry standards, external technology, or anything the model lacks confidence on. Skip this agent only when the topic is entirely self-contained and well-understood from the user's description. When in doubt, prefer to spawn research — over-asking is cheaper than producing a vague or poorly-grounded proposal.
Run both agents in parallel where both are warranted.
Once agents complete, synthesise findings — what the model knows from training, what research turned up, what prior work items exist — as the foundation for Step 3.
If a similar existing work item is found: Check its status.
If the status is done, abandoned, or superseded — mention the work item
briefly and note it is already closed, then continue creating the new one.
Otherwise — surface the work item and offer the user numbered options, for example:
/update-work-item once
available; for now, update it manually)Adapt the options to what makes sense given the work item's kind and status. Do not silently continue or modify the existing work item inline. Wait for the user's choice before proceeding.
In enrich-existing mode: exclude the resolved input file from the
similarity scan. The {documents locator agent} search of {work_dir} will
find the file being enriched; do not surface it as a "potential duplicate" of
itself. Other near-duplicates discovered are handled per the unchanged rules
above.
Using the business context and investigation synthesis, the model leads with a structured proposal. Do not ask the user to generate requirements or acceptance criteria from scratch — propose them and invite challenge.
kind field (loaded at the top of this skill) — do
not hardcode the list. Default to story when the kind is genuinely
ambiguous.Assumptions and invite
the user to confirm or correct them.Open Questions.Drafting Notes so a reviewer can challenge them.Present as a structured proposal:
Based on what you've told me and my research, here's what I think this work item needs:
**Suggested kind**: [kind]
**Rationale**: [one sentence]
**Requirements I'd suggest**:
- [requirement]
**Out of scope** (explicitly not captured here):
- [item]
**Acceptance criteria I'd suggest**:
- Given/When/Then...
**Assumptions I've made** (scope-changing calls — confirm or correct):
- [assumption]
**Drafting Notes** (interpretations a reviewer should see):
- [interpretation — e.g. who stakeholders are, what a vague term means,
scope boundary, implied technical approach]
**Open questions** (unknowns to resolve before work begins):
- [anything the user should clarify before drafting]
Wait for the user to validate, push back, or refine. Challenge vague or untestable responses — if an acceptance criterion is not measurable (e.g., "it works correctly"), first ask a clarifying question to understand the intent ("what would a passing test actually look like here?"). Only after understanding the intent should you help reformulate it into something testable. Do not accept vague criteria into the draft. Iterate until the proposal is well-specified and agreed.
Do not lead with a from-scratch proposal. Instead present a section-by-section review and augmentation:
Here's how the existing work item reads against my research, with proposed
additions for the gaps:
**[Section name]** — [complete | needs improvement: <reason> | missing]
[existing content excerpt or note that it is missing]
[proposed addition or replacement, when applicable]
[repeat per section]
**Title**: [keep / propose new title with rationale]
**Kind**: [keep existing <kind> / propose change to <kind> with rationale]
**Priority**: [keep / propose change with rationale]
**Parent**: [keep / propose change]
**Tags**: [keep / propose additions]
**Status**: [keep <cached> — say so if you'd like to transition it]
Apply the canonical Identity Field Rules (see Quality Guidelines): propose only the fields marked Proposable; never propose changes to immutable fields; surface a status transition only if the user makes a direct explicit request for one (the listing offers the affordance but never proposes a change unsolicited).
The refinement loop in this step (challenging untestable criteria, vague requirements, etc.) applies equally to existing and proposed content.
Draft a complete work item from the agreed proposal using the template
structure loaded at the top of this skill. Use XXXX as the placeholder
work item number throughout. Do NOT call work-item-next-number.sh at this step.
Kind-specific content placement:
Summary section with a user story statement —
"As a [role], I want [goal], so that [benefit]." — before the
descriptive sentencesRequirements sectionRequirements sectionRequirements section as a listPopulate the References section with any external material that
informed the work item — research artefacts surfaced by the web researcher,
related work items found in Step 2, design docs, or source specs. Leave it
empty if nothing external was consulted; do not invent references.
Populate the Drafting Notes section with the interpretations
carried over from the agreed proposal. If there were none (the user
confirmed every call), the section may be omitted or left as an empty
list — but do not leave placeholder bracketed text in it.
Present the full draft to the user:
Here's my draft work item. Please review and let me know if you'd like any
changes before I write it to disk:
[draft content]
work-item-next-number.sh is
never called during this loop.Produce a complete updated draft incorporating the existing content plus the additions approved in Step 3.
Apply the canonical Identity Field Rules (see Quality Guidelines) when filling frontmatter — the rules are the single source of truth for which fields are immutable, preserved, or proposable.
Apply the H1 sync rule (see Quality Guidelines).
Apply the Script avoidance rule (see Quality Guidelines).
Present the full updated draft, framed as an update preview:
Here's the updated work item. The Step 5 confirmation will name the file
path and ask for explicit approval before any write:
[draft content]
Continue to challenge during review — apply the same rules as the normal-path Step 4. Iterate the draft until the user is happy with it. Do not treat a "looks good" mid-iteration as approval to write — that approval is gated by Step 5's single confirmation.
work-item-next-number.sh to get the next full ID under the
configured pattern:${CLAUDE_PLUGIN_ROOT}/skills/work/scripts/work-item-next-number.sh
The output is the full ID (0001 under default {number:04d},
PROJ-0001 under {project}-{number:04d} with
work.default_project_code: "PROJ"). The allocator reads the pattern
and default project code from configuration; pass --project CODE if
the user explicitly wants a non-default project.
If the script exits non-zero (e.g., overflow, missing project value), abort immediately and surface the error message verbatim — do not proceed.
Resolve the target path: {work_dir}/<full-id>-kebab-slug.md
where <full-id> is the allocator's output and the slug is a
meaningful kebab-case summary of the title (not raw input text).
Check that the target path does not already exist. If it does, abort:
Path {path} already exists — another session may have written a work item
concurrently. Please re-run /create-work-item.
Create the work items directory if it does not exist.
Populate frontmatter: before writing the artifact file, capture metadata and substitute the unified base fields into the template's frontmatter block.
Invoke ${CLAUDE_PLUGIN_ROOT}/scripts/artifact-derive-metadata.sh
to obtain Current Date/Time (UTC):, Current Revision:, and
Repository Name:. Run the bare path directly as an executable;
never prefix it with bash/sh/env (a wrapper prefix escapes the
skill's allowed-tools permission and forces an unnecessary prompt).
Substitute every field below with the indicated value:
type: ← work-itemid: ← the full ID produced by work-item-next-number.sh,
always quoted as a YAML string (e.g. id: "0001" or
id: "PROJ-0001")title: ← the body H1 titledate: ← the Current Date/Time (UTC): valueauthor: ← the author value resolved per the rules below
(config → VCS user → prompt)producer: ← create-work-itemstatus: ← draftlast_updated: ← the same Current Date/Time (UTC): valuelast_updated_by: ← the same value resolved for authorschema_version: ← 1 (bare integer, not quoted)Optional linkage/foreign-ref keys are omit-by-default:
the template shows each as ""/[], but write a key into the
artifact only when it has a value, and omit it entirely
otherwise (do not carry the empty placeholder through). By default
a new draft names none of them.
parent: ← the parent work item's ID as a typed-linkage ref
("work-item:NNNN"). Fill when the user names a parent at draft
time; otherwise omit the key entirely.blocks: ← list of typed-linkage refs to work items this work
item blocks (["work-item:NNNN", ...]). Fill when blocking edges
are explicit at draft time; otherwise omit the key.blocked_by: ← list of typed-linkage refs to work items that
block this one. Prefer writing the canonical blocks: on the
other side; emit blocked_by: only when the canonical side
cannot be written, and omit it otherwise.derived_from: ← list of typed-linkage refs to artifacts this
work item is derived from (["plan:NNNN", ...]). Fill when
derivation is explicit; otherwise omit the key.relates_to: ← list of typed-linkage refs to related artifacts.
Fill when relationships are explicit; otherwise omit the key.source: ← typed-linkage ref to the originating source artifact
("issue-research:NNNN"). Fill when the source is explicit;
otherwise omit the key.external_id: ← cross-system pointer (e.g. a Jira/Linear key).
Fill when the work item is linked to an external tracker;
otherwise omit the key.Substitute XXXX with the full ID throughout the draft body (in
the H1 line). The H1 line reads # <full-id>: <title>.
Do not Write yet if an integration is configured — the push state
machine in Step 6 governs the single Write (so external_id can be
substituted in before it). If no integration is configured, Write the
file now with the substituted frontmatter block and skip to step 7.
Push state machine (only when Active integration is non-empty; otherwise this whole step is skipped and the file was already written in step 5.4). The drafted frontmatter is held in memory — no file exists yet.
Offer the push using the fail-safe gate (copied from the
enrich-mode gate): present the target tracker, the title, and the
resolvable target fields so the single keystroke maps to an understood,
non-destructive result. Get the preview through the dispatcher (never
reach into an integration script directly — the dispatcher is the only
sanctioned bridge and the one your allowed-tools permits):
${CLAUDE_PLUGIN_ROOT}/skills/work/scripts/work-item-create-remote.sh \
--integration <sys> --kind <kind> --dry-run
For jira it prints jira\t<issue type>\t<type source>\t<project>\t<project source> —
render the type and project with their sources, and say kind "<k>" → <Type> (default) when the type source is default. If --dry-run exits
70 (e.g. an unresolvable project), surface that as a pre-create failure
before the gate (name work.default_project_code) and do not offer the
push. For linear it prints that there are no user-resolvable
type/project fields (the team is fixed by /init-linear). State both
outcomes inline:
Push to <tracker> now? [y/N] (y = create the remote issue + save locally;
anything else = save locally only, unsynced — you can push it later by
running /create-<tracker>-issue <path>)
Interpret strictly: exactly y/Y (trimmed) accepts; anything else
declines. /sync-work-items is not built yet — do not tell the user
to run it; the "push later" path is the standalone /create-<tracker>-issue
skill on the saved file (it shares this external_id contract).
On decline → write the file now with external_id omitted (unsynced),
then go to step 7.
On accept → write the work item's Markdown body to a temp file and call the dispatcher with the tracker from the Active integration read above (never a re-derived value):
${CLAUDE_PLUGIN_ROOT}/skills/work/scripts/work-item-create-remote.sh \
--integration <sys> --title "<title>" --body-file <body-tmp> --kind <kind>
On success it prints only the bare remote identifier. Feed the dispatcher's exit code (and the attempt number, starting at 1) to the decision seam — never re-derive the branch by hand, it is the guard that prevents duplicate issues:
${CLAUDE_PLUGIN_ROOT}/skills/work/scripts/work-item-push-decide.sh \
--code <dispatcher-exit-code> --attempt <n>
Then act on the printed keyword, per the table below.
Outcome table (the seam returns the keyword; you render the message):
| Dispatcher result | Seam keyword | Action |
|---|---|---|
0 (success) | write-once | Substitute the returned identifier into the in-memory external_id line (add the line if omit-by-default dropped it), then Write once. |
70 retryable-transport, attempt 1 | retry | Offer one retry. Re-run the dispatcher; feed its code to the seam with --attempt 2. The retry's result re-enters this table (0→write-once; 71→loud-terminal; 70 again→local-save). |
70 retryable-transport, attempt 2 | local-save | Write locally without external_id; tell the user it saved unsynced and can be pushed later via /create-<tracker>-issue <path>. |
71 terminal-post-create | loud-terminal | Do NOT retry. Write locally without external_id, then print loud non-idempotent guidance naming the saved file's absolute path: a remote issue may already have been created — do not blindly re-run /create-work-item; check the tracker, and if the issue exists reconcile by running /create-<tracker>-issue <saved-path> (guarded against double-create) or set external_id: <KEY> by hand. |
| Accept → success but the single Write fails | loud-terminal (seam called with --code 0 --write-failed) | The remote issue exists and its identifier is known, but nothing is on disk. Print the same loud guidance, echoing the returned identifier and intended path; do not silently re-create (a re-run would duplicate). |
72 not-available (trello/github-issues) | local-save | Tell the user create support for <sys> is not built yet (cite 0049/0050), the item is saved locally and will sync once support lands; Write without external_id. |
73 unrecognised | local-save | Fail closed: report the misconfigured work.integration value; Write without external_id. |
The single Write is the only disk mutation on the success path —
external_id is substituted pre-write, so the replace-only
config_set_frontmatter_field is never on this path. The invariant "no file
exists until success / decline / confirmed-local-fallback resolves" holds
across every row, including the Write-failure row (the failure leaves no
partial file and hands recovery to the user).
Print a confirmation:
Work item created: `{work_dir}/<full-id>-kebab-slug.md`
When the item was saved unsynced (decline / fallback), say so:
Work item created (unsynced): … — push later with /create-<tracker>-issue <path>.
Do not call work-item-next-number.sh. The target path is the resolved
existing_work_item_path cached in Step 0.
At-write identity-swap check (best-effort guard): immediately before the confirmation prompt, re-read the target file's own identity from disk via:
bash ${CLAUDE_PLUGIN_ROOT}/skills/work/scripts/work-item-read-field.sh id <existing_work_item_path>
(The script returns the value of id: on unified-shape files and falls
back to work_item_id: on legacy files.)
"Error: <path> is no longer present or its frontmatter is unparseable. Your proposed draft is below — copy it before re-running /create-work-item: <draft>""Error: <path> changed identity since Step 0 (was <cached>, now <current>). Your proposed draft is below — copy it before re-running /create-work-item to refresh: <draft>"Single confirmation gate: present the path and a per-section change summary, then require explicit y/n approval before any write:
I'm about to overwrite <existing_work_item_path>.
Sections changed:
Added: [...]
Modified: [...]
Frontmatter changed:
<field>: <cached> → <new> # repeated per modified field
(status: <cached> unchanged) # always show status explicitly
Sections preserved verbatim: <count> (<terse list or "none">)
Frontmatter fields preserved verbatim: id, date, author
[+ any unmodified proposable fields]
Proceed? (y/n)
Confirmation interpretation (fail-safe):
y or Y (after trimming whitespace): proceed to step 5.n or N: go to step 8.n. Print:
"Did not recognise <response> as y/n — staying in review. What change would you like before I overwrite?" and go to step 8.On y — substitute cached immutable fields, then write: immediately
before invoking the Write tool, re-read the cached immutable identity fields
(id, date, author) from conversation state and overwrite the
corresponding frontmatter lines in the draft text with those exact values,
even if they appear unchanged. Also write last_updated: to the current
Current Date/Time (UTC): value and last_updated_by: to the resolved
author. This textual substitution defends against drift during Step 4
iteration.
Write the file to existing_work_item_path. The path-existence guard from
the normal flow does not apply — overwrite is the intended behaviour.
Print:
Work item updated: <existing_work_item_path>
On n or unrecognised: stay in Step 4 / Step 5 review and iterate.
Do not re-run the identity-swap check until the next y; do not write.
Never write a file without explicit user approval.
Never call work-item-next-number.sh before the user approves the draft.
The slug must be a meaningful kebab-case title, not raw input text.
Work item kind must come from the work item template's kind field (loaded at
the top of this skill), not a hardcoded list. Default to story when the
kind is genuinely ambiguous.
All frontmatter fields defined in the work item template must be populated
in every written work item: type (work-item), id matching the
assigned full ID (a quoted YAML string — see contract below), title
matching the user-approved title, date, author, producer
(create-work-item), status (draft), kind, priority (medium
unless the user specified otherwise), parent (empty string unless a
parent was established), external_id (empty unless set), tags (a
YAML array, possibly empty), last_updated, last_updated_by, and
schema_version: 1. No field may contain unfilled placeholder text
like [author] or NNNN. The body H1 format is # <full-id>: <title>
where <full-id> is whatever the configured work.id_pattern
produces — kept in sync with the frontmatter title: field.
id frontmatter type contract: the own-identity field is
always a quoted YAML string, regardless of the configured
pattern. Files created under default {number:04d} write
id: "0001"; files created under {project}-{number:04d} write
id: "PROJ-0001". This contract is uniform so consumers can read
the field as a string without coercion. See
skills/config/configure/SKILL.md > work for the full contract.
Legacy files carry the same value under work_item_id:;
work-item-read-field.sh returns either key transparently so
consumers do not need to know which shape is on disk.
Identity Field Rules (apply in enrich-existing mode):
id (or work_item_id on legacy files), date,
author. Cached from the source file in Step 0; never proposed for
change; the model substitutes the cached values back into the draft
frontmatter at write time (Step 5 step 5) as a defence against drift
during Step 4 iteration. This is a textual substitution the model
performs — the eval suite verifies the written file's values match
the cached values, which is the strongest guarantee the grader-
mediated harness can provide.status. Defaults to the cached
value. May only change if the user makes an explicit, direct request during
the conversation (e.g. "set status to in-progress"). The model must not
propose a status change unsolicited; if the user makes only an oblique
reference (e.g. "this is now in flight"), the model asks a clarifying
question rather than infer the transition. A proposed transition is shown
explicitly (e.g. "draft → in-progress") and requires confirmation in Step 3
before acceptance. The status: draft default applies only to
newly-created work items, not to enrichment.title, kind, priority, parent, tags.
Default to the cached values; can be replaced after explicit user agreement
in Step 3's augmentation review.H1 sync (enrich-existing mode): the body H1 is # <id>: <title>,
using the cached immutable id (the full ID produced by the configured
pattern, never a placeholder; sourced from work_item_id on legacy
files) and the title as confirmed or replaced in Step 3.
Script avoidance (enrich-existing mode): work-item-next-number.sh is
never called. The number is already cached. The path-existence guard in Step 5
does not apply — overwrite is the intended behaviour once the at-write
identity-swap check passes.
date must use the work item template's YYYY-MM-DDTHH:MM:SS+00:00 format
in UTC (e.g. obtained via date -u +%Y-%m-%dT%H:%M:%S+00:00).author is sourced in this order: configuration if present, then the
current git/jj user identity, then — only if both fail — ask the user
once before writing the file. Never write [author] or any placeholder.Summary and Requirements must have substantive content — no
[bracketed placeholder text] in the final written file. The same
applies to every other body section that is populated: if a section
would only contain a bracketed placeholder, remove the placeholder and
leave the section empty (or omit optional sections entirely).Drafting Notes with every meaningful interpretation made while
filling out the work item — who stakeholders are, what a vague term means,
where scope boundaries sit, which technical approach is implied. Use
Assumptions for scope-changing calls the user should confirm. Use
Open Questions for genuine unknowns that block progress. These three
sections serve different purposes; don't collapse them.References with any external material that informed the
work item — research artefacts, related work items, design docs, source specs.
Leave it empty if nothing external was consulted; do not invent
references.{documents locator agent} to {work_dir} only. Do not search
research documents, plans, or the codebase — work items are about business
requirements, not implementation details.{web-search-researcher agent} whenever there is uncertainty about any
aspect of the topic — business rules, domain concepts, competitive landscape,
industry standards, external technology, or otherwise. When in doubt,
prefer to spawn research — over-asking is cheaper than producing a
vague or poorly-grounded proposal.work-item-next-number.sh exits non-zero, abort and surface the error
message verbatim.!${CLAUDE_PLUGIN_ROOT}/scripts/config-read-skill-instructions.sh create-work-item
npx claudepluginhub atomicinnovation/accelerator --plugin acceleratorInteractively refines a work item by decomposing it into children, enriching it with codebase context, sharpening acceptance criteria, sizing it, or linking dependencies. Use after drafting and before planning.
Generates well-structured work items with titles, descriptions, acceptance criteria, journals, and notes using govctl. Useful for creating tasks, adding criteria, or WI/task/ticket mentions.
Task creation for issue trackers — structured descriptions, acceptance criteria, field categorization, and tracker linking. Invoke whenever task involves creating work items in any issue tracker — bugs, features, stories, tasks, or any tracked work from standalone requests or decomposition documents.