Mandatory verification protocol after code changes for Go projects. Use after any code modification to ensure quality.
Mandatory verification protocol for Go projects after any code modification. Triggers automatically after creating, modifying, or refactoring Go code files to ensure quality through formatting, linting, building, and testing.
/plugin marketplace add IvanTorresEdge/molcajete.ai/plugin install go@Molcajete.aiThis skill inherits all available tools. When active, it can use any tool Claude has access to.
This skill defines the mandatory verification steps that Go agents must perform after modifying code files.
Use this skill ALWAYS when:
Do NOT use when:
After completing code changes, agents MUST execute these steps IN ORDER:
make fmt
# or if Makefile not available:
go fmt ./...
Purpose: Ensure consistent code formatting using Go's official formatter.
make lint
# or if Makefile not available:
golangci-lint run
Purpose: Detect code quality issues, potential bugs, and style violations.
make build
# or if Makefile not available:
go build ./...
Purpose: Verify code compiles without errors. Go's compiler performs type checking.
make test
# or if Makefile not available:
go test ./path/to/modified/...
# or run all tests:
go test ./...
Purpose: Verify code changes do not break existing functionality.
TARGET: All steps must complete with ZERO errors and ZERO warnings.
If any step reports errors or warnings, proceed to Exception Handling.
When verification finds issues, follow this decision tree:
Issue Found During Verification
|
v
Was this issue caused
by current changes?
|
+------+------+
| |
YES NO
| |
v v
Fix it Is it in a file
now you modified?
|
+------+------+
| |
YES NO
| |
v v
Is it a Document and
small fix? report only
(< 10 lines) |
| |
+------+------+ v
| | DONE
YES NO (proceed with
| | task)
v v
Fix it Document,
now report,
recommend
separate task
Scenario 1: You add a new function and the linter reports an unused variable in your new code.
Scenario 2: You modify a file and discover a pre-existing lint warning (3 lines to fix) in a function you touched.
Scenario 3: You modify a file and discover 50+ lines of lint warnings throughout the file.
Scenario 4: Lint reports warnings in a file you did not modify.
Report verification results using this consistent format:
=== POST-CHANGE VERIFICATION ===
Format: [PASSED | FAILED | SKIPPED (reason)]
Lint: [PASSED | FAILED] ([X] errors, [Y] warnings)
Build: [PASSED | FAILED] ([X] errors)
Tests: [PASSED | FAILED] ([X]/[Y] passed)
Pre-existing issues: [NONE | count listed below]
[If issues exist, list them here]
=== [TASK COMPLETE | VERIFICATION FAILED] ===
=== POST-CHANGE VERIFICATION ===
Format: PASSED
Lint: PASSED (0 errors, 0 warnings)
Build: PASSED (0 errors)
Tests: PASSED (24/24)
Pre-existing issues: NONE
=== TASK COMPLETE ===
=== POST-CHANGE VERIFICATION ===
Format: PASSED
Lint: FAILED (0 errors caused by this change)
Build: PASSED (0 errors)
Tests: PASSED (24/24)
Pre-existing issues (not caused by this change):
- internal/legacy/handler.go: Line 45 - exported function without comment
- pkg/utils/strings.go: Lines 78-92 - ineffective assignment
These issues require structural changes beyond the scope of this task.
Recommend creating a separate cleanup task.
=== TASK COMPLETE ===
=== POST-CHANGE VERIFICATION ===
Format: PASSED
Lint: FAILED (2 errors, 1 warning)
Build: FAILED (1 error)
Tests: FAILED (22/24)
Issues to fix:
- cmd/server/main.go: Line 23 - undefined: Config
- internal/service/user.go: Line 45 - unused variable 'temp'
- internal/service/user.go: Line 67 - missing error check
=== VERIFICATION FAILED - FIX ISSUES BEFORE COMPLETING ===
Handle missing or failing commands gracefully:
| Situation | Status | Action |
|---|---|---|
| Command not found | SKIPPED (command not found) | Note and proceed to next step |
| Command timeout (> 5 min) | SKIPPED (timeout) | Note and proceed to next step |
| Execution error | SKIPPED (execution error: [reason]) | Note and proceed to next step |
=== POST-CHANGE VERIFICATION ===
Format: PASSED
Lint: SKIPPED (command not found - golangci-lint not installed)
Build: PASSED (0 errors)
Tests: PASSED (24/24)
Pre-existing issues: NONE
Note: Consider installing golangci-lint for full quality verification.
=== TASK COMPLETE ===
Go projects MUST use Makefile for build operations. Ensure these targets exist:
.PHONY: fmt lint build test
fmt:
go fmt ./...
lint:
golangci-lint run
build:
go build -o ./bin/app ./cmd/app
test:
go test -v ./...
# Combined verification target
verify: fmt lint build test
If Makefile targets are missing, fall back to direct commands but note in output.
make fmt over go fmt ./...Before completing any code-modifying task:
make fmt)This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.