# Work Item

> Use when opening or rewriting a work item on any git-based SCM. Source-control agnostic; GitHub, GitLab, and Azure Boards are adapters only.

- Skill: `shafthq/work-item` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shafthq/work-item`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shafthq/work-item/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- License: MIT
- Author: shafthq (https://skillmd.com/u/shafthq)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shafthq/work-item

---


# Work item

Load this skill when the deliverable is **open or rewrite a work item**. Do not
vendor Spec Kit or create `.specify/`. Keep GitHub PR delivery on
`work-github-playbook.md`. One GitHub issue tracks the full plan. When the owner names a currently active PR, deliver the plan and the user-issue fix in that same PR.

Contract and adapters: [work-item.md](../../references/work-item.md).

## One item, one problem

One work item owns one actionable problem. Trackers list children; they do not
absorb them. Preserve existing acceptance when rewriting.

## Required Spec Kit sections

Every body must include:

- User Scenarios & Testing
- Edge Cases
- Functional Requirements
- Success Criteria
- Assumptions or Out of scope

Keep adopter template headings (for example bug or feature fields) so existing
validators still match.

When rewriting an existing item for Spec Kit hygiene, specialize User Story,
`FR-*`, and `SC-*` from that issue's own acceptance (see
`scripts.agents.issue_filing.rewrite_body_spec_kit`). Keep the shared heading
checklist; never paste the generic stamp `Deliver the stated acceptance` onto
unrelated tickets. Trackers may keep a campaign-level story.

## Taxonomy

Exactly one primary type, exactly one lifecycle, at least one subsystem or
module. Missing taxonomy fails closed with a named reason. Ready needs a proof
plan; blocked needs at least one https dependency URL.

## Adapter selection

Detect the live CLI from the adopter environment. Do not assume GitHub.
Command maps live in the adapters reference named from the contract. Live
create/edit remains whatever CLI the adopter already runs; dry-run and fake
runners prove the other maps.