convex-deploy-guard
배포에 영향을 미치는 명령어를 실행하기 전에 대상 Convex 배포를 분류하고 공지해야 하며, 프로덕션 환경 작업에 대해서는 새로 명시적인 동의를 받아야 하고, 세션은 읽기 전용 모드로 설정되어야 합니다.
SKILL DIRECTORY
설치 수와 최근 흐름을 기준으로 필요한 Agent Skill을 찾아보세요.
skills.sh API 기준방금 확인
배포에 영향을 미치는 명령어를 실행하기 전에 대상 Convex 배포를 분류하고 공지해야 하며, 프로덕션 환경 작업에 대해서는 새로 명시적인 동의를 받아야 하고, 세션은 읽기 전용 모드로 설정되어야 합니다.
앱에 대한 Convex 배포 환경 변수 및 시크릿을 설정하고 연결하세요.
Convex 배포 환경의 72시간 분석 결과(읽기 제한, OCC 경합)를 검토하고, 코드 내에서 각 이벤트의 근본 원인을 파악한 후, 증거에 기반한 성능 및 비용 분석 결과와 수정 방안을 보고하십시오.
Convex 앱에 반복 예약 작업(크론)을 추가합니다.
현재 Convex 앱에 기능을 추가합니다. 제공되는 Convex 기능 카탈로그를 참조하여 항상 최신 상태의 절차(청구, 크론, 인증, 에이전트, 검색 등)를 확인하며, 해당 기능이 없을 경우 내장 호스팅 또는 @convex-dev 구성 요소 검색으로 대체합니다. 사용자가 /add를 실행하거나, 기존 Convex 앱에 호스팅/퍼블리싱 또는 기타 백엔드 기능을 추가하도록 요청할 때 트리거됩니다.
Convex 앱에 AI 에이전트/RAG 백엔드(@convex-dev/agent)를 추가합니다.
스냅샷으로 초기화된 미리보기 배포 환경에서 라이브 앱 스키마 변경 및 백필을 시뮬레이션하고, 검증한 후, 검증된 변경 사항을 프로덕션 환경으로 적용하며, 스냅샷을 롤백 수단으로 활용합니다.
실행 중인 Convex 앱의 로그 및 상태 정보를 자연어로 조회하기 (공식 MCP): 오류, 느리거나 비용이 많이 드는 함수, 인과 관계 파악 — 범위 지정 가능, 증거 기반, 대시보드 딥 링크 제공.
Convex 지출을 미리 살펴보기 — 인사이트를 바탕으로 ‘바이트/읽은 문서 수 × 호출 횟수’ 기준 순위를 매기고, 각 비용 요인의 성장 곡선을 예측하며, 가장 비용이 적게 드는 해결책을 제시하고, 유료 조치의 비용을 확인합니다.
기존 Convex 앱에 대해 설명하십시오 — 데이터 모델 및 관계, 공개 함수와 내부 함수의 구분, 인증/소유권 모델, 컴포넌트, 요청→데이터 흐름 — 스키마와 함수 표면을 참고하여 작성하십시오. 읽기 전용입니다.
Convex 백업을 설정하고, 복구가 가능함을 입증하는 복원 DRILL을 실행하십시오. — 스냅샷 생성, 일회용 미리보기 환경으로 복원, 데이터가 정상적으로 복구되었는지 확인 — 또한 RPO에 부합하는 일정을 수립하고, 단계별 복구 실행 매뉴얼을 마련하십시오.
모든 Convex 감사(authz, reviewer, advisor, insights) 결과를 하나의 점수가 매겨지고 중복이 제거된 준비 상태 보고서로 통합하고, 우선순위가 지정된 수정 계획을 제시합니다. 백엔드를 위한 Lighthouse와 같은 솔루션입니다.
Convex 앱에서 발생하는 다음 개발/운영 환경 오류나 요청을 주시하고 이에 대응하세요.
이미 소유하고 있는 도메인을 Convex 앱에 연결하세요(DNS 레코드, 사용자 지정 도메인 연결, auth-origin 재바인딩).
앱의 Convex 함수에 대한 볼록성 테스트를 생성합니다.
@convex-dev/stripe를 통해 Convex 앱에 Stripe 청구/결제 기능을 추가합니다(결제 처리 + 웹훅 + 접근 제어).
Convex 기능이 정상적으로 작동하는지 확인 — 시드 데이터를 생성하고, convex-test를 통해 여러 모의 사용자로 시뮬레이션하며, 부정적인 권한 부여 사례(잘못된 사용자 거부, 데이터 범위 적용)를 포함한 동작을 검증합니다.
Convex 데이터베이스에 데이터를 초기화하거나 가져옵니다.
이번 코딩 세션의 대본을 Convex 팀에 보내 주시면, 퀵스타트 시스템을 개선하기 위한 AI 사후 분석에 활용하겠습니다.
프로덕션 오류 → 우선순위 분류, 근본 원인 분석, 수정 및 검증(tsc + 리허설 + 재현 후 해소)을 거친 후, 사람이 병합할 수 있도록 수정 PR을 생성 — 그 후 오류가 더 이상 재발하지 않는지 확인합니다. 절대 자동 병합하지 않습니다.