메뉴
Use to push changes from `dev` to `main`. This handles the full release loop: local checks, commit to `dev`, merge `dev` into `main`, push `main`, watch CI, and return back to `dev` locally.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when asked to explain or summarize a technical concept quickly — "tldr", "what is", "quick overview", "how does X work" — for concepts, not for deep tutorials, debugging, or code-writing tasks
Use when a GitHub Actions / CI run is failing (red X, "failure", "cancelled") on the current branch, when the user asks to "fix CI", "perbaiki CI", "CI merah", "workflow gagal", or when a push/PR shows failing checks. Use before any patch when the failure cause is unknown — read the failing log first, never guess the symptom. Covers gh CLI, failed workflow logs, Storybook/a11y/color-contrast, lint, typecheck, build, and test failures in the UMKM Cepat `Quality` workflow.
Use to commit and push changes on the `dev` branch. Handles local verification, Conventional Commits, pushing, and watching CI. Incorporates CI fixing flow if the push fails CI checks.
Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.
| name | push-main |
| description | Use to push changes from `dev` to `main`. This handles the full release loop: local checks, commit to `dev`, merge `dev` into `main`, push `main`, watch CI, and return back to `dev` locally. |
Use this skill when the work on dev is complete, and it is time to release or deploy to main.
Ensure dev is in a clean state and all local changes are committed and pushed successfully:
Follow the @.agents/skills/push-dev skill workflow first (i.e. bun run check, git add, git commit with Conventional Commits, and git push origin dev).
Do not proceed to step 2 if dev fails CI.
Checkout the main branch, ensure it's up to date, and merge dev into it:
git checkout main
git pull origin main
git merge dev --no-edit
If there are merge conflicts, resolve them locally before continuing.
Ensure the combined codebase is completely healthy:
bun run check
If this fails, fix the errors on main and commit them before pushing.
Push the newly merged main branch to origin:
git push origin main
Verify the deploy/workflow succeeds on main. Find the newest run and block on it so you never stop mid-run waiting for a re-prompt:
RUN_ID=$(gh run list --branch main --limit 1 --json databaseId --jq '.[0].databaseId')
gh run watch "$RUN_ID" --exit-status # blocks until run finishes; exits non-zero on failure
gh run watch --exit-status is the gate. Do not gh run list and stop — that snapshot returns while the run is still in progress and forces the user to re-prompt you. Always block until the run reports a terminal state.
If CI fails, follow the @.agents/skills/fix-ci procedures. View failing logs (gh run view "$RUN_ID" --log-failed), commit a minimal fix, push again, then watch the new run to completion — loop until green.
Always leave the local worktree in the active development branch:
git checkout dev
If you had to apply CI fixes directly to main, make sure to merge those fixes back to dev locally (git merge main) and push them.