Conciseness

The same swallow-errors rule is stated three times ('Never `catch(e) {}` without logging or re-throwing', 'an empty catch must become an explicit log, handling branch, returned error, or rethrow', 'Never swallow errors: do not use an empty `catch`'), and a noise heading '## **Priority: P1 (HIGH)**' adds no guidance. Beyond 'minor trimming' (anchor 4), though the body is otherwise lean with no padding of known concepts.

Actionability

Some concrete guidance exists ('fmt.Errorf("process: %w", err)', "new Error('msg', { cause })", 'SCREAMING_SNAKE_CASE IDs (ORDER_PAYMENT_FAILED)', 'Use `400` with specific details'), but the core deliverable is broken: '**Standard Shape**: APIs must return standardized JSON envelope:' ends in a dangling colon with no shape shown inline, so a key detail is missing.

Workflow Clarity

A standards skill organized by layer with clear boundary rules ('API Layer: Map domain errors to HTTP responses globally', 'Domain Layer: Throw pure business errors', 'Infra Layer: Wrap 3rd-party exceptions') and a closing checklist. Not 5 because the dangling colon and the P1 heading noise introduce minor incoherence in an otherwise simple, single-purpose skill.

Progressive Disclosure

Both referenced files ([implementation examples](references/implementation.md), [API Error Contract](references/api-error-contract.md)) are real and one level deep, with a dedicated References section. Not 5 because the two files are largely redundant (both show the envelope) and describe slightly different shapes ('code/message/traceId' vs 'code/message/traceId/details').

Specificity

Names several concrete capability areas ('error design, response shapes, error codes, and boundary placement across API, domain, and infrastructure layers') plus concrete actions in the use-when clause ('defining error hierarchies, wrapping exceptions, building standardized error responses'). Not 5 because the opening sentence describes topical coverage rather than enumerating multiple concrete actions.

Completeness

Clearly answers both: 'what' ('Cross-cutting standards for error design, response shapes, error codes, and boundary placement...') and an explicit 'when' with concrete trigger phrases ('Use when defining error hierarchies, wrapping exceptions, building standardized error responses, or placing error boundaries in layered architectures').

Trigger Term Quality

Good natural keyword coverage: 'defining error hierarchies', 'wrapping exceptions', 'building standardized error responses', 'placing error boundaries', 'error codes'. Not 5 because common variations users say ('try/catch', 'catch', language-specific exception terms) are absent.

Distinctiveness Conflict Risk

The layer-boundary and error-code framing carves a mostly distinct niche, but 'wrapping exceptions' and generic error-handling phrasing could overlap with language-specific error-handling or logging skills. Minor overlap risk, above anchor 3.