Markuysa
UserReusable agent skills for Claude Code — Go, architecture, analysis, frontend, design, SRE and delivery practices, packaged as installable plugins by topic.
Categories
Indexed Skills (32)
requirements-clarification
Use when a request is vague, underspecified, or stated as a solution rather than a problem — turning it into a problem statement, scope boundaries, acceptance criteria, and open questions before work starts. Triggers on "make it better/faster", one-line feature requests, stakeholder asks without success criteria, or before writing a ticket, user story, or spec.
code-review
Use when reviewing someone else's changes — what to look for and in what order, separating blocking problems from preferences, and phrasing comments so they land. Triggers on "review this PR/diff/branch", a pull request awaiting review, or a request for feedback on someone else's code.
pull-request-authoring
Use when preparing a change for review or responding to review feedback — sizing and splitting a PR, writing the description, commit hygiene, self-review, and handling disagreement. Triggers on "open a PR", "prepare this for review", a large or long-open PR, or review comments that need a response.
query-performance
Use when a query or endpoint is slow, when designing indexes, or when reviewing data access code — reading EXPLAIN output, index selection, N+1 queries, pagination, and connection pool limits. Triggers on slow queries, timeouts under load, "the database is the bottleneck", ORM-generated SQL, or adding an index.
schema-design
Use when designing or reviewing a relational schema — table and key design, data types, constraints, nullability, normalization vs denormalization, soft deletes, and modelling time. Triggers on new tables, a migration adding columns, "how should I model this", or a schema review before it reaches production.
schema-migrations
Use when changing a database schema on a running system — expand/contract sequencing, avoiding blocking locks, backfilling large tables, renaming and dropping columns safely, and rollback. Triggers on a migration file, "add/drop/rename a column", a migration that timed out or locked production, or planning a zero-downtime deploy.
scope-breakdown
Use when planning a piece of work larger than a few days — splitting it into shippable increments, sequencing by risk, surfacing dependencies, and giving honest estimates and status. Triggers on "how long will this take", "break this epic down", planning a milestone, or a project that has been "almost done" for a while.
ui-design-review
Use when critiquing an interface, reviewing a mockup or an implemented screen, or deciding whether a UI is ready to ship — hierarchy, spacing, states, copy, and accessibility. Triggers on "review this design/screen", "does this look right", screenshots of UI, or before handing a design to implementation.
frontend-component-architecture
Use when building or refactoring UI components — deciding component boundaries, where state lives, server vs client state, prop design, and data fetching placement. Triggers on new components, prop drilling, "this component is too big", unnecessary re-renders, or reaching for a global store.
go-concurrency
Use when writing or reviewing Go code that starts goroutines, passes context, uses channels, sync primitives, worker pools, or errgroup — goroutine lifecycle and leaks, context propagation and cancellation, timeouts, and safe shared state. Triggers on `go func`, `context.Context`, `sync.`, `select`, or reports of leaks, races, and hangs.
go-error-handling
Use when writing, reviewing, or refactoring error handling in Go — wrapping with %w, sentinel vs typed errors, errors.Is/errors.As, when panic is acceptable, error message style, and mapping domain errors to transport codes (HTTP/gRPC). Triggers on any Go code that returns, wraps, logs, or inspects errors.
go-service-layout
Use when starting a new Go service, adding a package or layer to an existing one, or reviewing whether Go code is in the right place — package boundaries, cmd/internal structure, dependency direction, interface placement, and wiring dependencies in main. Triggers on questions about where code should live or how to structure a Go project.
go-testing
Use when writing or reviewing Go tests — table-driven tests and subtests, t.Helper/t.Cleanup, parallelism, fakes vs mocks, golden files, httptest, integration tests behind build tags, benchmarks and fuzzing. Triggers on _test.go files, `go test` failures, or questions about how to test Go code.
metrics-and-tracing
Use when instrumenting a service or reviewing its telemetry — choosing metrics with RED/USE, metric types, label cardinality, histogram buckets, span design, and context propagation across services. Triggers on adding metrics or traces, OpenTelemetry/Prometheus setup, a dashboard that doesn't answer questions, or cardinality blowing up the metrics backend.
structured-logging
Use when adding, reviewing, or cleaning up application logging — what to log and at which level, structured fields, correlation ids, cardinality and volume, redacting sensitive data, and sampling. Triggers on log statements in a diff, "add logging", noisy or useless logs, log costs, or an incident where the logs didn't answer the question.
architecture-decision-record
Use when a technical decision with lasting consequences needs to be recorded or revisited — choosing a database, protocol, framework, or boundary; splitting or merging a service; adopting or dropping a dependency. Writes and reviews ADRs. Triggers on "why did we choose", "document this decision", "ADR", or when a discussion converges on a hard-to-reverse choice.
system-design-review
Use when designing a new system or feature at the component level, or reviewing someone's design doc — sizing, data flow, failure modes, consistency, coupling, and operability. Triggers on "design a system for", "review this architecture/design doc", "how should we build X", or before committing to a service split, queue, or datastore choice.
slo-and-error-budgets
Use when defining or reviewing service reliability targets and alerting — picking SLIs, setting SLO targets, computing error budgets, and writing burn-rate alerts. Triggers on "what should we alert on", "set an SLO", noisy or missing alerts, uptime targets, or dashboards that don't reflect user experience.
flaky-test-triage
Use when a test fails intermittently, passes on retry, fails only in CI, or fails only when the full suite runs — reproducing nondeterminism, identifying the cause, and fixing it rather than retrying it. Triggers on "flaky test", "passes locally fails in CI", intermittent red builds, or a proposal to add automatic test retries.
test-design
Use when writing new tests, reviewing a test suite, or deciding what deserves a test — choosing the test level, structuring a test, naming, test doubles, determinism, and what not to test. Triggers on new test files, "how should I test this", untested code under change, brittle tests that break on every refactor, or coverage discussions.
autopilot
Starts, stops, or reports on unattended execution of the whole ticket queue. Refuses to start unless CI is actually gating merges.
plan
Turns docs/PRD.md into an architecture sketch and a set of independent tickets sized for one agent each.
retro
Finds what you had to explain more than once during this work and proposes concrete diffs to CLAUDE.md, skills, or agent roles so the next project starts smarter.
ship
Pre-merge gate for the current branch — runs validator and reviewer, then summarizes the diff for a human decision. Never merges.
spec
Turns a rough idea into docs/PRD.md with real acceptance criteria, by interviewing one question at a time.
execute-ticket
Implements one ticket from docs/tickets/ end to end and hands the branch to review. Designed to run unattended in a cloud session or routine, where nobody is available to answer questions.
frontend-design
Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
next-ticket
Picks the next dispatchable ticket from docs/tickets/ and implements it, without anyone naming which one. Claims by pushing the ticket branch, so concurrent runs cannot take the same ticket.
ponytail
Minimal-code discipline for writing, refactoring, and fixing code — climb the ladder from "does this need to exist" to "minimum that works" before adding anything.
board
Renders the whole ticket queue with derived statuses — the board view of docs/tickets/. Works from git alone, on any hosting or none.
unblock
Reports which tickets became dispatchable after the latest merge. With file-based tickets statuses are derived, so there is nothing to relabel — this is a read-only report kept for routine prompts that call unblock before next-ticket.
design-taste-frontend
Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.