菜单
Triggers when the user says「批量修复」「批量 jira-fix」「jira-fix-batch」「批量修复多个 Jira」「批量修复以下 bug」/ batch fix, batch jira-fix. Orchestrates end-to-end fixes across multiple Jira issues.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Hard gate before merging into a protected branch: run Parts A→B→C→R→D (OpenSpec archive association, rebase/conflict pre-check, coverage preference, pr-code-review with optional light depth via pr-review-gate, tip-pin merge). Do NOT merge while an associated OpenSpec change is still active; do NOT skip on a direct "merge MR" command. Triggers — 「合并 tip」「merge tip」「合并纪律」「push 后合并」「archive 合入」「合并前门控」「rebase 检查」「冲突预检」「合并前 rebase」「先 archive 再 merge」「合并前 code-review」 / merge discipline, archive-before-merge, rebase pre-check, coverage gate, pr code review before merge.
Dual-axis (Standards∥Spec) multi-perspective PR review with confidence ≥80 filtering, severity calibration, plan alignment, and optional GitHub/GitLab review comment. Best-of: Claude /code-review pipeline + mattpocock dual-axis + Superpowers plan/severity habits. Triggers — 「PR 代码审查」「审查这个 PR」「code-review」「/code-review」「审 PR」「pull request review」「双轴审查 PR」 / pr code review, review this PR. Do NOT use as a name alias for mattpocock code-review or Superpowers requesting-code-review.
Optional code-delivery discipline: decide whether this run needs commit + PR/MR, then commit/push via git-commit and create or update the PR/MR. Use after verification (and OpenSpec archive when the host requires it) and before feature-branch-closeout. Do NOT use for protected-branch merge (merge-discipline) or release→main shipping (git-release-finish). Triggers — 「提交并开PR」「提交并开MR」「代码交付」「开PR」「开MR」「delivery-discipline」 / deliver code, commit and open PR, open merge request.
Post-verification feature-branch closeout menu: after verify (and archive when applicable), and after optional delivery-discipline when code delivery is needed, present PR / merge / keep / continue options; optional worktree cleanup; selecting merge MUST load merge-discipline Parts A→B→C→R→D; keep/continue MUST NOT trigger merge gates. Open/update PR delegates to delivery-discipline. Triggers — 「分支收尾」「feature 收尾菜单」「合入或保留分支」「branch closeout」 / feature branch closeout, post-verify branch menu. Do NOT use as a name alias for finishing-a-development-branch.
End-to-end Jira bug-fix workflow (stages 0-10), driven by a single Jira link, from intake through PR/MR merge and Jira writeback. Manual mode (default) pauses for confirmation between stages; auto/force modes run end-to-end. Triggers — 「修复这个 bug [URL]」「帮我修复 [URL]」「jira-fix [URL]」「自动修复 [URL]」「强制修复 [URL]」「继续修复」「从上次继续」 / fix this bug, jira-fix, auto fix, force fix, resume fix. Do NOT use for batch fixes across multiple issues — use jira-fix-batch instead.
OpenSpec-flavored end-to-end Jira bug-fix workflow that persists root cause, behavior change, fix plan, verification, and archive into OpenSpec artifacts (openspec/changes/<name>/, archived into openspec/specs/) instead of leaving them only in chat context or Jira comments. Use when a Jira issue needs long-term behavioral-contract traceability, team review, or auditability. Do NOT use for a quick fix needing no traceability — use jira-fix-workflow instead. Triggers：「opsx-jira-fix」「OpenSpec Jira 修复」「规范化修复 Jira」「opsx修复Jira」「Jira OpenSpec 修复」「opsx自动修复Jira」「用OpenSpec修复Jira」「opsx-jira-fix-workflow」 / opsx jira fix, OpenSpec Jira fix workflow.
| name | jira-fix-batch |
| version | 1.2.0 |
| user-invocable | true |
| category | development |
| tags | ["jira","batch","workflow"] |
| description | Triggers when the user says「批量修复」「批量 jira-fix」「jira-fix-batch」「批量修复多个 Jira」「批量修复以下 bug」/ batch fix, batch jira-fix. Orchestrates end-to-end fixes across multiple Jira issues. |
This skill owns batch orchestration rules. Per-issue end-to-end fix (stages 0–10) lives in
jira-fix-workflow. Responsibilities here: split issues into tasks, detect relationships, invokejira-fix-workflowin order, track batch progress.Activate only when the user explicitly requests a batch fix. Loading this skill MUST NOT start orchestration by itself.
When the user explicitly requests batch fix, the outer orchestrator picks a loop runner by platform-native capability (describe intent: “sequential loop over issues”). Do not hardcode platform-specific command names as required; prefer whatever loop/batch runner the current agent already has.
The orchestrator invokes jira-fix [URL] per issue. This skill does not run an internal loop itself.
jira-fix [URL] for each issue in order.Per-issue mode is set explicitly from the user’s batch-level intent. The child skill’s “auto reverts to manual” rule MUST NOT break batch continuity.
| Batch trigger | Orchestrator behavior | Child mode |
|---|---|---|
| Contains「自动」/ "auto" (e.g.「批量自动修复」) | Attach --auto or use auto-mode triggers on each child call | Auto |
| No「自动」/ "auto" (e.g.「批量修复」) | Do not attach --auto; use default triggers | Manual |
jira-fix-workflow need not know about batch context; “revert to manual after one round” stays consistent.Before serial execution, run a light relationship pass; after each issue, re-check remaining issues. Do not treat every issue as fully independent by default.
Record judgments in the batch progress doc (at least in notes: related issue, type, rationale).
At batch start, create a progress file (suggested: .jira-fix/batch-[YYYYMMDD-HHMM]/progress.md). Update on every status change; emit a final summary at the end.
Minimum fields:
| Field | Meaning |
|---|---|
| Issue | Jira ID or URL |
| Mode | Auto / Manual |
| Status | pending / in progress / done / skipped (duplicate) / waiting dependency / conflict pending / review failed (cap) / failed |
| Current stage | Stages 0–9, or not started / skipped |
| Result summary | Fix result, failure reason, or review summary |
| PR URL | When a PR exists |
| Notes | Related issues, relationship type, blockers, human asks |
If an issue’s solution-review loop hits the 3-round cap without pass: mark review failed (cap), skip later stages (do not enter stages 6/8/9), record the three-round review summary in the progress doc and final report, continue with the next issue.
Orchestrator start
└── Detect relationships (PROJ-001, PROJ-002, PROJ-003)
├── PROJ-001: jira-fix-workflow → done → update progress
├── PROJ-002: evaluate deps → jira-fix-workflow → done → update progress
└── PROJ-003: jira-fix-workflow → done → batch summary
Keep the progress doc updated throughout; when finished, print its path and the final summary.