han-feedback

## 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 existing file and then skipped is the failure this step exists to prevent. The default is to
update.

## Step 4: Determine the filename

When Step 3 found a file to update, that file's name is the filename. Keep it as it is, even when this run covers a
component the name does not mention; renaming it would break the path already reported to the user.

Otherwise compute the filename as `{TODAY}-{short-names}.md`, where:

- Each component's short name is its plugin namespace stripped (everything up to and including the colon). For example
  `han-planning:plan-a-feature` becomes `plan-a-feature`, `han-github:post-code-review-to-pr` becomes
  `post-code-review-to-pr`, and the agent `han-c