Skip to content
cccskills
FreePublished on GitHub

gh-commit

Review git changes and split them into semantic commits with clear messages. Use when the user asks to commit work, clean up local history, or group a mixed diff into logical commits. Do not commit on main or master unless the user explicitly asks.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573 stars(GitHub 573 + cccskills 0)

Run score Not tested

See how to install

Files included (2)

  • SKILL.md2.2 KB
  • agents/openai.yaml198 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

GH Commit

Goal

Turn the current working tree into a small set of clean commits without mixing unrelated changes.

Workflow

  1. Verify git context.
  • Run git rev-parse --show-toplevel and git status -sb.
  • Read the branch with git branch --show-current.
  • If the branch is main or master, stop and ask the user to switch/create a branch (recommend codex/...) unless they explicitly asked to commit on that branch.
  1. Inspect all changes before staging anything.
  • Run git diff --stat and git diff --cached --stat.
  • List untracked files with git ls-files --others --exclude-standard.
  • Read actual hunks with git diff and git diff --cached.
  • Include untracked files in the review (read them if needed) so commit grouping decisions cover the full diff.
  1. Propose semantic commit groups.
  • Group by intent, not just file type (for example: bug fix, refactor, tests, docs).
  • Keep user-authored unrelated work separate.
  • Call out any files that need partial staging because they contain mixed concerns.
  1. Create each commit group.
  • Stage only the files or hunks for that group (git add <paths> or git add -p).
  • Verify exactly what is staged with git diff --cached --stat and git diff --cached.
  • Commit with a concise imperative message.
  • Prefer type(scope): summary when the change has an obvious type/scope; otherwise use a clear plain-English summary.
  1. Repeat until done.
  • After each commit, re-check git status -sb.
  • Continue until all intended changes are committed or intentionally left uncommitted.
  1. Report the result.
  • List the commit SHAs and messages in order.
  • Note any remaining staged/unstaged/untracked files.

Safety Rules

  • Avoid git add -A unless the entire remaining diff belongs in one commit.
  • Use partial staging when a file mixes multiple concerns.
  • Do not rewrite or discard user changes unless explicitly asked.
  • If grouping is ambiguous, ask before committing.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Meet or work with Assistant, the user's relaxed ongoing work support. Use when the user invokes Assistant, starts or resumes an Assistant chat, asks what they should know, wants proactive work awareness, asks for reply drafts, asks to keep an eye on work, or needs follow-up/check-in help. On first contact, start with exactly "Hi, I'm your assistant." then decide whether onboarding is brand new, partial, or already established.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Audit, de-slop, parameterize, modularize, or safely clean up AI-generated or AI-shaped backend/general code. Use for Python, TypeScript, or other implementation diffs that may contain duplicate helpers, fixture hacks, hard-coded test data, over-defensive control flow, broad exception wrappers, config-bag or boolean-mode soup, speculative scaffolding, hallucinated APIs/dependencies, local-idiom drift, brittle tests, or maintainability/safety/performance gaps after a feature, bugfix, prototype, or agent pass.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Audit AI-generated, AI-shaped, or AI-looking frontend code, UI screenshots, and design diffs. Use for prompts like "audit AI frontend", "de-slop UI", "componentize this screen", "parameterize this React/Tailwind/shadcn UI", "make it responsive/accessible", or "review design-system drift"; check component APIs, reusable props/data models, modular composition, shared primitives/tokens, responsive resilience, accessibility, copy quality, hard-coded fixture screens, one-off CSS piles, and generic cards/gradients/fonts.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Audit pasted chatbot output, AI-cleanup diffs, wiki drafts, Markdown/MDX/docs, and source-backed articles for generic AI fluff, LLM writing tells, weak audience model, lack of theory of mind, inflated significance, vague attribution, leaked tokens, placeholders, broken markup, fabricated or mismatched citations, and detector false positives. Use for requests like "AI writing audit", "check for AI slop", "find writing fluff", "does this sound like ChatGPT", "cleanup LLM tells", "make this less generic", "verify these citations", "detector flagged this", or text containing turn0search0, oaicite, oai_citation, contentReference, utm_source=chatgpt.com, malformed references, or wrong target-format markup.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Help address review/issue comments on the open GitHub PR for the current branch using `oai_gh` or `gh`; verify auth first and prompt the user to authenticate if not logged in.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `oai_gh` or `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.

The English summary is being prepared. Showing the original description.

jxnl/personal-monorepo-template573Updated Jun 23, 2026

See all skills by jxnl

Report a problem with this skill