Menu
Use when creating or drafting Jira/Atlassian tickets or issues, or when standardizing ticket output for a project
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when constructing or interpreting the approval handoff envelope between subagent and orchestrator -- sealed_payload schema, approval_id format, APPROVAL_REQUEST contract shape, and reading a granted approval from the DB
Use when producing any agent response
Use when classifying any operation before executing it, or deciding whether user approval is required
Use when a mutative command was blocked by the hook and you need to request user approval, or when presenting a plan for a T3 operation before executing it
Use when the user wants to build, design, or extend a diagram — an architecture overview, a timeline, a planner board, a flow diagram, a presentation, a comparison, or a mind-map — as a portable, data-driven deck rendered from plain YAML. Triggers — "build a diagram", "architecture diagram", "diagram deck", "timeline", "flow diagram", "planner board", "add a page/section/component to the diagram".
Use when the user wants something to run routinely / on a schedule rather than once now -- "tarea programada", "rutinariamente", "cada mañana", "cada N horas", "todas las noches", "schedule", "cron". Covers mounting, structuring, and running an unattended headless task that reports back, plus consuming its reports. NOT for a live in-session agentic loop (that is agentic-loop).
| name | jira-ticket-writing |
| description | Use when creating or drafting Jira/Atlassian tickets or issues, or when standardizing ticket output for a project |
| metadata | {"user-invocable":true,"type":"technique"} |
The formula for tickets humans can read in ~15 seconds. The what and why go at the top; the how and evidence go in a comment. One Story per brief or theme; consolidate rather than inflate.
A Story is readable by a non-technical stakeholder in 15 seconds. This means: plain English, active voice, value-oriented title, high-level description. All implementation detail and verification evidence lands in the first comment -- never in the description -- so the description reads clean.
Title: verb + outcome, plain English, no jargon, 80 chars max.
Description fields:
| Field | Content |
|---|---|
| Objective | 1-2 sentences: what it achieves and why (high level). |
| What it covers | 3-5 bullets of scope -- what, not how. |
| Acceptance criteria | Checklist "Done when..." -- verifiable, not vague. |
| Links | Brief slug / repo if applicable. |
Evidence -- first comment only, never in description: commit hashes, verbatim commands, anything reproducible.
Title: short action phrase, plain English. Description: one line -- what it is / done when X.
Map to a brief or theme. One Story = one brief or coherent chunk of work. If the work spans multiple unrelated concerns, split into separate Stories. If it is one theme with sequential steps, use Subtasks.
Write the title last. Draft the Objective and What-it-covers first; the title compresses naturally from those. If the title needs jargon to be precise, the description is missing context.
Write the Acceptance Criteria as done-when checks. Each AC is a checkbox that a person (not a CI system) can verify. Vague ACs get pushed back: "migrated" means what? "History intact" means no commit lost.
Move all evidence to the first comment. After the ticket is created, post a comment with: commit hashes, commands run verbatim, output snippets. This keeps the description clean for stakeholders and the evidence auditable for engineers.
Adapt to the project's board conventions. Do not create Epics if the team does not use them. Respect the active Sprint. Use existing Labels and Components, not invented ones. Check 2-3 existing tickets before creating the first one.
Consolidate, do not inflate. Prefer fewer well-scoped tickets over many granular ones. If two Subtasks share all context, make one Subtask. If a Story has one Subtask, fold the Subtask into the Story.
See examples.md for real tickets from the AOS migration project.
