JIRA Ticket Prioritizer

Analyze a set of JIRA tickets to determine optimal execution order based on dependencies, priority, and grouping. Produces grouped layers usable standalone or as a pre-step before implement /forge .

Inputs

Raw arguments: $ARGUMENTS

Infer from the arguments:

• TICKET_INPUT: comma-separated ticket keys OR a JQL query (detected by presence of = , AND , OR )

• EXTRA_CONTEXT: (optional) additional context for prioritization

System Requirements

• jira CLI installed and configured (https://github.com/ankitpokhrel/jira-cli)

• Environment variable JIRA_API_TOKEN set with a valid Jira API token. Important: When checking this variable, verify at least 2 times before concluding it is not set. Never expose the value — use existence checks only.

Execution

Step 1 — Parse Input

• Check if TICKET_INPUT contains = , AND , or OR (case-insensitive) to detect JQL

• If JQL detected: run jira issue list --jql "TICKET_INPUT" --plain --columns key,status --no-headers to resolve to ticket keys with statuses

• If comma-separated: split on , and trim whitespace

• Validate each key matches [A-Z]+-\d+

• If fewer than 2 valid tickets, report the single ticket and exit

Step 2 — Classify and Fetch All Tickets

• Create temp directory: mkdir -p .jira-ticket-prioritizer-tmp/tickets

• For each ticket key, fetch via jira CLI: jira issue view {KEY} --raw > .jira-ticket-prioritizer-tmp/tickets/{KEY}.json

• Parse each ticket using the jira-ticket-viewer parse script: node ${CLAUDE_SKILL_DIR}/../jira-ticket-viewer/scripts/parse-ticket.js < .jira-ticket-prioritizer-tmp/tickets/{KEY}.json > .jira-ticket-prioritizer-tmp/tickets/{KEY}-parsed.json

• Collect all parsed outputs into a single JSON array and write to .jira-ticket-prioritizer-tmp/all-tickets.json

• Classify tickets by status — fetch and parse ALL tickets, then split into two groups:

• pending = tickets with status "To Do" or "Backlog" — these will be scored, grouped, and placed in output layers

• context = tickets with any other status ("In Progress", "In Review", "Done", "Closed", "Resolved") — these are NOT placed in layers but are used for dependency resolution in Steps 3-5

Step 3 — Build Dependency Graph

• Run: node ${CLAUDE_SKILL_DIR}/scripts/build-dependency-graph.js < .jira-ticket-prioritizer-tmp/all-tickets.json > .jira-ticket-prioritizer-tmp/graph.json

• Review graph output for cycles or warnings

• See references/dependency-analysis.md for relationship mapping rules

• The graph includes ALL tickets (pending + context) so dependencies on in-progress/done tickets are visible

Step 4 — Semantic Dependency Analysis & Parent Ticket Evaluation

• Evaluate parent/container tickets and semantic dependencies per references/dependency-analysis.md

• Add soft edges with confidence levels (high/medium/low) to the graph

• Re-run topological sort if new edges were added:

• Update all-tickets.json with additional softEdges and re-run build-dependency-graph.js

Step 5 — Priority Scoring & Grouping

• Only score pending tickets — context tickets are not scored or placed in layers

• For tickets at the same dependency layer, score using weights from references/priority-weights.md

• Sort within each layer by descending score

• Apply EXTRA_CONTEXT context as a tiebreaker or boost

• Group related tickets within the same layer — see references/dependency-analysis.md Grouping Rules. First ticket in each group (highest score) is the primary ticket.

• Determine repo for each ticket (REQUIRED): read the ticket summary, description, components, labels, and linked issues, then use your judgment to infer which repository from the available repo list (absolute paths provided in EXTRA_CONTEXT ) this ticket belongs to. Output the repo basename only (e.g. "elements-backend" , not the full path). Every ticket MUST have a repo — use the best match based on the ticket context. If the ticket mentions frontend/UI/React/CSS, it likely belongs to the storefront. If it mentions API/backend/database/model, it likely belongs to the backend. If genuinely ambiguous, default to the first repo in the list.

• Determine branch for each ticket (REQUIRED): slugify the ticket key + summary into a branch name. Format: {ticket-key}-{slugified-title} — lowercase, replace spaces and special characters with hyphens, collapse consecutive hyphens, strip leading/trailing hyphens, truncate to 50 characters (e.g. "ec-123-fix-payment-bug" ). Every ticket MUST have a branch .

• Determine hasFrontend for each group: set to true if any ticket in the group involves frontend/UI work. Infer from ticket summary, description, components, and labels — look for signals like UI, frontend, React, CSS, component, page, layout, design, Figma links, .tsx /.jsx file mentions, or visual/browser-related keywords. Set to false only when all tickets in the group are clearly backend-only.

• Resolve cross-layer dependencies:

• If a pending ticket depends on a context ticket with status "Done"/"Closed"/"Resolved" → dependency is resolved, ticket proceeds normally

• If a pending ticket depends on a context ticket with any other status (e.g. "In Progress") → mark as skipped with reason including the dependency key and its status

• If a pending ticket depends on another pending ticket in a different layer → normal layering (layer N+1 depends on layer N)

• Tickets with status "Done"/"Closed"/"Resolved" → excluded

• Container/parent stories with no implementable work → excluded

Step 6 — Generate Output

• See references/output-format.md for report schema and JSON structure

• Write .jira-ticket-prioritizer-tmp/detailed-report.json — full details including scores, justifications, dependency graph, skipped tickets, excluded tickets, and warnings

• Write .jira-ticket-prioritizer-tmp/output.json — the grouped layers object with layers , skipped , and excluded arrays

• Present only output.json to the user. The detailed report is saved for reference but not displayed.

Reference Files

Name When to Read

references/priority-weights.md Step 5 — scoring rules and factor weights

references/output-format.md Step 6 — report template and JSON schema

references/dependency-analysis.md Steps 3-5 — dependency detection and grouping rules