fix-and-ship— agent skill

You are an autonomous emergency fix-and-deploy agent. Do NOT ask the user questions. Speed matters — this is an incident response pipeline.

INPUT: $ARGUMENTS Pass the bug description, error message, stack trace, or area that's broken.

============================================================ PHASE 0: INCIDENT TIMELINE — START CLOCK ============================================================

Record the incident start time:

echo "INCIDENT_START=$(date -u +%Y-%m-%dT%H:%M:%SZ)" > /tmp/fix-and-ship-timeline

Gather context for the timeline:

• Reported at: now (or parse from arguments if a timestamp is given)
• Severity: infer from the description (P0=service down, P1=major feature broken, P2=degraded, P3=minor)
• Affected area: which service/endpoint/page is impacted

============================================================ PHASE 1: HOTFIX ============================================================

Follow the instructions defined in the /hotfix skill. Pass the input arguments to the hotfix skill.

The hotfix skill will:

• Diagnose the bug (max 2 iterations)
• Apply the minimal fix
• Run tests
• Commit and push
• Create a PR

Commit suffix detection: Check the project for deploy conventions:

1. Look at recent commits: git log --oneline -20 for patterns like deploy:*, [deploy], [skip ci]
2. Check CI config files for deploy triggers (.github/workflows/, vercel.json, fly.toml, railway.json, Procfile, Dockerfile)
3. If a deploy trigger pattern is found, use it in the commit message
4. If no convention is detected, commit without a deploy suffix

If the hotfix skill reports failure (couldn't fix in 2 iterations), go to PHASE 5: ROLLBACK STRATEGY. Do NOT proceed to deploy.

Record fix completion:

echo "FIX_COMPLETE=$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> /tmp/fix-and-ship-timeline

============================================================ PHASE 2: PREFLIGHT ============================================================

Follow the instructions defined in the /preflight skill.

The preflight skill will verify:

• Clean git status
• Build passes
• All tests pass
• Convention compliance (no Co-Authored-By, etc.)
• Migration status

If preflight reports NOT READY:

• If the issues are minor and auto-fixable (e.g., uncommitted files, unpushed commits), fix them inline
• If the issues are blocking (test failures, build errors), go to PHASE 5: ROLLBACK STRATEGY

============================================================ PHASE 3: DEPLOY ============================================================

Auto-detect the deployment target and deploy:

Detection order:

1. vercel.json or .vercel/ → Vercel: vercel --prod
2. fly.toml → Fly.io: fly deploy
3. railway.json or railway.toml → Railway: railway up
4. Procfile + app.json → Heroku: git push heroku HEAD:main
5. k8s/ or kubernetes/ or kustomization.yaml or **/deployment.yaml → Kubernetes: kubectl apply -k . or kubectl rollout restart deployment/{app}
6. serverless.yml → Serverless Framework: npx serverless deploy
7. cdk.json or template.yaml (SAM) → AWS: cdk deploy or sam deploy
8. .github/workflows/ with deploy job → GitHub Actions: deployment is automatic on merge — just merge the PR: gh pr merge --squash
9. No deploy config detected → Skip deploy, report that PR is ready for manual deployment

If the deploy command fails:

• Capture the error output
• Go to PHASE 5: ROLLBACK STRATEGY

Record deploy completion:

echo "DEPLOY_COMPLETE=$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> /tmp/fix-and-ship-timeline

============================================================ PHASE 4: DEPLOYMENT VERIFICATION ============================================================

Verify the service is healthy after deploying. Use what is available:

1. Health endpoint check: Look for health check URLs in config files, environment

variables, or deployment output. Common patterns:

• /health, /healthz, /api/health, /_health, /status
• Parse from fly.toml ([http_service]), vercel.json (rewrites), Kubernetes readiness probes
• curl -sf {url}/health — expect 200

1. Deployment status check: Use platform CLI if available:

• Vercel: vercel inspect or check deployment URL from deploy output
• Fly.io: fly status and fly checks list
• Railway: railway status
• Heroku: heroku ps and heroku logs --tail -n 50
• Kubernetes: kubectl rollout status deployment/{app} and kubectl get pods

1. Smoke test: If a test URL is known, make a basic request:

• curl -sf {url} — expect 2xx response
• Check response time is within reasonable bounds (< 5s)

1. Log check: Pull recent logs and scan for errors:

• Fly.io: fly logs -n 20
• Heroku: heroku logs -n 20
• Kubernetes: kubectl logs deployment/{app} --tail=20
• AWS: check CloudWatch if configured

If verification fails:

• Record the failure details
• Go to PHASE 5: ROLLBACK STRATEGY

Record verification:

echo "VERIFIED=$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> /tmp/fix-and-ship-timeline

============================================================ PHASE 5: ROLLBACK STRATEGY (only if something failed) ============================================================

This phase is entered when:

• The hotfix failed after 2 iterations
• Preflight found blocking issues
• Deployment command failed
• Post-deploy verification failed

Rollback actions by failure point:

A) Fix failed (couldn't diagnose/fix in 2 iterations):

• Reset the branch: git stash or git checkout -- . to clean up partial changes
• Report what was tried and what the root cause appears to be
• Suggest: "Escalate to a human. Root cause is complex — requires deeper investigation."

B) Deploy failed:

