phase-9-deployment
Skill605 starsChanged 3 months agoApache-2.0View on GitHub
Deploy to production — CI/CD pipelines, environment config, deployment strategies. Triggers: deployment, CI/CD, production, Vercel
- Reads credentials
- Installs packages
3 other projects use a version of this.
Adopted by
Most recently taken up by
- popup-studio-ai/bkit-claude-codeword for word, first seen Oct 8, 2026
- ww-w-ai/bkit-geminitheir own version, first seen Apr 9, 2026
- ww-w-ai/bkit-codextheir own version, first seen Feb 23, 2026
Other versions3 projects use a version of this.
Word for word · 1
- popup-studio-ai/bkit-claude-code★ 605100% same
Edited · 0
None found.
Wrote their own version · 2
- ww-w-ai/bkit-codex★ 69same name
- ww-w-ai/bkit-gemini★ 66same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository45 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/CLAUDE.mdCLAUDE.md
- auditSkill
- bkend-authSkill
- bkend-cookbookSkill
- bkend-dataSkill
- bkend-quickstartSkill
- bkend-storageSkill
- bkit-evalsSkill
- bkit-exploreSkill
- bkit-rulesSkill
- bkitSkill
- bkit-templatesSkill
- btwSkill
- cc-version-analysisSkill
- claude-code-learningSkill
- code-reviewSkill
- controlSkill
- deploySkill
- desktop-appSkill
- development-pipelineSkill
- dynamicSkill
- enterpriseSkill
- mobile-appSkill
- pdca-batchSkill
- pdca-fast-trackSkill
- pdcaSkill
- pdca-watchSkill
- phase-1-schemaSkill
- phase-2-conventionSkill
- phase-3-mockupSkill
- phase-4-apiSkill
- phase-5-design-systemSkill
- phase-6-ui-integrationSkill
- phase-7-seo-securitySkill
- phase-8-reviewSkill
- plan-plusSkill
- pm-discoverySkill
- qa-phaseSkill
- rollbackSkill
- skill-createSkill
- skill-statusSkill
- sprintSkill
- starterSkill
- zero-script-qaSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 36
Build: Create production build
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Phase 9: Deployment
Production deployment
Purpose
Deliver the completed application to users.
What to Do in This Phase
- Prepare Deployment Environment: Infrastructure setup
- Build: Create production build
- Execute Deployment: Actual deployment
- Verification: Post-deployment operation check
Deliverables
docs/02-design/
└── deployment-spec.md # Deployment specification
docs/04-report/
└── deployment-report.md # Deployment report
(Infrastructure config files)
├── vercel.json # Vercel configuration
├── Dockerfile # Docker configuration
└── k8s/ # Kubernetes configurationPDCA Application
- Plan: Establish deployment plan
- Design: Design deployment configuration
- Do: Execute deployment
- Check: Verify deployment
- Act: Problem resolution and completion report
Level-wise Application
| Level | Deployment Method |
| Starter | Static hosting (Netlify, GitHub Pages) |
| Dynamic | Vercel, Railway, etc. |
| Enterprise | Kubernetes, AWS ECS, etc. |
Starter Deployment (Static Hosting)
# GitHub Pages
npm run build
# Deploy dist/ folder to gh-pages branch
# Netlify
# Configure netlify.toml then connect GitDynamic Deployment (Vercel)
# Vercel CLI
npm i -g vercel
vercel
# Or auto-deploy via Git connectionEnterprise Deployment (Kubernetes)
# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: my-app:latestEnvironment Management
Environment Configuration Overview
┌─────────────────────────────────────────────────────────────┐
│ Environment Variable Flow │
├─────────────────────────────────────────────────────────────┤
│ │
│ Development │
│ └── .env.local → Developer local machine │
│ │
│ Staging │
│ └── CI/CD Secrets → Preview/Staging environment │
│ │
│ Production │
│ └── CI/CD Secrets → Production environment │
│ └── Vault/Secrets Manager (Enterprise) │
│ │
└─────────────────────────────────────────────────────────────┘Environment Classification
| Environment | Purpose | Data | Variable Source |
| Development | Local development | Test data | .env.local |
| Staging | Pre-deployment verification | Test data | CI/CD Secrets |
| Production | Live service | Real data | CI/CD Secrets + Vault |
CI/CD Environment Variable Configuration
GitHub Actions
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main, staging]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set environment
run: |
if [ "${{ github.ref }}" == "refs/heads/main" ]; then
echo "DEPLOY_ENV=production" >> $GITHUB_ENV
else
echo "DEPLOY_ENV=staging" >> $GITHUB_ENV
fi
- name: Build
env:
# General environment variables (can be exposed)
NEXT_PUBLIC_APP_URL: ${{ vars.APP_URL }}
NEXT_PUBLIC_API_URL: ${{ vars.API_URL }}
# Secrets (sensitive info)
DATABASE_URL: ${{ secrets.DATABASE_URL }}
AUTH_SECRET: ${{ secrets.AUTH_SECRET }}
API_STRIPE_SECRET: ${{ secrets.API_STRIPE_SECRET }}
run: npm run build
- name: Deploy to Vercel
env:
VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
run: |
npx vercel --prod --token=$VERCEL_TOKENGitHub Secrets Configuration Guide
Repository Settings → Secrets and variables → Actions
1. Repository secrets (sensitive info)
├── DATABASE_URL
├── AUTH_SECRET
├── API_STRIPE_SECRET
└── VERCEL_TOKEN
2. Repository variables (general settings)
├── APP_URL
├── API_URL
└── NODE_ENV
3. Environment-specific secrets
├── production/
│ ├── DATABASE_URL (production DB)
│ └── API_STRIPE_SECRET (live key)
└── staging/
├── DATABASE_URL (staging DB)
└── API_STRIPE_SECRET (test key)Vercel Environment Variable Configuration
Project Settings → Environment Variables
┌─────────────────┬─────────────┬─────────────┬─────────────┐
│ Variable Name │ Development │ Preview │ Production │
├─────────────────┼─────────────┼─────────────┼─────────────┤
│ DATABASE_URL │ dev-db │ staging-db │ prod-db │
│ AUTH_SECRET │ dev-secret │ stg-secret │ prod-secret │
│ API_STRIPE_* │ test key │ test key │ live key │
└─────────────────┴─────────────┴─────────────┴─────────────┘
Configuration steps:
1. Project Settings → Environment Variables
2. Add New Variable
3. Select environment (Development / Preview / Production)
4. Check Sensitive (if sensitive info)Secrets Management Strategy
Level-wise Secrets Management
| Level | Secrets Management Method | Tools |
| Starter | CI/CD platform Secrets | GitHub Secrets, Vercel |
| Dynamic | CI/CD + environment separation | GitHub Environments |
| Enterprise | Dedicated Secrets Manager | Vault, AWS Secrets Manager |
Starter/Dynamic: CI/CD Secrets
# Usage in GitHub Actions
- name: Deploy
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}Enterprise: HashiCorp Vault
# Fetch Secrets from Vault
- name: Import Secrets from Vault
uses: hashicorp/vault-action@v2
with:
url: https://vault.company.com
token: ${{ secrets.VAULT_TOKEN }}
secrets: |
secret/data/myapp/production db_password | DB_PASSWORD ;
secret/data/myapp/production api_key | API_KEYEnterprise: AWS Secrets Manager
// lib/secrets.ts
import { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";
const client = new SecretsManagerClient({ region: "ap-northeast-2" });
export async function getSecret(secretName: string): Promise<Record<string, string>> {
const command = new GetSecretValueCommand({ SecretId: secretName });
const response = await client.send(command);
if (response.SecretString) {
return JSON.parse(response.SecretString);
}
throw new Error(`Secret ${secretName} not found`);
}
// Usage
const dbSecrets = await getSecret("myapp/production/database");
// { host: "...", password: "...", ... }Environment-specific Build Configuration
Next.js Environment Configuration
// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
// Environment-specific settings
env: {
NEXT_PUBLIC_ENV: process.env.NODE_ENV,
},
// Environment-specific redirects
async redirects() {
if (process.env.NODE_ENV === 'production') {
return [
{ source: '/debug', destination: '/', permanent: false },
];
}
return [];
},
};
module.exports = nextConfig;Environment-specific API Endpoints
// lib/config.ts
const config = {
development: {
apiUrl: 'http://localhost:3001',
debug: true,
},
staging: {
apiUrl: 'https://api-staging.myapp.com',
debug: true,
},
production: {
apiUrl: 'https://api.myapp.com',
debug: false,
},
} as const;
type Environment = keyof typeof config;
const env = (process.env.NODE_ENV || 'development') as Environment;
export const appConfig = config[env];Environment Variable Validation (Pre-deployment)
Required Variable Check Script
#!/usr/bin/env node
// scripts/check-env.js
const REQUIRED_VARS = [
'DATABASE_URL',
'AUTH_SECRET',
'NEXT_PUBLIC_APP_URL'
];
const missing = REQUIRED_VARS.filter(v => !process.env[v]);
if (missing.length > 0) {
console.error('❌ Missing required environment variables:');
missing.forEach(v => console.error(` - ${v}`));
process.exit(1);
}
console.log('✅ All required environment variables are set');Validation in CI/CD
# GitHub Actions
- name: Validate Environment
run: node scripts/check-env.js
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
AUTH_SECRET: ${{ secrets.AUTH_SECRET }}
NEXT_PUBLIC_APP_URL: ${{ vars.APP_URL }}Environment Variable Management Checklist
Pre-deployment
- Secrets Registration
- DATABASE_URL (per environment)
- AUTH_SECRET (per environment)
- External API keys (per environment)
- Environment Separation
- Development / Staging / Production distinction
- Per-environment database separation
- Per-environment external service key separation (test/live)
- Validation
- Run required variable check script
- Build test
Post-deployment
- Operation Check
- Verify environment variables are injected correctly
- External service integration test
- Security Check
- Verify no sensitive info in logs
- Verify no server-only variables exposed to client
Deployment Checklist
Preparation
- Environment variable configuration (see checklist above)
- Domain connection
- SSL certificate
Deployment
- Build successful
- Deployment complete
- Health check passed
Verification
- Major feature operation check
- Error log review
- Performance monitoring
Rollback Plan
If problems occur:
1. Immediately rollback to previous version
2. Analyze root cause
3. Fix and redeployTemplate
See templates/pipeline/phase-9-deployment.template.md
After Completion
Project complete! Start new feature development cycle from Phase 1 as needed
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

