---
description: "Monitor or trigger a production build and don\'t stop until it succeeds"
version: 1.0.0
---

# /fix-production - Get Production Building and Deployed

<objective>
Ensure the production build is passing and deployed successfully. Do whatever it takes — commit, push, monitor, fix — and don't stop until you see a successful production build or you need something from me to get there.
</objective>

<steps>
1. **Detect the CI/CD platform**
   - Look for config files to identify the platform:
     - `.github/workflows/` — GitHub Actions
     - `.gitlab-ci.yml` — GitLab CI
     - `amplify.yml` — AWS Amplify
     - `vercel.json` or `.vercel/` — Vercel
     - `netlify.toml` — Netlify
     - `.circleci/` — CircleCI
     - `Jenkinsfile` — Jenkins
     - `bitbucket-pipelines.yml` — Bitbucket Pipelines
     - `fly.toml` — Fly.io
     - `render.yaml` — Render
   - Check for deployment CLIs available: `gh`, `vercel`, `netlify`, `aws`, `flyctl`, `railway`
   - If you can't determine the platform, ask the user immediately

2. **Check current build status**
   - Use the platform's CLI or API to check if a build is running
   - Platform-specific commands:
     - **GitHub Actions:** `gh run list --limit 5` and `gh run view <id>`
     - **GitLab CI:** `glab ci list` or check via API
     - **AWS Amplify:** `aws amplify list-jobs --app-id <ID> --branch-name <BRANCH> --region <REGION>`
     - **Vercel:** `vercel ls` or check dashboard
     - **Netlify:** `netlify status` or `netlify watch`
     - **Fly.io:** `flyctl status`
   - If a build is running, skip to step 5 (monitor it)

3. **If no build is running, check for changes to push**
   - Run `git status` and `git diff` to see uncommitted changes
   - Identify the deploy branch (usually `main` or `master`)
   - Check if local is ahead of remote: `git log origin/<branch>..HEAD`

4. **Trigger a build**
   - If there are uncommitted changes: review, commit, and push
   - If local is ahead of remote: push to trigger CI
   - If the last build failed: investigate the failure, fix it, commit and push
   - If the last build succeeded and nothing changed: tell the user — production may already be fine
   - Always run the project's build command locally first to catch errors before pushing

5. **Monitor the build**
   - Poll build status every 30-60 seconds
   - Report phase transitions as they happen
   - Platform-specific monitoring:
     - **GitHub Actions:** `gh run watch <id>` or poll `gh run view <id>`
     - **AWS Amplify:** poll `aws amplify get-job`
     - **Vercel:** `vercel ls` or poll deployment status
     - **Netlify:** `netlify watch`

6. **If the build fails**
   - Pull logs and identify the root cause
   - Fix the issue locally
   - Verify the fix by running the build locally
   - Commit and push to trigger a new build
   - Go back to step 5
   - If the same error persists after 2 attempts, pause and ask the user

7. **If the build succeeds**
   - Confirm the deployment is live
   - Report the build ID/URL and deployment status
</steps>

<rules>
- Do NOT stop until you see a successful build or you genuinely need input from the user
- If you can't figure out how to check build status or trigger a build, ask immediately
- Always build locally before pushing to catch errors early
- Make minimal, targeted fixes for build failures — don't refactor unrelated code
- Never force-push or rewrite history on the deploy branch
- If credentials or permissions are missing, ask the user
</rules>
