메뉴
Proactive prod-issue sweep. Discover what's new/worst since the last watermark, diagnose each via /analyze-prod-issue, auto-file a bug + priority:high issue, and notify. Runs unattended on a 12h schedule (launchd) or by hand. Invoke with: /prod-watch
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | prod-watch |
| description | Proactive prod-issue sweep. Discover what's new/worst since the last watermark, diagnose each via /analyze-prod-issue, auto-file a bug + priority:high issue, and notify. Runs unattended on a 12h schedule (launchd) or by hand. Invoke with: /prod-watch |
| disable-model-invocation | true |
Proactively find production issues instead of waiting for a reported symptom. Each run does a
sweep for what's newly broken since the last watermark, diagnoses the survivors with the
existing /analyze-prod-issue workflow, auto-files a scrubbed bug + priority:high issue for
each real user-blocker, and notifies you it's ready to pick up.
Type: Rigid workflow. Follow steps exactly.
Prerequisite: read-only prod DB access (bin/prod-db) and the Honeycomb MCP session must be
live — same as /analyze-prod-issue. If bin/prod-db --check fails, see
docs/runbooks/prod-db-access.md.
The exact sweep SQL, the Honeycomb scan, and the issue-body template are in
references/sweep.md — read it when a step says to.
The wrapper (bin/prod-watch) owns state I/O and supplies it in the invocation: a watermark
timestamp and the filed_fingerprints array already filed. Use those — do not read
.prod-watch/state.json yourself (a headless run can't reliably write it back, so the wrapper
handles both ends). The wrapper defaults the watermark to now − 12h on the first run.
Done when: you hold the wrapper-supplied watermark and the set of already-filed fingerprints.
Run the sweep from references/sweep.md:
error_tracker_errors where last_occurrence_at > watermark,
status = 'unresolved' (error_tracker's live status — there is no 'open'), NOT muted, joined
for an occurrence count, ranked by count descending.error=true scan over the 12h window for funnel drops the DB won't show
(an entry span with many mounts but its terminal action near zero).Done when: you have a ranked candidate list, each with its fingerprint, kind,
source_function, and occurrence count.
Drop any candidate whose fingerprint is in filed_fingerprints. As a second guard that survives
a lost state file, also run gh issue list --search "<fingerprint>" --state open and drop
candidates that already have an open issue. Apply the re-alert predicate in references/sweep.md
(a resolved-then-recurring error should re-alert; a still-open known one should not). Cap the
survivors to the top 3 by occurrence count.
Done when: a deduped candidate list of at most 3 remains (may be empty — then jump to Step 6).
For each surviving candidate, run the full /analyze-prod-issue workflow, using the candidate's
error (kind + source_function + reason) as the symptom. Do not restate diagnosis here —
/analyze-prod-issue owns it. Its Step 6 honest-scoping is the quality gate: a candidate it
demotes to "noise / not a user-blocker" is dropped, not filed.
Done when: each candidate has either a real-blocker diagnosis (root cause + count-scoped impact
For each candidate that survived as a real blocker, create the issue directly (the loop is
unattended — do not route through /create-issue, whose confirmation gate cannot run here):
gh issue create --label "bug,priority:high" --assignee MaxPayne89 \
--title "[BUG] <one-line symptom>" \
--body "$(cat <<'EOF'
<body from references/sweep.md template>
EOF
)"
The body carries the fingerprint marker <!-- prod-watch-fingerprint: <fp> --> so the next
sweep can dedup on it. Count + opaque UUID only — never names or emails (the repo is public;
inherit the PII rule from /analyze-prod-issue).
Done when: each real blocker has an issue URL, or is recorded as dropped-noise.
Send one PushNotification per filed issue: prod-watch filed #NNN: <one-line>. If nothing was
filed, send none. Then report the error_tracker fingerprints you filed this run (a JSON array,
possibly empty) between these exact markers, and finish:
PROD_WATCH_FILED_BEGIN
["<fingerprint>", ...]
PROD_WATCH_FILED_END
Do not write .prod-watch/state.json — the wrapper stamps the new watermark and unions these
fingerprints into state. Emit the block even on a clean sweep ([]), so the wrapper always advances
the watermark.
Done when: notifications sent (or none needed) and the PROD_WATCH_FILED block is emitted.
/analyze-prod-issue Step 6 must confirm a real user-blocker first.fingerprint, not on title text. Re-alert only when a known
error recurs after its prior issue was closed (see the re-alert predicate in
references/sweep.md).bin/prod-db (SELECT-only reader).Diagnose a production issue end-to-end across Honeycomb (error shape) and the prod DB error_tracker tables (who + why), scope impact honestly, and optionally file a PII-scrubbed issue. Invoke with: /analyze-prod-issue "<symptom>"
Fetch, triage, and address PR review comments for the current branch. Reads all comments from the PR, classifies each as actionable, nit, question, or dismissible, presents a structured assessment for confirmation, then plans and applies fixes. Use when: "address PR comments", "handle review feedback", "fix PR comments", "triage PR review", "respond to review", or after receiving PR review notifications. Invoke with /address-pr-comments.
Deliberate TDD-first, design-heavy workflow for building an Elixir/Phoenix change end-to-end — surface rival designs, pick one, drive red→green, keep the test suite lean. Invoke with: /build-elixir <what you're building>
Use when the user wants to read a Daily QA discussion by number, triage the findings (Carried-Forward and New Code Review), assess validity against current code, present a structured summary, then systematically fix confirmed issues. Invoke with the discussion number as argument (e.g. `/triage-qa-discussion 449`).
This skill should be used when the user wants to assess or scope a GitHub issue before committing to work — triggers on "assess issue
Test-drive code changes using Chrome DevTools and Tidewave MCP. Verifies backend logic, UI flows, responsive design, and edge cases. Use when: completing a feature branch, before creating a PR, after addressing PR review comments, or when asked to "test-drive", "verify changes", or "QA this". Invoke with /test-drive [branch|unstaged|<issue-number>].