القائمة
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.