sergeyklay
UserMy personal, curated set of artifacts for AI coding agents
Categories
Indexed Skills (33)
babysit-pr
Resolve reviewer comments on a pull request or pasted feedback using a six-step evidence-grounded protocol. Use when asked to resolve review feedback, address reviewer comments, process PR comments, triage review feedback, apply review suggestions, handle code review feedback, decide which review comments to accept or reject, or babysit a PR through its review lifecycle. The protocol verifies every library claim with Context7, classifies each comment across seven categories, applies changes surgically or defers them to the project's issue tracker, and emits the summary directly in the chat response for the human operator (never to a file). The skill NEVER posts replies, reactions, or messages back to the reviewer. Do NOT use for authoring a new code review, for security scans, or for opening a new PR.
check-dependabot
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.
compare-it
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.
context-files
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.
create-pr
Use when asked to create a pull request, open a PR, or submit changes for review. Handles branch verification, change analysis, title and description generation, and gh pr create. Do NOT use for committing, pushing without PR, or reviewing existing PRs
delegate-work
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).
explain-it
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.
git-commit
Use when asked to commit, save, or persist changes to Git. Handles atomic commits, branch safety, Conventional Commits format, and project style matching. Do NOT use for pushing, creating PRs, or branch management beyond safety checks.
improve-self
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.
isolate-cli
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).
jira-syntax
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.
log-changes
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.
make-docs
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.
make-skill
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.
manage-adr
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.
manage-issues
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.
manage-tickets
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'). Also use for read-only backlog sweeps: which ticket to pick up next, what is unblocked, what blocks a given key, how many issues are open. Handles type discovery, parent linking, label assignment, duplicate detection via JQL, status transitions, issue-link creation, and large queries that overflow the tool output limit. 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.
manage-todo
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.).
monitor-ci
Drive a long-running GitHub Actions run to a trustworthy conclusion without burning the session on polling. Use when asked to wait for a pipeline, watch a build, babysit a release or deploy run, restart it if it fails, or report whether it went green. Also use when a run must finish before a follow-up step such as a push, a tag, or a dependent job in another repository. Covers confirming the run is the intended one, bounded waiting instead of open-ended blocking, reading the real per-job outcome rather than the summary icon, extracting facts from logs without matching the workflow's own echoed source, and deciding between a re-run of failed jobs and a fresh dispatch. Do NOT use for authoring or debugging workflow YAML, for proving that a green result was capable of failing (that is prove-checks), or for reviewing pull request feedback (that is babysit-pr).
prove-checks
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).
research-it
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.
review-arch
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.
review-impl
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.
review-spec
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.
scan-security
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.
search-web
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.
split-docs
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.
test-go
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.
test-ts
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.
verify-impl
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.
vet-dependency
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).
writing-plans
Convert a technical specification, tracker reference, or feature request into a rigorous, atomic, dependency-ordered implementation plan the coder agent executes step-by-step. Use whenever the output is a Markdown plan file under `.plans/`, or when asked to plan, break down work, sequence implementation phases, turn a spec into actionable tasks, write a roadmap, decompose a feature into phases, or convert a `Spec-*.md` into a `Plan-*.md` artifact. Defines phase structure, output-style rules (WHAT not HOW, signatures only, no language-tagged code fences, symbol references over file paths), step anatomy (atomic, file-explicit, verify-gated), per-phase constraint checks, the philosophy-checklist self-gate, and a validation script. Do NOT use for writing the specification itself, writing implementation code, writing tests, code review, or evaluating an existing plan.
writing-specs
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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.