메뉴
Use when creating a new branch, starting new feature work, fixing a bug on a new branch, or any situation where a branch needs to be created. Use when the user asks to "create a branch", "start a new branch", "branch off of X", or "make a branch for this work".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when implementing background jobs, task queues, scheduled jobs, retries, or any Redis-backed async worker in a Python backend service in this harness. arq is the chosen queue (async-native, Redis-backed). Replaces the old bullmq skill.
Use when creating CI/CD pipelines for any project. Use when asked to "set up CI/CD", "create a pipeline", "automate deployments", "configure GitHub Actions", "set up Vercel/Render/AWS", or similar. The harness is a polyglot monorepo — a Python (FastAPI + uv) backend in `apps/api/` and a TypeScript (Vite + pnpm) frontend in `apps/web/`. Pipelines run the two stacks as parallel lanes that join at a final gate.
Use when writing, reviewing, or editing a Dockerfile or docker-compose file. Use when asked to "containerize", "dockerize", "add Docker support", or "write a Dockerfile" for any application or service in this harness — FastAPI backend (Python + uv) or Vite frontend (TypeScript + pnpm, served as static assets).
Use when writing, reviewing, or refactoring TypeScript code on the frontend — especially when tempted to use `any`, type assertions, unvalidated casts, or when designing types, generics, utility types, or tsconfig settings. Backend code in this harness is Python, not TypeScript; see `effective-python` / `python-linting` for the backend equivalents.
FastAPI implementation guide. Load whenever building or modifying any backend HTTP service in this harness — defining routes, request/response models, dependencies, middleware, error handlers, lifespan events, or background tasks. Triggers include: APIRouter, Depends, FastAPI app instance, response_model, OpenAPI generation, async endpoint handlers. Use alongside `sqlalchemy`, `pydantic`, and `rest-api-design`.
Use when the developer advocate needs to verify the application can be cloned and run by a new engineer. Triggers include: adding a new application or service, changing docker-compose or Dockerfiles, changing environment variable handling, changing networking between services, adding or modifying Makefile targets / uv / pnpm scripts, changing the Python or Node toolchain pin, changing database schemas or Alembic migrations, or changing README/setup documentation.
| name | branch-from-main |
| description | Use when creating a new branch, starting new feature work, fixing a bug on a new branch, or any situation where a branch needs to be created. Use when the user asks to "create a branch", "start a new branch", "branch off of X", or "make a branch for this work". |
Every new branch must be based off the tip of main. No exceptions.
Always branch from main. Never branch from another feature branch, develop, staging, or any other branch — even if asked to.
git checkout maingit pull origin maingit checkout -b feature/your-branch-nameThat's it. Never skip steps 1 or 2.
Refuse. Explain the rule. Then do it correctly from main.
Do not comply even if:
Say: "All branches must be based off the tip of main. I'll create it from main."
Then run the 3 steps above.
Rebase it onto main using --onto:
git branch backup/your-branch-name # safety net first
git rebase --onto main <wrong-base> your-branch-name
This replays only your commits on top of main, discarding the wrong base entirely. The number of commits or conflicts does not change the requirement — rebase it regardless.
Do not suggest "just merge into main when done" as an alternative. That defers the problem and pollutes the PR diff with unrelated commits.
Any of these thoughts means you are about to violate the rule. Stop. Branch from main.