/han-feedback

name: han-feedback
description: >
  Capture structured feedback on the Han skills and agents used in the current session and optionally post it as a
  GitHub issue to testdouble/han. Use at the end of any session where one or more han-* skills or agents ran, to rate a
  run, log what worked and what didn't, or submit observations for maintainers. Does not review code, investigate bugs,
  or research options; use code-review, investigate, or research for those. Does not provide feedback on skills or
  agents from non-Han plugins.
allowed-tools:
  Read, Write, Bash(ls *), Bash(mkdir *), Bash(gh *), Bash(date *),
  Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")

Project Context

• Today's date: !`date +%Y-%m-%d`
• personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
• project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Capture Feedback

Operating Principles

• _*The whole han-* family is in scope._* Capture skills and agents from every Han plugin (`han-core`, `han-planning`,

`han-coding`, `han-github`, `han-reporting`, `han-feedback`, and any future `han-*` plugin). Skills and agents from non-Han plugins are out of scope.

• **Invocations count, not completions.** A skill or agent is considered used if it appeared in the session, regardless

of whether it finished or was cancelled. Feedback on a partial run is still feedback.

• **Agents count even when a skill dispatched them.** Most Han agents run because a skill dispatched them. Those agents

are still in scope; record which ones contributed so the feedback names where specialist value came from.

• **Conservative defaults on posting.** The feedback directory is user-space. The posting target is a public GitHub

repository. Ambiguous confirmation is treated as a stop, not a go.

• **One file per day, updated in place.** There is one feedback file per day per set of components. A file that already

exists for today is updatable, not closed: when the session continued past it, or the user asks for a compiled report, read it and update it in place rather than skipping. Never overwrite what is there. Skip only when nothing new has happened since that file was written.

• **Compacted sessions limit visibility.** The skill can only see turns present in the context window. If the session

was compacted before running this skill, earlier invocations may not be visible.

Step 1: Identify Han skills and agents used this session

Look back through the conversation for any use of a Han plugin component. A component counts as used if it was invoked, regardless of whether it completed or was cancelled.

**Han skills.** Look for invocations of skills namespaced to any `han-*` plugin. The namespace is the plugin name followed by a colon: `han-core:`, `han-planning:`, `han-coding:`, `han-github:`, `han-reporting:`, `han-feedback:`, and the same shape for any future `han-*` plugin (treat a bare `han:` prefix as Han too). Watch for slash-command invocations (like `/han-planning:plan-a-feature`), messages showing a skill launching (like "Launching skill: han-planning:plan-a-feature"), and any output that identifies a specific Han skill ran.

**Han agents.** Look for dispatches of agents from any `han-*` plugin. For example, an `Agent` tool call whose `subagent_type` is `han-core:adversarial-security-analyst`, or skill output naming a Han agent it launched (`evidence-based-investigator`, `plan-synthesizer`, `risk-analyst`, and so on). Record each distinct Han agent that ran, whether a skill dispatched it or it was invoked directly.

Build one list of the Han skills used and one list of the Han agents used. Deduplicate each.

If no Han skill or agent invocations are visible in the current context window, ask the user before stopping: "No Han skill or agent invocations are visible in this context window. If you ran Han skills or agents earlier but the session was compacted, list what you used and I will generate feedback for them." If the user confirms none were used, stop without writing any file.

Step 2: Create the feedback directory if it does not exist

Check whether `~/.claude/han-feedback/` exists by running `ls ~/.claude/han-feedback/ 2>/dev/null`. If the command fails (directory absent), run `mkdir -p ~/.claude/han-feedback/` before proceeding.

Step 3: Check for existing feedback today

Run `ls ~/.claude/han-feedback/ 2>/dev/null` and identify any files whose name begins with today's date (from Project Context). A file already covering a component used this session is the file this run updates, not a reason to skip.

Read each matching file, then decide between two paths:

**Nothing new has happened.** Every component in this session is already covered, and the session produced nothing the existing file does not record: no further runs of those components, no new problems, no correction you have not already written down. Report the existing file paths, say plainly that nothing new happened since they were written, and stop.

**Something new has happened.** The session continued past that file, a covered component ran again, a new problem surfaced, or the user asked for a compiled report. Update the file in place. Add the new material and preserve everything already there; never overwrite it. Then state the update: name the file you updated and what you added to it, so the user is not left guessing whether their newer session was captured.

A run that continued past an exis