hb

Plugin hb from marketplace helderberto-skills in helderberto/agent-skills. Commands read from the repo's manifest — 17 days ago.

Skills (41)

• a11y-audit

  Audit accessibility (WCAG) in frontend code. Use when asked to "check accessibility", "audit a11y", "check WCAG", or find accessibility issues. Don't use for backend code, bundle size (/perf-audit), or translations (/i18n).

• architecture-audit

  Surface architectural friction across a codebase and propose deep-module refactors as RFCs.

• check

  Validate code quality — auto-fix formatting/lint, verify types, run tests. Use when asked to "validate code", "check code", or validate before committing; also lint-only asks ("run linter", "fix lint errors"). Don't use for committing (/commit), pushing (/to-pr), or writing new tests (/tdd).

• code-review

  Review a PR or branch on two axes only, quality and spec, in parallel subagents reported side by side.

• codebase-design

  Shared vocabulary for designing deep modules — interface, seam, depth. Use when designing or improving a module's interface, placing a seam, or deciding what an API hides. Don't use for codebase-wide audits (/architecture-audit), behavior-preserving cleanup (/refactor), or UI components (/frontend-u

• commit

  Group unstaged changes into atomic commits by concern, matching repository style. Use when asked to "commit", "create a commit", or "commit changes". Don't use for pushing or pull requests (/to-pr).

• create-skill

  Create or restructure agent skills — frontmatter, description routing, progressive disclosure. Use when asked to create, write, or build a new skill, or "make a skill for X". Don't use for eval-driven trigger optimization (skill-creator) or one-off prose edits to a skill.

• debate

  Settle a go/no-go on one risky change against an alternative through an advocate, a skeptic, and a neutral investigator.

• debug

  Disciplined diagnosis loop for hard bugs and performance regressions. Use when user says "diagnose" or "debug this", or reports something broken, throwing, failing, or slow. Don't use to build a feature or fix an understood bug test-first (/tdd).

• deps-audit

  Check dependencies for known CVEs and staleness. Use when asked to "audit dependencies", "check for vulnerable packages", or find outdated packages. Don't use for code-level security (/harden) or committed secrets (/safe-repo).

• domain-modeling

  Build a project's domain model — challenge terms, pin down a ubiquitous language, write the glossary down. Use when defining domain terminology, naming a concept, resolving terms used inconsistently, or updating the glossary. Don't use for a single architectural decision (/to-adr) or explaining code

• feedback

  Fetch unresolved review comments on a GitHub PR (Copilot and human), verify against the code, classify Address / Skip / Optional / Discuss. Use when asked to triage reviewer feedback, which comments to actually fix, or to sort signal from noise on a PR. Don't use to reply to or resolve threads, or t

• frontend-ui-engineering

  Front-load UI construction decisions — component boundary and prop API, state placement, required states, responsiveness, accessibility. Use when creating or refactoring a component, page, or design-system primitive. Don't use for pure logic (/tdd), throwaway exploration (/prototype), or auditing fi

• grill

  Interview in rounds until a plan or idea has no open decisions.

• guide

  Explain which hb skill or flow fits your situation, from a map of how the skills fit together.

• handoff

  Compact the current conversation into a handoff document for a fresh agent.

• harden

  Harden code where untrusted input enters the system. Use when implementing auth, handling user input, storing sensitive data, integrating external APIs, adding file uploads or LLM features, or crossing any trust boundary. Don't use for secret scanning (/safe-repo) or dependency CVEs (/deps-audit).

• i18n

  Audit internationalization coverage and find hardcoded strings. Use when asked to "check i18n", "find hardcoded strings", or verify translation coverage. Don't use for backend code, projects without an i18n library, accessibility (/a11y-audit), or bundle size (/perf-audit).

• perf-audit

  Audit frontend bundle size and Core Web Vitals risks. Use when asked to "audit performance", "analyze bundle", "check bundle size", "check Core Web Vitals", or find frontend bottlenecks. Don't use for backend performance, database queries, or diagnosing a specific slowdown (/debug).

• prototype

  Build a throwaway prototype — a shareable HTML demo for state/logic questions, or several UI variations toggleable from one route. Use when comparing design directions before committing, or the user says "prototype", "mock up", "try a few approaches". Don't use for production code (/build, /tdd).

• refactor

  Improve existing code without changing behavior — split large functions, backfill tests, simplify. Use when asked to "refactor", "add missing tests", "split functions", "simplify", "clean up code", or "reduce complexity". Don't use for new features (/tdd), security hardening (/harden), or PR review

• research

  Investigate a question against primary sources and capture cited findings as Markdown. Use when the user wants a topic researched, docs or API facts gathered, or reading delegated to a background agent. Pass the question as the argument. Don't use for implementing against pinned dependency versions

• retro

  Run a retrospective on a coding session and suggest changes to the agent's environment, not the code.

• review

  Run the full pre-merge panel: parallel audit and lens reviewers over a diff, consolidated into one severity-ranked verdict.

• revise

  Edit prose in place — restructure article drafts (reorder sections, tighten arguments) or polish markdown/text (typos, dashes, filler). Use when asked to "revise", "edit my draft", "improve my article", "fix typos", or "fix dashes" in a doc or post. Don't use for code style or linting (/check), comm

• safe-repo

  Scan the repository for committed secrets and sensitive data; `--diff [<base>]` scopes to a branch's changes. Use when asked to "check for sensitive data", "scan for secrets", or verify no credentials or company data are committed. Don't use for code-level security (/harden), dependency CVEs (/deps-

• setup

  Configure this repo's issue tracker for the flow skills: GitHub, Jira, or local markdown (the default).

• source-driven

  Implement features from official docs for the exact installed dependency versions, not training data. Use when asked to "check the docs", "use official docs", "source-driven", or with unfamiliar APIs/libraries. Don't use for well-known stdlib APIs, project-internal code, or researching without imple

• tdd

  Test-driven development, from unit to end-to-end tests. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration or end-to-end tests (Playwright, Cypress). Don't use to backfill tests on existing code (/refactor) or diagnose an unknown bug

• teach

  Teach a concept over multiple sessions, with lessons and records kept in this workspace.

• to-adr

  Record an Architecture Decision Record (ADR) — 1–3 sentences on what was decided and why. Use when user says "create an ADR", "record this decision", or just made an architecturally significant choice. Don't use for forward-looking specs (/to-spec) or repo conventions (CLAUDE.md).

• to-doc

  Turn an investigation, data, or a decision into a doc for readers across the company, published to Confluence, a GitHub issue, or Markdown.

• to-pr

  Gate, push, and open a GitHub pull request on the repo's PR template, then watch CI.

• to-release

  Prepare a library release on its PR (version, changelog, draft GitHub release) for review, then tag and publish it after you merge.

• to-spec

  Turn the settled conversation into a spec (PRD), published through the repo's tracker: `.specs/specs/<slug>.md` by default.

• to-stack

  Split a large branch or PR into a stack of small PRs, verified layer by layer, and open them as linked drafts.

• to-tickets

  Slice a spec or a ticket into tracer-bullet tickets with blocking edges, published through the repo's tracker: `.specs/tickets/<slug>.md` by default.

• triage

  Classify any input — idea, bug, ticket key, `#42`, PR URL, stack trace — size it, and name the command to type; with no args, report where you are.

• visual-review

  Two visual modes — render a PR diff as an HTML page with each hunk annotated by principle, or check a UI change in a real browser (screenshots, console, network). Use for a visual/HTML diff report, "check the UI", or "screenshot before/after". Don't use for text-only feedback (/code-review), unit te

• wait-what

  Stop — that last message didn't land. Re-pitch it plainly.

• zoom-out

  Explain code with visual diagrams and analogies. Use when explaining how code works, walking through a codebase area, or the user asks "how does this work?" Don't use for modifying code, fixing bugs, or multi-session learning (/teach).

Subagents (4)

• parity-auditor

  Audit code migrations for missing functionality. Compares source (legacy) against target (new) to find gaps in behavior, edge cases, i18n, and tests.

• perf-auditor

  Read-only frontend performance audit — bundle size and Core Web Vitals risks. Invoke from review, or for a performance pass on a web app.

• security-auditor

  Read-only security audit of a diff or module — exploitable flaws at trust boundaries. Invoke from review, or for a security pass before merge.

• test-auditor

  Audit test effectiveness beyond coverage. Invoke when writing tests or before PRs.

Similar plugins