Token导航 LogoToken导航TokenDH.com
前端设计敏感数据github未标认证来源可访问许可证需确认审计提醒

jira-ticket-prioritizerJira ticket prioritizer 前端

Agent Skill

用于处理 Jira 项目、任务、缺陷、Sprint、负责人和状态流转。它适合让 Agent 辅助查询工单、汇总迭代进展、创建任务或整理需求和缺陷信息。使用时要确认项目权限、字段配置和工作流规则,不同团队的 Issue 类型、状态和必填字段可能不同;涉及批量改状态、改负责人或创建工单时,应先预览变更内容再执行。

总安装

1,042

周安装

43

GitHub Stars

1

下载量

341
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:jira-ticket-prioritizer(Jira ticket prioritizer 前端)
来源仓库:https://github.com/delexw/claude-code-misc
仓库路径:skills/jira-ticket-prioritizer
安装命令:
npx skills add https://github.com/delexw/claude-code-misc --skill jira-ticket-prioritizer
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/delexw/claude-code-misc --skill jira-ticket-prioritizer

简介

用于处理 Jira 项目、任务、缺陷、Sprint、负责人和状态流转。

  • 适合辅助查询工单、汇总迭代进展、创建任务或整理需求和缺陷信息。
  • 使用时需确认项目权限、字段配置和工作流规则,不同团队配置可能不同。
  • 涉及批量改状态、改负责人或创建工单时,应先预览变更内容再执行。
  • 安装方式:github,支持 Codex、Claude、Cursor、Gemini CLI。

SKILL.md

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 4b — Redundancy Detection

  • Read references/redundancy-analysis.md for the full detection rules
  • Look at every pair of pending tickets and assess how much their scope overlaps — consider their summaries, descriptions, components, labels, ticket type, and any explicit JIRA duplicate links
  • For each pair, form a judgment on how likely they are to describe the same work: assign a weight (how much overlap) and a confidence level (how certain you are)
  • When two tickets clearly overlap, decide which one is the primary — prefer the higher-scoring ticket, or the lower-numbered one if scores are equal
  • When the overlap is strong enough to act on (high confidence, or medium confidence with substantial weight), pull the secondary ticket out of the pending set and put it in skipped. Write a plain-English reason that explains exactly what was found — which fields overlapped, what the textual similarity was, and why you concluded one ticket's scope is covered by the other. See references/redundancy-analysis.md for evidence string guidelines
  • When the overlap is weaker (low confidence, or medium confidence with low weight), treat the tickets as independent — leave both in the layers and do not flag them
  • Tickets moved to skipped here must not appear in the scoring or grouping steps below

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.
  • 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 5a — Repo Assignment

Read references/repo-assignment.md for the full rules. Determine repos, branch, complexity, and hasFrontend for every ticket per those rules.

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.

Step 7 — Cleanup

  • Remove the temp directory: rm -rf.jira-ticket-prioritizer-tmp

Reference Files

NameWhen to Read
references/priority-weights.mdStep 5 — scoring rules and factor weights
references/output-format.mdStep 6 — report template and JSON schema
references/dependency-analysis.mdSteps 3-5 — dependency detection and grouping rules
references/redundancy-analysis.mdStep 4b — redundancy detection, weight/confidence rules, skipped entry format
references/repo-assignment.mdStep 5a — repo understanding, assignment rules, branch/complexity/hasFrontend

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

38.21%
按下载量换算130

Claude

28.66%
按下载量换算98

Cursor

21.85%
按下载量换算75

Gemini CLI

9.07%
按下载量换算31

安全审计

Gen Agent Trust Hub

可疑

Socket

通过

Snyk

可疑

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills