Agent skill

Han Feedback

by testdouble in testdouble/han

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.

MITAuto-check passedDevelopment

Install Han Feedback

skills CLI
$ npx skills add testdouble/han --skill han-feedback -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install testdouble/han han-feedback --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/testdouble/han.git skills-src && mkdir -p .claude/skills && cp -r skills-src/han-feedback/skills/han-feedback .claude/skills/han-feedback && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
han-feedback
GitHub stars
279
Token cost
~3.9k tokens
SKILL.md length
2,093 words
Files
1
Skills in repo
54
Repo updated
First seen
Licence
MIT

At a glance

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.

  • Works in 10 steps: Identify Han skills and agents used this… → Create the feedback directory if it does… → Check for existing feedback today → …
  • Tasks that involve Code review
  • SKILL.md covers Project Context, Operating Principles, Step 1: Identify Han skills… and Step 2: Create the feedback…, plus 8 more sections
  • Calls gh and bash

What it does

Han Feedback is an agent skill from testdouble/han. 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.

Its SKILL.md is about 3.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Code review. It works with GitHub. The repository describes itself as: Han: AI skills and agents for "Solo" product engineers and small teams. The licence is MIT.

When your agent uses it

  • Tasks that involve Code review

Example prompts

  • “/han-feedback”

Requirements

  • Pre-approved tools (allowed-tools): Read, Write, Bash(ls *), Bash(mkdir *), Bash(gh *), Bash(date *), Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")

Workflow steps

10 steps, taken from the step headings in SKILL.md.

  1. Identify Han skills and agents used this session
  2. Create the feedback directory if it does not exist
  3. Check for existing feedback today
  4. Determine the filename
  5. Read the format reference
  6. Gather feedback
  7. Write or update the feedback file
  8. Verify the file is non-empty
  9. Review for sensitive content
  10. Offer to post as a GitHub issue

What it can do on your machine

Read from SKILL.md and the folder at commit abba73a. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Bash(ls *)
    • Bash(mkdir *)
    • Bash(gh *)
    • Bash(date *)
    • Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • bash

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Han Feedback loads about 3.9k tokens when it runs. Until then it costs about 126 tokens; SKILL.md has 2,093 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~126
When it runs · the whole SKILL.md, loaded when a task matches
~3.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from testdouble/han at commit abba73a, republished under its MIT licence (© testdouble). 2,093 words, ~3,933 tokens.

