Dankosik
UserGo REST API template and Golang microservice boilerplate, AI-native for coding agents, with OpenAPI, PostgreSQL, sqlc, observability, and CI.
Categories
Indexed Skills (39)
digitalocean-benchmark-runner
DigitalOcean benchmarks: Use when an agent must provision, operate, or clean up ephemeral DigitalOcean Droplets for Go, PostgreSQL, or external HTTP benchmark execution, including private dirty source or a separate k6 generator. Own secure paid-resource lifecycle, same-testbed comparison, artifact return, and cleanup; Skip when measurement stays local, the workload or budget is undecided, or only code-level performance analysis is requested.
agent-prompt-composer
Reconstruction: Use when incomplete, mixed-language, instruction-noisy, or rough source input needs a high-signal English coding handoff grounded in the repository. Own preserved identifiers, facts, authorization, bounded inference, and one agent-ready brief; Skip when the prompt is already clear or needs only translation or copy editing.
go-api-contract
API contract: Use when client-visible REST resources, representations, HTTP semantics, errors, pagination, idempotency, async behavior, or compatibility must be decided. Own the API decision and its proof; Skip when router topology, system/data architecture, security policy, or implementation is primary.
go-chi
Chi transport: Use when router composition, middleware, OpenAPI wiring, fallbacks, CORS, or route labels need a decision, or when changed chi routing needs conformance review. Own chi transport decisions and review; Skip when client-visible API semantics, system topology, or a general Go defect is primary.
go-coder
Smallest complete change: Use when an authorized Go outcome is accepted and ready to implement. Own production code, task-required tests, cleanup, and current claim-scoped proof at the earliest valid owner; Skip when behavior or ownership is unresolved or the request is diagnosis-only, test-only, or verification-only.
go-concurrency
Concurrency: Use when changed Go touches goroutines, shared state, channels, locks, atomics, WaitGroups, timers, worker bounds, cancellation unblock, or join protocols. Own happens-before and lifecycle-mechanism review; Skip when service resilience policy, durable replay, or Go context API semantics is primary.
go-data-architecture
Data architecture: Use when authoritative data ownership, models, tenant identity, schema evolution, backfills, retention, history, projections, or datastore fit must be decided. Own data truth and lifecycle; Skip when runtime DB/cache behavior, business acceptance, distributed recovery, or implementation ownership is primary.
go-db-cache
DB/cache: Use when runtime SQL, transactions, cache role, freshness, invalidation, fallback, or observability needs a decision, or when changed DB/cache paths need conformance review. Own data-access and cache policy and review; Skip when schema authority, distributed consistency, endpoint semantics, or broad concurrency is primary.
go-delivery-platform
Delivery platform: Use when CI/CD gates, release trust, drift controls, containers, migrations, or rollout policy needs a decision, or when changed delivery controls need conformance review. Own delivery acceptance and review; Skip when API, data, security, reliability, or pipeline implementation is primary.
go-distributed
Distributed flow: Use when durable cross-service consistency, sagas, messages, replay, ordering, compensation, redrive, or reconciliation needs a decision, or when changed durable behavior needs review. Own distributed recovery policy and conformance; Skip when local transactions, synchronization, service lifecycle, or system topology is primary.
go-domain-invariant
Domain invariants: Use when business terms, transitions, acceptance, violation, replay, or effect-order policy needs a decision, or when changed Go may violate accepted business rules. Own domain policy and conformance; Skip when transport, data/cache mechanics, security enforcement, or test structure is primary.
go-idiomatic
Go idiom: Use when changed Go may violate language or standard-library contracts for errors, context, nil/zero values, receivers, method sets, aliasing, resources, or exported APIs. Own Go-semantic review; Skip when behavior is correct but readability, whole-diff structure, or package ownership is primary.
go-implementation-ownership
Implementation ownership: Use when accepted decisions need Go package, file, dependency, cleanup, and proof placement, or when changed Go may violate those accepted boundaries. Own implementation placement and conformance; Skip when system topology, domain policy, Go semantics, or local readability is primary.
go-language-simplifier
Go readability: Use when behaviorally correct, locally owned Go is hard to understand or change because of control flow, predicates, naming, or helper shape. Own behavior-preserving simplification review; Skip when Go semantics, package ownership, or explicit whole-diff structural overbuild is primary.
go-observability
Observability: Use when logs, metrics, traces, SLI/SLOs, alerts, diagnostics, privacy, cardinality, sampling, or cost needs a decision, or when changed telemetry needs conformance review. Own telemetry policy, operator evidence, and review; Skip when reliability behavior, performance behavior, or delivery governance is primary.
go-performance
Performance: Use when latency, throughput, allocation, contention, memory, capacity, or workload budgets need a decision; when a design introduces workload amplification such as per-item I/O or serialization, growing scans, fan-out, batching, retention, or contention; or when changed hot paths and benchmark/profile evidence need review. Own measurable performance policy and conformance; Skip when correctness, reliability, or DB/cache policy is primary.
go-reliability
Reliability: Use when timeouts, retries, overload, degradation, readiness, startup, drain, shutdown, recovery, or rollout needs a decision, or when changed Go must conform to accepted resilience policy. Own service resilience policy and review; Skip when synchronization, durable replay, or Go context API semantics is primary.
go-security
Security: Use when trust boundaries, identity, authorization, tenant isolation, browser/token controls, secrets, abuse, injection, or SSRF needs a decision, or when changed Go crosses those boundaries. Own security policy and conformance review; Skip when the primary concern is non-security API, data, reliability, or implementation placement.
go-structural-quality
Structural quality: Use when the user requests a harsh whole-diff review or a change is structurally overbuilt across files. Own abstraction cost, spaghetti growth, mixed responsibility, speculative flexibility, and missed deletion; Skip when Go semantics, local readability, or accepted architecture conformance is primary.
go-system-architecture
System architecture: Use when service boundaries, topology, source of truth, sync/async flow, consistency, failure, or migration must be decided. Own runtime and component authority; Skip when package placement, local data mechanics, domain policy, or implementation review is primary.
go-systematic-debugging
Root cause: Use when a Go bug, flaky test, build failure, hang, deadlock, timeout incident, or production regression needs causal diagnosis. Own the first broken invariant and, only when authorized, the smallest causal fix and replayed proof; Skip when feature implementation, unresolved policy design, broad review, or claim-only verification is primary.
go-test-implementation
Executable proof: Use when approved behavior or test design is ready for Go test code and fixtures. Own the smallest deterministic layer and independent oracle covering required success and failure paths; Skip when production behavior must change, proof strategy is unresolved, existing tests need review, or claims need closeout verification.
go-test-strategy
Test strategy: Use when accepted behavior needs risk scenarios, proof levels, deterministic oracles, or executable gates, or when changed tests and validation evidence need review. Own proof design and test conformance; Skip when behavior is unresolved, tests must be implemented, or completion claims need validation.
go-verification-before-completion
Claim-scoped proof: Use when a correctness, readiness, or completion claim needs current evidence of equal scope. Own claim-to-command matching, result inspection, proof scope, and explicit gaps; Skip when code or tests must change, root cause is unknown, test strategy is unresolved, or implementation is still underway.
grilling
Grill: Use when the user explicitly asks to grill or stress-test a plan, decision, or idea. Own a relentless one-question-at-a-time interview through every material decision branch and a recommended answer for each decision; Skip when a direct answer or implementation is requested without that challenge.
idea-refine
Convergence: Use when a raw, solution-led, or ambiguous product idea still lacks one concrete direction worth engineering. Own the problem, outcome, core bet, MVP boundary, assumptions, and remaining decision; Skip when the direction is chosen and only engineering framing remains.
planning-and-task-breakdown
Task ledger: Use when ready decisions need one delegated, dependency-ordered tasks.md with owners, proof, cleanup, and reopen conditions. Own faithful ledger authoring; Skip when behavior remains unresolved, implementation is requested, or root planning-phase ownership and readiness review are needed.
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 existing research or framing needs a few independent, discriminating questions before specification or planning. Own questions about hidden assumptions, ownership, failure semantics, irreversible consequences, and rollout risk, plus the next owner; Skip when framing is blank, ordinary spec review is needed, or one isolated high-impact approval question is primary.
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 when one candidate-spec decision is high-impact, hard to reverse, or explicitly challenged. Own a read-only pressure test with evidence, options, and decision owner; Skip when framing is blank, whole-spec review is needed, or the clarification is low-impact.
spec-document-designer
Candidate spec: Use when an accepted brief and evidence need one delegated spec.md draft or normalized revision inside an active specification phase. Own faithful document authoring and explicit open decisions; Skip when phase ownership, review gating, or end-to-end repair is needed.
spec-first-brainstorming
Problem frame: Use when a chosen or mostly chosen feature/refactor direction still needs an engineering-ready behavior delta, scope, constraints, assumptions, and readiness decision. Own that frame, prioritized questions, challenge routing, and next owner; Skip when raw ideation, final design decisions, or task breakdown is primary.
specification-review
Evidence boundary: Use when a fixed spec candidate needs a risk-triggered or explicitly requested read-only review. Own anchored findings and a PASS, CONCERNS, or FAIL verdict against current evidence and authorities; Skip when root self-review, editing, repair, or open-ended spec authoring is sufficient.
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 when a workflow-plan.md has high-impact or contested routing/handoffs, or the user explicitly requests a challenge. Own a read-only, anchored gap result and next owner; Skip when the plan is ordinary and low-risk or when authoring or state changes are requested.
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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.