next-featurelisted

# Next feature Recommend a capability someone can actually use, with enough detail to decide whether to build it. ## Understand the request - Follow the requested count and scope. Default to one recommendation; add at most two one-line alternatives only when they represent meaningful tradeoffs. - For a proposed feature, evaluate and sharpen that feature. For a supplied list, compare those items; respect a request to rank all of them. - Use the user's objective, constraints and stage of product. A prototype can justify an exploratory feature without existing customers or usage data. ## Ground the recommendation Reuse relevant context already provided. Otherwise inspect a small amount of available evidence: the product overview, relevant UI or command flow, implementation, and issues or feedback. Start with at most five targeted reads or searches; avoid whole-repository dumps. Stop once you understand current behavior, the gap, and a plausible delivery path. Expand only to resolve a specific uncertainty that could change the recommendation, or when asked for deeper research. Check that the capability is not already present. Code demonstrates implementation, not adoption or demand. Distinguish observed facts, user-reported needs and your hypotheses; never invent users, requests, metrics or conversion gains. Cite the one or two strongest available sources beside the reasoning. When access or context is missing, state the limitation. Ask one focused question if it determine