cg-error-management

Audits and refactors Go error handling against AppError wrapper and Result envelope standards.

Updated May 16, 2026
One-click install
npx skills add https://github.com/alimtvnetwork/img-pdf-v2 --skill cg-error-management-alimtvnetwork
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: cg-error-management
Source: https://github.com/alimtvnetwork/img-pdf-v2/tree/main/.agents/skills/cg-error-management
Command: npx skills add https://github.com/alimtvnetwork/img-pdf-v2 --skill cg-error-management-alimtvnetwork

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Enforcing consistent error management across a large Go repository is tedious and error-prone: bare panics, raw error returns, and ad-hoc multi-value returns slip through code review. This Skill autonomously audits, refactors, and validates repository-wide error handling against the rules defined in 02-spec/03-error-manage/. ## Core Features & Use Cases - Invariant Enforcement: Detects and eliminates bare panics, os.Exit calls, and raw standard library error returns, replacing them with structured *appfault.AppError wrappers carrying Op, Code, Type, Severity, and Cause context. - Result Envelope Refactoring: Converts multi-value returns like (T, error) into typed appfault.Result[T], ResultSlice[T], or ResultMap[K, V] containers with pointer-receiver predicate methods such as IsFailure, IsEmpty, and IsCountOtherThan. - Targeted Verification: Validates only modified files via linter-scripts/check-error-management.py instead of running the full CI/CD pipeline, and records changes atomically in .ai-memory/temp/recent-file-changes.json. - Use Case: After adding a new Go package, run this Skill to sweep the package for banned error patterns, refactor returns into Result envelopes, define reusable types in types.go, and commit everything in a single atomic push. ## Quick Start Audit the Go files in my new package for banned error patterns, refactor them to use AppError wrappers and Result envelopes, verify with the targeted linter, and commit the changes.

Frequently Asked Questions about cg-error-management

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce consistent error handling across a Go repository?

Define structured error wrappers like appfault.AppError carrying Op, Code, Type, Severity, and Cause, then ban raw error returns and bare panics. Validate modified files with a targeted linter such as check-error-management.py instead of running the full CI pipeline.

How to replace (T, error) return values in Go with a Result type?

Wrap returns in generic containers like appfault.Result[T], ResultSlice[T], or ResultMap[K, V] and expose predicate methods such as IsFailure, IsSuccess, IsEmpty, and IsCountOtherThan on pointer receivers. Define reusable aliases in a dedicated types.go file per package.

Why should Result methods use pointer receivers in Go?

Pointer receivers let nil receivers return safe canonical defaults instead of panicking: IsFailure returns true, IsSuccess returns false, Count returns 0, and AppError returns nil. Value receivers on nil Results cause nil pointer dereference panics.

Can I run go test or go build to verify error handling refactors?

No, this workflow strictly bans running tests, builds, and the full CI/CD runner during routine refactoring turns. Verification happens only through targeted file-level linters on modified files, with full testing deferred to CI/CD.

What are the limitations of automated error handling audits?

The audit enforces structural patterns like wrappers and envelopes but cannot judge whether error codes, severity levels, or messages are semantically correct for the business domain. Human review is still needed for contextual error design decisions.