Dankosik
UserGo REST API template and Golang microservice boilerplate, AI-native for coding agents, with OpenAPI, PostgreSQL, sqlc, observability, and CI.
Categories
Indexed Skills (64)
thermo-nuclear-code-quality-review
Thermo-nuclear review: Use only on an explicit ask for a thermo-nuclear, thermonuclear, harsh, or deep code-quality audit of one fixed candidate. Own read-only structural simplification and maintainability findings; Skip ordinary review and implementation.
go-performance
Measured performance decisions. Use when a workload or budget can change the mechanism, or when an optimization claim needs a comparable baseline, attribution, and delta.
go-reliability
Retry and deadline budgets. Use for any Go decision or review involving end-to-end deadlines, per-attempt timeouts, retry or backoff counts, overload, readiness, drain, shutdown, or rollout recovery.
go-systematic-debugging
First broken invariant. Use when a bug, flaky test, build failure, hang, deadlock, timeout, or regression has an unknown cause and needs diagnosis or authorized root-cause repair.
go-distributed
Durable recovery. Use when cross-service consistency, replay, ordering, compensation, redrive, or reconciliation must survive process or owner boundaries.
go-implementation-ownership
Source ownership in Go. Use when accepted behavior is closed but its package, file, canonical source, dependency direction, or proof location is not.
go-observability
Operator evidence. Use when an operational question needs a signal, SLI, SLO, or alert, or when an emitted field or label changes correlation, privacy, cardinality, or cost.
go-test-strategy
Falsification design. Use while writing tests when a failure observable, deterministic control, or proving layer is non-obvious; resolve that choice inside the current implementation task.
spec-first-brainstorming
Problem frame: Use when a chosen change needs behavior delta, scope, constraints, or readiness. Own frame/next owner; Skip ideation, design, and tasks.
go-coder
Earliest valid owner. Use for an authorized Go outcome whose accepted behavior and owner are closed and need causal production code, routine focused tests, cleanup, and proof.
orchestrator
Ledger routing: Use only as LEDGER_ORCHESTRATOR for a ready persisted Implementation ledger. Own routing; Skip unit work.
go-modern-version
Go version idioms. Use when the module's Go version can change a language or standard-library choice in the planned diff, or modernization is requested.
agent-prompt-composer
Task messages: Use when asked to turn rough input into a clear repository task or handoff. Write as to a capable colleague, preserving intent and leaving execution choices to them.
go-api-contract
Observable contract. Use when a REST change can alter what a deployed client distinguishes across success, error, replay, async recovery, or compatibility.
go-chi
Chi route composition. Use when a change adds, mounts, moves, or reviews routes, middleware, fallbacks, CORS, or bounded route identity.
go-concurrency
Happens-before in Go. Use when correctness depends on overlapping goroutines, publication of shared state, bounded concurrent work, or stopping and joining goroutines.
go-data-architecture
Data authority. Use when identity, durable schema, backfill, projection, derived surfaces, retention, or datastore fit changes where a datum is true over its lifecycle.
go-db-cache
Runtime data access. Use when SQL or transaction boundaries, query semantics, cache freshness or invalidation, or bounded fallback determine a request path.
go-delivery-platform
Release gates. Use when CI/CD, artifact provenance, drift, containers, migrations, rollout, or control-plane evidence determines whether a candidate may ship.
go-domain-invariant
Domain invariants. Use when business acceptance, rejection, transitions, replay meaning, or effect order changes what states and moves are legal.
go-idiomatic
Semantic ownership. Use when errors, context, nil or zero values, method sets, aliasing, or resource lifetimes change what a Go caller observes.
go-language-simplifier
Indirection economics. Use when opaque Go control flow, predicates, names, helpers, or deduplication obscure intent and behavior must remain unchanged.
go-security
Attacker paths. Use when identity, authorization, tenancy, tokens, secrets, injection, SSRF, abuse, or another trust boundary changes what an attacker can reach.
go-structural-quality
Deletion test. Use when a Go diff may overbuild, split responsibility, or add parallel structure and needs an abstraction-cost or collapse decision.
go-system-architecture
Runtime boundary design. Use when a change adds or changes a component crossing, protocol, source of truth, consistency expectation, failure model, or migration topology.
go-test-implementation
Executable Go falsifiers. Use for test-only changes or non-routine fixtures and harnesses, selecting cases and assertions from accepted behavior during implementation.
go-grpc
gRPC typed status paths. Use when grpc-go composition, interceptors, status mapping, streaming, credentials, Protobuf compatibility, limits, health, or shutdown changes an RPC.
go-verification-before-completion
Evidence boundaries for claims. Use for verification-only work or when existing evidence may not prove the requested scope.
acceptance-unit-lead
Unit: Use when bound ACCEPTANCE_UNIT_LEAD for an implementation unit or final delivery validation. Own the assigned boundary; Skip sibling scheduling.
idea-refine
Idea convergence: Use when a raw or solution-led idea lacks one buildable direction. Own problem/outcome/MVP/assumptions/decision; Skip engineering-ready work.
digitalocean-benchmark-runner
DigitalOcean benchmark: Use for authorized Go/PostgreSQL/HTTP measurement on ephemeral Droplets. Own evidence/cleanup; Skip local or undecided work.
grilling
Grill: Use only on an explicit ask to grill/stress-test a plan or decision. Own one question per turn with a recommendation; Skip ordinary answers.
merge-conflict-resolution
Active merge conflicts. Use when an in-progress merge, rebase, cherry-pick, or revert has conflicted hunks that require intent reconstruction, resolution, proof, and continuation.
manage-workflow
Workflow loading: Use for path/phase selection, movement/resume, or before change/build/fix. Own the current required read set and next owner; Skip when AGENTS.md fully owns the answer.
spec-document-designer
Spec authoring: Use for delegated spec.md synthesis or repair from accepted inputs. Own falsifiable behavior; Skip phase and review ownership.
planning-and-task-breakdown
Task ledger: Use when closed decisions need ordered tasks.md. Own boundaries, proof, and reopen conditions; Skip behavior and implementation.
planning-session
Ledger readiness: Use when the full root planning phase must complete through tasks.md authoring or repair, task review, findings repair, and its stop rule. Own phase orchestration and accepted planning readiness; Skip when only delegated draft breakdown or implementation is requested.
pre-spec-challenge
Pressure-test: Use when research/framing needs discriminating questions before spec/planning. Own hidden risks and next owner; Skip blank framing, ordinary review, or one approval question.
research-session
Research: Use when current external or repository evidence could change a task decision and model memory is insufficient, especially for platforms, unfamiliar mechanisms, infrastructure, dependencies, or non-trivial design choices. Own sourced facts, conflicts, implications, gaps, and justified persistence; Skip when local inspection already answers the fact, policy must be selected, or a claim needs executable proof.
spec-clarification-challenge
Approval question: Use for one high-impact, hard-to-reverse, or challenged spec decision. Own read-only evidence/options/recommendation; Skip blank framing, whole-spec review, or low-impact clarification.
specification-review
Evidence boundary: Use for risk-triggered or explicit read-only review of a fixed spec. Own anchored findings and PASS/CONCERNS/FAIL; Skip root self-review, editing, repair, or open-ended authoring.
specification-session
Spec readiness: Use when the whole root specification phase must complete through candidate spec, path/risk-matched review, disposition, and its stop rule. Own phase orchestration and accepted readiness; Skip when only delegated draft authoring or implementation is requested.
technical-design-session
Design closure: Use when the root technical-design phase needs end-to-end system/integration and Go-ownership decisions through review, repair, and its stop rule. Own phase orchestration and accepted design readiness; Skip when implementation or delegated placement-only authoring is requested.
test-design-session
Non-obvious proof: Use when accepted behavior needs dedicated test design before planning. Own proof obligations, deterministic oracles, proving layers, and the test-design handoff; Skip when obvious inline planning proof, executable test implementation, or test review is enough.
workflow-plan-adequacy-challenge
Handoff integrity: Use for contested workflow-plan.md routing or an explicit challenge. Own a read-only anchored gap/next owner; Skip ordinary low-risk plans, authoring, or state changes.
workflow-planning-session
Coordination: Use when a task genuinely needs a compact workflow-plan.md across sessions or independent lanes. Own only the routing, handoffs, and reopen conditions needed for that coordination; Skip when one lane is sufficient or process would exist only for documentation.
auth-access-control
Principal, credential, permission, tenant-isolation, and revocation depth reference reached from go-security.
cache-engineering
Cache value, key, freshness, fill, invalidation, degradation, and value depth reference reached from go-db-cache.
concurrency-control
Durable-state interleaving, arbitration, conflict, fencing, and singleton depth reference reached from go-concurrency.
distributed-system-design
Cross-component topology, state, coordination, resilience, capacity, and evolution depth reference.
durable-background-jobs
Durable acceptance, identity, leases, effects, retries, schedules, and recovery depth reference.
external-api-integration
External provider request identity, bounded attempts, ambiguity, callbacks, reconciliation, and migration depth reference.
postgres-performance
PostgreSQL latency, load, locks, connections, WAL, vacuum, planner, and capacity depth reference.
postgres-schema-design
Relational identity, cardinality, invariant, constraint, lifecycle, and migration depth reference.
reliable-messaging
Broker publish, consume, identity, ordering, acknowledgement, redrive, replay, and business-effect depth reference.
auth-access-control
Principal-first authentication and access control. Use when designing, building, auditing, or diagnosing login and credential flows, OAuth2/OIDC, sessions, JWTs and refresh rotation, API keys, service-to-service identity, RBAC/ABAC/ReBAC permission models, tenant isolation, revocation, or access bugs such as privilege escalation, IDOR, and confused-deputy paths. Route permission storage schema to postgres-schema-design, decision/session cache freshness to cache-engineering, and the external IdP HTTP boundary to external-api-integration.
cache-engineering
Freshness-first cache engineering. Use whenever deciding whether caching should exist; designing or changing request, in-process, distributed/Redis, HTTP, or CDN cache contracts; diagnosing stale or cross-scope data, invalidation races, stampedes, hot keys, eviction, outages, or cache-driven latency/load; or proving cache correctness and measured value. Route PostgreSQL bottleneck attribution to postgres-performance and data ownership/schema invariants to postgres-schema-design.
concurrency-control
Interleaving-first concurrency control for shared durable state. Use when designing, building, auditing, or diagnosing lost updates, double effects from concurrent requests, check-then-act races, duplicate submissions, optimistic vs pessimistic locking, version columns and ETags, unique-constraint arbitration, isolation anomalies like write skew, advisory and distributed locks, fencing tokens, leader election, or singleton work. Route job claim/lease design to durable-background-jobs, PostgreSQL lock contention as a bottleneck to postgres-performance, and constraint modeling to postgres-schema-design.
distributed-system-design
Forces-driven design and review of cross-component distributed systems. Use for service boundaries, interactions, data ownership, consistency, replication, partitioning, scalability, availability, multi-region behavior, failure isolation, capacity, migration, or architectural tradeoffs. Route a single messaging, external-API, background-job, cache, or PostgreSQL mechanism to its dedicated skill; use this skill to compose multiple mechanisms into one system contract.
durable-background-jobs
Lease-oriented discipline for durable background jobs. Use when designing, implementing, auditing, or diagnosing work that must survive request or worker failure: queues/workers and retries; visibility timeouts, heartbeats, stuck or poison jobs, and crash recovery; recurring jobs or scheduled billing; long backfills, checkpointing, cancellation, or drain. Route event/command delivery to reliable-messaging and multi-process business orchestration elsewhere.
external-api-integration
boundary-first production integration with external HTTP providers. Use for design, build, diagnosis, or review of API clients, OAuth credentials, idempotency, deadlines/retries/rate limits, ambiguous outcomes, synchronization, webhooks, reconciliation, and provider migration. Own request identity through convergence and proof; hand public API, business/ledger, messaging, and PostgreSQL internals to their dedicated skills.
postgres-performance
PostgreSQL performance optimization and diagnosis through a tight evidence loop. Use when PostgreSQL performance or capacity is the task: slow queries or regressions; high CPU, I/O, locks, connections, WAL, replication lag, vacuum/bloat, or temp-file load; or requests to reduce database load or improve latency, throughput, or capacity through SQL, indexes, planner statistics, pooling, maintenance, configuration, or architecture.
postgres-schema-design
Invariant-first PostgreSQL schema design. Use when translating business entities and rules into normalized tables, keys, relationships, constraints, ERDs, or safe migrations; or reviewing a schema for integrity gaps, update anomalies, temporal or tenant rules, polymorphic/EAV/JSON misuse, and intentional denormalization. Use postgres-performance instead when the primary outcome is query, load, or index tuning.
reliable-messaging
Delivery discipline for application-to-broker-to-application boundaries. Use when designing or changing publish/consume behavior, diagnosing loss, duplicates, ordering, retries, redrive, or replay, or proving a broker-backed business effect across Kafka, RabbitMQ, Amazon SQS, NATS JetStream, or an equivalent broker. Broker operations belong here when they change that delivery boundary.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.