القائمة
Triggers when the user says「opsx 批量修复」「批量 opsx-jira-fix」「opsx-jira-fix-batch」「批量 OpenSpec Jira 修复」/ opsx batch fix, batch OpenSpec Jira fix. Orchestrates multi-issue end-to-end fixes and records relationship judgments in OpenSpec artifacts.
التثبيت باستخدام 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 | opsx-jira-fix-batch |
| version | 1.3.0 |
| user-invocable | true |
| category | development |
| tags | ["jira","openspec","batch","workflow"] |
| description | Triggers when the user says「opsx 批量修复」「批量 opsx-jira-fix」「opsx-jira-fix-batch」「批量 OpenSpec Jira 修复」/ opsx batch fix, batch OpenSpec Jira fix. Orchestrates multi-issue end-to-end fixes and records relationship judgments in OpenSpec artifacts. |
OpenSpec-flavored batch orchestration. Per-issue flow (stages 0–8) lives in
opsx-jira-fix-workflow. Responsibilities here: split issues, detect relationships, invokeopsx-jira-fix-workflowin order, and persist relationship judgments into OpenSpec artifacts.Activate only when the user explicitly requests a batch fix. Loading this skill MUST NOT start orchestration by itself.
Unlike plain
jira-fix-batch, relationship judgments MUST land in OpenSpec artifacts — not only in a temp progress file or chat context.
opsx-jira-fix-workflow stage 0), then confirm or create an independent OpenSpec change in that project. If several issues share one root cause and one project, they MAY reuse one change, but design.md MUST state coverage. Cross-project issues get separate changes and cross-link in each design.md.opsx-jira-fix-workflow per issue; do not skip OpenSpec recording, verification, or archive requirements of stages 0–8.Per-issue mode is set explicitly from batch-level user intent. Child “auto reverts to manual” MUST NOT break batch continuity.
| Batch trigger | Orchestrator behavior | Child mode |
|---|---|---|
| Contains「自动」/ "auto" (e.g.「opsx 批量自动修复」) | Attach --auto on each child call | Auto |
| No「自动」/ "auto" (e.g.「opsx 批量修复」) | Do not attach --auto | Manual |
opsx-jira-fix-workflow need not know batch context.Optionally note the mode used in each change’s design.md.
<change-name>”; do not open another fix PR.design.md, tasks.md, PR/MR diff, and verification evidence.design.md Risks/Dependencies; prefer serial handling.Write relationships into the corresponding design.md at least as:
## Related Issues
- <JIRA-ID>: duplicate / dependency / overlap / conflict / derived; conclusion; related PR/MR or OpenSpec change.
If the orchestrator also keeps a progress file, suggested statuses: pending / in progress / done / skipped (duplicate) / waiting dependency / conflict pending / review failed (cap) / failed.