work-item

Drafts work items with testable acceptance criteria for Jira, GitHub, Azure DevOps, and Linear.

Updated Apr 12, 2026
One-click install
npx skills add https://github.com/azborgonovo/ai-skills --skill work-item-azborgonovo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: work-item
Source: https://github.com/azborgonovo/ai-skills/tree/main/skills/planning/work-item
Command: npx skills add https://github.com/azborgonovo/ai-skills --skill work-item-azborgonovo

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes assets (resource) components.

What problem does it solve? Teams routinely file tickets, issues, and stories that lack context or testable acceptance criteria, forcing triagers and engineers to chase clarification. This Skill drafts well-formed work items with a consistent structure and observable acceptance criteria, and tightens existing items that are missing pieces. ## Core Features & Use Cases - Structured drafting: Produces work items with a framing section (Context, Observed Symptoms, or Steps to reproduce), optional Root cause or Plan, and mandatory testable acceptance criteria. - Standalone vs. child logic: Determines whether an item is standalone or a child of a parent, and only adds acceptance criteria to child items that are independently verifiable. - Tracker-agnostic creation: Creates or updates the item in whatever tracker is connected at runtime, such as Jira via MCP, GitHub via gh issue create, Azure DevOps, or Linear. - Use Case: A user says "log a bug for the 502 errors on the orders API" and receives a complete defect ticket with observed symptoms, impact, and acceptance criteria, ready to file in Jira. ## Quick Start Ask the assistant to draft a work item for the bug you just found, including acceptance criteria, and create it in your connected tracker.

Frequently Asked Questions about work-item

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a Jira ticket with good acceptance criteria?▼

Write each acceptance criterion as a testable, observable outcome such as "X no longer happens" or "Y is logged", never a vague statement like "works correctly". Pair the criteria with a framing section such as Context or Observed Symptoms so a triager understands the work on one read.

How do I create a GitHub issue from a bug description?▼

Describe the defect in one line and the Skill drafts a full issue with observed symptoms, impact, and acceptance criteria, then creates it through `gh issue create` when you explicitly ask. The same flow works for Jira, Azure DevOps, and Linear through their connected tools.

Does this work with trackers other than Jira?▼

Yes, the Skill is tracker-agnostic and defines content only. It works with Jira, GitHub, Azure DevOps, Linear, or any other tracker, picking whichever creation tool is connected in the current session.

When should a sub-task have its own acceptance criteria?▼

A child item needs its own acceptance criteria only when it can be verified independently, meaning its own deploy, test, and done state. A child item that is just a checklist entry under a parent whose criteria already cover it stays minimal.

When should I not use this for writing tasks?▼

Do not use it for general prose, PR descriptions, or commit messages, because those follow different conventions. It is scoped to tracker work items such as tickets, issues, stories, tasks, and bug reports.