Imported from YueZhaoDreams/PokemonSimulator (.cursor/skills/fix-jira-issue/SKILL.md). Install upstream with npx skills add YueZhaoDreams/PokemonSimulator --skill fix-jira-issue. Copyright stays with the author.

Fix Jira Issue

Generated by Harmonia for YueZhaoDreams/PokemonSimulator from fix-jira-issue@1.8.1.

Repo Context

• configuredRepo: YueZhaoDreams/PokemonSimulator
• defaultBaseBranch: main
• language: python
• purpose: family Pokémon TCG simulator with scan, chat, Monte Carlo lab, and printed-card-text engine
• repoId: YueZhaoDreams/PokemonSimulator
• repoName: PokemonSimulator
• service: family-cup-simulator

Instructions

fix-jira-issue

This is the orchestrator skill. Do not treat it as a standalone worker.

Invocation:

• The Jira issue key is optional. Harmonia-automated runs always supply one.
• Manual use: /fix-jira-issue PROJ-123 when working a ticket, or /fix-jira-issue <task description> with no key.
• When no key is provided, treat the remainder of the user message as the task description and skip Jira fetch and comment steps unless a key becomes available later.

Execution flow:

1. Verify the required repo-specific skills are already installed and current before issue work begins. Do not run install-harmonia-skills, regenerate .cursor/skills/**, or touch the .codex/skills symlink as part of a product issue branch; that bootstrap happens in a separate process before issue resolution starts.
2. Switch back to the repository base branch before creating or refreshing any issue branch. Use main (defaultBaseBranch in generated skill metadata / .harmonia/repo.json context). Fetch/reset it from origin, and stop if the working tree is not clean. After reset, create or check out a dedicated issue branch (harmonia/<short-slug> or chore/<short-slug>) from main before compile-test-fix-loop. Never apply the fix on the base branch. Do not use a local master branch even if one exists.
3. Prepare the environment with setup-env when required.
4. Understand the issue context. When a Jira issue key is available, load Jira details first. When no key was provided, use the user request, repo state, and recent history as the source of truth.
5. Apply the fix using compile-test-fix-loop.
6. Run post-due-diligence after the fix loop completes so repo-specific checks happen against the final implementation.
7. Re-run validation and summarize outcomes, risks, and follow-up items.
8. Local review loop (before push): Before submitting or refreshing the PR, run local code review on the current branch diff using the local Bugbot workflow for the active agent surface: Cursor /review-bugbot with branch changes, or Codex bugbot subagent with Diff: branch changes. Do not push until this loop completes cleanly on the latest diff or you document a concrete blocker.

In Codex, launch exactly one bugbot subagent with readonly: true, run_in_background: false, description: "Bugbot", and subagent_type: "bugbot". In Cursor, invoke /review-bugbot for branch changes. Use this prompt shape:

Full Repository Path: <absolute repository path>
Diff: branch changes

After Bugbot finishes, summarize findings (one-line status when clean; severity table when issues exist). Apply valid actionable findings that apply to the current diff and align with the issue scope; ignore findings that are out of scope, stylistic-only when repo policy disagrees, or pre-existing on the base branch. Document ignored findings briefly.

When fixes are applied, re-run compile-test-fix-loop and post-due-diligence, then repeat this local review step on the updated diff. Continue until Bugbot reports no actionable issues on the current diff or you document a blocker (repeated subagent failure, structural refactor needed — raise follow-up Jira issue instead of pushing a partial fix).

Session checkpoint: Completing compile-test-fix-loop and post-due-diligence is not permission to push yet — continue into this local review loop in the same session before PR submission. 9. Once the fix is ready, submit or refresh the PR automatically as part of this workflow. Do not wait for a separate human request to open the PR, request review, or continue the merge path. 10. PR closure loop (mandatory, long-running): Do not end this session or send a final user response until the PR is merged or you document a concrete blocker. After the PR is opened or updated, do not hand off to the human while the PR remains open and mergeable work may remain. Operate as a long-running agent until the PR is merged or a concrete blocker is documented (policy, failing checks that cannot be fixed, structural refactor follow-up). Treat this step as the continuation of the same session — not a follow-up task for the user to request later.

Copilot review signals (do not conflate):

MCP 404 on the request path does not satisfy completion. It only documents that the request API failed; polling must continue on the completion path.

Read .harmonia/repo.json pr_closure overrides when present (copilot_required, copilot_min_polls, copilot_poll_interval_seconds, copilot_min_wait_after_push_minutes; defaults: copilot_required false/omitted so Copilot is skippable after the wait budget — set pr_closure.copilot_required true to forbid skip, min polls 8, interval 90s, min wait 10 min after last push).

Request GitHub Copilot review by default (request_copilot_review MCP, else gh). Log the request outcome (success or MCP error text). Poll with gh pr checks, gh pr view, and GitHub MCP pull_request_read (get_reviews, get_review_comments) plus raw gh api repos/<owner>/<repo>/issues/<n>/comments for PR conversation comments — sleep 60–120 seconds between polls (or repo-configured interval) and retry until checks and reviews reach a terminal state. Distinguish pending review request from completed review on the current headRefOid. Wait until a fresh Copilot review for the current PR head completes on the completion path before treating silence as success; do not exit early because Copilot is slow. When actionable review comments, CI failures, or merge conflicts remain (Copilot, human, bot, or conflict resolution), apply valid fixes (document ignored/out-of-scope items), then run compile-test-fix-loop and post-due-diligence, then repeat the local Bugbot review loop (same contract as the pre-push local review step) on the updated branch diff. Do not push until that local review loop is clean on the latest diff or you document a concrete blocker. Then push fixes, refresh the PR, re-request Copilot review, and restart the Copilot wait loop from poll 1. Do not tell the user you are done while checks are pending/in_progress or actionable review comments remain. Use the babysit skill workflow when helpful for triage and polling, but do not delegate the loop to the human and do not let babysit bypass the orchestrator's compile-test-fix-loop → post-due-diligence → Bugbot gate before push. 11. Keep the PR description detailed and current. Include the Jira context, a concrete root-cause explanation, the implementation summary, and the validation performed so reviewers can understand why the change exists. 12. Pre-merge checklist (gate): Before gh pr merge, verify all of: [ ] headRefOid recorded, [ ] Copilot review for that SHA exists on the completion path or documented skip per the narrow Copilot skip rule, [ ] no actionable review threads on the current diff (Bugbot/Copilot/human), [ ] required CI green or repo has no checks (explicitly noted), [ ] mergeable == MERGEABLE. Do not merge until every item passes or is explicitly documented as N/A with rationale. 13. When the pre-merge checklist passes, merge the PR in this session (gh pr merge or GitHub MCP merge_pull_request) if policy allows. If checks are still running, keep polling in this session — enable auto-merge when supported and wait until merge completes rather than exiting. Only stop with an open PR when you document the exact blocker (check name, failing command, policy rule). Never exit immediately after push because Copilot or Bugbot is merely pending. 14. If the issue cannot be resolved safely because the code needs structural cleanup, stop and raise a follow-up Jira issue for refactoring instead of attempting a refactor inside this workflow. 15. When a Jira issue key is available, add a Jira comment on the issue summarizing progress and the final outcome (merged PR, open PR, blocked, validation failure, or refactor follow-up) so the ticket reflects what happened. Skip this step when no key was provided.

Rules:

• Explicitly reference dependencies instead of assuming they already exist.
• Keep the orchestration summary visible in the final output.
• Stop and surface blockers when prerequisite skills are missing or invalid.
• When creating a refactor follow-up, include the failed validation evidence and why it should be a separate Jira issue.
• Post the Jira progress comment only when an issue key is available (Harmonia runs always have one). Skip Jira writes when no ticket is linked unless the user later supplies a key or this is an explicit dry-run with no Jira writes.
• Local review gate: Do not open or refresh the PR until the local review loop completes with no actionable findings on the current branch diff, or you document a concrete blocker (subagent failure, structural refactor needed).
• Default reviewer: Run Bugbot locally during orchestrator runs (fix-jira-issue, fix-feature). In Cursor, use the /review-bugbot workflow. In Codex, launch the bugbot subagent against Diff: branch changes. Do not ask the user to choose during Harmonia-automated issue resolution. Manual invocations may use /review to pick Bugbot or Security Review when the operator explicitly wants that choice before push.
• Fix and re-validate: Apply valid actionable findings (from Bugbot, Copilot, human review, CI failures, or merge conflict resolution), then re-run compile-test-fix-loop and post-due-diligence before re-reviewing. Any code change — including post-PR review feedback — restarts the local review loop from Bugbot step 1.
• Forbidden early push: Pushing or opening the PR while actionable local review findings remain unresolved is a workflow violation unless documented as out-of-scope or blocked by tooling.
• Forbidden early push after review feedback: Pushing Copilot, human, CI, or conflict-resolution fixes without compile-test-fix-loop + post-due-diligence + a clean local Bugbot pass on the latest diff is a workflow violation (same gate as pre-PR push).
• Audit trail: Log each local review pass (pass number, finding count, fixes applied) before proceeding to PR submission.
• Session completion: Do not send a final response to the user until the PR is merged or you document a concrete blocker (policy, failing check, tooling failure). Creating or updating the PR is never the terminal step.
• Forbidden handoff: Summarizing implementation and ending the session while the PR remains open — checks pending/in_progress, Copilot review incomplete for the current head, or actionable review comments unresolved — is a workflow violation.
• Forbidden early merge: Merging because request_copilot_review returned 404, because Bugbot was silent, or because no CI checks exist — without a completed copilot-pull-request-reviewer[bot] review on headRefOid or a documented skip that meets the wait budget below.
• User no-merge preference: If the user asks you not to merge, that is a merge policy blocker only after the PR is merge-ready (required checks green, fresh Copilot/Bugbot review addressed for the current head). It does not permit skipping the review poll loop or popping out while checks or bot reviews are still pending.
• Treat Copilot comments as valid when they are actionable, apply to the current diff, and do not conflict with the request or repo policy; document comments ignored as invalid or out of scope.
• Do not merge or enable auto-merge solely because no comments have appeared; require evidence that Copilot review completed for the current PR head (commit_id == headRefOid).
• Re-push invalidates Copilot: Any new commit to the PR branch invalidates prior Copilot reviews for merge purposes. After push, restart the Copilot wait loop from poll 1.
• Long-running agent: The orchestrator session includes the full PR closure loop. Do not stop after creating the PR, after requesting review, or because a bot is still pending — poll until merge or a documented blocker.
• After requesting Copilot review, do not stop polling just because GitHub has not shown the review yet; wait until a fresh review for the current head appears and completes, or document a skip only after the wait budget below is exhausted.
• Copilot skip (narrow): Copilot may be marked skipped only after all of: (1) MCP request attempted (404 or success logged), (2) ≥ N polls at 60–120s intervals (or pr_closure.copilot_poll_interval_seconds from .harmonia/repo.json) with ≥ 10 minutes total elapsed after the last push (defaults: N=8, interval=90s, min wait=10 min — all overridable under pr_closure in .harmonia/repo.json), (3) no copilot-pull-request-reviewer[bot] review with commit_id == headRefOid, (4) repo policy does not mandate Copilot (pr_closure.copilot_required: true means never skip). Document skip in a PR comment or session handoff with head SHA, poll count, elapsed time, and MCP error text.
• When Copilot is skipped per the rule above, still poll required repository checks and address Bugbot or other bot/human review comments before merge.
• If Copilot review completed for the current head and there are no valid current-head Copilot comments, prefer merging the PR now instead of leaving it open just because auto-merge is disabled.
• Audit trail: Log whether Copilot was requested through GitHub MCP or a fallback path, plus poll count, head SHA, timestamps, and skip rationale when applicable.

Orchestration Hints

• Use this skill as the main prompt payload for Jira issue execution.
• When invoked without a Jira key, treat the slash-command remainder as the task description.
• Include dependency summaries so humans can understand the planned flow.
• The session is incomplete until the PR merges or a concrete blocker is documented — poll checks and reviews like a long-running agent.
• Run the local Bugbot review loop on branch changes before push (Cursor /review-bugbot, Codex bugbot subagent); fix actionable findings and re-validate until clean.
• Copilot feedback loop = validate locally (compile-test-fix-loop → post-due-diligence → Bugbot) before every push.
• If structural debt blocks completion, create a Jira refactor follow-up instead of invoking another code-changing skill.

Dependencies

• setup-env
• compile-test-fix-loop
• post-due-diligence