Download SKILL.mdSave it as .claude/skills/han-feedback/SKILL.md (or your agent's skills folder).
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, 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-core:risk-analyst becomes risk-analyst.
  • Join the short names of the skills being processed in this run with hyphens. Skills name the file because they are the unit of work; the agents are recorded inside the file.
  • When a session used Han agents directly with no Han skill, use the agent short names instead.
  • {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 2026-05-29-plan-a-feature-code-review.md.

Step 5: Read the format reference

Run ls -t ~/.claude/han-feedback/ 2>/dev/null | grep '\.md$' | head -1 to identify the feedback file with the most recent modification time.

If a file is found, read it to confirm the current output structure before writing. If no .md files exist in the directory, skip this step and use the embedded template in Step 7.

Step 6: Gather feedback

Think through the session for each qualifying skill and assess the following.

What worked well: Where did the skill do something noticeably better than doing it manually? Which dispatched Han agents added value, and how? Which findings or decisions from the skill or its agents changed the outcome?

What didn't work: Where did the skill or one of its agents ask a question the evidence could have answered? Where was the output disproportionately long for the decision at hand? Where did you redirect or correct the skill or an agent mid-run?

Overall: One paragraph summarizing the fit for this use case.

Rating: Score each dimension on a 1-to-5 scale. When the reference file from Step 5 exists, reuse its dimensions so ratings stay comparable across runs. When no reference file exists, use this default set, and add or drop a dimension only when the skill type clearly calls for it:

  • Output accuracy. Was the produced artifact factually correct and internally consistent?
  • Evidence discipline. Did the skill ground its claims in evidence and resolve questions before asking you?
  • Finding signal-to-noise. Were the dispatched agents' findings real and worth the turns they cost?
  • Output length vs. decision count. Was the artifact proportionate to the decisions it captured?
  • Turn efficiency. Did the skill converge without unnecessary rounds or escalations the evidence could have settled?

For a session that used Han agents directly (no skill), assess the agents the same way.

Show full SKILL.md (834 more words)Show less

Step 7: Write or update the feedback file

When Step 3 found a file to update, edit that file in place rather than rewriting it. Keep its existing structure and every point already recorded, and fold the new material into the sections it belongs in: new points onto the existing lists, any newly-used skill or agent onto the **Skills used:** and **Agents used:** lines, and a re-scored dimension only where this session's evidence actually changed it. Add an ## Update {TIME} heading before the new material when the 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:

markdown
# Han Feedback — {TODAY}

**Skills used:** `han-core:{skill-name}` **Agents used:** `han-core:{agent-name}` **Context:** {one sentence describing
what you were doing} **Outcome:** {one sentence describing what was produced}

---

## What worked well

- {point}
- {point}

---

## What didn't work

- {point}
- {point}

---

## Overall

{one paragraph}

---

## Rating

| Dimension                        | Score |
| -------------------------------- | ----- |
| Output accuracy                  | {N}/5 |
| Evidence discipline              | {N}/5 |
| Finding signal-to-noise          | {N}/5 |
| Output length vs. decision count | {N}/5 |
| Turn efficiency                  | {N}/5 |

List every Han skill used on the **Skills used:** line and every Han agent used on the **Agents used:** line, each with its full plugin namespace (for example han-github:update-pr-description, han-core:risk-analyst). If no Han agents ran, write **Agents used:** none.

Keep it honest and specific. Generic praise or criticism is not useful. Cite concrete moments from the session.

If the write fails, tell the user: "The write failed. The file was being written to $HOME/.claude/han-feedback/{filename}. Run ls ~/.claude/han-feedback/ and delete any file at that path before retrying." 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 added to it. "Updated 2026-07-29-plan-a-feature.md with the two escalation problems from this afternoon's run" tells the user their newer session was captured. Reporting only the path leaves them unable to tell an update from a skip.

Step 8: Verify the file is non-empty

Check that the written file contains content beyond whitespace. If the file is empty or whitespace-only, notify the user and stop. Do not proceed to the sensitive-content checklist.

Step 9: Review for sensitive content

Display the full content of the written file. Then present this checklist and ask the user to confirm, in a single response, that the content contains none of the following:

  • Personal identifiers (names, emails, personal details)
  • Internal operational details (team structure, business processes, or organization-specific internal systems — Han skill and agent names are fine, they are publicly documented open-source tools)
  • Client-specific information (project names, client work content, proprietary context)

A clear affirmative is "yes", "correct", "looks clean", or a similar unqualified confirmation. A response like "I think so", "probably", "seems fine", or any ambiguous answer is not a clear affirmative — treat it as sensitive content present.

If the response is a clear affirmative: proceed to Step 10.

If sensitive content is confirmed or the response is ambiguous: confirm the file is saved at ~/.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}

Step 10: Offer to post as a GitHub issue

Ask: "Ready to post this as a GitHub issue to testdouble/han?"

A clear affirmative is "yes", "go ahead", "post it", or a similar unqualified instruction. Anything else — including "maybe", "not yet", silence, or an ambiguous response — is treated as no.

If yes:

Build {skill-name} for the title from the **Skills used:** field with each plugin namespace stripped (everything up to and including the colon); join multiple short names with hyphens. When no Han skill ran, use the stripped names from the **Agents used:** field instead. Extract {TODAY} from the feedback filename's date component (not the current clock).

Run:

gh issue create --repo testdouble/han --title "Han Feedback: {skill-name} ({TODAY})" --body-file $HOME/.claude/han-feedback/{filename}

If the environment refuses to run the command (the tool call is denied, a permission or sandbox layer blocks it, the command is not permitted in this environment, or the run has no network access): say plainly that the environment refused the publish. Do not describe it as the run declining, choosing not to post, or deciding to skip. Those are three different statements and only the environment's refusal is true, so a user told the run declined goes looking for a decision nobody made.

Do not retry the identical command. A refusal that came from a permission or sandbox layer returns the same answer every time, and a second attempt spends a turn to learn nothing.

Then hand over the command to run by hand, filled in rather than templated, so it can be pasted as it stands:

gh issue create --repo testdouble/han --title "Han Feedback: {skill-name} ({TODAY})" --body-file $HOME/.claude/han-feedback/{filename}

Confirm 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 manually, 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 at ~/.claude/han-feedback/{filename}. Provide the posting command above. If the error contains "auth" or "login", add: "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 https://github.com/testdouble/han/issues to confirm. Do not retry — running the command again would create a duplicate issue."

If no: Confirm the file is saved at ~/.claude/han-feedback/{filename}. Provide the posting command above for later use.

© testdouble, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in han-feedback/skills/han-feedback of testdouble/han.

Open the folder on GitHubat commit abba73a

Compare with similar skills

Han Feedback next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Han Feedback compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Han Feedback this skilltestdouble/han279—~3.9kAutomated safety check: PassMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
GitHub Review Iterationprisma/orm48k—~2.2kAutomated safety check: PassApache-2.0
PR Finalize Reviewmicrosoft/garnet12k—~3.1kAutomated safety check: PassMIT
PR Review State Fetchprisma/orm48k—~767Automated safety check: PassApache-2.0
Fastlane Pull Request Reviewfastlane/fastlane42k—~550Automated safety check: PassMIT

Similar skills

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed
  • Official

    Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.

    48k GitHub stars~2.2k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • PR Finalize Review

    microsoft/garnet

    Official

    Checks that a pull request's title and description match its implementation and reviews the code for Garnet best practices, reporting findings without posting them.

    12k GitHub stars~3.1k tokensUpdated today
    DevelopmentAuto-check passed
  • Official

    Fetches a pull request's canonical review state as JSON, validates it, and renders markdown, a text summary and triage target files from it using bundled scripts.

    48k GitHub stars~767 tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Reviews a fastlane pull request against its linked issue and the project guides, separating blocking from non-blocking findings and handling vulnerabilities privately.

    42k GitHub stars~550 tokensUpdated today
    DevelopmentAuto-check passed
  • Reviews open pull requests in the daisyUI repository using read-only GitHub data and isolated base-versus-PR checks, then writes a merge verdict report.

    43k GitHub stars~766 tokensUpdated 7 days ago
    DevelopmentAuto-check passed

More from testdouble/han

All 54 skills in this repo
  • HTML Summary

    testdouble/han

    Convert a stakeholder summary markdown file into a single self-contained HTML executive report — bottom line and decision asks up front, supporting detail later — styled with a Test Double-derived…

    279 GitHub stars~2.9k tokensUpdated 6 days ago
    Auto-check passed
  • Update Han plugin documentation so every skill, agent, guidance doc, index, and cross-reference is current and accurate.

    279 GitHub stars~3.4k tokensUpdated 6 days ago
    Auto-check passed
  • Guidance

    testdouble/han

    Authoritative guidance for building Claude Code skills, agents, and plugins, plus init and update steps that install and refresh the plugin-building skills in the current repository.

    279 GitHub stars~1.8k tokensUpdated 6 days ago
    Auto-check passed
  • Han Release

    testdouble/han

    Cut a Han release: update CHANGELOG.md with the changes since the last release, bump and tag every plugin that changed as {plugin-name}--v{version} so a version-constrained dependency can resolve…

    279 GitHub stars~8.6k tokensUpdated 6 days ago
    Auto-check passed
  • Plan Implementation

    testdouble/han

    Builds a feature implementation plan from an existing feature specification (or equivalent context) through a facilitated team conversation.

    279 GitHub stars~9.5k tokensUpdated 6 days ago
    Auto-check passed
  • Refactor

    testdouble/han

    Restructure existing code without changing its behavior, through a test-gated refactoring loop: a named target, a green suite over that target before any edit, a planned sequence of small named…

    279 GitHub stars~3.1k tokensUpdated 6 days ago
    Auto-check passed

Works with

Categories

Questions about Han Feedback

What does Han Feedback do?

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. Han Feedback is an agent skill from testdouble/han. 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.

When should I use Han Feedback?

Han Feedback fits situations like: tasks that involve Code review.

How do I install Han Feedback in Claude Code?

Run `npx skills add testdouble/han --skill han-feedback -a claude-code`. Or copy the skill folder (han-feedback/skills/han-feedback in testdouble/han) into .claude/skills/han-feedback in your project. Claude Code loads it when a task matches its description.

How do I install Han Feedback in Codex?

Run `npx skills add testdouble/han --skill han-feedback -a codex`. Or copy the skill folder (han-feedback/skills/han-feedback in testdouble/han) into .agents/skills/han-feedback in your project. Codex loads it when a task matches its description.

Can I use Han Feedback in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add testdouble/han --skill han-feedback -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/han-feedback, .gemini/skills/han-feedback, .github/skills/han-feedback and .opencode/skills/han-feedback in your project.

What does Han Feedback need to run?

Going by SKILL.md and its folder, Han Feedback needs the command-line tools its instructions call (gh and bash). Its frontmatter pre-approves these tools: Read, Write, Bash(ls *), Bash(mkdir *), Bash(gh *), Bash(date *), Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh").

Does Han Feedback access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Han Feedback safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Han Feedback use?

Han Feedback is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Han Feedback use?

About 3.9k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Han Feedback?

Skills that share tags, products or a category with Han Feedback: PR Babysitter (openinterpreter/openinterpreter, 69k stars), GitHub Review Iteration (prisma/orm, 48k stars), PR Finalize Review (microsoft/garnet, 12k stars) and PR Review State Fetch (prisma/orm, 48k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Han Feedback?

testdouble (a GitHub organization) maintains it in testdouble/han, which has 279 GitHub stars. The repository holds 54 skills in this directory. The repository was last updated on October 1, 2026.

Source: testdouble/han on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.