القائمة
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.