メニュー
Re-verify a vendor's API behavior against its docs/vendors/<vendor>.md snapshot, bump dates, append a Change log entry, and either open a doc-only PR (no drift impact) or file a type:vendor-evolution issue (drift forces connector changes). Use when API drift is suspected.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Verify gates one last time and merge an assistant PR (new-assistant or vendor-evolution). Use when the issue is at phase:merge-ready.
Scaffold (new-assistant) or refactor (vendor-evolution), document, test, and open a draft PR. Use when the issue is at phase:approved or phase:implementing and the contributor is starting or resuming work.
Open the right `type:new-assistant` / `type:vendor-evolution` GitHub issue from a free-form intent. Use when the user says they want to support / fix / evolve a vendor and has not yet filed an issue.
Review an open assistant PR against the dual-track checklist (dated documentation first, then code), with per-issue-type addenda for new vendors vs evolution. Use when the issue is at phase:review.
Routes to the correct sub-skill of the assistant family based on the issue's type:* and phase:* labels. Use when the user mentions a vendor onboarding or evolution and is unsure which skill to run.
Tally tester sign-off comments on a phase:testing issue, audit any attached connector logs for sanitization gaps, and draft follow-ups for incomplete confirmations. Use whenever a tester comments.
| name | assistant-reverify |
| description | Re-verify a vendor's API behavior against its docs/vendors/<vendor>.md snapshot, bump dates, append a Change log entry, and either open a doc-only PR (no drift impact) or file a type:vendor-evolution issue (drift forces connector changes). Use when API drift is suspected. |
| model | opus |
Read docs/ASSISTANT-ONBOARDING.md (re-verify section) and the
existing docs/vendors/<vendor>.md. If this skill and the spec
disagree, the spec wins.
A vendor slug. Not an issue number — re-verification is decoupled from any closed onboarding issue and never transitions a phase label.
Note the Last verified date and the dated payload samples. Identify
the API endpoints the connector exercises today.
Capture fresh payloads (or guide the user to). Sanitize per the vendor
doc's Sanitized fields list before saving. Date the captures with
today's date.
Compare the fresh samples against the existing dated samples. Categorize:
Bump Last verified to today. Append the fresh dated samples. Mark
older samples superseded by <today> — never delete (the historical
trail is the value). Append a Change log entry describing what was
checked, what was unchanged, and what drifted.
No drift or drift with no connector impact → open a small doc-only PR with the refreshed dates / samples / changelog. Stop here. No issue is required — nothing about the connector changes, so the testers / DMG / sanitization-audit gate adds no value.
Drift forcing connector changes → DO NOT write connector code
from this skill. DO NOT open a code PR directly. Instead, file (or
instruct the maintainer to file) a type:vendor-evolution issue
via vendor-evolution-request.yml, pre-filled with:
kind:* (enrichment / breaking /
urgent-fix if the connector is currently broken in the field).The doc PR from phase D can either be merged independently first or
rolled into the implementation PR opened later by
assistant-implement — the maintainer decides.
From there, the workflow takes over so the connector change goes through the testers / DMG / sanitization-audit gate like any other vendor evolution.
Never bundle re-verification with an old, already-closed onboarding PR.