skills/deploy/SKILL.md
Deploy feature to target environment (dev/staging/prod) with level-based strategy. Triggers: deploy, /pdca deploy, 배포, デプロイ, 部署, desplegar, déployer, bereitstellen, distribuire.
npx skillsauth add popup-studio-ai/bkit-claude-code deployInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Deploy code to target environment with automated CI/CD pipeline generation. Strategy adapts based on project level (Starter/Dynamic/Enterprise).
/pdca deploy {feature} # Deploy to default env (dev)
/pdca deploy {feature} --env dev # Deploy to DEV
/pdca deploy {feature} --env staging # Deploy to STAGING (requires DEV 90%+)
/pdca deploy {feature} --env prod # Deploy to PROD (requires STAGING 95%+ & Human Approval)
/pdca deploy status # Show deploy state machine status
| Level | Strategy | Environments | Tools | |-------|----------|-------------|-------| | Starter | Guide only | dev | GitHub Pages, Netlify, Vercel | | Dynamic | Docker + GHA | dev, staging | Docker Compose, GitHub Actions | | Enterprise | 6-Layer CI/CD | dev, staging, prod | Terraform, EKS, ArgoCD, Canary |
/pdca deploy feature --env dev
│
▼
① Level Detection (Starter/Dynamic/Enterprise)
│
▼
② Generate CI/CD Files (if not exist)
├── .github/workflows/deploy.yml
├── Dockerfile (Dynamic/Enterprise)
├── docker-compose.yml (DEV)
├── k8s/ manifests (Enterprise)
└── terraform/ (Enterprise)
│
▼
③ Deploy State Machine Transition
init → dev → verify(90%) → staging → verify(95%) → approval → prod(canary) → complete
│
▼
④ Return to PDCA Check phase
| Gate | Condition | Action |
|------|-----------|--------|
| DEV → STAGING | Match Rate ≥ 90% | Auto-promote |
| STAGING → PROD | Match Rate ≥ 95% + Human Approval | Require /pdca deploy --env prod |
| PROD Canary | Error rate < threshold | Auto-rollout 10% → 25% → 50% → 100% |
.github/workflows/deploy.yml — Docker build + push + deployDockerfile — Multi-stage builddocker-compose.yml — DEV environment.env.example — Environment variables templateinfra/terraform/ — AWS infrastructureinfra/k8s/ — Kubernetes manifestsinfra/argocd/ — ArgoCD Application + Helm/pdca deploy rollback {feature} # Rollback current deploy
/pdca deploy rollback {feature} --env prod # Rollback specific environment
Rollback triggers:
/pdca deploy rollback commandself-healing agent exhausts its 5-iteration auto-fix budget without restoring SLO, it triggers /pdca deploy rollback as final remediation (see Self-Healing Integration below).Rollback resets deploy state machine to idle and restores previous version.
The self-healing agent (linked-from-skills: deploy) closes the deploy ⇄ recovery loop:
| Stage | Trigger | Action |
|-------|---------|--------|
| Detect | Sentry/Slack error pattern matches deploy window | self-healing agent activated via 8-lang triggers ("자동 수정", "auto fix", etc.) |
| Diagnose | 4-Layer Living Context loaded (Scenarios + Invariants + Impact + Incidents) | Identify deploy-introduced regression |
| Auto-fix | Spawn code-analyzer + gap-detector via Task tool | Up to 5 iteration cycles with scenario runner verification |
| Verify | Re-run feature scenarios | Pass → auto PR; Fail → escalate |
| Escalate | Iteration budget exhausted or critical invariant violated | Trigger /pdca deploy rollback + alert human on-call |
Invocation paths:
/pdca deploy rollback first checks for active self-healing session and aborts to wait for it; user can force-bypass with --force-rollbackThe self-healing → deploy contract is mediated by lib/audit/audit-logger.js ACTION_TYPES (rollback_executed, agent_completed, gate_failed) so all transitions remain audit-trail compliant.
| Event | When | Hook |
|-------|------|------|
| deploy-start | Deploy initiated | Pre-validation |
| deploy-complete | Deploy successful | Post-notification |
| deploy-failed | Deploy failed | Error handling + rollback suggestion |
testing
Sprint Management — generic sprint capability for ANY bkit user. 16 sub-actions: init, start, status, watch, phase, iterate, qa, report, archive, list, feature, pause, resume, fork, help, master-plan. Triggers: sprint, sprint start, sprint init, sprint status, sprint list, 스프린트, 스프린트 시작, 스프린트 상태, スプリント, スプリント開始, スプリント状態, 冲刺, 冲刺开始, 冲刺状态, sprint, iniciar sprint, estado sprint, sprint, demarrer sprint, statut sprint, Sprint, Sprint starten, Sprint Status, sprint, avviare sprint, stato sprint, master plan, multi-sprint plan, sprint master plan, 마스터 플랜, 멀티 스프린트 계획, 스프린트 마스터 플랜, マスタープラン, マルチスプリント計画, スプリントマスタープラン, 主计划, 多冲刺计划, 冲刺主计划, plan maestro, plan multi-sprint, plan maestro sprint, plan maître, plan multi-sprint, plan maître sprint, Masterplan, Multi-Sprint-Plan, Sprint-Masterplan, piano principale, piano multi-sprint, piano principale sprint.
tools
CC CLI version upgrade impact analysis — research changes, analyze bkit impact, generate report. Triggers: cc-version-analysis, CC upgrade, version analysis, CC 버전 분석, 버전 영향.
testing
Manage PDCA checkpoints and rollback — create, list, restore for safe recovery. Rollback events are recorded via lib/audit/audit-logger ACTION_TYPES.rollback_executed. For sprint-level recovery, individual feature rollbacks may be triggered from within sprint phases (sprint itself is forward-only — terminal state is `archived`, not rolled back; v2.1.13). Triggers: rollback, checkpoint, restore, undo, 롤백, 체크포인트, 복원.
testing
QA Phase execution — L1-L5 test planning, generation, execution, and reporting for a single feature. For sprint-level QA (7-Layer dataFlowIntegrity / S1 gate across multiple features) use /sprint qa <sprintId> which delegates to sprint-qa-flow agent (v2.1.13). Triggers: qa phase, QA test, qa run, QA 실행, QAフェーズ, QA阶段, fase QA, phase QA, QA-Phase, fase QA.