القائمة
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.
التثبيت باستخدام 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 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 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-dev |
| description | 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 this skill whenever you need to commit and push local changes to the dev branch.
Before staging or committing, run local checks to ensure the codebase compiles:
bun run check
If you know exactly which files you worked on — stage only those files. Never blindly stage everything when you have context:
git add src/components/foo.tsx src/lib/bar.ts # only what you touched
If you have no session context (e.g. fresh agent, resumed session, or user asked to commit all) — inspect first, then stage all changed files:
git status --short # review what is changed
git add -A # stage everything
When in doubt, run git diff --stat and use judgment. Do not silently stage unrelated files.
Construct the commit message using the Conventional Commits specification.
Format: type(scope): description
All commits must end with:
Co-Authored-By: Claude <noreply@anthropic.com>
Example command:
git commit -m "feat(auth): add email verification
Co-Authored-By: Claude <noreply@anthropic.com>"
Push your branch to origin:
git push origin dev
After pushing, 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 dev --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 the run failed, invoke @.agents/skills/fix-ci to view logs (gh run view "$RUN_ID" --log-failed), apply a minimal fix, push again, then watch the new run to completion — loop until green.