본문으로 건너뛰기
cccskills
무료GitHub에 공개

launch

You are a release engineer. Execute each phase in order. Each must fully complete before advancing. Do NOT ask for permission. Stop only if something is truly unfixable.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구GitHubDocker
설치 방법 보기

포함된 파일(1)

  • SKILL.md11.0 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Launch — Pre-flight Pipeline: Docker → Test → Lint → Security → Build → Commit → Push → Cleanup

Release engineer mode: execute each phase in order; each must fully complete before advancing. Do NOT ask for permission. Stop only if something is truly unfixable.


Phase 0 — Docker Build & Smoke Test (if applicable)

PROJECT_ROOT=$(git rev-parse --show-toplevel)
ls "$PROJECT_ROOT/Dockerfile" 2>/dev/null && echo "HAS_DOCKERFILE" || echo "NO_DOCKERFILE"

Skip this phase if no Dockerfile exists. Otherwise:

0a. Build images

Detect multiple services from docker-compose.yml. Build all:

cd "$PROJECT_ROOT"
docker build -t $(basename $PROJECT_ROOT)-api:local . 2>&1
# If dashboard/frontend Dockerfile exists:
docker build -t $(basename $PROJECT_ROOT)-dashboard:local ./dashboard 2>&1 || true

Fix build errors; iterate until all images build.

0b. Start stack

# Use docker-compose.yml or compose.yml if present
COMPOSE_FILE=$(ls docker-compose.yml compose.yml deploy/docker-compose.yml 2>/dev/null | head -1)
[ -n "$COMPOSE_FILE" ] && docker compose -f "$COMPOSE_FILE" up -d || docker compose up -d
docker compose ps

Expected: all services running/healthy.

0c. Run migrations (if applicable)

docker compose run --rm migrate 2>/dev/null || true

0d. Smoke test

Read the project instruction file or README.md for the health endpoint; fall back to common defaults:

curl -s http://localhost:8000/health 2>/dev/null || \
curl -s http://localhost:3000/health 2>/dev/null || \
curl -s http://localhost:8080/health 2>/dev/null || echo "No health endpoint found"

0e. Cleanup

docker compose down 2>/dev/null || true

GATE: All images build, containers healthy, smoke test passes.


Phase 1 — Tests

Run the test workflow, which will:

  1. Auto-start required Docker services (DB, Redis, etc.) for integration tests
  2. Run unit tests against real services — no DB mocks
  3. Run integration tests against a real Docker DB
  4. Run E2E tests against the full docker compose stack
  5. Loop until all thresholds are met with zero failures

Thresholds: Lines ≥ 95% | Functions ≥ 95% | Statements ≥ 95% | Branches ≥ 90%

GATE: The test workflow reports "COVERAGE MET ✅" with zero failures.


Phases 2–4 — Lint ‖ Security ‖ Build (fan out)

