← all publishers

sergeyklay

@sergeyklay source repo

29 published skills

  1. Test TS · sergeyklay bundle
    Write, review, and run TypeScript/React tests for this Next.js 16 App Router project. Use whenever writing or modifying *.test.ts or *.test.tsx files, adding test coverage to components, hooks, Server Actions, or utilities, setting up Vitest configuration, or asked about testing strategy. Covers Vitest (the project's test runner, not Jest), React Testing Library v16, accessibility-first queries, user-event for interactions, AAA structure, parameterized tests with describe.each and it.each, Prisma mock patterns, next/navigation and next/headers mocking, and the RSC boundary testing strategy. Do NOT use for Playwright end-to-end tests or performance benchmarks.
    0 installs
  2. Test Go · sergeyklay bundle
    Write, review, and improve Go test code for this project. Use whenever generating, reviewing, or modifying Go tests - including when invoked by the Tester agent, the /test prompt, or any test-related request. Covers table-driven tests, subtests, t.Parallel(), test helpers with t.Helper(), error assertions via errors.As/errors.Is, fixture loading from testdata/, httptest servers, env-gated integration tests, mock/fake/spy patterns, and adapter conformance. Do NOT use for benchmarks or performance profiling.
    0 installs
  3. Check Dependabot · sergeyklay bundle
    Validate a Dependabot configuration against the published JSON Schema and audit its groups against the repository's real dependency manifests. Use when creating or rewriting .github/dependabot.yml, when adding or reorganising `groups`, `ignore` or `exclude-patterns`, when a dependency lands in the wrong grouped PR or keeps arriving as an individual PR, when Dependabot stops opening PRs after a config edit, or when reviewing a PR that touches dependabot.yml. Catches keys the schema rejects, patterns that match no declared package, ignore entries for packages that no longer exist, and dependencies claimed by two groups at once. Do NOT use for diagnosing a Dependabot PR's failing CI, for choosing version bumps, for npm audit or vulnerability triage, or for validating GitHub Actions workflow files.
    0 installs
  4. Manage Tickets · sergeyklay bundle
    Create, edit, search, transition, close, and triage Jira tickets via the Atlassian MCP. Use when asked to file a bug, request a feature, create a task, log a defect, search the backlog, triage findings into the tracker, edit ticket fields, transition status, or manage Jira work items. Also use when the user says 'create a Jira issue', 'file a bug', 'open a ticket', 'add to backlog', 'search Jira', 'close ticket', 'move to Done', or names any Jira issue key (e.g. 'PROJ-123'). Handles type discovery, parent linking, label assignment, duplicate detection via JQL, status transitions, and issue-link creation. Defers all field-content formatting to the `jira-syntax` skill. Do NOT use for pull requests, changelog entries, non-Jira trackers (GitHub Issues, Linear, GitLab), or managing local TODO.md.
    0 installs
  5. Vet Dependency · sergeyklay bundle
    Measure a candidate library's real maintenance state and its behavior against the protocol, schema, or API version the project has already pinned, before taking it as a dependency. Covers any ecosystem (Go, npm, PyPI, Cargo, Maven) and any forge (GitHub, GitLab, Gitea). Use when deciding whether to adopt, replace, or drop a library, when asked which of two or more packages that do the same job to use ('should we use X or Y'), when an architecture decision turns on whether a package is still maintained, or when a package looks healthy by stars and release count and the real question is whether it can reach the project's pin. Answers with a measured verdict on named candidates, from the unmerged pull request queue and a runtime probe against the published artifact rather than the README. Do NOT use for a vulnerability in a dependency already adopted (scan-security), a weighted-criteria comparison document for publication (compare-it), or a library question with no adoption decision attached (research-it).
    0 installs
  6. Context Files · sergeyklay bundle
    Create or validate project context files (AGENTS.md, CLAUDE.md, GEMINI.md). Use when bootstrapping a new project, initializing agent configuration, writing a context file, or when asked to create, review, audit, or validate an existing context file. Handles codebase archaeology, user interviews, golden-rule validation, and platform-specific formatting. Do NOT use for creating Agent Skills, rules or .instructions.md files.
    0 installs
  7. Delegate Work · sergeyklay
    Brief a background agent, confirm the brief arrived, and verify its report before acting on it. Use when writing the prompt for a subagent or parallel session, when several agents will run against one repository, when an instruction sent to a running agent goes unmentioned in its report, when a delegated fix has been rejected and another verification round is about to start, or before relaying a delegate's report onward. Also use when a delegate's final report arrives as a fragment or refers to a message that never reached you. Do NOT use to measure a run's cost (audit-agent), to prove a green check could go red (prove-checks), or to check a delegated claim (research-it).
    0 installs
  8. Manage Issues · sergeyklay bundle
    Create, edit, search, close, and triage GitHub Issues via the gh CLI. Use when asked to file a bug, request a feature, create a task, report a problem, search the backlog, triage issues, or manage the issue tracker. Also use when the user says 'create an issue', 'file a bug', 'open a ticket', 'add to backlog', 'search issues', 'close issue', or mentions GitHub Issues in any task-management context. Handles label/milestone assignment, duplicate detection, and project board integration. Do NOT use for pull requests, changelog entries, or non-GitHub trackers (Jira, Linear, GitLab) or managing TODO.md file.
    0 installs
  9. Scan Security · sergeyklay bundle
    Run a Snyk SAST + SCA security audit on the repository, remediate findings that pass the project's verification gates, and write a prioritized report to .audit/. Optional scope argument: all (default), code, deps, or changed.
    0 installs
  10. Writing Specs · sergeyklay bundle
    Write technical specifications from feature requests, prompts, or tracker references. Use when asked to specify, architect, design, write a spec, define requirements, create a technical specification, analyze a feature request, or produce a specification document. Also use when given a tracker reference (Jira, GitHub issue, Linear, Asana, etc.) and a specification is the expected output. Do NOT use for code review, implementation, implementation planning, or reviewing existing specs. Produces structured specification documents the implementer can build from without further clarification.
    0 installs
  11. Prove Checks · sergeyklay
    Prove a passing check was capable of failing before recording it as evidence. Use when a test, CI job, build-and-diff, smoke test or rehearsal comes back green and that green is about to be treated as proof - especially when the check depends on a setup mutation (a sed/awk rewrite, an env var, a secret, a fixture file, a branch or working-copy state), when a job passes under continue-on-error, `|| true`, `set +e` or warning-only output, when an event-driven workflow is hand-run while nothing has changed, when simulating a future input such as the next release, or when a flaky or racy fix is about to be called verified. Covers asserting the precondition actually took effect, confirming the subject rather than the receiver was exercised, stripping failure suppressors, and running a negative control, which a race needs forced, not reverted. Do NOT use for zero-hit searches or absence claims (that is research-it), or for authoring unit tests in a specific language (that is test-go or test-ts).
    0 installs
  12. Improve Self · sergeyklay bundle
    Detect when a missing Agent Skill would have made the current task faster or more reliable, then scaffold a candidate SKILL.md for user review. Use after a non-trivial task when one of these signals fires: the same procedure repeated 3+ times, error recovery required inventing a workflow, the user corrected the approach (not the answer), the agent realized mid-task that a playbook did not exist, or 5+ tool calls produced what should have taken 1-2. Detects which `.{vendor}/` directories exist on the host (project and home), reads every skill and slash command in them before proposing, and never duplicates. Writes candidates into the project's .{vendor}/skills/{name} directory that the running host actually loads, never the home folder. Do NOT use for first-attempt failures, one-off questions, fact gaps that belong in research, or style gaps that belong in rules files. Pass the trace and the signal that fired as arguments; the skill does not reconstruct them from the conversation.
    0 installs
  13. Audit Agent · sergeyklay bundle
    Audits AI-agent runs and session snapshots for token usage, cache traffic, cost, duration, turns, tool calls, failures, retries, subagent attribution, duplicated reads, and artifact yield. Use when reporting or comparing a Codex CLI rollout, GitHub Copilot CLI, Gemini CLI, OpenCode, Claude Code, a runner export, or transcript logs. Do NOT use to monitor live CI, prove a check can fail, or sandbox a CLI.
    0 installs
  14. Isolate CLI · sergeyklay bundle
    Run a third-party CLI as a subprocess without leaking into it or leaving state on the host, and prove both. Use when a script or skill shells out to an external tool, when a run must leave no trace outside the repository, when private input (a diff, a prompt, a credential) must not reach the tool's session log, when a policy or deny-list handed to the tool must actually be in force, when a claim about the tool's own behaviour (which paths it searches, which config file wins) must be settled against the shipped binary or bundle rather than its documentation, or before a measurement series whose runs must be comparable. Covers behaviour and state roots read out of the installed binary or bundle, a snapshot-diff-prune harness proven able to go red, and policy rules validated offline. Do NOT use to investigate an external system in general (that is research-it, which delegates here for artifacts on disk) or to judge whether a green result counts as evidence (that is prove-checks).
    0 installs
  15. Jira Syntax · sergeyklay bundle
    Use when writing Jira issue descriptions, comments, or work logs. Also use when converting Markdown to Jira wiki markup, when the user says 'format for Jira', 'Jira markup', 'wiki notation', or asks to create, update, or validate Jira ticket content. Handles bug report and feature request templates. Do NOT use for Jira API operations, JQL queries, or workflow transitions.
    0 installs
  16. Log Changes · sergeyklay bundle
    Use when asked to update the changelog, document version changes, prepare a release, or add entries for recent work, and when reviewing a diff or pull request that touches CHANGELOG.md. Produces concise user-facing CHANGELOG.md entries, follows Keep a Changelog and Semantic Versioning, and verifies that new bullets sit under [Unreleased] rather than a published version. Do NOT use for committing, user guides, or release notes outside CHANGELOG.md.
    0 installs
  17. Manage Todo · sergeyklay bundle
    Read, update, validate, and report on the project roadmap (TODO.md). Use when asked to add tasks, mark tasks complete, check roadmap status, find what to work on next, triage deferred items into the roadmap, validate TODO.md format, reorder or renumber tasks, or edit milestone descriptions. Also use when the user mentions 'roadmap', 'TODO', 'backlog', 'milestone', 'task list', or asks 'what's next'. Do NOT use for architecture decisions, for changelog entries, for creating implementation plans from specs or managing Issue Trackers (Jira, GitHub, Linear, etc.).
    0 installs
  18. Research It · sergeyklay bundle
    Investigate a technical question with a detective's discipline - gathering evidence from primary sources, cross-referencing independent confirmations, and never accepting the first plausible answer. Use when asked to investigate, research, fact-check, verify, deep-dive, or 'find out the truth' about a technology, claim, system, or behaviour. Also use before any explanation of a real-world system, library, or protocol that depends on external facts. Establishes source priority, scales effort to question complexity, triangulates every implementation claim across at least two independent sources, reports conflicts between sources, and refuses to cite training data as evidence. Do NOT use for opinion questions, code generation independent of external facts, internal refactoring, or trivial lookups the user could do themselves.
    0 installs
  19. Review Arch · sergeyklay bundle
    Conduct a principal-level architecture review of a system, specification, diagram, or set of design decisions. Use when asked to review an architecture, evaluate a design, assess coupling/cohesion, check for anti-patterns, audit system boundaries, or produce an Architecture Review Board (ARB) style verdict. Also use when someone says 'review this architecture', 'is this design sound', 'what's wrong with this topology', 'evaluate these tradeoffs', or 'audit this system'. Produces a structured verdict organized around critical risks, significant concerns, observations, strengths, and open questions, grounded in evidence from the codebase and cited against established methodology (ATAM, ISO/IEC 25010, documented anti-pattern catalogues). Do NOT use for line-by-line code review, spec-vs-implementation verification, or PR-level correctness checks. Name the system, spec, or design to be reviewed in the arguments; the skill does not infer the target from the conversation.
    0 installs
  20. Review Impl · sergeyklay
    Review implementation changes for a given task against architectural standards. Use when reviewing a PR, evaluating recently committed code, assessing whether implementation changes are correct and architecturally sound, or when asked to 'review my changes', 'check this implementation', 'review what I built', 'is this PR ready', or 'audit recent commits'. Accepts a task description, task tracker URL, or issue shorthand (owner/repo#123, #123) as input. Produces a structured review with severity-rated findings, code evidence, and a verdict (Block / Request changes / Approve with notes / Approve). Saves the review to .reviews/Review-impl-{slug}.md. Do NOT use for specification review or spec-vs-implementation verification.
    0 installs
  21. Review Spec · sergeyklay bundle
    Architectural review of a specification or design document, performed before implementation begins. Use whenever a spec or design proposal is in scope and the user asks any quality question — even when not phrased explicitly: 'review this spec', 'evaluate this design', 'is this spec implementable', 'is this ready to build', 'check this architecture proposal', 'review the design for feature X', 'is this design sound', 'what's missing from this spec'. Also triggers when a file under `.specs/` is being evaluated without an existing implementation. Do NOT use for verifying an existing implementation against a spec, reviewing a PR or implementation changes, reviewing an existing system's architecture, or security review. Identify the spec and any review focus in the arguments; the skill does not infer them from the conversation.
    0 installs
  22. Verify Impl · sergeyklay bundle
    Forensic audit of an implementation against its authoritative specification. Use whenever a specification document and an implementation are both in scope and the user asks any conformance question - even when not phrased explicitly: 'does this code match the spec', 'verify this implementation', 'check spec conformance', 'audit compliance between design and code', 'is the implementation faithful', 'verify spec coverage', 'audit against requirements', 'spec-vs-code'. Also triggers when a file path under `.specs/` is mentioned alongside an implementation. Do NOT use for general code review, specification design review before implementation begins, security review, or architecture review without a spec document. Pass both the spec and the implementation scope as arguments; the skill does not infer them from the conversation.
    0 installs
  23. Compare It · sergeyklay bundle
    Produce structured architectural comparison documents that evaluate two tools, technologies, or solutions against weighted criteria. Use when asked to compare tools, evaluate alternatives, write a technology assessment, create a build-vs-buy analysis, or produce a recommendation report. Also use when someone says 'which should we use', 'should we adopt X or keep Y', 'compare X vs Y', 'evaluate X against Y', or 'is X better than Y'. Handles evaluation framework design, weighted scoring, cost analysis, risk assessment, gap analysis, and actionable recommendations with reversal conditions.
    0 installs
  24. Explain It · sergeyklay bundle
    Explain technical concepts, mechanisms, and systems to a technically fluent reader who is unfamiliar with the specific topic. Use when asked to explain how something works, walk through an algorithm or protocol, write a deep-dive or onboarding article, answer 'what is X', 'why does X behave this way', 'how does X work', 'break down X', or when synthesising findings from research into a written explanation. Also use when the reader will decide, review or approve rather than build, and asks what a change, task or proposal means in practice, what it costs, or what users will see. Builds understanding progressively along the reader's 'aha path' - opens with the why, bridges to adjacent knowledge, introduces one concept at a time, works the example at the altitude the reader needs, closes with tradeoffs. Do NOT use for marketing copy, code review, reference-style API documentation, or commit messages.
    0 installs
  25. Make Skill · sergeyklay bundle
    Use when creating, improving, comparing, evaluating, reviewing or packaging Agent Skills following the agentskills.io specification. Also use when deciding whether a skill is the right solution vs MCP servers, Claude Rules Files, CLAUDE.md or AGENTS.md. Handles SKILL.md authoring, frontmatter optimization, description writing, progressive disclosure, platform targeting, invocation control, vendor-specific extensions, and distribution.
    0 installs
  26. Manage Adr · sergeyklay bundle
    Create, update, and validate Architecture Decision Records (ADRs) following MADR 4.0 format. Use when the user mentions ADR, architecture decision, decision record, or asks to document a technical decision. Also use when creating new files in docs/decisions/. Handles numbering, frontmatter, section structure, and README index updates. Do NOT use for general documentation or non-architectural decisions.
    0 installs
  27. Search Web · sergeyklay
    Search the live web and fetch page content as markdown via Keenable's keyless API (no key or signup). Use when an answer depends on information that post-dates training data or must be checked against a live source: current events, release notes, changelogs, vendor announcements, whether a project is still maintained. Use when restricting a search to one domain, filtering results by publication date, when built-in web search is unavailable or rate-limited, or when reading a specific URL - 'summarize this link', 'read this page', 'what's on this URL', 'pull this article'. Composes with research-it, which owns investigation method and calls this skill for retrieval. Do NOT use for library or framework API reference (use context7) - unless the request names a site, a date window, or a specific URL, which this skill owns and context7 cannot do. Do NOT use for searching files in the repository (use grep and glob), or for general concepts, algorithms, and design questions that rest on no external fact.
    0 installs
  28. Split Docs · sergeyklay bundle
    Split one oversized Markdown reference document into a progressive-disclosure tree - a curated index page plus one file per section - without altering a byte of prose. Use when a single doc has grown too large to read whole (a multi-hundred-line architecture spec, PRD, catalogue, or reference), when asked to split, shard, or break up a doc into sections, when each row of a table or list should become its own file, when converting a monolith-plus-stale-digest pair into an index-plus-sections layout, or when a digest has drifted from the doc it summarizes. Verifies byte-faithfulness by concatenation and repairs inbound and outbound links repo-wide. Do NOT use for authoring new documentation content (that is make-docs), for choosing a Diataxis type, for splitting source code, or for editing prose during the move.
    0 installs
  29. Make Docs · sergeyklay bundle
    Create, edit, and validate technical documentation using the Diataxis framework. Use when writing tutorials, how-to guides, reference docs, or explanations. Use when reviewing or auditing existing documentation for structural correctness. Use when deciding what type of document to write. Also use when the user mentions Diataxis, documentation quality, documentation types, or asks to write 'deep dive' articles, onboarding guides, API docs, or architectural explanations. Do NOT use for code comments, commit messages, changelogs, or README generation.
    0 installs