Agent skill
jira-syntax
Use when writing Jira issue descriptions, comments, or work logs. Also use when converting Markdown to Jira wiki markup, when the user says "format for Jira", "Jira markup", "wiki notation", or asks to create, update, or validate Jira ticket content. Handles bug report and feature request templates. Do NOT use for Jira API operations, JQL queries, or workflow transitions.
Install this agent skill to your Project
npx add-skill https://github.com/sortie-ai/sortie/tree/main/.github/skills/jira-syntax
Metadata
Additional technical details for this skill
- version
- 1775952000
SKILL.md
Jira wiki markup
Jira uses its own wiki notation that differs from Markdown in every formatting construct. Agents default to Markdown. Mixing the two produces broken rendering in Jira. This skill ensures correct output.
Markdown-to-Jira conversion table
These substitutions are mandatory when targeting Jira:
| Concept | Jira wiki markup | NOT Markdown |
|---|---|---|
| Heading | h2. Title |
## Title |
| Bold | *bold* |
**bold** |
| Italic | _italic_ |
*italic* |
| Inline code | {{code}} |
`code` |
| Code block | {code:java}...{code} |
```java ``` |
| Link | [text|url] |
[text](url) |
| Issue link | [PROJ-123] |
n/a |
| User mention | [~username] |
@username |
| Bullet list | * item |
- item |
| Numbered list | # item |
1. item |
| Table header | ||Header|| |
|Header| |
Read references/syntax-reference.md for the complete notation including panels, colors, nested lists, and special blocks.
Conversion examples
Example 1 (bug comment with code):
Input (Markdown):
## Root cause
The `processData()` function throws when **input is null**.
- Missing null check on line 45
- Related: see issue #123
Output (Jira wiki markup):
h2. Root cause
The {{processData()}} function throws when *input is null*.
* Missing null check on line 45
* Related: see [PROJ-123]
Example 2 (status update with table):
Input (Markdown):
### Sprint progress
| Task | Status | Owner |
|------|--------|-------|
| Auth module | Done | @john |
| API docs | In progress | @jane |
Output (Jira wiki markup):
h3. Sprint progress
||Task||Status||Owner||
|Auth module|{color:green}Done{color}|[~john]|
|API docs|{color:yellow}In progress{color}|[~jane]|
Workflow
Step 1: Determine content type
Choose the appropriate template based on the task:
- Bug report — read
assets/bug-report.md - Feature request — read
assets/feature-request.md - Free-form content — write directly using the conversion table and examples above
Step 2: Write content in Jira wiki markup
Apply these rules:
- Use
h2.for top-level sections,h3.for subsections. Always include a space after the period becauseh2.Titlefails to render. - Use
*for bullet lists and#for numbered lists. Nest with repeated symbols (**,##,#*), not indentation. - Wrap code in
{code:language}...{code}. Always specify the language because bare{code}blocks lose syntax highlighting. - Use
{{text}}for inline code, paths, and UI element names. - Use
[text|url]for labeled links. Use[PROJ-123]for issue references,[~username]for mentions. - Use
||for table headers and|for data cells. Keep column counts consistent per row. - Use
{panel:title=X}...{panel}for callout boxes. Use{color:red}text{color}for colored text. - Close every block macro (
{code},{panel},{color},{quote},{expand},{noformat}).
Step 3: Validate
Run the validation script against the content file:
sh scripts/validate-jira-syntax.sh <file>
The script checks for Markdown syntax used where Jira markup is expected, unclosed block macros, headings missing the space after the period, and code blocks without a language identifier.
If the script is unavailable, verify manually:
- No Markdown headings (
##), bold (**), or backtick code blocks - All
{code},{panel},{color}blocks are closed - Headings have a space after the period (
h2. Title) - Code blocks specify a language (
{code:python}) - Links use pipe syntax (
[label|url]) - Lists use
*for bullets and#for numbers
Step 4: Submit
Pass the validated content to the Jira API or paste it into the Jira editor. If an MCP tool or jira-communication skill is available, use it for submission. This skill handles syntax only.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
managing-adrs
Create, update, and validate Architecture Decision Records (ADRs) following MADR 4.0 format. Use when the user mentions ADR, architecture decision, decision record, or asks to document a technical decision. Also use when creating new files in docs/decisions/. Handles numbering, frontmatter, section structure, and README index updates. Do NOT use for general documentation or non-architectural decisions.
context-files
Create or validate project context files (AGENTS.md, CLAUDE.md, GEMINI.md). Use when bootstrapping a new project, initializing agent configuration, writing a context file, or when asked to create, review, audit, or validate an existing context file. Handles codebase archaeology, user interviews, golden-rule validation, and platform-specific formatting. Do NOT use for creating Agent Skills (use creating-agent-skills instead) or .instructions.md files (use agent-customization instead).
creating-agent-skills
Use when creating, improving, comparing, evaluating or packaging Agent Skills following the agentskills.io specification. Also use when deciding whether a skill is the right solution vs MCP servers, custom instructions, AGENTS.md, or Cursor Rules. Handles SKILL.md authoring, frontmatter optimization, description writing, progressive disclosure, cross-platform compatibility, and distribution.
git-commit
Use when asked to commit, save, or persist changes to Git. Handles atomic commits, branch safety, Conventional Commits format, and project style matching. Do NOT use for pushing, creating PRs, or branch management beyond safety checks.
diataxis-documentation
Create, edit, and validate technical documentation using the Diataxis framework. Use when writing tutorials, how-to guides, reference docs, or explanations. Use when reviewing or auditing existing documentation for structural correctness. Use when deciding what type of document to write. Also use when the user mentions Diataxis, documentation quality, documentation types, or asks to write 'deep dive' articles, onboarding guides, API docs, or architectural explanations. Do NOT use for code comments, commit messages, changelogs, or README generation.
managing-github-issues
Create, edit, search, close, and triage GitHub issues for this project using gh CLI. Use when asked to file a bug, request a feature, create a task, report a problem, search the backlog, triage issues, or manage the issue tracker. Also use when the user says "create an issue", "file a bug", "open a ticket", "add to backlog", "search issues", "close issue", or mentions GitHub Issues in any task-management context. Handles label/milestone assignment, duplicate detection, and project board integration. Do NOT use for pull requests (use creating-pr) or changelog entries (use changelog-maintenance).
Didn't find tool you were looking for?