neneko-code-taste

Neneko Code Taste

Apply this skill when the user wants new Go code or a review to feel native to tRPC-Agent-Go (or to a project deliberately adopting its engineering style). The goal is a small, clear, compatible change whose public API and lifecycle semantics are intentional. Treat the target repository's local conventions as the final authority when they conflict with an example below.

Working loop

Before editing:

1. Identify the owning package and read its AGENTS.md, nearby constructors, options, interfaces, tests, and error paths. Search for an existing extension point before adding a new one.
2. State the contract that must remain stable: defaults, nil behavior, errors, cancellation, ordering, resource lifetime, and exported API.
3. Choose the smallest focused patch. Avoid unrelated refactors and avoid a new abstraction until its responsibility and ownership are clear.

While editing:

• Prefer concrete constructors; introduce an interface only when a consumer needs substitution or multiple implementations, and keep it consumer-owned.
• Keep implementation-specific types and configuration private to the owning package. Export only the narrow contract callers need.
• Put context.Context first in methods that accept it; propagate cancellation and do not store contexts in structs.
• Make goroutine, channel, timer, close, and shutdown ownership explicit. The creator owns cleanup unless the API documents a different contract.
• Return wrapped errors with lowercase, punctuation-free messages; use %w when callers need to inspect the cause. Do not silently discard meaningful errors.
• Match existing naming, option precedence, default initialization, copy/clone behavior, and Godoc/comment patterns.

After editing:

1. Add or update tests that prove observable contracts (including defaults, invalid input, errors, cancellation, concurrency, and lifecycle where relevant), not merely line coverage or private implementation details.
2. Run the narrowest relevant tests first, then repository formatting/import and lint checks. Use scripts/check.sh when it fits the target repository.
3. Perform a second-pass API/design review of the final diff: exported surface, abstraction/ownership, compatibility, context propagation, concurrency, error semantics, and unrelated churn. Report residual risks explicitly.