golang-cli-review
starsforks
How to install golang-cli-review?
asteroid-belt/skulto/golang-cli-review
$npx -y skills add asteroid-belt/skulto --skill golang-cli-reviewComprehensive code review for Golang CLI applications. Produces an actionable checklist covering error handling, CLI framework patterns (Cobra/urfave), testing, performance, security, and Go idioms. TRIGGERS: Review Go CLI, review golang command-line, code review .go CLI, audit C
SKILL.md
| 1 | # Go CLI Code Review |
| 2 | |
| 3 | Review Go CLI applications and produce an actionable checklist of findings. |
| 4 | |
| 5 | ## Review Workflow |
| 6 | |
| 7 | 1. **Gather code** - Read all Go files in the CLI project |
| 8 | 2. **Analyze** - Evaluate against review categories (see below) |
| 9 | 3. **Produce checklist** - Use template from [references/review-checklist.md](references/review-checklist.md) |
| 10 | |
| 11 | ## Review Categories |
| 12 | |
| 13 | Evaluate each area systematically: |
| 14 | |
| 15 | ### CLI Structure & Framework |
| 16 | - Framework usage (prefer Cobra for complex CLIs) |
| 17 | - Command hierarchy and discoverability |
| 18 | - Help text quality with examples |
| 19 | - Version command following semver |
| 20 | |
| 21 | ### Error Handling |
| 22 | - RunE vs Run (must return errors) |
| 23 | - Error wrapping with `%w` and context |
| 24 | - User-facing error actionability |
| 25 | - Meaningful exit codes (0=success, 1=error, 2=usage) |
| 26 | - No panics in normal paths |
| 27 | |
| 28 | ### Flag & Argument Design |
| 29 | - Lowercase-kebab-case naming |
| 30 | - Short flags for common options (`-v`, `-o`, `-q`) |
| 31 | - Required flags marked and validated early |
| 32 | - Sensible defaults |
| 33 | - Clear descriptions |
| 34 | |
| 35 | ### Input/Output |
| 36 | - stderr for errors/progress, stdout for data |
| 37 | - Machine-readable output support (`--json`, `--format`) |
| 38 | - Quiet and verbose mode support |
| 39 | - Non-TTY mode handling (no prompts) |
| 40 | |
| 41 | ### Security |
| 42 | - Secrets via env vars or files, never flags |
| 43 | - Path traversal prevention |
| 44 | - No shell injection |
| 45 | - URL scheme validation |
| 46 | - No sensitive data in logs |
| 47 | |
| 48 | ### Testing |
| 49 | - Command-level unit tests |
| 50 | - Error path coverage |
| 51 | - Integration tests for critical flows |
| 52 | |
| 53 | ### Performance & Resources |
| 54 | - Context-based cancellation |
| 55 | - Signal handling (SIGINT/SIGTERM) |
| 56 | - Proper resource cleanup (defer) |
| 57 | - No goroutine leaks |
| 58 | |
| 59 | ### Go Idioms |
| 60 | - Effective Go style compliance |
| 61 | - Immediate error handling |
| 62 | - Package naming conventions |
| 63 | - Interface/struct patterns |
| 64 | |
| 65 | ## Reference Material |
| 66 | |
| 67 | For patterns and examples, see [references/cli-patterns.md](references/cli-patterns.md). |
| 68 | |
| 69 | ## Output Format |
| 70 | |
| 71 | Use the checklist template from [references/review-checklist.md](references/review-checklist.md): |
| 72 | |
| 73 | ``` |
| 74 | ## Critical Issues |
| 75 | - [ ] **[C1]** `file.go:123` - Description |
| 76 | - **Impact:** ... |
| 77 | - **Fix:** ... |
| 78 | |
| 79 | ## Warnings |
| 80 | - [ ] **[W1]** `file.go:45` - Description |
| 81 | - **Why:** ... |
| 82 | - **Fix:** ... |
| 83 | |
| 84 | ## Suggestions |
| 85 | - [ ] **[S1]** `file.go:78` - Description |
| 86 | - **Consider:** ... |
| 87 | |
| 88 | ## Positive Patterns |
| 89 | - **[P1]** `file.go:90` - What was done well |
| 90 | ``` |
| 91 | |
| 92 | Severity levels: |
| 93 | - **Critical**: Security issues, crashes, data loss - must fix |
| 94 | - **Warning**: Bugs, anti-patterns, maintenance concerns - should fix |
| 95 | - **Suggestion**: Style, optimization, minor improvements - nice to have |
| 96 | - **Positive**: Good practices worth highlighting |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
