alexei-led
UserBattle-tested Claude/Codex/Gemini/Pi plugin marketplace — 27 skills, 34 agents, 9 hooks for code review, Go/Python/TypeScript/Web dev, infrastructure ops, and spec-driven development
Categories
Indexed Skills (40)
parsing-documents
Extract structured data from PDF documents — text, tables, forms, and metadata. Use when reading or extracting content from a `.pdf` file, parsing invoices/reports/scanned documents, or converting PDF data to JSON/CSV. NOT for generating PDFs, and NOT for plain-text/markdown files (read those directly).
reviewing-cc-config
Review Claude Code configuration for context efficiency, signal density, and anti-patterns. Use when user says "review config", "review setup", "check configuration", "review cc config", "context review", "config review", "review my setup", "review skills", "review agents", "review hooks", or wants feedback on their Claude Code configuration quality. NOT for editing config files — review only; user applies fixes unless --fix is passed. NOT for applying config changes (use `evolving-config`).
smart-explore
Token-efficient local code navigation and extraction. Use when exploring a known file or bounded module outline, finding a known symbol in a scoped area, or extracting exact function/type bodies with available structure tools and text-search fallbacks. NOT for repo-wide structural pattern search, architecture or trace-flow questions, ast-grep/codegraph/GitNexus evidence, or broad caller/implementation maps.
managing-infra
Infrastructure patterns for Kubernetes, Terraform, Helm, Kustomize, and GitHub Actions. Use when making K8s architectural decisions, choosing between Helm vs Kustomize, structuring Terraform modules, writing CI/CD workflows, or applying security best practices. NOT for cloud CLI commands (see using-cloud-cli) or deploy validation and apply workflows (see deploying-infra).
using-cloud-cli
Cloud CLI patterns for GCP and AWS. Use when running bq queries, gcloud commands, aws commands, or making decisions about cloud services. Covers BigQuery cost optimization and operational best practices. NOT for Terraform or Kubernetes architectural decisions (see managing-infra).
spec-done
Mark a task complete with evidence. Use when finishing a task, discovering which in-progress tasks look done from git history, or verifying quality gates before closing out. Handles follow-up task creation and durable learnings. NOT for reporting progress (spec-status).
spec-init
Initialize a `.spec/` project or extract requirements from a document. Use when there is no `.spec/` directory yet, or to add requirements from an existing design doc. NOT for one-off task/req creation (spec-new) or deep PRD-quality requirement capture (spec-interview).
spec-interview
Capture PRD-quality requirements through structured Q&A. Use when a new requirement needs deep exploration — produces a `REQ-*.md` via 8–15 targeted questions. NOT for creating tasks or implementation plans — use spec-plan for that.
spec-plan
Turn a requirement or a concrete feature idea into an EPIC with vertical-slice TASKs. Use when you have a REQ file, or a feature idea already specific enough for a quick 3–5 question pass, and need an executable plan with dependencies and acceptance criteria. NOT for open-ended idea exploration — use brainstorming-ideas. NOT for capturing PRD-quality requirements — use spec-interview. NOT for implementing tasks — use spec-work.
spec-status
Spec-driven development status and orientation. Use when checking overall project state, viewing a specific task with its linked req/epic, listing tasks by status, running a quality audit for orphans/cycles/missing fields, or for a pipeline overview when unsure which spec sub-skill to use. NOT for mutating state — read-only; use spec-done or spec-work for state changes.
spec-work
Implement the next ready task. Use when starting a development session — selects the highest-priority ready task, plans with a specialist subagent, implements with approval at every step, verifies quality gates, and commits. One task per session. NOT for batch task execution or planning new work — use spec-plan for planning.
writing-typescript
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, behavior tests, and project-configured tooling. NOT for Go, Python, plain HTML/CSS/JS, or server-rendered templates.
deploying-infra
Validate infrastructure changes and, after explicit confirmation, apply Terraform, Helm, Kustomize, or Kubernetes deployments. Use when the user says "deploy", "deploy to staging", "terraform apply", "helm upgrade", "kubectl apply", "rollout", "deploy check", "validate deployment", or "validate infrastructure". Dockerfiles and GitHub Actions are validate-only here. NOT for ongoing service troubleshooting, cloud inspection, rollback investigation, or authoring infra from scratch; use operating-infra for those.
writing-shell
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, TypeScript, Go, web code, or infrastructure operations.
mem-history
Query project history, past decisions, and known gotchas from configured memory, local docs, and git history. Use when user asks "last session", "did we already", "what did we decide", "project history", "timeline", or "what happened with".
writing-python
Idiomatic Python 3.12+ development. Use when writing Python code, CLI tools, scripts, or services. Emphasizes stdlib, type hints, uv/ruff/pyright toolchain, and minimal dependencies. NOT for Go, TypeScript, or shell-only tasks.
spec-new
Create a single TASK or REQ file from a template. Use for one-off artifact creation without the full planning workflow. NOT for full project bootstrap (spec-init) or multi-task planning from a requirement (spec-plan).
writing-web
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
evolving-config
Audit Claude Code configuration against latest features and best practices. Use when user says "evolve", "self-improve", "audit config", "what's new in claude code", "upgrade configuration", "check for improvements", "are we up to date".
using-modern-cli
Prefer modern CLI tools for shell and file workflows — rg, fd, bat, eza, sd, dust, procs, and delta over legacy grep/find/cat/ls/sed/du/ps/diff. Use when writing bash scripts, optimizing command chains, or replacing legacy Unix tools. NOT for repo-wide code search, architecture review, AST/codegraph/GitNexus evidence, or application logic.
browser-automation
Browser automation for rendered UI exploration, validation, screenshots, recordings, and end-to-end flows. Use when a task needs an actual browser or rendered DOM: inspect UI state, click/fill forms, debug frontend behavior, capture evidence, verify a feature, or run/generate browser tests. NOT for API checks or pure logic tests where curl, unit tests, or JSDOM is cheaper.
brainstorming-ideas
Brainstorm ideas and stress-test draft plans before coding. Use when brainstorming, exploring approaches, designing a feature/API/flow, grilling or debating a bounded plan, challenging assumptions, or resolving design-blocking terminology. NOT for implementation task breakdown; use spec-plan. NOT for generic technology comparisons or best-practice research; use researching-web. NOT for docs updates; use documenting-code.
cleanup-git
Remove merged local branches and stale git worktrees. Use when the user says "cleanup branches", "prune worktrees", "tidy git", "remove merged branches", "delete merged branches", "gone branches", or wants to clean local git state. NOT for creating commits, creating worktrees, or configuring git hooks.
learning-patterns
Extract durable learnings from a session and propose project customizations — agent-instructions file, CONTEXT.md, ADRs, project skills, hooks. Use when the user says "learn", "extract learnings", "what did we learn", "save learnings", "adapt config", "capture domain language", or wants to encode session patterns durably. NOT for documentation edits (use documenting-code) or committing changes (use committing-code).
writing-go
Idiomatic Go development. Use when writing Go code, designing APIs, reviewing Go implementations, or changing Go tests. Follow the module's target Go version. Prefer stdlib, concrete types, explicit errors, context propagation, and behavior tests. NOT for Python, TypeScript, shell scripts, or infra-only work.
committing-code
Create normal git commits with logical grouping. Use when committing, saving changes, creating commits, or grouping work into commits. NOT for amending, rebasing, force-pushing, or rewriting history.
documenting-code
Create or update human-facing docs, agent-facing instructions, architecture docs, API docs, README content, and useful code comments from implementation facts. Use when docs are stale, missing, or must reflect code changes. NOT for code-quality review, prompt scoring, speculative docs, or ADRs unless explicitly requested.
fixing-code
Fix code defects with a reproducible feedback loop, root-cause diagnosis, minimal patch, regression test, and clean verification. Use when debugging, diagnosing, or resolving lint/test/build failures. NOT for behavior-preserving refactors (use refactoring-code), test-suite cleanup without a production bug (use improving-tests), or code review findings without fixes (use reviewing-code).
improving-tests
Improve test design and coverage with behavior-focused tests, useful seams, characterization tests, TDD, and test refactoring. Use when improving tests, adding coverage, refactoring brittle tests, removing test waste, or working test-first. NOT for fixing production bugs (use fixing-code), production-code refactors (use refactoring-code), or reviewing non-test code quality (use reviewing-code).
refactoring-code
Batch behavior-preserving refactors for multi-file, repeated-pattern, large-file, rename, move, extract, split, or restructure work. Use for "refactor across files", "batch rename", "update pattern everywhere", large files (500+ lines), or 5+ coordinated edits in one file. NOT for single targeted edits, behavior changes or bug fixes (use fixing-code), test-only refactors (use improving-tests), code review (use reviewing-code), or architecture redesign (use architecture-design/review).
reviewing-code
Use when reviewing changed code, PRs, diffs, or specific files. Finds evidence-backed defects in security, correctness, tests, reliability, performance, maintainability, and docs. Supports quick, standard, deep, team, and external-review modes. NOT for repo-wide architecture review, general codebase exploration, fixing issues (use fixing-code), improving tests without a code review (use improving-tests), or applying refactors (use refactoring-code).
configuring-git-hygiene
Configure safe git workflow hygiene: pre-commit/pre-push hooks, Gitleaks secret scanning, .gitignore rules, local git config, and guardrails. Use when setting up git hooks, gitleaks/git leaks, staged pre-commit checks, pre-push validation, core.hooksPath, .gitignore, or git config best practices. NOT for creating commits (use committing-code), cleaning branches/worktrees (use cleanup-git), or creating worktrees (use using-git-worktrees).
using-git-worktrees
Creates isolated git worktrees for parallel development. Use when starting feature work needing isolation or working on multiple branches simultaneously. NOT for simple branch switching, bulk branch cleanup (use cleanup-git), or git hook/config setup (use configuring-git-hygiene).
operating-infra
Author, inspect, troubleshoot, and review infrastructure across IaC, Kubernetes, cloud resources, containers, CI/CD, and Linux hosts. Use when changing Terraform/OpenTofu, Kubernetes, Helm, Kustomize, Dockerfiles, GitHub Actions, AWS, GCP, Cloud Run, BigQuery, IAM, logs, instances, or service health. NOT for deploy/apply/rollback workflows (see deploying-infra). NOT for shell scripts or generic command pipelines (see writing-shell).
playwright-skill
Support-only Playwright runtime/reference for browser-automation — dev-server detection, a Node.js script runner, and helpers for clicks, form fills, screenshots, multi-viewport, and custom HTTP headers. Use when browser-automation selects the bundled Playwright fallback; do not route user intent here directly.
looking-up-docs
Find current, version-correct library/API/framework docs through one lookup workflow. Use when the user says "look up docs", "how to use", "API for", "syntax for", "examples of", "show me the docs", mentions "ctx7"/"Context7", passes a `/org/project` library ID, or wants the latest/current/actual behavior of a library, framework, CLI, or API. NOT for comparisons, best-practice surveys, or recent ecosystem news — use researching-web.
researching-web
Web research via platform web tools. Use for technical comparisons, recent facts, ecosystem news, best practices, standards, or questions needing grounded web evidence. NOT for API syntax lookup or code examples — use looking-up-docs for those. NOT for repo-specific questions — search local files first.
reviewing-instructions
Use when asked to lint, audit, review, or score AI-facing instruction files such as SKILL.md, AGENT.md, AGENTS.md, CLAUDE.md, platform body.md files, prompt files, rules, policies, and agent-facing references. NOT for application code review, harness configuration review, ordinary docs, tests, or generated build output.
sequential-thinking
Structured stepwise reasoning with explicit revisions and branches. Use when the user says "think step by step", "sequential thinking", "plan this out", "reason through this", "branch this idea", or when tackling a hard multi-step problem (architecture decisions, ambiguous bugs, multi-constraint tradeoffs, plans that may need revision). NOT for trivial lookups, single-tool fetches, or tasks the model can answer directly without planning.
exploring-repos
Explore public GitHub repositories using GitHub CLI, local clones, and available web tools. Use when the user asks how a public repo works, wants architecture orientation, or needs repo-level Q&A. NOT for library API docs (use looking-up-docs) or local private codebases (use a local codebase workflow).
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.