AgentSkillsCN

jira-ticket-create

创建格式规范、字段齐全,并遵循 Jira 特定最佳实践的优质 Jira 工单的通用模式

SKILL.md
--- frontmatter
name: jira-ticket-create
description: Patterns for creating well-structured Jira tickets with proper formatting, fields, and Jira-specific best practices.

Jira Ticket Creation Skill

This skill provides patterns and templates for creating high-quality Jira tickets.

Jira Markup Format

Jira uses its own wiki markup, not Markdown:

Headings

code
h1. Heading 1
h2. Heading 2
h3. Heading 3

Text Formatting

code
*bold*
_italic_
-strikethrough-
+underline+
{{monospace}}

Lists

code
* Bullet point
** Nested bullet

# Numbered list
## Nested numbered

Code Blocks

code
{code:java}
// Code here
{code}

{code:javascript}
// JavaScript code
{code}

{noformat}
Plain text, no formatting
{noformat}

Links

code
[Link text|http://example.com]
[PROJ-123] - links to ticket

Tables

code
||Header 1||Header 2||Header 3||
|Cell 1|Cell 2|Cell 3|
|Cell 4|Cell 5|Cell 6|

Panels

code
{panel:title=Panel Title}
Panel content here
{panel}

{info}
Information callout
{info}

{warning}
Warning callout
{warning}

Ticket Templates

Bug Report Template

code
h2. Bug Summary
[One sentence description of the bug]

h2. Environment
* *Browser/OS*: [e.g., Chrome 120 / macOS]
* *Environment*: [Production/Staging/Development]
* *Version*: [App version if applicable]

h2. Steps to Reproduce
# Step 1
# Step 2
# Step 3

h2. Expected Behavior
[What should happen]

h2. Actual Behavior
[What actually happens]

h2. Screenshots/Logs
[Attach or describe]

h2. Additional Context
[Any other relevant information]

User Story Template

code
h2. User Story
*As a* [type of user]
*I want* [goal/desire]
*So that* [benefit/value]

h2. Context
[Background on why this is needed]

h2. Acceptance Criteria
* Given [context]
* When [action]
* Then [expected result]

h2. Out of Scope
* [What this story does NOT include]

h2. Technical Notes
* [Any technical considerations]
* [Related files or systems]

h2. Design
[Link to designs or describe UI requirements]

Technical Task Template

code
h2. Objective
[Clear statement of what needs to be done]

h2. Background
[Why this task is needed]

h2. Requirements
* Requirement 1
* Requirement 2
* Requirement 3

h2. Technical Approach
[High-level approach, not implementation details]

h2. Files to Modify
* {{path/to/file1.ts}}
* {{path/to/file2.ts}}

h2. Testing
* Unit tests: [What to test]
* Integration tests: [What to test]

h2. Definition of Done
* [ ] Code complete
* [ ] Tests passing
* [ ] Code reviewed
* [ ] Documentation updated

Epic Template

code
h2. Epic Overview
[High-level description of the initiative]

h2. Goals
* Goal 1
* Goal 2
* Goal 3

h2. Success Metrics
||Metric||Target||Current||
|[Metric 1]|[Target]|[Baseline]|
|[Metric 2]|[Target]|[Baseline]|

h2. Scope
h3. In Scope
* Feature 1
* Feature 2

h3. Out of Scope
* Feature X
* Feature Y

h2. Dependencies
* Dependency 1 [PROJ-XXX]
* Dependency 2

h2. Timeline
||Phase||Target Date||
|Design|[Date]|
|Development|[Date]|
|Testing|[Date]|
|Release|[Date]|

h2. Stories
[Link child stories here as they're created]

Field Guidelines

Summary (Title)

  • Keep under 80 characters
  • Be specific and action-oriented
  • Include relevant context
  • Avoid generic descriptions

Good: "Add email notification when order ships" Bad: "Email feature"

Priority

PriorityWhen to Use
BlockerSystem down, data loss
CriticalMajor feature broken
HighSignificant impact
MediumModerate impact
LowNice to have

Labels

  • Use existing labels when possible
  • Create new labels sparingly
  • Common labels: tech-debt, security, performance, documentation

Components

  • Assign all affected components
  • Helps with team routing
  • Enables better reporting

Story Points

PointsComplexity
1Trivial change
2Small, well-understood
3Medium, some unknowns
5Large, multiple parts
8Very large, significant unknowns
13Epic-sized, consider splitting

Best Practices

DO

  • Write for the implementer, not yourself
  • Include the "why" not just the "what"
  • Reference file paths, not code snippets
  • Link related tickets
  • Set appropriate priority
  • Add acceptance criteria

DON'T

  • Paste large code blocks
  • Use vague descriptions
  • Leave priority unset
  • Forget acceptance criteria
  • Create duplicate tickets
  • Over-specify implementation details

Jira API Patterns

Creating a Ticket

javascript
// POST /rest/api/3/issue
{
  "fields": {
    "project": { "key": "PROJ" },
    "issuetype": { "name": "Story" },
    "summary": "Add email notifications for shipped orders",
    "description": {
      "type": "doc",
      "version": 1,
      "content": [/* ADF content */]
    },
    "priority": { "name": "Medium" },
    "labels": ["notifications", "email"],
    "components": [{ "name": "Backend" }]
  }
}

Adding Comments

javascript
// POST /rest/api/3/issue/{issueKey}/comment
{
  "body": {
    "type": "doc",
    "version": 1,
    "content": [/* ADF content */]
  }
}

Note: Newer Jira API uses Atlassian Document Format (ADF) for rich text instead of wiki markup.