Jira Syntax

Jira Syntax

Jira wiki markup syntax, templates, and validation. For API operations, use the jira-communication skill.

Quick Syntax Reference

See references/jira-syntax-quick-reference.md for complete syntax documentation.

Available Templates

Bug Report

Path: templates/bug-report-template.md

Sections: Environment, Steps to Reproduce, Expected/Actual Behavior, Error Messages, Technical Notes

Feature Request

Path: templates/feature-request-template.md

Sections: Overview, User Stories, Acceptance Criteria, Technical Approach, Success Metrics

Syntax Validation

Run before submitting to Jira:

${CLAUDE_SKILL_DIR}/scripts/validate-jira-syntax.sh path/to/content.txt

Validation Checklist

• [ ] Headings: h2. Title (space after period)
• [ ] Bold: *text* (single asterisk)
• [ ] Code blocks: {code:language}...{code}
• [ ] Lists: * for bullets, # for numbers
• [ ] Links: [label|url] or [PROJ-123]
• [ ] Tables: ||Header|| and |Cell|
• [ ] Colors: {color:red}text{color}
• [ ] Panels: {panel:title=X}...{panel}

Common Mistakes

Integration with jira-communication Skill

Workflow: 1. Get template from jira-syntax 2. Fill content using Jira wiki markup 3. Validate with ${CLAUDE_SKILL_DIR}/scripts/validate-jira-syntax.sh 4. Submit via jira-communication skill

References

