القائمة
Use when committing code — writing commit messages, staging, or reviewing commits before push.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Remove signs of AI-generated writing from text — rhythm, sentence mechanics, contrast frames, and stock AI vocabulary. Use when editing or reviewing text to make it sound more natural and human-written.
Refactor code safely using clean code principles and design patterns. Use this skill whenever the user asks to refactor, clean up, simplify, restructure, modernize, or "improve" existing code; whenever they complain code is messy, hard to read, hard to test, duplicated, or "spaghetti"; whenever they ask which design pattern to apply; and during code review when suggesting structural improvements. Also use after writing new code
Run, test, and eval the xtras plugin skills (x-humanizer, clean-code-refactoring). Use when asked to run a skill, test or verify a skill change, add an eval case, or red-green build a skill. The driver launches each skill headlessly via claude -p in a throwaway workspace and grades the output with deterministic checks.
استنادا إلى تصنيف SOC المهني
| name | x-commit |
| description | Use when committing code — writing commit messages, staging, or reviewing commits before push. |
Commit msg = for person reading git log 6 months later. Tell why change exists — diff shows what/how.
git status + git diff first. Never git add -A / git add ..
git add files from current task. Leave other unstaged/untracked changes alone./commit): stage all, unless incomplete features (half-written code, TODO stubs, broken imports). Warn user, commit only complete stuff. If user insists, commit what they ask.git commit --no-verify.docs/superpowers/ etc.) — those are ephemeral agent guidance, not project docs.Try to split into as many atomic commits as possible. If there is a list of features (e.g. "Implemented X, Y, and Z types"), split each one into a separate commit.
IT IS ABSOLUTELY IMPERATIVE THAT IF YOU EVER SAY "+" OR "and" OR ANYTHING SIMILAR IN A COMMIT MESSAGE (or your description of it would include that), SPLIT IT INTO MULTIPLE COMMITS.
Split by motivation, not subsystem. Different whys = different commits. Same why = same commit. "Fix X, Fixed Y" = 2 commits. "Build X, needs A+B+C" = 1 commit if the code won't work without A+B+C; 3 commits if A, B, and C can exist independently. "Crash recovery + its error reporting" = 2 commits. "Fix typo + add feature" = 2 commits.
Don't merge by code proximity. Same function/file ≠ same commit if different problems. Interleaved changes → git add -p or commit one feature first, then other. Trap: "shared infrastructure / same loop" ≠ same why.
Single commit needs VERY good reason. ALWAYS prefer splitting the code hunks into as many commits as possible.
:gitmoji: type(scope): imperative description
GitHub shortcode + Conventional Commits. Prefer specific gitmojis (:passport_control: not :sparkles:, :rocket: not :wrench:).
| Gitmoji | Use |
|---|---|
| :sparkles: | New feature |
| :bug: | Bug fix |
| :ambulance: | Critical hotfix |
| :recycle: | Refactor |
| :fire: | Remove code/files |
| :zap: | Perf |
| :memo: | Docs |
| :white_check_mark: | Tests |
| :arrow_up: / :arrow_down: | Dep upgrade/downgrade |
| :lock: | Security |
| :boom: | Breaking change |
| :pencil2: | Typo |
| :lipstick: | UI/style |
| :art: | Code style |
| :wrench: | Config |
| :construction_worker: | CI/build |
| :truck: | Move/rename |
Niche gitmojis: https://gitmoji.dev/
Independent but related. Gitmoji can be more specific than type: :ambulance: fix(auth): — general fix type, specific :ambulance: emoji.
: — :bug: fix(auth): handle null user:pencil2: fix(docs): correct "recieve" → "receive")# BAD: says what
:bug: fix(auth): add null check before accessing user.email
# GOOD: says why
:bug: fix(auth): prevent crash when user session expires
# BAD: wrong gitmoji + type
:sparkles: feat(deps): upgrade React to 19.0
# GOOD
:arrow_up: build(deps): upgrade React to 19.0
Only when subject alone doesn't explain why. Use for: bugs, non-obvious decisions, breaking changes, wide blast radius. Skip for obvious changes.
:bug: fix(orders): prevent duplicate submissions on double-click
Users creating duplicate orders clicking Submit before first request
completed. Debouncing insufficient — slow network extended vulnerable window.
Disable button on first click, re-enable on error. Chose this over
request deduplication for immediate visual feedback.
Never heredocs (cat <<'EOF'). Bash quoting + heredocs = syntax errors + token waste. Use: git commit -m "subject\n\nbody".