helderberto
UserMy personal SDLC toolbelt for AI coding agents — PRD to ship.
Categories
Indexed Skills (37)
architecture-audit
Surface architectural friction across a codebase and propose refactors toward deep modules as RFCs. Use when asked to audit architecture, find structural friction, or spot refactor opportunities. Don't use for one module's interface (/codebase-design) or a diff (/code-review).
build
Implement the next unblocked phase of a plan with feedback loops, mark its checkboxes, offer a commit. Use after /plan when `.specs/plans/<slug>.md` exists, or when asked to build the next phase. Don't use for unplanned changes (/tdd) or to check progress (/test).
code-review
Review a GitHub PR for bugs, security, performance, and code quality. Use when asked to review a PR or give pull request feedback. Don't use for local uncommitted changes, creating PRs, or merging.
codebase-design
Shared vocabulary for designing deep modules. Use when designing or improving a module's interface, placing a seam, making code more testable, or when another skill needs it. Don't use for codebase-wide audits (/architecture-audit) or UI components (/frontend-ui-engineering).
create-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 (/spec) or repo conventions (CLAUDE.md).
create-pull-request
Create a GitHub pull request — concise body on the repo's PR template, conventional-commit title, ticket refs. `--draft` for a draft PR, `--diagram[=type]` to add a mermaid diagram of the change.
diagnose
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).
fortify
Improve existing code without changing behavior — split large functions, backfill tests, simplify. Use when asked to "fortify", "make robust", "bulletproof", "strengthen", "add missing tests", "split functions", "simplify", "clean up", or "reduce complexity". Don't use for new features (/tdd), security (/harden), or PR review.
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 finished UI (/a11y-audit).
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 crossing any trust boundary. Don't use for secret scanning (/safe-repo) or dependency CVEs (/deps-audit).
plan
Turn a spec into a multi-phase implementation plan of tracer-bullet vertical slices. Use after /spec when `.specs/specs/<slug>.md` exists, or when asked to break work into phases or slices. Don't use without a spec, or for single-file changes with obvious scope.
prototype
Build a throwaway prototype — a terminal app 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).
review
Fan out parallel read-only reviewers over a diff and consolidate into one severity-ranked verdict. Use for a full pre-ship review, "review/validate this PR", or "spawn agents to review". Don't use for a single-lens PR review (/code-review), one audit, or triaging existing comments (/triage-review).
spec
Create a spec (PRD) through user interview, codebase exploration, and module design. Use when starting a feature with unclear requirements, or asked to spec or define what to build, "write a spec", "write a PRD". Don't use when requirements are crisp and a plan exists (/plan, /build).
tdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests. Don't use to backfill tests on existing code (/fortify) or diagnose an unknown bug (/diagnose).
teach
Teach the user a new skill or concept, within this workspace.
triage-review
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 to write a fresh review (/code-review).
visual-review
Render a GitHub PR diff as a self-contained HTML page, each hunk annotated with a principle and a suggested simplification. Use when the user wants a visual/HTML diff report or PR feedback linked to principles. Don't use for text-only feedback (/code-review), screenshots (/visual-validate), or multi-reviewer orchestration (/review).
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 (/ship) or pull requests.
domain-modeling
Build a project's domain model — challenge terms, pin down a ubiquitous language, write the glossary down. Use when defining domain terminology, resolving ambiguous terms, or another skill needs the shared vocabulary. Don't use for a single architectural decision (/create-adr) or explaining code (/explain-code).
handoff
Compact the current conversation into a handoff document for another agent. Use when the user wants to hand off, move context to a fresh session, or says "write a handoff". Don't use to summarize for the current session or to brief on plan progress (/test).
prose-fix
Fix prose formatting, typos, and clarity in markdown or text files. Use when asked to "fix dashes", "fix typos", "clean up text", or "improve sentences". Don't use for code style, linting, or full rewrites (/revise).
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. Don't use for implementing against pinned dependency versions (/source-driven) or codebase search.
safe-repo
Check the repository for sensitive data. Use when asked to "check for sensitive data" or verify no credentials or company data are committed; `--diff` scopes to staged + unstaged changes. Don't use for general code review or non-git directories.
ship
Commit and push changes with a pre-launch gate (validate-code + safe-repo) by default. `--fast` skips the gate.
visual-validate
Validate UI changes in a real browser via Chrome DevTools or Playwright MCP — before/after screenshots, console and network capture. Use when asked to "visual validate", "check the UI", "screenshot before/after", or after a UI change. Don't use for unit tests (/tdd), E2E flows (/e2e), or backend changes.
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.
validate-code
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, pushing, or writing new tests.
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).
deps-audit
Check dependencies for known vulnerabilities and staleness. Use when asked to "audit dependencies", "check for vulnerabilities", or check dependency health. Don't use for code quality review.
e2e
Write end-to-end tests for user flows with the project's E2E framework (Playwright, Cypress, other). Use when asked to "write e2e tests", "add Playwright/Cypress tests", or test a user flow end-to-end. Don't use for unit or component tests (/tdd) or manual browser checks (/visual-validate).
explain-code
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).
grill-me
Relentless interview to sharpen a plan or design. Use when the user wants to stress-test a plan, pressure-test assumptions, or says "grill me" or "poke holes in this". Don't use for code review (/code-review) or gathering initial requirements (/spec).
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 performance. Use when asked to "audit performance", "analyze bundle", "check bundle size", or find frontend bottlenecks. Don't use for backend performance, database queries, or projects without a frontend build step.
revise
Structurally edit article drafts — reorder sections, tighten arguments, improve clarity. Use when asked to "revise", "improve my article", or "edit my draft". Don't use for typos or formatting (/prose-fix), code docs, or non-article content.
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 or project-internal code.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.