What is the recommended format for error messages?

Error messages should follow a specific three-part pattern: [what's wrong]. [what's expected]. [example of correct usage].

How do I test these improved error messages?

The guide includes a testing pattern to verify that error messages contain the invalid input description, the expected format, and a concrete example.

Does this guide cover multi-line configurations?

Yes, the skill includes guidelines for multi-line YAML examples using newline characters within Go error strings to provide clear, readable context.

When should I include examples in my error messages?

You should always include examples for format/syntax errors, enum/choice fields, type mismatches, and complex configurations to help users fix the issue immediately.

Structured Error Messages

Name: Structured Error Messages
Author: githubnext

bygithubnext

•

273

开发者工具

Standardizes validation error messages to ensure they are actionable, clear, and include specific usage examples.

关于

This skill provides a comprehensive style guide and implementation pattern for creating user-friendly validation errors within the GitHub Agentic Workflows environment. It enforces a standardized three-part structure—identifying the problem, stating requirements, and providing a concrete example—to reduce developer friction and improve the end-user experience when configuration errors occur. By following these patterns, developers can ensure that every error message acts as a helpful guide rather than a dead end, featuring specific templates for format, type, enum, and complex configuration validations.

主要功能

273 GitHub stars
Best practices for dynamic content using Go type verbs
Self-documenting error message testing strategies
Standardized [what's wrong]. [what's expected]. [example] template
Guidelines for multi-line YAML configuration error formatting
Concrete patterns for format, type, and enum validation

使用场景

Refactoring vague 'invalid' errors into actionable developer guidance
Designing robust validation for complex MCP and tool configurations
Ensuring consistent error reporting across large, distributed Go projects

关于

主要功能

273 GitHub stars
Best practices for dynamic content using Go type verbs
Self-documenting error message testing strategies
Standardized [what's wrong]. [what's expected]. [example] template
Guidelines for multi-line YAML configuration error formatting
Concrete patterns for format, type, and enum validation

使用场景

Refactoring vague 'invalid' errors into actionable developer guidance
Designing robust validation for complex MCP and tool configurations
Ensuring consistent error reporting across large, distributed Go projects