testdouble
OrganizationHan: AI skills and agents for "Solo" product engineers and small teams
Categories
Indexed Skills (26)
architectural-analysis
Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase — including requests to audit module boundaries, check for architectural smells, or inform refactoring decisions. Requires a specific focus area (module, directory, or component) to analyze. Not for creating new project structures, scaffolding, or boilerplates. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for writing documentation or architectural decision records.
code-review
Run a comprehensive code review on local source files. Use this skill when the user asks to review, audit, inspect, evaluate, or check code — or when they ask to make sure, verify, or validate that code follows good coding standards, is free of errors or bugs, has sufficient test coverage, or meets best practices, even if they never use the word "review." Triggers for any request to assess code quality, correctness, or security of specific files, directories, or the current branch. Also use when the user invokes /code-review directly. Works on git branches (reviewing changed files against the default branch) or on specified files and directories when git is not available. Does not post comments to GitHub pull requests — use post-code-review-to-pr for that. Does not analyze architectural structure or module boundaries — use architectural-analysis for that. Does not capture feedback on Han's own skills — use han-feedback for that.
gap-analysis
Performs a gap analysis between two artifacts (a current state and a desired state) and produces a plain-language, stakeholder-readable report indexed by stable gap IDs. Use when the user wants to compare, evaluate, audit, or reconcile one artifact against another — including spec-vs-implementation gaps, PRD-vs-shipped-feature gaps, design-vs-build gaps, requirements-vs-code audits, or any "what's missing from X compared to Y" question — and wants a human-readable report rather than raw analyst output. Orchestrates the `gap-analyzer` agent for the primary analysis, then runs a validator-and- augmenter swarm by default to corroborate, contradict, and enrich the findings — including an actor-perspective sweep across human users, API callers, AI agents, and other actor types. The user may opt out of the swarm with `no swarm` to fall back to a lightweight gap-analyzer-only pass. Recommends a swarm team size (small / medium / large) based on gap count, gap-category distribution, and the specific domains the gaps t
iterative-plan-review
Sharpens and stress-tests an existing plan file through multiple codebase-grounded review passes, editing it in place and recording every finding and iteration in cross-referenced companion files. Use this skill whenever the user wants to iterate on, refine, tighten, or improve a plan — including terse commands like "iterate", "refine it", or "iterate for correctness" where a plan is present in context. Also use it when the user asks to verify, validate, or confirm feasibility of an approach (e.g., "can you verify this will work", "check this for correctness", "is this sound") — the defining signal is that the user wants critical evaluation of a proposed approach, not execution of it. Produces two companion files in an artifacts/ subfolder next to the plan: review-findings.md (every finding raised and how it was resolved) and review-iteration-history.md (round-by-round record of specialists engaged and plan changes applied). Do NOT use for implementing plan steps, generating new plans from scratch, writing te
plan-a-feature
Builds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation — including requests like "help me plan X", "spec out this feature", "design the Y flow", or "let's figure out what it should do". Explores the codebase, project documentation, coding standards, and ADRs to resolve questions before asking the user, and always offers a recommended answer when questions must be surfaced. Produces a feature-specification.md focused on system behaviors, coordinations, processes, and user interactions — not implementation detail. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not investigate bugs or failures — use investigate. Does not analyze existing architecture — use architectural-analysis. Does not document already-built features — us
plan-implementation
Builds a feature implementation plan from an existing feature specification (or equivalent context) through a project-manager-led team conversation. Use when the user wants to plan how to implement, build, deliver, or ship a feature that has already been specified — including requests like "plan the implementation of X", "how do we build this", "turn this spec into an implementation plan", or "figure out how we'd actually ship this". Launches a team of specialist sub-agents sized to the feature, always including `project-manager` as coordinator and `junior-developer` as generalist stress-tester, and iterates rounds of discussion until the project-manager confirms the plan is ready or only user input remains. Produces three cross-referenced files in the same folder as the source feature specification: feature-implementation-plan.md (the primary plan), implementation-decision-log.md (every committed decision with rationale and evidence), and implementation-iteration-history.md (round-by-round record of speciali
research
Researches an open-ended question — options, possible solutions, prior art, trade-offs, or how something works — and produces a durable, evidence-backed, adversarially-validated report that recommends an option without committing the team to any artifact. Use when you want to research approaches, weigh options, survey prior art or the state of the art, or understand how something works before committing to a direction — including 'what are my options for X', 'should I use A or B', 'what's the landscape for Y'. Reaches the codebase, the open web, and any material you provide. Does not diagnose a bug, failure, or root cause — use investigate. Does not specify a feature — use plan-a-feature. Does not create or update a coding standard — use coding-standard. Does not compare two concrete artifacts for gaps — use gap-analysis. Does not assess an existing module's architecture — use architectural-analysis. Does not capture feedback on Han's own skills — use han-feedback.
architectural-decision-record
Create, extract, or convert an ADR (architectural decision record) using the ADR template. Use when creating new ADRs, extracting an ADR from existing documentation, converting a document into an ADR, recording an architecture or design decision, or updating the status of an existing ADR. Does not create or update enforceable coding standards or conventions — use coding-standard for that. Does not write feature or system documentation — use project-documentation instead. Does not produce runbooks for operational scenarios — use runbook for that.
coding-standard
Creates and updates coding standards, conventions, rules, and guidelines for the current project. Use when creating new standards from scratch, converting existing documents into coding standards, or updating existing standards — including evaluating whether a proposed standard belongs in automated tooling like linters or formatters instead. Does not create architectural decision records — use architectural-decision-record for ADRs. Does not write feature or system documentation — use project-documentation for that. Does not research open-ended options or prior art that is not destined for a standard — use research. Does not produce runbooks for operational scenarios — use runbook for that.
investigate
Evidence-based investigation of issues, bugs, API calls, integrations, and other aspects of software development that need a deep dive to find the root cause and solutions. Use when you need to debug, troubleshoot, diagnose, or figure out why something is broken — especially when in-depth analysis of the reasons and an adversarial validation of the proposed solution are needed. Does not review code for quality or style — use code-review for auditing changes or post-code-review-to-pr for posting review feedback to GitHub. Does not assess architectural health or structural risk — use architectural-analysis for architectural concerns. Does not research open-ended options, prior art, or how something works when nothing is broken — use research for that. Does not capture feedback on Han's own skills — use han-feedback for that.
project-documentation
Creates and maintains project documentation for features, systems, and components. Discovers project structure dynamically to work across any technology stack. Use when documenting how a feature, system, or component works — including writing, updating, or organizing docs. Does not scan or detect the project's technology stack — use project-discovery for repository analysis and config detection. Does not create architectural decision records — use architectural-decision-record for ADRs. Does not create or update coding standards — use coding-standard instead. Does not generate PR descriptions — use update-pr-description for that. Does not produce runbooks for operational scenarios — use runbook for that.
runbook
Create or update a runbook for an operational scenario — an incident an alert fires for, a recurring scheduled task, or a known failure mode on a live service — using a consistent template. Use when writing, drafting, authoring, or updating a runbook for an alert, incident, on-call procedure, scheduled maintenance, or operational SOP. Each invocation produces one runbook at a time. Applies a YAGNI preflight that requires the scenario to be real (an alert that has fired, a recurring task that exists, or a live failure mode on a service that receives traffic) before producing the runbook. Does not produce feature or system documentation — use project-documentation. Does not record architectural decisions — use architectural-decision-record. Does not create coding standards — use coding-standard.
han-release
Cut a Han release: update CHANGELOG.md with the changes since the last release, bump every plugin that changed, tag the suite version vX.Y.Z, and publish a GitHub release whose notes attribute every merged pull request to its author, credit every closed issue to the person who opened it, the people who contributed to it, and the people who worked on the fix, and link back to the full changelog for that version. Han ships as a parent meta-plugin (`han`) plus child plugins (`han.core`, `han.github`, `han.reporting`, and any future `han.*` extension); the skill versions each plugin independently. Use when releasing, cutting a release, shipping a new Han version, publishing release notes, or tagging a version. Reads each plugin's target version from its plugin.json; when a plugin has not been bumped past the latest tag yet, it proposes a semantic-versioning bump and confirms the whole plan before continuing. Requires the gh CLI, jq, and a clean git checkout. This is a repository-maintenance skill for the Han repo
han-update-documentation
Update Han plugin documentation so every skill, agent, guidance doc, index, and cross-reference is current and accurate. On a non-default branch, scopes the pass to entities the branch actually touched. On the default branch, performs a full documentation sweep across the whole plugin. Use when updating, refreshing, syncing, auditing, or verifying Han's docs after changing skills, agents, references, or top-level guidance — including "update the docs", "doc sweep", "refresh documentation", "audit the docs", "make sure the docs are current". This is a repository-maintenance skill for the Han repo itself, not a general documentation skill — use /project-documentation to document features in arbitrary projects, /han-release to cut a release (and update CHANGELOG), and /update-pr-description for PR bodies.
issue-triage
Triage a raw, vague issue or bug report into a structured document that names what is known, what is missing, and what to do next. Use when an incoming issue, bug report, or problem description is too vague or incomplete for investigation or planning: classify the issue type, identify missing information, assess severity and reproducibility, and recommend the right next han skill. Does not investigate root causes or trace code paths — use investigate for debugging, diagnosis, and root cause analysis. Does not plan features or build solutions — use plan-a-feature or plan-implementation for that.
plan-a-phased-build
Splits a body of context into a sequence of vertical-slice build phases where each phase is independently demonstrable to a real user and each builds on the work of the previous. Use when the user wants to plan, sequence, phase, slice, break down, or order the build of a feature, capability, system, or initiative — including requests like "split this into phases", "what should we build first", "create a build plan", "phase this work", "turn this into vertical slices", "outline the order of delivery", or "what's our roadmap". Accepts any source of context — gap analyses, PRDs, design documents, feature specifications, conversation notes, ADRs, requirements lists, or inline descriptions — and produces a plain-language `build-phase-outline.md` indexed by stable phase IDs. Each phase explains what gets built, why it lands at that position, the outcome a real person can be shown end-to-end, cross-references back to the source artifact for traceability, and preconditions. Foundational or prerequisite phases appear
plan-work-items
Break a trusted implementation plan (or other provided context) into independently-grabbable, atomic work items, written to a single work-items.md file. Use when the user wants to convert a plan into work items, create implementation tickets or tasks, divide a plan into work units, or break the plan down into grabbable pieces. Do not use when there is no implementation plan yet or the plan is not yet trusted — use plan-implementation to produce the plan or iterative-plan-review to harden it first. Does not sequence work into demoable delivery phases — use plan-a-phased-build for that. Does not write code — use tdd to implement a work item.
project-discovery
Discovers key attributes of the current code repository and its projects — languages, frameworks, tooling, configuration, documentation structure — and writes a static reference for other skills, agents, and hooks to consume. Use when scanning, analyzing, or detecting the project's technology stack, build tools, or repository structure. Does not create or update project documentation — use project-documentation for writing feature or system docs.
tdd
Write code through a disciplined, BDD-framed Test-Driven Development loop: build a behavior test list, then drive each behavior through red-green-refactor with an enforced observed-failure gate. Use when the user wants to implement, build, or write code test-first, "do TDD", follow "red-green-refactor", drive code from tests, or grow a feature behavior-by-behavior with tests leading. This skill writes and changes code; it does not produce a test plan document (use test-planning), review or audit existing code (use code-review), specify what a feature should do (use plan-a-feature), or find the root cause of a bug (use investigate).
test-planning
Produce a standalone test plan by analyzing code for test coverage gaps and edge cases. Use when you need to create, generate, or draft a test plan for a branch, need to analyze test coverage, or need to identify what tests to write for specific files or directories. Does not write test code — produces a plan document only; use tdd to implement behavior test-first through a red-green-refactor loop. Does not refine or iterate on existing plans — use iterative-plan-review to improve a previously drafted work plan. Does not review code quality, security, or style — use code-review for full code review. Does not evaluate architectural testability or structural coupling — use architectural-analysis for architectural assessment.
han-feedback
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 across the whole han.* plugin family: han.core, han.github, han.reporting, han.feedback, and any future han.* plugin. 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. Produces a dated markdown feedback file under ~/.claude/han-feedback/ and walks through a sensitive-content review before offering to post. 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.
post-code-review-to-pr
Run a full pull request review and post review comments directly to the current branch's GitHub PR. Requires the gh CLI to be installed and a PR to already exist for the current branch. Use when you want review feedback posted to GitHub as PR comments. For local code review without posting to GitHub, use code-review instead. Does not write or update PR descriptions — use update-pr-description for that.
update-pr-description
Generate a PR description from the current branch's changes against a GitHub PR, using the gh CLI. Use when writing, drafting, or updating pull request descriptions, PR summaries, or PR bodies. Requires the gh CLI to be installed and a PR to already exist for the current branch. Does not review code or post review comments — use code-review for local review or gh-pr-review for posting a review to GitHub.
stakeholder-summary
Produces a plain-language stakeholder summary from an existing feature specification, for sharing with non-technical stakeholders before implementation kicks off. Use when the user wants to draft a stakeholder summary, executive summary, or business summary of a feature spec or PRD. Does not write the spec itself — use plan-a-feature. Does not sequence the build into phases — use plan-a-phased-build. Does not produce an implementation plan — use plan-implementation.
gh-pr-review
Run a full pull request review and post review comments directly to the current branch's GitHub PR. Requires the gh CLI to be installed and a PR to already exist for the current branch. Use when you want review feedback posted to GitHub as PR comments. For local code review without posting to GitHub, use code-review instead. Does not write or update PR descriptions — use update-pr-description for that.
html-summary
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 palette and self-contained mermaid diagrams. Use when the user wants to turn a stakeholder summary, executive summary, or business summary into an HTML report, generate an HTML version of a summary doc, or produce a shareable HTML file from a summary markdown. Requires an existing markdown summary file. Produces an HTML sibling file only; does not modify the source markdown, commit, push, or publish anything.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.