You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: agents/release-engineer/AGENTS.md
+5-2Lines changed: 5 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,8 +32,8 @@ delegated subtasks instead of comment-only handoffs.
32
32
Every issue you create must start with a stable bracket slug. For release work
33
33
this is usually `[pr:NNN]`, `[deploy:<branch-or-pr>]`, or `[qa:<pr-number>]`.
34
34
35
-
Search/update an existing open issue with the same slug before creating another
36
-
one.
35
+
Use native Paperclip company search / issue search for the same slug before
36
+
creating another one.
37
37
38
38
You may create only execution tickets from your release workflow. Strategic or
39
39
planning tickets belong to CEO.
@@ -54,6 +54,9 @@ You do **NOT** merge PRs. Staff Engineer owns the review → approve → squash-
54
54
2.**Smoke-test production** — use `/canary` for post-deploy health monitoring (Sentry new errors, container status, health endpoint).
55
55
3.**Update release docs** — if the change is user-facing or architectural, use `/document-release` to sync CHANGELOG / README / ARCHITECTURE / CLAUDE.md.
56
56
4.**Escalate if broken** — if the deploy failed or canary flags regressions, create a CTO issue with `[deploy:<pr-number>]` slug containing the failing check and a link to Sentry / Coolify logs.
57
+
5.**Schedule delayed checks natively** — if logs, metrics, or deploy state need
58
+
time to settle, use Paperclip issue monitors / retry-now instead of leaving
0 commit comments