Skills publicadas
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
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
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 investi
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 comm
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
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 "fig
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
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
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. D
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
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, referenc
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 modu
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
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
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 wr
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,
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 arc
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 co
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 subm
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
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-bui
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 cod
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
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", "cr
work-items-to-issues
Break a work-items.md file (produced by /plan-work-items) into independently-grabbable GitHub issues, one per slice, in each slice's target repo. Use when you want to turn a work-items file into GitHub issues, publish work items as issue tickets, or create implementation tickets that can be worked on and tracked on GitHub. Requires the gh CLI to be installed and authenticated. Does not produce the
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 post-code-review-to-pr for posting a
Alerta por categoría