date +%Y-%m-%dbash \"${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh\" 2>/dev/null || echo \"$HOME/.claude\"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\nthat returns no file is no personal configuration: continue silently. When that file or the project .han/config.md\nprobe supplies content, apply it per config-rule.md, which governs precedence\nbetween the two files, relative-path resolution, and what to do with a file that reads but cannot be used.
han-core, han-planning,\nhan-coding, han-github, han-reporting, han-feedback, and any future han-* plugin). Skills and agents from\nnon-Han plugins are out of scope.Look back through the conversation for any use of a Han plugin component. A component counts as used if it was invoked,\nregardless of whether it completed or was cancelled.
\nHan skills. Look for invocations of skills namespaced to any han-* plugin. The namespace is the plugin name\nfollowed by a colon: han-core:, han-planning:, han-coding:, han-github:, han-reporting:, han-feedback:, and\nthe same shape for any future han-* plugin (treat a bare han: prefix as Han too). Watch for slash-command\ninvocations (like /han-planning:plan-a-feature), messages showing a skill launching (like \"Launching skill:\nhan-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\nsubagent_type is han-core:adversarial-security-analyst, or skill output naming a Han agent it launched\n(evidence-based-investigator, plan-synthesizer, risk-analyst, and so on). Record each distinct Han agent that ran,\nwhether 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.
\nIf no Han skill or agent invocations are visible in the current context window, ask the user before stopping: \"No Han\nskill or agent invocations are visible in this context window. If you ran Han skills or agents earlier but the session\nwas compacted, list what you used and I will generate feedback for them.\" If the user confirms none were used, stop\nwithout writing any file.
\nCheck whether ~/.claude/han-feedback/ exists by running ls ~/.claude/han-feedback/ 2>/dev/null. If the command fails\n(directory absent), run mkdir -p ~/.claude/han-feedback/ before proceeding.
Run ls ~/.claude/han-feedback/ 2>/dev/null and identify any files whose name begins with today's date (from Project\nContext). 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:
\nNothing new has happened. Every component in this session is already covered, and the session produced nothing the\nexisting file does not record: no further runs of those components, no new problems, no correction you have not already\nwritten down. Report the existing file paths, say plainly that nothing new happened since they were written, and stop.
\nSomething new has happened. The session continued past that file, a covered component ran again, a new problem\nsurfaced, or the user asked for a compiled report. Update the file in place. Add the new material and preserve\neverything already there; never overwrite it. Then state the update: name the file you updated and what you added to it,\nso the user is not left guessing whether their newer session was captured.
\nA run that continued past an existing file and then skipped is the failure this step exists to prevent. The default is to\nupdate.
\nWhen 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\ncomponent the name does not mention; renaming it would break the path already reported to the user.
\nOtherwise compute the filename as {TODAY}-{short-names}.md, where:
han-planning:plan-a-feature becomes plan-a-feature, han-github:post-code-review-to-pr becomes\npost-code-review-to-pr, and the agent han-core:risk-analyst becomes risk-analyst.{TODAY} is today's date from Project Context.Example: a session with han-planning:plan-a-feature and han-coding:code-review on 2026-05-29 produces\n2026-05-29-plan-a-feature-code-review.md.
Run ls -t ~/.claude/han-feedback/ 2>/dev/null | grep '\\.md$' | head -1 to identify the feedback file with the most\nrecent modification time.
If a file is found, read it to confirm the current output structure before writing. If no .md files exist in the\ndirectory, skip this step and use the embedded template in Step 7.
Think through the session for each qualifying skill and assess the following.
\nWhat worked well: Where did the skill do something noticeably better than doing it manually? Which dispatched Han\nagents added value, and how? Which findings or decisions from the skill or its agents changed the outcome?
\nWhat didn't work: Where did the skill or one of its agents ask a question the evidence could have answered? Where\nwas the output disproportionately long for the decision at hand? Where did you redirect or correct the skill or an agent\nmid-run?
\nOverall: One paragraph summarizing the fit for this use case.
\nRating: Score each dimension on a 1-to-5 scale. When the reference file from Step 5 exists, reuse its dimensions so\nratings stay comparable across runs. When no reference file exists, use this default set, and add or drop a dimension\nonly when the skill type clearly calls for it:
\nFor a session that used Han agents directly (no skill), assess the agents the same way.
\nWhen Step 3 found a file to update, edit that file in place rather than rewriting it. Keep its existing structure and\nevery point already recorded, and fold the new material into the sections it belongs in: new points onto the existing\nlists, any newly-used skill or agent onto the **Skills used:** and **Agents used:** lines, and a re-scored dimension\nonly where this session's evidence actually changed it. Add an ## Update {TIME} heading before the new material when\nthe session's story changed rather than merely lengthened, so a reader can see what arrived later. Then continue to Step 8.
Otherwise write the file to ~/.claude/han-feedback/{filename} using this structure:
# Han Feedback — {TODAY}\n\n**Skills used:** `han-core:{skill-name}` **Agents used:** `han-core:{agent-name}` **Context:** {one sentence describing\nwhat you were doing} **Outcome:** {one sentence describing what was produced}\n\n---\n\n## What worked well\n\n- {point}\n- {point}\n\n---\n\n## What didn't work\n\n- {point}\n- {point}\n\n---\n\n## Overall\n\n{one paragraph}\n\n---\n\n## Rating\n\n| Dimension | Score |\n| -------------------------------- | ----- |\n| Output accuracy | {N}/5 |\n| Evidence discipline | {N}/5 |\n| Finding signal-to-noise | {N}/5 |\n| Output length vs. decision count | {N}/5 |\n| Turn efficiency | {N}/5 |\nList every Han skill used on the **Skills used:** line and every Han agent used on the **Agents used:** line, each\nwith its full plugin namespace (for example han-github:update-pr-description, han-core:risk-analyst). If no Han\nagents ran, write **Agents used:** none.
Keep it honest and specific. Generic praise or criticism is not useful. Cite concrete moments from the session.
\nIf the write fails, tell the user: \"The write failed. The file was being written to\n$HOME/.claude/han-feedback/{filename}. Run ls ~/.claude/han-feedback/ and delete any file at that path before\nretrying.\" Do not proceed to the checklist or posting steps.
When this run updated an existing file, say so in the same message that reports the path: name the file and name what you\nadded to it. \"Updated 2026-07-29-plan-a-feature.md with the two escalation problems from this afternoon's run\" tells\nthe user their newer session was captured. Reporting only the path leaves them unable to tell an update from a skip.
Check that the written file contains content beyond whitespace. If the file is empty or whitespace-only, notify the user\nand stop. Do not proceed to the sensitive-content checklist.
\nDisplay the full content of the written file. Then present this checklist and ask the user to confirm, in a single\nresponse, that the content contains none of the following:
\nA clear affirmative is \"yes\", \"correct\", \"looks clean\", or a similar unqualified confirmation. A response like \"I think\nso\", \"probably\", \"seems fine\", or any ambiguous answer is not a clear affirmative — treat it as sensitive content\npresent.
\nIf the response is a clear affirmative: proceed to Step 10.
\nIf sensitive content is confirmed or the response is ambiguous: confirm the file is saved at\n~/.claude/han-feedback/{filename}, provide the ready-to-run command below for manual use after editing, and stop.
gh issue create --repo testdouble/han --title \"Han Feedback: {skill-name} ({TODAY})\" --body-file $HOME/.claude/han-feedback/{filename}\nAsk: \"Ready to post this as a GitHub issue to testdouble/han?\"
\nA clear affirmative is \"yes\", \"go ahead\", \"post it\", or a similar unqualified instruction. Anything else — including\n\"maybe\", \"not yet\", silence, or an ambiguous response — is treated as no.
\nIf yes:
\nBuild {skill-name} for the title from the **Skills used:** field with each plugin namespace stripped (everything up\nto and including the colon); join multiple short names with hyphens. When no Han skill ran, use the stripped names from\nthe **Agents used:** field instead. Extract {TODAY} from the feedback filename's date component (not the current\nclock).
Run:
\ngh issue create --repo testdouble/han --title \"Han Feedback: {skill-name} ({TODAY})\" --body-file $HOME/.claude/han-feedback/{filename}\nIf the environment refuses to run the command (the tool call is denied, a permission or sandbox layer blocks it, the\ncommand is not permitted in this environment, or the run has no network access): say plainly that the environment refused\nthe publish. Do not describe it as the run declining, choosing not to post, or deciding to skip. Those are three\ndifferent statements and only the environment's refusal is true, so a user told the run declined goes looking for a\ndecision nobody made.
\nDo not retry the identical command. A refusal that came from a permission or sandbox layer returns the same answer every\ntime, and a second attempt spends a turn to learn nothing.
\nThen hand over the command to run by hand, filled in rather than templated, so it can be pasted as it stands:
\ngh issue create --repo testdouble/han --title \"Han Feedback: {skill-name} ({TODAY})\" --body-file $HOME/.claude/han-feedback/{filename}\nConfirm the file is saved at ~/.claude/han-feedback/{filename} and stop.
If gh is not found (command not found or not installed): Report that the gh CLI is not installed. To post\nmanually, visit https://github.com/testdouble/han/issues/new and paste the file contents.
If the command exits with a non-zero code: Display the error message without modification. Confirm the file is saved\nat ~/.claude/han-feedback/{filename}. Provide the posting command above. If the error contains \"auth\" or \"login\", add:\n\"Run gh auth login and retry.\"
If the command exits successfully but no URL is parseable in the output: Say \"The issue was likely created. Check\nhttps://github.com/testdouble/han/issues to confirm. Do not retry — running the command again would create a duplicate\nissue.\"
\nIf no: Confirm the file is saved at ~/.claude/han-feedback/{filename}. Provide the posting command above for later\nuse.