# Entry tracking
entry_mode = "new_issue" or "existing_pr"
issue_link = <extracted from task>
existing_pr_link = <extracted or None>

# Branch tracking
baseline_branch_id = parent_branch_id
analysis_branch_id = None  # Set after Step 1
last_fix_branch_id = None  # Set after Step 2 or skipped if existing_pr

# PR tracking (pre-filled if existing_pr, otherwise set after Step 2)
pr_number = <extracted or None>
pr_url = <extracted or None>
pr_head_branch = <extracted or None>

# Metrics
review_cycle_count = 0  # Increment each time Step 5.1 executes

=== PHASE 1: SYNC CODE ===

Pull the latest code from master branch.

=== PHASE 2: DEEP ANALYSIS ===

Analyze issue: {issue_link}

Apply scientific rigor. Default stance: every claim may be invalid until evidence proves otherwise.

1. Restate the issue claim precisely (expected vs actual, triggering inputs/config)
2. Locate relevant code paths and exact conditions to reach them
3. Determine reachability under default/common production configs
4. Identify root cause with code-causal chain (why this, not alternatives)
5. Search for counter-evidence (feature gates, guards, fallbacks, test-only paths, unreachable branches)
6. Assess impact and blast radius (unavailability, correctness, data safety, security, performance)
7. Check for broader systemic issues (same pattern elsewhere, shared abstractions)
8. If the report mentions a failing test, identify the minimal failing case and rerun it on current HEAD to confirm repro (or prove non-repro)

=== PHASE 3: CONCLUSION ===

Output exactly ONE of:

--- Option A: No action needed ---
VERDICT=NO_ACTION_NEEDED
REASON=<brief explanation: not a bug / already fixed / duplicate / out of scope / test-only>

--- Option B: Action required ---
VERDICT=NEED_FIX

BEGIN_SOLUTION_DESIGN
root_cause: <one-line root cause>
severity: <P0 / P1 / P2 / feature>
approach: <clear, concise solution using KISS principle; describe what to change and why>
test_strategy: <how to verify the fix>
risks: <potential risks or edge cases>
alternatives_rejected: <why other approaches were not chosen>
END_SOLUTION_DESIGN

=== PHASE 1: SYNC CODE ===

Checkout the existing PR branch: {pr_head_branch}

=== PHASE 2: DEEP ANALYSIS ===

Analyze existing PR: {existing_pr_link}
Associated issue (if any): {issue_link}

Apply scientific rigor. Default stance: assume the PR may not need changes unless evidence proves otherwise.

1. Understand the PR's intent and current implementation
2. Analyze code changes (what changed, why, impact)
3. Identify potential issues or improvement opportunities
4. Assess code quality, edge cases, and compatibility
5. If there's an associated failing test, rerun it on current PR HEAD to verify status

=== PHASE 3: CONCLUSION ===

Output exactly ONE of:

--- Option A: No action needed ---
VERDICT=NO_ACTION_NEEDED
REASON=<brief explanation: PR is good / already addresses issue / no improvements needed>

--- Option B: Action required ---
VERDICT=NEED_FIX

BEGIN_SOLUTION_DESIGN
root_cause: <what needs improvement in the PR>
severity: <P0 / P1 / P2 / enhancement>
approach: <clear, concise improvement using KISS principle; describe what to change and why>
test_strategy: <how to verify the improvement>
risks: <potential risks or edge cases>
alternatives_rejected: <why other approaches were not chosen>
END_SOLUTION_DESIGN

=== CONTEXT: SOLUTION DESIGN ===

The analysis phase has identified the following solution:

{paste entire SOLUTION_DESIGN block from Step 1}

=== WORKING METHOD (CRITICAL) ===

Do not rush to write code.
First, make sure you fully understand the issue and current behavior.
Then, design the best fix strategy based on the solution design.
You are a Linus bigfan: use KISS (accurate, rigorous, concise) to find the best simple, robust, minimal-change strategy.
Only after the strategy is clear should you implement.
If new constraints appear during implementation, pause and re-evaluate the strategy before continuing.

=== YOUR TASK: IMPLEMENT ===

Implement the solution following the design above:

1. Follow the expert method above and the original solution design
2. Apply KISS principle: accurate, rigorous, and concise
3. Self-review your diff (correctness, edge cases, compatibility)
4. Run the smallest relevant tests/build to verify basic functionality
5. Create a NEW PR:
   - Use `gh pr create`
   - Include a clear title and description referencing {issue_link}
6. Handle GitHub CLI auth:
   - If `gh` is unauthorized (token expired/invalid), retry once
   - If still unauthorized: commit locally, keep the branch, and output GH_AUTH_EXPIRED mode

=== OUTPUT ===

Output exactly ONE of the following modes:

--- Success mode ---
IMPLEMENTATION_SUCCESS
PR_URL=<url>
PR_NUMBER=<number>
PR_HEAD_BRANCH=<branch>