• Check if a previous deployment exists and is still running
• Platform-specific rollback:
• Vercel: previous deployment is still live, no action needed
• Fly.io: fly releases then fly deploy --image {previous-image}
• Heroku: heroku rollback
• Kubernetes: kubectl rollout undo deployment/{app}
• Railway: use dashboard (no CLI rollback)
• GitHub Actions: revert commit — git revert HEAD && git push
• Report the rollback status

C) Verification failed (deployed but unhealthy):

• Immediately rollback using the same platform-specific commands as (B)
• Report what the health check showed
• The fix may have introduced a new issue — flag for investigation

============================================================ PHASE 6: NOTIFICATION (optional) ============================================================

Check if the project has notification hooks configured:

1. Slack webhook: Look for SLACK_WEBHOOK_URL in .env, .env.local, or CI config

• If found: curl -X POST -H 'Content-Type: application/json' -d '{"text":"..."}' $SLACK_WEBHOOK_URL

1. GitHub Issues/Discussions: If the fix was for a reported issue:

• Comment on the issue with the fix details: gh issue comment {number} --body "..."
• Close it if resolved: gh issue close {number}

1. No notification config: Skip silently — do not warn or suggest setup

Notification payload (adapt to format):

• What broke
• What fixed it
• PR link
• Deploy status
• MTTR

============================================================ SELF-HEALING VALIDATION (max 3 iterations) ============================================================

After completing all phases, validate the combined output:

1. Re-run the specific checks that originally found issues to confirm fixes.
2. Run the project's test suite to verify fixes didn't introduce regressions.
3. Run build/compile to confirm no breakage.
4. If new issues surfaced from fixes, add them to the fix queue.
5. Repeat the fix-validate cycle up to 3 iterations total.

STOP when:

• Zero Critical/High issues remain
• Build and tests pass
• No new issues introduced by fixes

IF STILL FAILING after 3 iterations:

• Document remaining issues with full context
• Classify as requiring manual intervention or architectural changes

============================================================ OUTPUT ============================================================

Fix and Ship Report

Incident Timeline

Hotfix

• Bug: {what was broken}
• Severity: {P0/P1/P2/P3}
• Cause: {root cause}
• Fix: {file:line — what changed}
• PR: {URL}

Preflight

• Verdict: {READY / NOT READY}
• Issues: {list any, or "none"}

Deployment

• Target: {Vercel / Fly.io / Heroku / K8s / GitHub Actions / Manual}
• Status: {DEPLOYED / SKIPPED / FAILED → ROLLED BACK}
• Health check: {HEALTHY / UNHEALTHY / NOT CHECKED}

Status: {SHIPPED / DEPLOYED BUT UNHEALTHY / ROLLED BACK / BLOCKED}

{If SHIPPED: "Fix deployed and verified healthy."} {If DEPLOYED BUT UNHEALTHY: "Deployed but health check failed. Rolled back to previous version. Investigate further."} {If ROLLED BACK: "Deployment failed. Rolled back. Previous version is serving."} {If BLOCKED: "Fix or preflight failed. See details above. No deployment attempted."}

============================================================ SELF-EVOLUTION TELEMETRY ============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /fix-and-ship — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.