right-size-pr

name	right-size-pr
description	Open the GitOps pull request for a resource right-sizing change after a right-size investigation returns a 'recommend' verdict. Scope is specifically right-sizing (resource requests) — this is NOT a general-purpose GitOps PR tool. Trigger when: a right-size investigation completes with verdict 'recommend' and no existing open PR for that workload.

Right-Size PR

Turn a right-sizing "recommend" verdict into a reviewable pull request in the GitOps repository. The PR includes before/after resource requests, projected savings, a risk summary, and a soak monitoring plan.

This skill covers only what a right-sizing PR must contain and the rails it must respect — the git/gh mechanics of creating the PR are left to the agent.

IMPORTANT: Never self-approve. The PR requires human review and merge. The agent must NOT approve, merge, or bypass branch protection on its own PRs.

Prerequisites

• gh CLI authenticated (gh auth status)
• GITOPS_REPO environment variable set (e.g., your-org/k8s-manifests)
• Git configured with committer identity
• The workload's manifest is a plain YAML file in the GitOps repo
• No open PR already exists for this workload. Check first and stop if one does, to avoid duplicates:

  gh pr list --repo "$GITOPS_REPO" --state open --search "right-size {namespace}/{workload} in:title" --json number -q '.[0].number'
  

  A non-empty result means a PR is already open — do not open another. Note this also matches an open auto-revert PR (revert(right-size): {namespace}/{workload} …) from the soak skill; that is intentional — do not re-recommend a workload while a revert for it is still pending.

Step 1: Locate Manifest

Clone a fresh working copy of $GITOPS_REPO and find the Deployment/StatefulSet manifest for {namespace}/{workload}.

If the manifest uses Kustomize overlays or Helm values:

• For Kustomize: edit the patch file or base resource
• For Helm: edit the values.yaml (resource requests section)
• Document which file was modified in the PR body

Step 2: Edit Resources

Modify only resources.requests.{resource} to the proposed value:

# BEFORE
resources:
  requests:
    cpu: "4000m"      # ← changing this
    memory: "8Gi"
  limits:
    cpu: "8000m"      # ← do NOT touch limits
    memory: "8Gi"

# AFTER
resources:
  requests:
    cpu: "1200m"      # ← new value from investigation
    memory: "8Gi"
  limits:
    cpu: "8000m"
    memory: "8Gi"

Rules:

• The "Before" value is the current per-container request as written in the manifest — read it from the file. Do not assume the candidate's current_request, which may be a workload-level aggregate across replicas.
• Likewise ensure the proposed value is the intended per-container request.
• Do NOT modify resource limits unless the investigation explicitly recommends it
• Do NOT modify any other fields in the manifest
• If multiple containers in the pod have recommendations, handle each in a single PR

Step 3: Compose PR Body

Use this template:

## Right-Size: {namespace}/{workload} ({resource})

### Summary
| Metric | Before | After |
|--------|--------|-------|
| {resource} request | {current_request} | {proposed_request} |
| Waste ratio | {waste_ratio}% | ~{target_headroom}% headroom |
| Estimated savings | — | ${savings}/month |

### Risk Assessment
{List of risk flags checked and their status}

### Evidence
- P95 usage ({window}): {p95_usage}
- 30-day peak: {peak_30d}
- Headroom multiplier applied: {headroom_multiplier}x
- Safety factor applied: {safety_factor}x

### Soak Plan
After merge, the agent will:
1. Record baseline metrics (p99 latency, error rate, CPU throttle ratio)
2. Monitor for 24 hours
3. Auto-revert if any metric regresses beyond threshold:
   - Latency: +10% of baseline p99
   - Error rate: +0.5 percentage points
   - CPU throttle: >5% ratio
4. Report soak result to this PR

### Decision Record
- Decision ID: {decision_id}
- Investigated at: {decided_at}
- Full reasoning logged in decisions.db

Step 4: Open the PR

Create the branch, commit the single manifest change, push, and open the PR with your own git / gh tooling, following these conventions:

• Branch: sre/right-size/{namespace}-{workload}-{YYYYMMDD}
• Commit: stage only the edited manifest; message right-size({namespace}/{workload}): reduce {resource} request {current} → {proposed}
• Base branch: the repo's actual default branch — resolve it, do not assume main (gh repo view "$GITOPS_REPO" --json defaultBranchRef -q .defaultBranchRef.name).
• Title: same as the commit subject.
• Body: the Markdown from Step 3.
• Labels: sre-optimization, auto-generated. Labels must exist in the repo or gh pr create --label fails after the branch is pushed. Create them best-effort first (gh label create <name> --force — ignore "already exists"), or open the PR without labels and add them afterward with gh pr edit. Never let a missing label leave an orphan branch and no PR.

Before doing any of this, honor the guard in the Prerequisites: if an open PR already exists for this workload, stop and do not open a duplicate.

Do not approve or merge the PR (see the human-in-the-loop gate below). Capture the resulting PR URL for Step 5.

Step 5: Record in decisions.db

UPDATE decisions
SET pr_url = ?, pr_opened_at = datetime('now'), status = 'pr_open'
WHERE candidate_id = ?;

Step 6: Register Soak Watch

After the PR is opened, note that soak-and-rollback should be activated when this PR merges. The soak skill will be triggered by detecting the merge event (via scheduled polling or webhook).

Important: Human-in-the-Loop Gate

This skill opens a PR for review. It does NOT:

• Approve the PR
• Merge the PR
• Bypass any branch protection rules
• Override reviewer requirements

The PR is labeled auto-generated so reviewers know it came from the agent. The human reviewer is the final gate before any change reaches the cluster.