Phase 1 (tests) is the long pole and must pass first. Phases 2–4 — lint, security, build — are mutually independent (they read the tree, not each other's results), so run them in parallel via the fan-out ladder from the subagents skill: prefer the Workflow tool (one stage per phase, schema-validated return), else parallel Agent/Task subagents, else serial. Each returns { phase, status, findings[] }; all three must report passed before the gate-cache write below. The phase descriptions that follow define each one.


Phase 2 — Lint

Run the lint workflow. Fix all errors across frontend, backend, and type checks.

GATE: Zero lint errors remaining.


Phase 3 — Security

Run the security workflow. Fix critical/high vulnerabilities. Confirm no real secrets in source.

GATE: No critical/high vulns (outside documented known exceptions) AND no real secrets.


Phase 4 — Build

PROJECT_ROOT=$(git rev-parse --show-toplevel)
cd "$PROJECT_ROOT"

Detect and run applicable builds:

  • npm frontend: npm run build
  • npm backend: cd api && npm run build
  • Python: ./venv/bin/python -m build 2>/dev/null || true

Fix compiler errors; re-build only the failing target.

GATE: All applicable builds succeed with zero errors.

Phases 1–4 constitute a full gate pass. Record it so the gate-on-commit hook and the commit/push workflows skip re-running the gate:

python3 ~/100xprism/hooks/gate-pass.py 2>/dev/null || true

This writes a token for the current tree state (HEAD + tracked diff + untracked files), so any later edit re-arms the gate. Only run it when all of Phases 1–4 passed.


Phase 5 — Commit

Run the commit workflow. Stage, write, and create a conventional commit.


Phase 6 — Push & Deploy

Run the push workflow. Push, handle hooks, monitor CI/CD, auto-fix failures if needed.


Phase 6b — Deployment Verification

After CI/CD passes and deployment completes, run the full verification pipeline.

# Detect project instruction file
INSTRUCTION_FILE=$(for f in .claude/100xprism.yml CLAUDE.md AGENTS.md .cursorrules; do [ -f "$PROJECT_ROOT/$f" ] && echo "$PROJECT_ROOT/$f" && break; done)

Step 1 — Health checks

Read health endpoint URLs from the project instruction file, README, or common defaults:

# From project instruction file
[ -n "$INSTRUCTION_FILE" ] && grep -E "https?://[^ ]*/health" "$INSTRUCTION_FILE" 2>/dev/null | head -3

# Common defaults to try
# /health, /healthz, /api/health, /status

Hit each endpoint with a bounded exponential backoff loop — a fresh deploy may still be rolling out, so don't hammer at a fixed interval or wait forever:

HEALTH_URL="$1"   # resolved above
attempt=0; max_attempts=6; delay=2
until curl -fsS --max-time 5 "$HEALTH_URL" >/dev/null 2>&1; do
  attempt=$((attempt + 1))
  if [ "$attempt" -ge "$max_attempts" ]; then
    echo "Health check failed after $max_attempts attempts (~$((2 ** max_attempts))s)"; exit 1
  fi
  echo "Health not ready (attempt $attempt/$max_attempts) — retrying in ${delay}s"
  sleep "$delay"; delay=$((delay * 2))   # 2,4,8,16,32s — caps total wait, backs off cleanly
done
echo "Health OK after $attempt retr$([ "$attempt" = 1 ] && echo y || echo ies)"

Confirm HTTP 200 and a healthy response body.

If the loop exhausts max_attempts → trigger rollback (Step 4).

Step 2 — Smoke tests

If E2E or smoke tests exist, run a targeted subset against production:

# Detect smoke test locations
ls tests/smoke/ e2e/smoke/ tests/critical/ 2>/dev/null || true

Detection patterns: directories tests/smoke/, e2e/smoke/, tests/critical/; tagged tests @smoke, @critical, mark.smoke. If none exist, skip this step gracefully.

Run detected smoke tests against the production URL configured in the project instruction file:

# Look for production URL in project instruction file
[ -n "$INSTRUCTION_FILE" ] && grep -E "https?://[^ ]+" "$INSTRUCTION_FILE" 2>/dev/null | grep -iE "prod|production|live" | head -1

If smoke tests fail → trigger rollback (Step 4).

Step 3 — Metrics check

If a monitoring URL is configured in the project instruction file:

[ -n "$INSTRUCTION_FILE" ] && grep -iE "monitoring|grafana|datadog|newrelic" "$INSTRUCTION_FILE" 2>/dev/null | head -1

If found: note the monitoring URL for manual review, check error rate information if accessible via API, and flag if error rate appears elevated compared to normal. If no monitoring URL configured, skip this step gracefully.

Step 4 — Auto-rollback (on failure)

If any verification step fails:

echo "Deployment verification FAILED. Rolling back..."

# Revert the last commit (safe — creates a new commit, not destructive)
git revert HEAD --no-edit

# Push the revert
git push origin "$(git branch --show-current)"

After rollback:

  1. Re-run health checks to confirm rollback succeeded
  2. Report which verification step failed and why
  3. Provide full diagnosis
DEPLOYMENT FAILED — ROLLED BACK
Health:      ✅ PASSED / ❌ FAILED
Smoke tests: ✅ PASSED / ❌ FAILED (details)
Metrics:     ✅ NORMAL / ⚠️ ELEVATED / skipped
Action:      Auto-reverted commit <hash>
Rollback:    ✅ Health confirms rollback OK
STATUS: ROLLED BACK — human review required
Diagnosis:   [what failed and why]

If the project instruction file sets rollback: manual, report the failure but do NOT auto-revert. Wait for human decision.

Verification output (on success)

DEPLOYMENT VERIFIED
Health:      ✅ All endpoints responding (200)
Smoke tests: ✅ N/N passed | skipped
Metrics:     ✅ Error rate normal | skipped
STATUS: DEPLOYED & VERIFIED ✅

Phase 7 — Post-launch cleanup

7a. Close related GitHub issues

Scan commit messages from this launch for issue references:

git log $(git rev-parse HEAD~10 2>/dev/null || git rev-list --max-parents=0 HEAD)..HEAD \
  --format='%s %b' 2>/dev/null | grep -oE '#[0-9]+' | sort -u

For each referenced issue that is still open:

gh issue close <N> --comment "Resolved in $(git log -1 --format='%h') — $(git log -1 --format='%s')" 2>/dev/null || true

Skip issues already closed or in different repos.

7b. Update ROADMAP.md (if exists)

[ -f "$PROJECT_ROOT/ROADMAP.md" ] || exit 0
OPEN=$(gh issue list --state open --json number 2>/dev/null | python3 -c "import sys,json; print(len(json.load(sys.stdin)))" 2>/dev/null)
CLOSED=$(gh issue list --state closed --json number --limit 1000 2>/dev/null | python3 -c "import sys,json; print(len(json.load(sys.stdin)))" 2>/dev/null)
echo "Open: $OPEN | Closed: $CLOSED"

Update the issue count summary line in ROADMAP.md if counts changed. Update Last updated date.

7c. Update project instruction file (if features changed)

If new features were implemented or bugs fixed, update the feature audit table. Update Last updated date.

7d. Commit doc updates (if any changed)

git diff --name-only ROADMAP.md CLAUDE.md AGENTS.md .cursorrules 2>/dev/null | grep -q . && \
  git add ROADMAP.md CLAUDE.md AGENTS.md .cursorrules 2>/dev/null && \
  git commit -m "docs: update issue tracker counts and documentation after launch" && \
  git push origin main || true

Summary output

=== Launch Summary ===
Phase 0 Docker:     ✅ Built + healthy | skipped (no Dockerfile)
Phase 1 test:       ✅ COVERAGE MET (XX%)
Phase 2 lint:       ✅ PASSED
Phase 3 security:   ✅ PASSED
Phase 4 Build:      ✅ CLEAN
Phase 5 commit:     <short-hash> <message> | Review ✅ no critical issues | ⚠️ N minor notes
Phase 6 Push:       ✅ CI/CD passed | Health ✅ | Smoke ✅ | Metrics ✅
Phase 7 Cleanup:    Issues closed: #N, #M ✅ | Docs updated ✅ | no changes
Status:             LAUNCHED ✅

Troubleshooting

ProblemFix
Docker build failsFix Python/dependency or TypeScript errors, iterate
Coverage below 95%/test loops automatically — let it finish
Test fails after fixRe-run only that suite
Build fails with TS errorsRun npm run typecheck to isolate first
Pre-push hook failsFix → NEW commit → push again. Never --no-verify
Push rejected (non-fast-forward)git pull --rebase origin main then push
gh issue close failsIssue may be in a different repo — check gh repo view
ROADMAP counts don't matchRe-run gh issue list and reconcile manually

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Act as a Senior Accessibility Engineer to audit a page, component, or design against WCAG 2.2 AA. Produces a triaged finding list (critical/serious/moderate), focus-order map, contrast report, ARIA decision tree, and a screen-reader test plan. Use when shipping new UI, hardening an existing flow, or preparing for VPAT/accessibility conformance.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

rajitsaha/100xprism102026년 10월 14일 업데이트

When the user wants to plan, design, or implement an A/B test or experiment — "split test," "variant copy," "multivariate test," "hypothesis," "statistical significance," "how long should I run this test," or comparing two versions. For tracking implementation, see analytics-tracking. For page-level conversion optimization, see page-cro.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

rajitsaha/100xprism102026년 10월 14일 업데이트

When the user wants to generate, iterate, or scale ad creative — headlines, descriptions, primary text, full variations — for any paid platform; 'ad copy variations,' 'RSA headlines,' 'bulk ad copy,' 'creative testing,' 'write me some ads.' For campaign strategy and targeting, see paid-ads. For landing page copy, see copywriting.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

rajitsaha/100xprism102026년 10월 14일 업데이트

ai-seo

무료

When the user wants content cited by LLMs or surfaced in AI-generated answers — 'AI SEO,' 'AEO,' 'GEO,' 'LLMO,' 'answer engine optimization,' 'AI Overviews,' 'optimize for ChatGPT/Perplexity/Claude,' 'AI citations,' 'zero-click search.' For traditional technical/on-page audits, see seo-audit. For structured data, see schema-markup.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

rajitsaha/100xprism102026년 10월 14일 업데이트

When the user wants to set up, improve, or audit analytics tracking and measurement — "GA4," "conversion tracking," "event tracking," "UTM parameters," "tag manager," "GTM," "tracking plan," "attribution," "Mixpanel," "Segment," "are my events firing," or how to measure marketing results. For A/B test measurement, see ab-test-setup.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

rajitsaha/100xprism102026년 10월 14일 업데이트

architect

무료

Architectural decision advisor for cloud, data, and SaaS distributed systems. Use when the user asks "should we use X or Y", weighs a tradeoff, or needs a decision matrix, scaling analysis, cost-at-scale review, data-tier design, multi-tenancy model, or API/resilience guidance. For full technical blueprints, use enterprise-design.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

rajitsaha/100xprism102026년 10월 14일 업데이트

rajitsaha의 스킬 모두 보기

이 스킬의 문제 신고