--- GH auth expired mode ---
GH_AUTH_EXPIRED
LOCAL_COMMIT=<sha>
RETRY_PUSH_BRANCH=<branch>

--- Implementation blocked mode (use ONLY if design is fundamentally flawed) ---
IMPLEMENTATION_BLOCKED
REASON=<why the design doesn't work; requires re-analysis>

Review PR #{pr_number} (related to: {issue_link}) with scientific rigor.

=== REVIEW PRINCIPLES ===

1. Treat this like a scientific investigation: read as much as needed, explain what the code actually does (don't guess)
2. Only accept a P0/P1 finding when code evidence + reachability justify it
3. Default stance: assume no critical issues unless proven otherwise

=== REVIEW CHECKLIST ===

1. Correctness: Does the fix address the root cause? Are there logical errors?
2. Edge cases: Are boundary conditions handled? What about error paths?
3. Compatibility: Does this break existing behavior or APIs?
4. Regressions: Could this introduce new bugs in other code paths?
5. Performance: Are there performance implications?
6. Security: Are there security vulnerabilities (injection, XSS, auth bypass, etc.)?
7. Testing: If the original issue was a failing test, rerun that test on the current PR HEAD to verify the fix

=== OUTPUT ===

If you find any P0 or P1 issues, output:

P0_P1_FINDINGS
BEGIN_P0_P1_FINDINGS
<list each finding with:>
- Severity: P0 or P1
- Description: What is the issue?
- Code evidence: Exact file:line and why it's a problem
- Reachability: How is this triggered? (default config / common config / edge case)
- Blast radius: What is the impact? (availability / correctness / data / security / performance)
END_P0_P1_FINDINGS

If no P0/P1 issues found, output exactly:
NO_P0_P1

IMPORTANT: Do NOT post PR comments or create GitHub issues in this step.

Verify the P0/P1 findings from the review for PR #{pr_number}.

=== INPUT: REVIEW FINDINGS ===

{paste entire content between BEGIN_P0_P1_FINDINGS and END_P0_P1_FINDINGS from Step 3}

=== VERIFICATION PRINCIPLES ===

Default stance: Each finding may be a misread, misunderstanding, or edge case—unless code evidence forces you to accept it.

Read as much as needed. Treat analysis like a scientific experiment: explain what the code does (don't guess), challenge assumptions, confront gaps in understanding.

=== TRIAGE PROCESS ===

For EACH finding, perform the following triage:

1. **Validity**: Confirm it is real on current PR HEAD
   - Is the issue actually present in the code?
   - Is it reachable in realistic scenarios?
   - Is the severity assessment correct?

2. **Origin**: Best-effort determination
   - Introduced by this PR? (check git diff)
   - Pre-existing on master? (check base branch)

3. **Fix Difficulty & Risk**:
   - Difficulty: S (small) / M (medium) / L (large)
   - Risk: low / med / high

4. **Scope Decision** (choose exactly ONE per finding):

   - **FIX_IN_THIS_PR**: Must be fixed before merge
     - Issue is introduced by this PR, OR
     - Merging makes things worse, OR
     - P0/P1 that must be addressed now

   - **DEFER_CREATE_ISSUE**: Valid but does NOT block this PR
     - Not introduced by this PR and merge doesn't worsen it, OR
     - Fix is large/risky and better handled separately

   - **INVALID_OR_ALREADY_FIXED**: Not a real issue
     - Not valid, not reachable, not actually P0/P1, OR
     - Already fixed by current HEAD, OR
     - Duplicate of existing issue

=== GITHUB ISSUE CREATION ===

For every finding marked DEFER_CREATE_ISSUE:

1. Extract repo name:

   REPO=$(gh pr view {pr_number} --json baseRepository --jq .baseRepository.nameWithOwner)

2. Search for existing issues (avoid duplicates):

   gh issue list -R "$REPO" --search "<keywords> in:title,body state:open" --limit 10

3. If matching open issue exists:
   - Do NOT create new issue
   - Optionally add comment with new evidence + link to PR #{pr_number}
   - Use existing issue URL

4. If no match, create new issue:

   gh issue create -R "$REPO" --title "<title>" --body "<body>"

   Body must include: code evidence, repro steps, impact, link to PR #{pr_number}

=== PR COMMENT (IDEMPOTENT) ===

Post ONE summary comment on the PR (idempotent per PR HEAD SHA):

1. Get PR HEAD SHA:

   HEAD_SHA=$(gh pr view {pr_number} --json headRefOid --jq .headRefOid)

2. Check if comment already exists:
   - Search for existing comment containing: `<!-- pantheon-verify:$HEAD_SHA -->`
   - If found, do NOT post again (comment is idempotent per SHA)

3. Post comment via stdin (preserves formatting):

   gh pr comment {pr_number} --body-file - <<'EOF'
<!-- pantheon-verify:$HEAD_SHA -->

## Review Verification Summary

### ✅ FIX_IN_THIS_PR (blocking merge)
<list each item with: severity, brief rationale, difficulty/risk>

### 📋 DEFER_CREATE_ISSUE (tracked separately)
<list each item with: issue link, brief rationale>

### ❌ INVALID_OR_ALREADY_FIXED
<brief rationale for each>
EOF

=== OUTPUT ===

If NO findings are marked FIX_IN_THIS_PR, output:
NO_IN_SCOPE_P0_P1

Otherwise, output:
IN_SCOPE_P0_P1
BEGIN_IN_SCOPE_P0_P1
<list only the findings marked FIX_IN_THIS_PR, with full details: severity, description, code evidence, fix guidance>
END_IN_SCOPE_P0_P1

WHILE in-scope P0/P1 issues exist:
    1. Fix the issues
    2. Review again (Step 3)
    3. If NO_P0_P1: break
    4. Verify again (Step 4)
    5. If NO_IN_SCOPE_P0_P1: break
END WHILE

Fix the following in-scope P0/P1 issues for PR #{pr_number}:

=== ISSUES TO FIX ===

{paste entire content between BEGIN_IN_SCOPE_P0_P1 and END_IN_SCOPE_P0_P1 from Step 4}

=== REQUIREMENTS ===

1. Do not rush into code changes
2. First understand each finding and the affected code paths
3. Then design the best fix strategy before editing: you are a Linus bigfan, and use KISS (accurate, rigorous, concise) to find the best simple, robust path
4. If new constraints are discovered, pause and re-evaluate the strategy before continuing
5. Fix each issue using KISS principle: accurate, rigorous, concise
6. Do NOT introduce new bugs or regressions
7. Self-review your changes
8. Run smallest relevant tests/build

9. PR Management:
   - Do NOT create a new PR
   - Checkout existing PR branch: `gh pr checkout {pr_number}` (or `git checkout {pr_head_branch}`)
   - Commit your fixes
   - Push to existing branch: `git push`

10. Handle GitHub CLI auth:
   - If `gh` unauthorized: retry once
   - If still unauthorized: commit locally, output GH_AUTH_EXPIRED mode

=== OUTPUT ===

Success mode:
FIX_SUCCESS

GH auth expired mode:
GH_AUTH_EXPIRED
LOCAL_COMMIT=<sha>
RETRY_PUSH_BRANCH={pr_head_branch}

Improve the existing PR #{pr_number} based on the following analysis:

=== SOLUTION DESIGN ===

{paste entire SOLUTION_DESIGN block from Step 1}

=== REQUIREMENTS ===

1. Do not rush into code changes
2. First understand the current PR behavior and what needs improvement
3. Then design the best improvement strategy before editing: you are a Linus bigfan, and use KISS (accurate, rigorous, concise) to find the best simple, robust path
4. If new constraints are discovered, pause and re-evaluate the strategy before continuing
5. Implement improvements following the design using KISS principle
6. Do NOT introduce new bugs or regressions
7. Self-review your changes
8. Run smallest relevant tests/build

9. PR Management:
   - Checkout existing PR branch: `gh pr checkout {pr_number}` (or `git checkout {pr_head_branch}`)
   - Commit your improvements
   - Push to existing branch: `git push`

10. Handle GitHub CLI auth:
   - If `gh` unauthorized: retry once
   - If still unauthorized: commit locally, output GH_AUTH_EXPIRED mode

=== OUTPUT ===

Success mode:
FIX_SUCCESS

GH auth expired mode:
GH_AUTH_EXPIRED
LOCAL_COMMIT=<sha>
RETRY_PUSH_BRANCH={pr_head_branch}

gh pr comment {pr_number} --body "$(cat <<'EOF'
## ✅ Pantheon Issue Resolution Complete

This PR has been analyzed and iterated through the Fix/Review/Verify loop until no in-scope P0/P1 blockers remain.

**Final Status:**
- ✅ No P0/P1 blocking issues found in latest review
- ✅ All identified issues have been either fixed or deferred to separate issues
- ✅ PR is ready for final human review and merge

**Workflow Summary:**
- Issue analyzed: {issue_link}
- PR created/updated: #{pr_number}
- Review cycles completed: {review_cycle_count}

---
🤖 Automated by [pantheon-issue-resolve](https://github.com/pingcap-inc/pantheon-agents/tree/main/agents/skills/pantheon-issue-resolve)
EOF
)"

Step 1 (Analyze)
  ↓ outputs: SOLUTION_DESIGN
Step 2 (Implement) ← receives SOLUTION_DESIGN
  ↓ outputs: PR info (pr_number, pr_url, pr_head_branch)
Step 3 (Review) ← knows PR info
  ↓ outputs: P0_P1_FINDINGS (or NO_P0_P1)
Step 4 (Verify) ← receives P0_P1_FINDINGS
  ↓ outputs: IN_SCOPE_P0_P1 (or NO_IN_SCOPE_P0_P1)
Step 5 (Fix Loop) ← receives IN_SCOPE_P0_P1
  ↓ iterates: Fix → Review → Verify
  ↓ workflow complete when no in-scope P0/P1 remain