一键导入
deploy
Use when building, packaging, or deploying KimPay - covers the build, container image, required environment/secrets, migrations, and health verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when building, packaging, or deploying KimPay - covers the build, container image, required environment/secrets, migrations, and health verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when reviewing a KimPay change or PR - applies a payment-gateway-specific checklist covering correctness, security, concurrency, and module hygiene.
Use when investigating a bug, test failure, or unexpected behavior in KimPay - enforces root-cause analysis and a regression test before any fix.
Use when adding a new feature or endpoint to KimPay - guides spec-driven, TDD implementation that respects module boundaries and payment security rules.
Use when restructuring KimPay code without changing behavior - enforces green-tests-before-and-after and respect for module boundaries.
Use when adding or improving test coverage for KimPay - guides choosing the right test level and writing meaningful payment/concurrency/security tests.
| name | deploy |
| description | Use when building, packaging, or deploying KimPay - covers the build, container image, required environment/secrets, migrations, and health verification. |
Build and ship KimPay safely. Sandbox-grade: test PSP credentials only, never live keys.
./mvnw clean verify is green (unit + integration)../mvnw -pl payment-api -am clean package (boot jar in payment-api/target).payment-api/Dockerfile. Tag with the git SHA. Scan the image (Trivy) before promoting.docker compose up brings up Postgres/Redis/Kafka (see docker-compose.yml).DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORDREDIS_HOST, REDIS_PORT, REDIS_PASSWORDKAFKA_BOOTSTRAP_SERVERS, PAYMENT_KAFKA_ENABLEDPAYMENT_KEY_PROVIDER (kms in shared envs), PAYMENT_ENCRYPTION_KEY_BASE64 (local only), gateway private keyFLYWAY_ENABLED=true). For controlled rollouts, run migrations as a separate gated step before rolling app instances./actuator/health returns UP (and readiness once observability lands).