• references/jira-syntax-quick-reference.md - Complete syntax documentation
• references/cross-project-refs.md - GitLab cross-project ref convention (group/project!N, group/project#N, group/project@tag) when linking to GitLab from Jira
• templates/bug-report-template.md - Bug report template
• templates/feature-request-template.md - Feature request template
• ${CLAUDE_SKILL_DIR}/scripts/validate-jira-syntax.sh - Automated syntax checker
• Official Jira Wiki Markup

<!-- Managed by agent: keep sections & order; edit content, not structure. Last updated: 2025-12-12 -->

AGENTS.md — jira-syntax

Development guide for maintaining templates, references, and validation scripts.

Overview

Static content skill: templates, reference docs, and a validation script. No runtime dependencies.

Setup & environment

No special setup. Files are plain text/markdown/shell.

Build & tests

# Test validation script
scripts/validate-jira-syntax.sh templates/bug-report-template.md

Code style & conventions

Templates (`templates/`):

• Use actual Jira wiki markup, never Markdown
• Include section comments explaining purpose
• Test in real Jira before committing

References (`references/`):

• Keep jira-syntax-quick-reference.md as single source of truth
• Examples must be copy-pasteable into Jira

Validation script:

• Bash with grep patterns
• Should catch common Markdown mistakes

Security & safety

• No executable code in templates
• No sensitive data in examples

PR/commit checklist

• [ ] All examples use valid Jira wiki markup
• [ ] Tested in actual Jira instance
• [ ] Updated quick-reference if adding new syntax
• [ ] Validation script catches the patterns

Good vs. bad examples

Template changes:

# ✓ Test paste into Jira before commit
# ✓ Update quick-reference if new syntax

# ✗ Assume Markdown works in Jira
# ✗ Add syntax without testing

When stuck

• Paste content into real Jira to verify rendering
• Check official docs: https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa

House rules

• SKILL.md has the user-facing syntax reference
• This file is for maintaining the skill itself

---

Maintaining this file: See root AGENTS.md for convention reference.

Cross-Project References to GitLab Resources

When referencing GitLab merge requests, issues, tags, or commits from a Jira description, comment, or worklog, prefer the GitLab cross-project autolink syntax — even though Jira itself doesn't autolink GitLab paths, the cross-project form removes ambiguity for human readers and matches the convention used in GitLab itself.

Convention

The same prefix characters (!, #, @) are what GitLab itself recognises for cross-project autolinks in markdown, commit messages, and MR descriptions — so a reader who pastes the reference into a GitLab UI will get a working link automatically.

In Jira wiki markup

Wrap the cross-project text inside the standard Jira link syntax [text|url]:

[jira/jira!25|https://git.netresearch.de/jira/jira/-/merge_requests/25]
[jira/jira@v9.12.3-2|https://git.netresearch.de/jira/jira/-/tags/v9.12.3-2]
[jira/jira#42|https://git.netresearch.de/jira/jira/-/issues/42]

Why not just !25?

A bare !25 in a Jira issue forces the reader to guess which GitLab project it lives in — and to click to find out. A bare v9.12.3-2 is even worse: tag names are reused across many repos.

When an issue references multiple repos in the same group (e.g. jira/jira for the image build and jira/app for the deploy stack), the cross-project form is essential — !3 could be either repo's MR.

Inside {{...}} monospace

!, #, and @ all work inside {{...}}, but *unescaped `{`, `}` and ` inside a {{...}} block break Jira's parser**: a raw { makes the whole block render as raw text, and a *` pair turns bold mid-token. Escape them with a backslash (verified against the Jira Server 9.12 wiki renderer).

Broken — the block falls apart on the raw {, and backup- renders bold:

{{compose.example.{yml,override.pga.yml}}}
{{jira-*backup-*}}

Correct — renders compose.example.{yml,override.pga.yml} and jira-*backup-* in monospace:

{{compose.example.\{yml,override.pga.yml\}}}
{{jira-\*backup-\*}}

Splitting into separate {{...}} references also works when escaping would hurt readability.

The validate-jira-syntax.sh script catches the brace collision.

Jira Wiki Markup Syntax - Quick Reference

Complete reference for Jira's wiki markup syntax to ensure proper formatting in tickets, comments, and descriptions.

Table of Contents

• Text Formatting
• Headings
• Lists
• Links
• Code Blocks
• Tables
• Panels and Quotes
• Colors
• Special Blocks
• Line Breaks and Horizontal Rules
• Special Characters
• Emoticons
• Common Patterns
• Validation Checklist
• Common Mistakes to Avoid

Text Formatting

Headings

h1. Heading Level 1 (largest)
h2. Heading Level 2
h3. Heading Level 3
h4. Heading Level 4
h5. Heading Level 5
h6. Heading Level 6 (smallest)

Rules:

• Space required after h1. through h6.
• One heading per line
• Use h2 for main sections, h3 for subsections

Lists

Bulleted Lists

* Level 1 item
** Level 2 nested item
*** Level 3 nested item
* Another level 1 item

Numbered Lists

# First item
## Nested item
## Another nested item
# Second item

Mixed Lists

# Numbered item
#* Nested bullet
#* Another bullet
# Another numbered item

Rules:

• Space after * or #
• Nesting uses additional symbols (**, ##)
• Can mix list types with combined syntax (#*)

Links

Code Blocks

Inline Code

Use {{code}} for inline monospace text

Code Blocks with Syntax Highlighting

{code:java}
public class Example {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}
{code}

Supported Languages (Jira Server / Data Center):

The Jira Server source-code formatter accepts ONLY this fixed list. Using any other identifier (e.g. typoscript, rust, typescript, yml, shell) produces:

Unable to find source-code formatter for language: <name>. Available languages are: ...

Notes:

• Use c# / c++ literally, not csharp / cplusplus (though cpp is also accepted).
• There is no typescript, rust, kotlin, dart, shell, yml, dockerfile, terraform, or typoscript formatter.
• For unsupported languages, fall back to {code:none} (or {noformat}) to preserve the block without highlighting.

{code:none}
[request && request.getNormalizedParams().getHttpHost() == "backend.example.de"]
page.meta.robots = noindex,noarchive
[END]
{code}

Preformatted Text (No Highlighting)

{noformat}
Plain text without syntax highlighting
Preserves whitespace and formatting
{noformat}

Block Tags Are Never Inline

{code}, {noformat}, {quote} and {panel} are block-level macros: the tag must stand alone on its own line. An unescaped tag inside a prose sentence opens a real block mid-line and swallows the rest of the line — the classic failure is writing about code blocks.

Broken — renders everything after "in" as an opened code block:

All commands are documented in {code} blocks with output.

Correct — renders the literal text {code}:

All commands are documented in \{code\} blocks with output.

Escape literal mentions of any block tag with backslashes: \{code\}, \{noformat\}, \{quote\}, \{panel\}. For inline monospace use {{...}}, never an inline {code} pair — even {code}one-liner{code} renders as a block, not inline.

scripts/validate-jira-syntax.sh flags inline block tags and unbalanced tag counts; run it on composed text before submitting to Jira.

Tables

Basic Table

||Header 1||Header 2||Header 3||
|Cell A1|Cell A2|Cell A3|
|Cell B1|Cell B2|Cell B3|

Rules:

• || for header cells (double pipe)
• | for regular cells (single pipe)
• Rows must have same number of cells
• No trailing pipe at end of row

Example with Content

||Feature||Status||Owner||Priority||
|User Login|{color:green}Complete{color}|[~john.doe]|High|
|Password Reset|{color:yellow}In Progress{color}|[~jane.smith]|Medium|
|2FA|{color:red}Not Started{color}|Unassigned|Low|

Panels and Quotes

Panel with Title and Background

{panel:title=Important Information|bgColor=#FFFFCE}
Content inside the panel
{panel}

Panel Parameters:

• title=text - Panel heading
• bgColor=#HEXCODE - Background color
• borderStyle=solid|dashed - Border style
• borderColor=#HEXCODE - Border color
• titleBGColor=#HEXCODE - Title background

Quote Block

{quote}
Multi-line quoted text
Can span multiple paragraphs
{quote}

Single Line Quote

bq. This is a block quote on one line

Colors

{color:red}Red text{color}
{color:blue}Blue text{color}
{color:green}Green text{color}
{color:#FF0000}Hex color text{color}

Named Colors:

• red, blue, green, yellow, orange, purple
• black, white, gray, grey
• Or use hex codes: #FF0000, #00FF00, #0000FF

Special Blocks

Notice/Info Panels

{panel:title=⚠️ Warning|bgColor=#FFEBE9|borderColor=#FF0000}
This is a warning message
{panel}

{panel:title=ℹ️ Information|bgColor=#DEEBFF|borderColor=#0052CC}
This is an info message
{panel}

{panel:title=✅ Success|bgColor=#E3FCEF|borderColor=#00875A}
This is a success message
{panel}

Expand/Collapse Section

{expand:title=Click to expand}
Hidden content that can be toggled
{expand}

Line Breaks and Horizontal Rules

Line 1\\
Line 2 (line break with \\)

First paragraph

Second paragraph (blank line creates new paragraph)

----
Horizontal rule (4 dashes)

Special Characters

--- (em-dash: —)
-- (en-dash: –)
\\ (line break)
\{escaped brace\}

To escape special characters, use backslash: \*, \{, \[.

• Only escape characters Jira actually parses as markup — *, _, -, +, ^, ~, {, [, |, \. Do not escape plain punctuation such as ., ,, or : — \. renders the backslash literally and produces the wrong output.
• Never escape inline monospace — {{text}} is not a macro, so \{\{text\}\} is wrong. Only escape the opening brace of a macro name shown as prose (e.g. \{code\}).
• Preserve existing backslash escapes — a source \*, \_, or \{ already suppresses Markdown markup; keep it as-is, because Jira uses the same \ escape mechanism for the same characters.

Common gotcha: macro names in prose

Writing a macro name literally in prose (e.g. "commands wrapped in \{code\} blocks") without escaping breaks rendering — Jira parses the literal as the start of a code-block macro and either consumes the rest of the comment or pairs with the next unrelated occurrence it finds. The same trap applies to any macro that opens and closes with the same token: {noformat}…{noformat}, {quote}…{quote}, {color}…{color}, {panel}…{panel}, {anchor}…{anchor}, and so on.

Three ways to write the literal token safely, in order of preference:

The backslash escape is the official Jira mechanism; the rephrase is editorial; the {{monospace}} wrap renders fine but is disliked by teams that reserve monospace for actual code spans rather than inline references.

A quick sanity check before posting: run skills/jira-syntax/scripts/validate-jira-syntax.sh <file> on your draft (from the repo root). The script verifies that the six paired macros (code, panel, color, noformat, quote, anchor) are balanced — every opener matches a closer, even with a language tag like {code:bash} — and catches Markdown leakage ( ` fences, [text](url) links, ` code ` spans), language declarations Jira Server does not recognise, and malformed table headers.

Emoticons

Common Patterns

Status Update Comment

h3. Status Update - 2025-11-06

h4. Completed
* Implemented user authentication
* Added unit tests (95% coverage)
* Updated documentation

h4. In Progress
* Integration testing
* Performance optimization

h4. Blocked
* Waiting for API key from [~admin]
* See [PROJ-123] for details

h4. Next Steps
# Deploy to staging environment
# Conduct security review
# Schedule production deployment

Code Review Comment

h3. Code Review Findings

h4. ✅ Approved Changes
* Clean separation of concerns
* Comprehensive error handling
* Well-documented functions

h4. 🔧 Suggestions
{code:java}
// Current implementation
public void processData(String input) {
    // Process directly
}

// Suggested improvement
public void processData(String input) {
    validateInput(input);  // Add validation
    // Process after validation
}
{code}

h4. ❌ Issues Found
* Missing null check on line 45
* Potential memory leak in {{DataProcessor}}
* Security vulnerability: [OWASP-A03|https://owasp.org/Top10/A03_2021-Injection/]

[~developer] Please address these before merging.

Meeting Notes

h2. Sprint Planning Meeting - 2025-11-06

h3. Attendees
* [~pm] - Product Manager
* [~tech-lead] - Technical Lead
* [~dev1], [~dev2], [~dev3] - Development Team

h3. Agenda
# Review last sprint outcomes
# Plan current sprint scope
# Assign tasks and estimates

h3. Decisions
||Decision||Owner||Action Items||
|Implement caching layer|[~tech-lead]|[PROJ-500] - Research Redis options|
|Upgrade to Node 20|[~dev1]|[PROJ-501] - Test compatibility|
|Refactor authentication|[~dev2]|[PROJ-502] - Design proposal needed|

h3. Action Items
# [~pm] - Update roadmap with Q1 priorities
# [~tech-lead] - Schedule architecture review
# [~dev1] - Provide effort estimates by Friday

h3. Next Meeting
*Date:* 2025-11-13 10:00 AM
*Focus:* Sprint retrospective

Validation Checklist

Before submitting, verify:

Headings

• [ ] Using h1. through h6. (not Markdown #)
• [ ] Space after period (h2. Title not h2.Title)
• [ ] One heading per line

Text Formatting

• [ ] *bold* not **bold**
• [ ] _italic_ not *italic*
• [ ] {{code}} not ` code `

Lists

• [ ] * for bullets, not -
• [ ] # for numbers
• [ ] Proper nesting (**, ## not spaces/tabs)

Code

• [ ] {code:language} not `` language ``
• [ ] Proper language identifier
• [ ] Closing {code} tag

Links

• [ ] [Label|url] not [Label](url)
• [ ] [PROJ-123] for issues
• [ ] [~username] for mentions

Tables

• [ ] || for headers
• [ ] | for cells
• [ ] Consistent column count

Colors

• [ ] {color:name}text{color} format
• [ ] Proper closing {color} tag

Panels

• [ ] Opening {panel:params}
• [ ] Closing {panel}
• [ ] Valid parameters

Common Mistakes to Avoid

Resources

• Official Jira Wiki Markup
• Jira Text Formatting
• JQL Reference

Jira Bug Report Template

Use this template when creating bug reports in Jira with proper wiki markup syntax.

Template

h2. Bug Description

[Provide a clear, concise description of the bug]

h3. Environment
* *Browser:* Chrome 120.0
* *OS:* Windows 11
* *Version:* 2.1.0
* *Environment:* Production

h3. Steps to Reproduce
# Navigate to [specific page/feature]
# Perform [specific action]
# Observe [unexpected behavior]

h3. Expected Behavior
[Describe what should happen]

h3. Actual Behavior
[Describe what actually happens]

{panel:title=Error Message|bgColor=#FFEBE9}
{code:java}
[Paste error message or stack trace here]
{code}
{panel}

h3. Additional Context
* Frequency: [Always/Sometimes/Rare]
* User Impact: [Critical/High/Medium/Low]
* Workaround Available: [Yes/No]

h3. Screenshots
[^screenshot1.png]
[^screenshot2.png]

h3. Related Issues
* Blocks [PROJ-XXX]
* Related to [PROJ-YYY]

h3. Technical Notes
{code:javascript}
// Code snippet showing the issue
function problematicCode() {
    // Details here
}
{code}

---
*Reported by:* [~username]
*Date:* YYYY-MM-DD

Example - Filled Template

h2. Bug Description

Login button becomes unresponsive after failed authentication attempt, requiring page refresh to retry.

h3. Environment
* *Browser:* Chrome 120.0.6099.109
* *OS:* Windows 11
* *Version:* 2.3.1
* *Environment:* Production

h3. Steps to Reproduce
# Navigate to {{/login}} page
# Enter invalid credentials
# Click *Login* button
# Observe error message
# Try to enter correct credentials
# Click *Login* button again
# Button remains disabled

h3. Expected Behavior
After a failed login attempt, the login button should become active again, allowing users to retry with different credentials.

h3. Actual Behavior
The login button remains in a disabled state after the first failed attempt. Users must refresh the page to attempt login again.

{panel:title=Error in Browser Console|bgColor=#FFEBE9}
{code:javascript}
TypeError: Cannot read property 'reset' of null
    at LoginForm.handleSubmit (login.js:45)
    at onClick (login.js:23)
{code}
{panel}

h3. Additional Context
* Frequency: Always (100% reproduction rate)
* User Impact: High (blocks login functionality)
* Workaround Available: Yes (page refresh)
* Affects ~1000 daily users based on error logs

h3. Screenshots
[^login-disabled-state.png] - Login button stuck in disabled state
[^console-error.png] - Browser console showing error

h3. Related Issues
* Blocks [PROJ-234] - User authentication improvements
* Related to [PROJ-189] - Form validation refactoring

h3. Technical Notes
{code:javascript}
// Problem in LoginForm component
handleSubmit(event) {
    event.preventDefault();
    this.setState({ isSubmitting: true });

    // Error occurs here if form ref is null
    this.formRef.reset();  // BUG: formRef can be null

    // Rest of submission logic
}
{code}

Suggested fix: Add null check before calling {{reset()}} method.

---
*Reported by:* [~john.smith]
*Date:* 2025-11-06

Usage with jira-communication Skill

# Create the bug report using the script
uv run scripts/workflow/jira-create.py issue PROJ \
  "Login button unresponsive after failed authentication" \
  --type Bug \
  --priority High \
  --labels frontend,authentication,ux \
  --description-file bug-description.txt

# Or with inline description (short version)
uv run scripts/workflow/jira-create.py issue PROJ \
  "Login button unresponsive after failed authentication" \
  --type Bug \
  --priority High

Checklist Before Submitting

• [ ] h2. heading for main Description section
• [ ] h3. headings for subsections
• [ ] Numbered list (#) for Steps to Reproduce
• [ ] Bulleted list (*) for Environment details
• [ ] \{panel\} for error messages with appropriate bgColor
• [ ] \{code:language\} for code snippets with correct language
• [ ] [^filename] format for attachment references
• [ ] [PROJ-XXX] format for issue links
• [ ] [~username] format for user mentions
• [ ] bold for emphasis on key terms
• [ ] {{monospace}} for UI elements and paths

Jira Feature Request Template

Use this template when creating feature requests in Jira with proper wiki markup syntax.

Template

h2. Feature Overview

[Provide a brief summary of the feature]

h3. Business Value
* *User Impact:* [Describe who benefits and how]
* *Business Goal:* [Align with strategic objectives]
* *Priority Justification:* [Why this should be prioritized]

h3. User Stories

h4. As a [user type]
* I want to [action]
* So that [benefit]

h4. As a [another user type]
* I want to [action]
* So that [benefit]

h3. Acceptance Criteria
# [Specific, testable criterion]
# [Specific, testable criterion]
# [Specific, testable criterion]

h3. Functional Requirements

h4. Must Have
* Requirement 1
* Requirement 2

h4. Should Have
* Requirement 3
* Requirement 4

h4. Could Have
* Requirement 5
* Requirement 6

h3. Non-Functional Requirements
* *Performance:* [Response time requirements]
* *Security:* [Security considerations]
* *Scalability:* [Scale requirements]
* *Accessibility:* [WCAG compliance level]

h3. Technical Considerations
{code:language}
// Pseudocode or technical notes
{code}

h3. UI/UX Mockups
[^wireframe-01.png] - Main interface mockup
[^user-flow.png] - User journey diagram

h3. Dependencies
* Requires [PROJ-XXX] to be completed first
* Impacts [PROJ-YYY] - needs coordination

h3. Open Questions
? Question 1 - needs clarification
? Question 2 - requires decision

h3. Success Metrics
||Metric||Target||Measurement Method||
|User Adoption|80% of active users|Analytics tracking|
|Performance|< 200ms response|Performance monitoring|
|Satisfaction|4.5/5 rating|User surveys|

---
*Requested by:* [~username]
*Stakeholders:* [~pm], [~designer], [~engineer]

Example - Filled Template

h2. Feature Overview

Implement bulk export functionality allowing users to export multiple projects to various formats (CSV, JSON, Excel) with customizable field selection.

h3. Business Value
* *User Impact:* 500+ power users currently export data manually one project at a time (30+ clicks per export)
* *Business Goal:* Reduce data export time by 90%, improving productivity and user satisfaction
* *Priority Justification:* #1 requested feature in Q4 2024 user survey (78% of respondents), competitive gap vs competitors

h3. User Stories

h4. As a Project Manager
* I want to export multiple projects at once with selected fields
* So that I can create consolidated reports without manual data entry

h4. As a Data Analyst
* I want to export historical project data in machine-readable formats
* So that I can perform advanced analytics in external tools

h4. As a Team Lead
* I want to schedule automated exports to run daily
* So that stakeholders receive up-to-date reports without manual intervention

h3. Acceptance Criteria
# User can select 1-100 projects for bulk export from project list
# Export supports CSV, JSON, and Excel formats
# User can customize which fields to include in export
# Export progress is shown with cancel option
# Completed exports are downloadable from exports history page
# Export file size limit is 50MB with pagination for larger datasets
# Exports are available for 30 days before auto-deletion

h3. Functional Requirements

h4. Must Have
* Multi-select checkbox interface for project selection
* Format selector (CSV, JSON, Excel)
* Field customization with drag-and-drop ordering
* Progress indicator during export generation
* Download link with expiration notice
* Export history page showing last 10 exports

h4. Should Have
* Search and filter for project selection
* Save field configurations as templates
* Email notification when export completes
* Preview sample data before full export

h4. Could Have
* Schedule recurring exports
* Share export links with team members
* Export directly to cloud storage (Google Drive, Dropbox)
* Advanced filtering within export data

h3. Non-Functional Requirements
* *Performance:* Export generation completes within 30 seconds for 50 projects
* *Security:* Exports encrypted at rest, only accessible to authorized users with audit trail
* *Scalability:* Support 1000 concurrent export requests
* *Accessibility:* WCAG 2.1 AA compliance for export interface
* *Browser Support:* Chrome 90+, Firefox 88+, Safari 14+, Edge 90+

h3. Technical Considerations
{code:python}
# Proposed export architecture
class BulkExporter:
    def export_projects(self, project_ids, format, fields):
        # Use async task queue for processing
        task = ExportTask.create(
            projects=project_ids,
            format=format,
            fields=fields,
            user=current_user
        )

        # Process in background
        celery.send_task('exports.process_bulk', args=[task.id])

        return task.id

    def get_export_status(self, task_id):
        # Return progress percentage and download link when complete
        return ExportTask.get(task_id).status
{code}

*Database Impact:* New {{exports}} table for tracking, ~1GB storage for 30-day retention
*API Endpoints:*
* {{POST /api/exports}} - Initiate export
* {{GET /api/exports/:id}} - Check status
* {{GET /api/exports/:id/download}} - Download file

h3. UI/UX Mockups
[^bulk-export-interface.png] - Main export dialog with project selection
[^field-customization.png] - Field selector with drag-and-drop ordering
[^export-progress.png] - Progress indicator during generation
[^export-history.png] - Export history page design

h3. Dependencies
* Requires [PROJ-456] - Background task queue infrastructure
* Impacts [PROJ-789] - Storage quota system (needs capacity planning)
* Coordinates with [PROJ-321] - API rate limiting (exports count as API calls)

h3. Open Questions
? Should exports include archived projects or only active ones?
? What permission level is required to export data? (View vs Export permission)
? Should we support incremental exports (only new/changed data)?
? How to handle very large exports exceeding 50MB limit?

h3. Success Metrics
||Metric||Target||Measurement Method||
|User Adoption|60% of power users within 3 months|Analytics event tracking|
|Time Savings|90% reduction in export time|User session timing comparison|
|User Satisfaction|4.5/5 feature rating|In-app feedback survey|
|Export Volume|5000+ exports per month|Export usage dashboard|
|Error Rate|< 1% failed exports|Error monitoring logs|

{panel:title=Launch Plan|bgColor=#DEEBFF}
h4. Phase 1 - Beta (Week 1-2)
* Release to 50 beta users
* Gather feedback and fix critical bugs

h4. Phase 2 - Limited Release (Week 3-4)
* Release to 20% of user base
* Monitor performance and error rates

h4. Phase 3 - Full Release (Week 5+)
* Release to all users
* Announce via email and in-app notifications
{panel}

---
*Requested by:* [~sarah.johnson]
*Stakeholders:* [~product.manager], [~ux.designer], [~backend.lead], [~frontend.lead]
*Estimated Effort:* 3 sprints (6 weeks)
*Target Release:* Q1 2025

Usage with jira-communication Skill

# Create the feature request using the script
uv run scripts/workflow/jira-create.py issue PROJ \
  "Bulk export functionality for multiple projects" \
  --type Story \
  --priority High \
  --labels feature-request,export,productivity \
  --description-file feature-description.txt

# Or with inline description (short version)
uv run scripts/workflow/jira-create.py issue PROJ \
  "Bulk export functionality for multiple projects" \
  --type Story \
  --priority High

Checklist Before Submitting

• [ ] h2. heading for Feature Overview
• [ ] h3. headings for all major sections
• [ ] h4. headings for User Stories and subsections
• [ ] Bulleted lists (*) for requirements and criteria
• [ ] Numbered lists (#) for Acceptance Criteria
• [ ] Tables (||header|| syntax) for Success Metrics
• [ ] \{code:language\} blocks for technical details
• [ ] \{panel\} for important launch/timeline information
• [ ] [^filename] for mockup/wireframe references
• [ ] [PROJ-XXX] format for dependency links
• [ ] [~username] format for stakeholder mentions
• [ ] bold for emphasis on metrics and targets
• [ ] {{monospace}} for technical terms and paths
• [ ] ? prefix for Open Questions