Superset 사용 현황을 살펴보고 아직 쓰지 않는 기능 중 업무 방식에 맞는 항목을 제안합니다. 각 기능을 설명하고, 사용자가 고른 예약 실행 에이전트나 병렬 작업 공간, 공유 작업 등을 설정합니다.
- 사용하지 않는 Superset 기능 찾기
- 에이전트 예약 실행 설정
- 여러 작업 공간에서 병렬 작업
Resend 발신 도메인의 인증 상태를 확인하고 테스트 주소로 메일을 점검한 뒤, 실제 수신자와 메시지 내용을 확인받아 발송합니다. 예약 및 일괄 발송을 지원하며 기존 앱에 Resend 발신 기능을 연결할 수 있습니다.
Send email through Resend without surprising anyone — check the sending domain first, prove the message on Resend's test addresses, and get the user's confirmation before mail goes to a real inbox. Use when the user asks to send, schedule, or batch-send an email, test a template, or wire Resend sending into a codebase.
실행 점수 미검증
설치 방법 보기Resend로 메일을 보내기 전에 발신 도메인이 인증되어 있는지 확인합니다. 실제 수신자에게 보내기 전에는 같은 내용을 Resend 테스트 주소로 보내 전달 결과를 살펴봅니다. 실제 발송 전에는 발신자, 수신자, 참조, 숨은 참조, 제목과 본문을 보여 주고 사용자의 확인을 받습니다. 재시도로 인한 중복 발송을 막기 위해 멱등성 키도 설정합니다. 예약 발송과 수신자끼리 서로의 주소를 볼 수 없는 일괄 발송도 지원합니다. 앱에 발신 기능을 추가해 달라는 요청에는 기존 Resend 호출 방식에 맞춰 발송 경로를 확장합니다.
메일 템플릿을 테스트하거나 개별 메일을 예약하거나 여러 사람에게 발송할 때 사용할 수 있습니다. 기존 앱에 Resend를 이용한 메일 발송을 추가할 때도 적합합니다. 발송 전에 내용과 수신자를 확인하고, 재시도로 인한 중복을 줄이고 싶은 경우에 도움이 됩니다.
실제 수신자에게 보내기 전에는 매번 사용자의 명확한 확인을 받아야 합니다. API 키는 환경 변수로 관리하고 저장소, 클라이언트 코드, 로그에 넣지 않아야 합니다. 발송은 서버에서 수행합니다.
이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.
AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.
점수에는 넣지 않았습니다. 2026년 10월 30일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Every other Resend call can be run again. send-email and send-batch-emails
put mail in someone's inbox, and nothing undoes that. Treat the send as the last
step of a short checklist.
The from address must be on a domain the account has verified for sending.
Run list-domains and find the domain of the from address:
verified: send.pending, not_started, failed, or partly verified: do not send. Run
get-domain and show the user the DNS records that are not verified yet.onboarding@resend.dev sends without a domain, but only to the account
owner's own address. It is for a first test, not for real recipients.
Before a real recipient, send the same message to Resend's test addresses.
Remove cc and bcc, and put only test addresses in to. A real address in
any recipient field gets the test email before the user confirms in step 3.
delivered@resend.dev: delivered. Add a label for each case, for example
delivered+welcome@resend.dev.bounced@resend.dev: a hard bounce.complained@resend.dev: delivered, then marked as spam.suppressed@resend.dev: suppressed as an address that bounced before.Then run get-email on the result. Its status is the truth: sent means
Resend accepted the message, delivered means the receiving server accepted
it.
Show the user the from, to, cc, bcc, subject, and body, and wait for a
clear yes. Get this confirmation every time. Approval for an earlier send does
not cover this one.
idempotencyKey (for example welcome/<user-id>), so a retry after a
timeout cannot send the message twice.scheduledAt. cancel-email can stop a scheduled email
until it is sent, and not after.send-batch-emails, at most 100 per call), or a broadcast. It is not one
email with a long to list.When the user wants their application to send mail, read how the codebase already calls Resend and extend that path. The API key comes from the environment and never goes in the repo, a client bundle, or a log line. Send from the server only.
delivered@resend.dev until the message is
right.sent as delivered. sent only means that Resend accepted it.from domain so the send works. The user picks the sender,
not the agent.아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Superset 사용 현황을 살펴보고 아직 쓰지 않는 기능 중 업무 방식에 맞는 항목을 제안합니다. 각 기능을 설명하고, 사용자가 고른 예약 실행 에이전트나 병렬 작업 공간, 공유 작업 등을 설정합니다.
반복 작업을 Superset 자동화로 설정합니다. 에이전트 지침, 일정 또는 이벤트 조건, 실행 작업 공간을 정리하고 명시적인 확인을 받은 뒤 자동화를 만듭니다. 저장된 조건과 첫 실행 결과를 살펴 지침을 조정합니다.
Superset 작업 공간의 브라우저에서 페이지를 열고 클릭하거나 입력하며, 화면과 콘솔 정보를 확인합니다. 개발 중인 웹 앱 미리 보기, 폼 동작 및 화면 이동 점검에 활용할 수 있습니다.
Stripe 공식 문서와 API 매개변수 정의를 확인해 결제, 구독, 청구서, 웹훅 연동을 구현합니다. 적절한 제품 선택부터 샌드박스 테스트와 웹훅 처리까지 다루며, 결제와 구독 상태를 웹훅 이벤트로 판단합니다.
Chrome DevTools Protocol로 실행 중인 Electron 데스크톱 앱을 조작해 UI 변경을 확인하고 문제를 재현합니다. 실제 사용 흐름을 따라 화면 전환을 검증하고, 스크린샷과 경로·스크롤 위치·포커스·저장 상태를 기록해 비교합니다.
GitHub Actions 실패 로그에서 최초 오류를 찾아 코드 결함, 환경 문제, 간헐적 실패, 기존 장애로 구분합니다. 기준 브랜치와 PR 변경 사항을 비교해 관련성을 설명하고 다음 조치를 정리합니다.