[FEATURE] Let user proactively share session/interaction feedback

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude Code does particularly well or particularly poorly, I find myself wanting to send feedback about that. But the “How is Claude doing” prompt only comes up randomly, and the /feedback command is only for bugs.

Proposed Solution

I would like /feedback to be as general as it sounds :) or else a new command to be added (call it /rate or something), to rate the session or the most recent interaction, maybe with a short explanatory note.

Alternative Solutions

_No response_

Priority

Low - Nice to have

Feature Category

CLI commands and flags

Use Case Example

The scenario that prompted me to write this today:

1. Claude had solved type check errors that came up after a merge, which were present on neither branch before the merge
2. Claude's conclusion was that there were latent type inconsistencies on the base branch, which were exposed by the target branch
3. Claude added missing type parameter propagation and other small type annotation fixes which did resolve the issue — correctly, I think
4. I then asked Claude a subtle causal reasoning question: “Which specific changes merged in from main caused these type inconsistencies to be revealed in this branch? Reviewing git diff b94b373db...0348b8774 (the changes brought in by the merge) I don't see any changes in lib/recalculate.ts or lib/DependencyGraph.ts, and none involving the dependency graph in lib/Model-serialization.ts. I think we're doing the right thing now but I want to understand how we were missing this before, and towards that, what exactly caused us to cease to miss it with this merge.”
5. It worked on that for a while, and then came back with:

I honestly don't have a definitive answer. Let me summarize what I've found and what remains unclear: What we know: [...] What I can't explain: [...] Possible theories (but I can't confirm any): [...] I don't have a satisfying answer for exactly what mechanism caused TypeScript to start flagging these errors after the merge. The errors we fixed were genuine type inconsistencies that should have been caught earlier, but I can't pinpoint what specifically triggered their discovery.

... which is _excellent!_ It _is_ a difficult question, and a frank surrender is much preferable to the _confidently stated but incorrect_ claims that LLMs often serve up in situations like this.

So I would love to give a positive-feedback signal about this. But there isn't a way for me to do it.

Additional Context

Confession: I fibbed a little with the checkbox: there _is_ already #8528 which does request roughly this feature. But I don't want to thumbs-up that (and it would be misleading if I did), because that issue is only 10% the feature suggestion (which I like) and 90% anger and contempt (which I don't).