RFC 9457 Problem Details Author

Use this skill when the user asks to:

• •return API errors over HTTP (or similar) in a structured way
• •define a problem-details schema/payload
• •map internal errors to HTTP status codes
• •standardize error responses across handlers/services

Mandatory references (read in order)

1. •references/nonnegotiables.md
2. •references/doterr.md
3. •references/clearpath.md (production code only)
4. •references/go-dt-paths.md (only if paths/files appear in metadata)
5. •references/rfc9457-package-notes.md (go-rfc9457 catalog notes)

Core requirements

• •Prefer go-rfc9457 for Problem Details instead of ad-hoc maps/structs.
• •Do not leak internal error strings; use stable sentinels + metadata.
• •Map known sentinel errors to stable type identifiers and HTTP status codes.
• •Include only safe details in responses (no secrets, tokens, internal stack traces).

Design guidance (default)

When designing problem details:

• •Define a small set of stable problem type values (URIs or uri-like strings).
• •Use title as a short, stable human label; use detail for request-specific explanation (safe).
• •Use instance when you have a request id / trace id / correlation id.
• •Add extensions/metadata keys for machine-consumable specifics (validated fields, limits, etc.).

What to deliver

When implementing:

• •Provide the Problem Details builder/mapping code (often a function that accepts error and request context).
• •Provide handler examples showing how to return it consistently.
• •Provide tests if requested (tests follow references/testing.md rules).

Self-check before final output

• •No compound if init; cond {} forms.
• •No ignored errors.
• •Uses doterr for internal errors and go-rfc9457 for external representation.
• •Problem response does not expose sensitive/internal information.