shafthq 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.
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.