Found by adversarial validation during the Lane D design audit (#2937), 2026-08-19.
plugins/work-items/skills/ship/SKILL.md:63 carries, under the heading "Through the seam (coordination verbs; no inline provider commands)":
"$TRACKER" get-item "<container-id>" # body = the spec
The comment is false against the seam contract. The normalized item object is schema_version, id, title, state, assignees, labels, type, blocked_by_count, parent_id, url (tools/work-item-tracker/CONTRACT.md, "JSON output contract") — there is no body field. The GitHub adapter confirms it: adapters/github/common.sh projects exactly those fields and requests --json number,title,state,assignees,labels,issueType,blockedBy,parent,url. --body exists only as a write parameter on create-item.
Consequence: a session following ship's own snippet to read the container spec gets no spec text, and the snippet's placement under a "no inline provider commands" heading implies the seam can do something it cannot. Reading an item body is a provider-mechanic operation per reference/tracker-seam.md (gh issue view --json body on GitHub; Jira REST), which that doc explicitly separates from seam verbs.
Shipped in #3010 (Lane Y). Note the same false premise was independently proposed in Lane D's first-draft design and caught by the same audit — worth fixing at the source so it stops propagating.
Fix
Correct the snippet and its surrounding prose: get-item for identity/state/parent_id (it IS authoritative for parent linkage), and a clearly-labelled provider-mechanic read for the body, with the non-GitHub degradation stated. Check plugins/work-items/skills/decompose/SKILL.md and plugins/planning/skills/plan/SKILL.md for the same assumption while in there.
Acceptance criteria
Found by adversarial validation during the Lane D design audit (#2937), 2026-08-19.
plugins/work-items/skills/ship/SKILL.md:63carries, under the heading "Through the seam (coordination verbs; no inline provider commands)":The comment is false against the seam contract. The normalized item object is
schema_version, id, title, state, assignees, labels, type, blocked_by_count, parent_id, url(tools/work-item-tracker/CONTRACT.md, "JSON output contract") — there is nobodyfield. The GitHub adapter confirms it:adapters/github/common.shprojects exactly those fields and requests--json number,title,state,assignees,labels,issueType,blockedBy,parent,url.--bodyexists only as a write parameter oncreate-item.Consequence: a session following ship's own snippet to read the container spec gets no spec text, and the snippet's placement under a "no inline provider commands" heading implies the seam can do something it cannot. Reading an item body is a provider-mechanic operation per
reference/tracker-seam.md(gh issue view --json bodyon GitHub; Jira REST), which that doc explicitly separates from seam verbs.Shipped in #3010 (Lane Y). Note the same false premise was independently proposed in Lane D's first-draft design and caught by the same audit — worth fixing at the source so it stops propagating.
Fix
Correct the snippet and its surrounding prose:
get-itemfor identity/state/parent_id(it IS authoritative for parent linkage), and a clearly-labelled provider-mechanic read for the body, with the non-GitHub degradation stated. Checkplugins/work-items/skills/decompose/SKILL.mdandplugins/planning/skills/plan/SKILL.mdfor the same assumption while in there.Acceptance criteria
work-itemsCHANGELOG entry (patch bump)