name: brian-feedback description: Capture quality signals from users — reactive when they flag issues or confirm accuracy, and proactive with a lightweight end-of-session check. user-invocable: false

brian-feedback

Capture quality signals — both reactive (user flags an issue) and proactive (end-of-session check).

When to use

Reactive triggers

• User signals retrieval was wrong: "that's not right", "that's outdated", "you're confusing X with Y"
• User signals retrieval was right: "yes exactly", "that's it", "perfect"
• User signals a gap: "you should know this", "why don't you remember that?"
• Any direct quality signal about Brian's retrieval or Claude's use of Brian

Proactive trigger

• At the natural close of a substantive session (before or alongside close_session)
• Maximum once per session. Never mid-conversation unless the user raises it.

Reactive capture — negative signals

When the user indicates retrieval was wrong, incomplete, or stale:

1. Acknowledge simply: "Got it — let me fix that"
2. Identify the specific memory or retrieval that failed if possible
3. Store feedback:

   store_memory(
     content: "User flagged retrieval failure: [specific description of what went wrong]",
     memory_type: "event",
     salience: 0.6,
     tags: ["feedback", "quality-signal-negative", "retrieval"]
   )
   

4. If the wrong memory can be identified, offer to delete or update it

Reactive capture — positive signals

When the user confirms something was recalled correctly or found useful:

store_memory(
  content: "User confirmed retrieval accurate: [what was confirmed]",
  memory_type: "event",
  salience: 0.4,
  tags: ["feedback", "quality-signal-positive"]
)

Low salience — this is signal data, not primary context.

Proactive capture — end of session

One question, lightly phrased. Not a survey. Examples:

• "Was Brian useful today, or anything that felt off?"
• "Did I pull up the right context for this, or did anything feel stale?"
• "Anything I should have remembered but didn't?"

Store the response:

store_memory(
  content: "Session feedback: [user's response]",
  memory_type: "event",
  salience: 0.4,
  tags: ["feedback", "session-feedback"]
)

Do not over-ask

Proactive feedback once per session maximum. If the user has already given reactive feedback during the session, skip the proactive ask — you already have their signal.

Relationship to backend feedback_collector

The backend has a feedback_collector passive soul that's injected alongside get_context responses. It instructs Claude to capture quality signals as event memories with tags ["feedback", "quality-signal-positive"] or ["feedback", "quality-signal-negative"]. This skill extends that pattern with proactive capture and more structured storage. They are complementary — the skill makes feedback collection consistent and reliable rather than depending on Claude reading and acting on tool response content.