Menü
Commit staged files only, generate message/PR, push to new branch
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use this skill whenever writing, reviewing, or refactoring ANY Go code — even small snippets. Triggers on: Go functions, structs, interfaces, goroutines, error handling, package design, HTTP handlers, CLI tools, or any .go file task. Don't skip this for 'simple' Go requests; idiomatic style matters even in small examples.
Remove defensive checks and silent fallbacks that only fire when upstream is broken
Enforce Go logging best practices for CLI tools, especially those doing high-volume file operations (read, write, parse, modify, scaffold). Use this skill whenever the user is writing, reviewing, or debugging Go CLI logging code — even if they only mention "how do I log this" or "add logging to my tool." Triggers on: slog, log/slog, zerolog, zap, logrus, --verbose flag, debug flag, file operation logging, structured logging, log levels, CLI output, scaffold tool, or any Go CLI that reads/writes/parses files. Always apply this skill before suggesting any logging approach in Go CLI context — don't rely on training data alone, the patterns here are authoritative for idiomatic Go 1.21+.
Best practices for building Go CLI applications using cobra and viper. Use this when creating new commands, handling flags, or implementing CLI workflows.
Testing best practices for Go projects including table-driven tests, mocking, and test organization. Use this when writing or reviewing test code.
Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.
| name | commit-push-pr |
| description | Commit staged files only, generate message/PR, push to new branch |
| disable-model-invocation | true |
| allowed-tools | ["Bash(git *)","Bash(gh *)","Read","Grep"] |
Verify staged changes: Run git diff --cached. If empty, stop and tell the user: "No staged files. Stage with git add first."
Analyze the diff: Read the staged diff carefully to understand what changed and why. This informs the commit message and PR body.
Branch: If $ARGUMENTS is provided, use it as the branch name. Otherwise, ask the user. Run git checkout -b <branch-name>.
Commit: Generate a Conventional Commit message from the staged diff following CLAUDE.md conventions (type(scope): description). Run git commit using a heredoc for the message.
Push: Run git push -u origin <branch-name>.
Create PR: Read .github/PULL_REQUEST_TEMPLATE.md, fill it in based on the commit(s), then run:
gh pr create --title "<title>" --body "<filled template>"
Confirm with the user before each destructive step (commit, push, PR creation).