jira-priority
Use when classifying the priority of a Jira issue or creating a Jira issue with the correct priority assigned.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when classifying the priority of a Jira issue or creating a Jira issue with the correct priority assigned.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when changing what a running devloop harness serves — pointing it at a different directory or worktree, or making the live harness serve newer or different code (a newer commit, another branch, or in-progress edits) without a wasteful restart.
Use when verifying that a UI change works end to end by driving the running app in a real browser — confirming a fix, reproducing a reported UI symptom, or proving a wizard/form/flow behaves — with Playwright against the exact code under review.
Enforce a Roborev plus Kata development workflow for code changes. Use when Codex is asked to implement, fix, refactor, or review work tracked by Kata and Roborev, especially when branch discipline, non-blocking review jobs, validation gates, SemVer, changelog checks, and final delivery reporting matter.
Use when working on GitHub pull requests that need PR-ready validation, review-thread replies, reviewer mentions, linked external references, or merge readiness checks.
Create or review a standalone repository that publishes a set of Codex or Claude skills with shared validation, linking, eval, and agent metadata conventions.
Prepare small, reviewable local commits with explicit rationale, SemVer impact, task hygiene, branch cleanup expectations, and clear commit commentary. Use when asked to commit work, prepare a PR-ready change, decide version impact, write commit messages, or clean up merged feature branches.
| name | jira-priority |
| description | Use when classifying the priority of a Jira issue or creating a Jira issue with the correct priority assigned. |
Classify the priority of a Jira issue using the scheme below. When asked to create the issue, use the Jira tool with the classified priority.
"Customer" means one tenant or organisation, not one individual user within it. "Blocked on all their work" means the customer cannot use any feature of the platform. "Blocked on part of their work" means one or more features are broken while others still work. Base priority is based on the broken functionality's scope — a customer is blocked on part of their work when a feature they use is broken, regardless of whether a workaround exists. Workarounds affect only the escalation rules, not the base classification. Each escalation rule raises the priority by exactly one level.
When assessing scope, consider what the customer's users can currently do — not what a workaround or technical intervention could restore. If every feature of the platform is inaccessible to the customer's users, they are blocked on all their work, even if a support action or admin procedure could fix it.
| Priority | Condition |
|---|---|
| Lowest | Cosmetic defect — orthography or screen positioning — that does not prevent use |
| Low | One customer blocked on part of their work |
| Medium | One customer blocked on all their work, OR many customers blocked on part of their work |
| High | Many customers blocked on all their work, but not a complete outage |
| Highest | Complete outage — no customer can do any work — OR a data or secret leak |
After setting the base priority, apply each rule independently. Each satisfied rule raises the priority one level. Rules only raise; they never lower the base. Cap at Highest. When the base priority is already Highest, escalation rules do not change the result.
Always respond in this exact order: