genaptic
OrganizationPortable, versioned Agent Skill packs for Claude Code, Codex, and OpenCode.
Categories
Indexed Skills (26)
genaptic-skillsets-create-skill
Create exactly one complete, researched Agent Skill inside an existing skillpack in this Genaptic repository, including routing instructions, resources, evals, registration, generation, and verification. Use when the user supplies a name, details, and scope for one new repository skill. Do not use for generic or personal skill authoring outside this repository, an existing-skill edit, a new or multi-skill pack, release/publishing work, or remote Git operations; use genaptic-skillsets-create-skillpack for a new pack.
genaptic-skillsets-create-skillpack
Create one complete, researched, independently installable skillpack and every declared skill in this Genaptic repository, including boundaries, resources, evals, compatibility fixtures, generated adapters, and verification. Use when the user supplies a new repository pack identity, scope, and detailed list of one or more skills, including a coherent one-skill pack with a genuine independent installation and release boundary. Do not use for generic or personal skill bundles outside this repository, an existing-skill edit, exactly one new skill that belongs in an existing pack, release/publishing work, or remote Git operations; use genaptic-skillsets-create-skill only for that existing-pack case.
postgres-backup-recovery
Design and assess PostgreSQL backup, WAL archiving, point-in-time recovery, retention, encryption, immutability, monitoring, restore runbooks, and recovery exercises against scenario-specific RPO and RTO. Use when recoverability or backup assurance is the goal. Do not use for routine high-availability tuning, query diagnosis, schema modeling, or migration sequencing.
postgres-index-design
Design, review, consolidate, or retire PostgreSQL indexes using proven constraints and query plans, covering access methods, key order, operator classes, INCLUDE, partial and expression predicates, uniqueness, overlap, total cost, and rollout. Use when an index is the established intervention. Do not use to diagnose an unexplained slow query or to execute a production migration.
postgres-migration-safety
Plan and review PostgreSQL production changes for locks, scans, rewrites, compatibility, bounded backfills, constraint validation, concurrent indexes, replication, observability, failure cleanup, and rollback or roll-forward. Use when a target schema or data change is approved for rollout. Do not use to choose the domain model, diagnose a query, or design the backup program.
postgres-query-performance-review
Diagnose PostgreSQL statement latency using sanitized SQL, EXPLAIN evidence, cardinality, buffers, temp work, joins, statistics, waits, parameters, and representative experiments. Use when a query or workload is slow, unstable, or regressed. Do not use for greenfield schema design, broad schema audits, or choosing an index without statement-level evidence.
postgres-schema-design
Design a new PostgreSQL schema from domain invariants and workloads, covering keys, types, nullability, constraints, relationships, tenancy, ownership, RLS, partitioning, index intent, and evolution. Use when creating or substantially reshaping a data model. Do not use for auditing an already deployed schema, diagnosing one slow query, or executing a production migration.
postgres-schema-review
Audit an existing PostgreSQL schema and deployed catalog state for integrity, ownership, privileges, search-path exposure, constraints, RLS, partitions, indexes, and operational drift. Use when reviewing current DDL, dumps, migrations, or catalog snapshots. Do not use for greenfield data modeling, one slow-query diagnosis, or applying remediation in production.
python-domain-exception-policy
Use when, and only when, the user explicitly requests Python exception classes or hierarchies, raise/catch boundaries, exception translation or chaining, traceback preservation, or an internal exception taxonomy or bounded retry classification for internal failures. Do not use this skill merely because another feature can fail or needs user-facing failure behavior.
python-project-layout
Use when, and only when, the user explicitly requests a Python packaging, import-boundary, package discovery, namespace-package, build-metadata, packaged-resource, typing-metadata, wheel, or sdist outcome. Do not use this skill merely to inspect a Python repository or while implementing an unrelated application feature.
python-test-architecture
Use when, and only when, the user explicitly requests repository-wide Python test strategy, multi-level test architecture, suite-wide fixture ownership, global determinism, coverage policy, flake elimination, CI selection, or runtime budgets. Do not use this skill merely because you plan to add tests while implementing another feature.
python-cli-command-design
Design or review a Python command-line interface's command tree, names, arguments, options, configuration precedence, input sources, human and machine output modes, help, destructive-action safeguards, and compatibility policy. Use when shaping how users and automation invoke a CLI. Do not use when only failure messages/exit codes or CLI tests need work.
python-cli-error-output
Design Python CLI failure behavior: messages, debug display, streams, status codes, machine errors, redaction, interrupts, broken pipes, and exception mapping. Use when defining CLI-facing failures. Do not use when the request excludes Python or CLI changes. Add python-domain-exception-policy only for explicit internal taxonomy or translation work; an exception merely causing CLI output keeps this skill alone. Do not use for internal exception work or command-tree design.
python-cli-testing
Design Python CLI tests: invocation, entry points, parsing/help, status, streams, stdin, isolation, TTY, signals, pipes, quoting, and platform CI. Use when changing command-interface tests. A comprehensive CLI-only matrix uses this skill alone. Add python-test-architecture only when explicitly combining it with repository-wide test architecture or CI policy. Do not use for broad strategy without a CLI deliverable, choosing the failure contract, or running an existing smoke command.
rust-abstraction-design
Design or review Rust concrete APIs, generics, traits, trait objects, closed enums, lifetimes, typed errors, panic boundaries, and safe wrappers around unsafe code. Use when deciding whether repeated behavior justifies abstraction or selecting static versus dynamic polymorphism and API failure contracts. Do not use when the primary task is crate/module layout or organizing fields, states, functions, and methods around one domain owner; prefer rust-project-architecture or rust-code-structure.
rust-async-concurrency
Design and review bounded, cancellable async Rust systems, including task ownership, joins and selection, channels, locks, timeouts, graceful shutdown, local tasks, and sync-to-async bridges. Use when Tokio, futures, streams, spawned work, cancellation, or concurrency limits determine correctness. Do not use when HTTP, gRPC, retry, or database-pool behavior is the primary outcome; use rust-networking instead.
rust-code-structure
Structure or refactor Rust structs, enums, functions, methods, constructors, builders, state models, and repeated parameter groups so ownership and invariants are explicit. Use when Rust code contains primitive soup, boolean or stringly typed state, Option-heavy pseudo-variants, god structs, misplaced behavior, or unclear lifecycle data. Do not use for crate/module layout or for choosing traits, generics, trait objects, lifetimes, and public error abstractions as the primary outcome; prefer rust-project-architecture or rust-abstraction-design.
rust-core-best-practices
Review and implement general Rust changes against the target repository's toolchain, MSRV, Cargo policy, ownership model, error conventions, linting, documentation, tests, and safety boundaries. Use when a Rust task needs a broad repository-aware quality pass without one narrower concern dominating. Do not use when crate layout, type structure, abstractions, async behavior, networking, testing, dependencies, portability, workspace prose, or rustdoc is the primary outcome; prefer the corresponding specialized Rust skill.
rust-dependency-portability
Review Rust dependencies, Cargo manifests and features, MSRV policy, supply-chain tradeoffs, and Windows/macOS/Linux portability, including paths, processes, environment, and target-specific code. Use when dependency or platform support is the primary decision. Do not use when crate and module boundaries are the primary outcome; use rust-project-architecture instead.
rust-networking
Design and review safe Rust HTTP, gRPC, and database clients, including connection reuse, transport/domain boundaries, retries, deadlines, backpressure, bounded error handling, and pool budgets. Use when network protocol behavior or remote-resource limits determine correctness. Do not use when task orchestration, cancellation propagation, or process shutdown is the primary outcome; use rust-async-concurrency instead.
rust-project-architecture
Design or review Rust package, crate, module, target, binary/library, workspace, ownership-seam, and test-placement boundaries. Use when creating or restructuring Cargo projects, deciding whether code belongs in an existing crate or a new package, keeping binaries thin, or reducing layout-driven coupling and clone-heavy data flow. Do not use for primarily internal type/API design, async behavior, test implementation, dependency selection, or adding one CLI command; prefer the corresponding specialized Rust skill.
rust-testing-strategy
Plan and review reliable Rust unit, integration, doctest, binary-smoke, live-dependency, and end-to-end tests, including placement, fixtures, determinism, authorization, and evidence. Use when choosing the smallest test boundary or designing coverage across crates and processes. Do not use when public API documentation and doctest prose are the primary deliverable; use rustdoc-maintenance instead.
rust-workspace-documentation
Reconcile a Rust repository's Markdown and agent-facing documentation with its current code, manifests, commands, ownership, and validation workflow. Use when behavior or structure changes require coordinated updates to README, architecture, contributor, operational, or agent guidance. Do not use for a public-API rustdoc-only refresh, a narrow copyedit, or undocumented code changes.
rustdoc-maintenance
Refresh public Rust API documentation, crate and module narratives, intra-doc links, examples, required safety sections, and doctests against the current implementation. Use when one or more Rust crates need coordinated rustdoc review or repair. Do not use for repository Markdown-only reconciliation, private implementation comments, or a feature implementation disguised as docs.
rust-cli-application-design
Design, implement, review, or refactor a portable Rust command-line application across grammar, runtime architecture, domain boundaries, paths, configuration, output, errors, completions, and tests. Use when the overall CLI contract or several cross-cutting command concerns are in scope. Do not use for adding or changing exactly one command in an established CLI or for non-CLI Rust.
rust-cli-command-development
Add or change exactly one command in an existing Rust CLI by extending its discovered grammar, dispatch, domain boundary, effects, output, documentation, and tests. Use when the application architecture and installation boundary already exist and one command is the focused public change. Do not use for a new CLI, a multi-command redesign, publishing, or generic Rust library work.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.