Menu
Remove defensive checks and silent fallbacks that only fire when upstream is broken
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | fail-fast |
| description | Remove defensive checks and silent fallbacks that only fire when upstream is broken |
Scan the code in scope (current changes by default, or files/paths given as args) and remove defensive code that hides bugs.
x is set, if x == nil and if x == "" inside the callee is dead defensive code.if x == "" { x = y }; if x == "" { x = z }). Usually a sign the author didn't trust their own invariants.if len(items) > 0 when the field is legitimately optional in config).git diff / git status and work on what's changed.// populated by the runner before this is called). Don't over-comment.If deleting a check would only change behavior when something upstream is broken, delete the check.
Report what you removed and why, briefly. Don't restate the rule of thumb in the report — show the concrete before/after reasoning per site.
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.
Commit staged files only, generate message/PR, push to new branch
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.