Autonomously fix a YouTrack issue end-to-end: from ticket pickup through code fix, tests, PR creation, CI validation, and reviewer assignment.
Guides commit message writing for the kotlinx-rpc project. Use this skill whenever committing code, writing commit messages, or when the user asks about commit conventions. Also use it when reviewing PRs for commit message quality. Triggers on: /commit, "commit", "commit message", "git commit", writing changelogs from commits.
Modify, build, publish, and verify the Kotlin/Native shim artifacts (gRPC shim and protobuf shim) in native-deps/shims/. Use this skill whenever the user wants to change shim C/C++ source code, update shim headers or .def files, bump a shim upstream version, add or remove archives from the overlap excludes list, patch KLIB metadata, update the annotation module, run shim fixture tests, publish shim artifacts locally, or debug any native shim build failure. Also trigger when the user mentions "shim", "cinterop", "native interop", "grpc shim", "protobuf shim", "KLIB patcher", "overlap archives", "native-deps", "Bazel shim build", or "shim verification".
Query and analyze kotlinx-rpc build scans, test results, and failure patterns from the Develocity server (ge.jetbrains.com) using MCP tools. Use this skill whenever the user wants to look at build scans, investigate CI failures across builds, check build cache hit rates, analyze flaky tests, find recurring failure patterns, or query build performance history. Also trigger when the user mentions "Develocity", "build scan", "GE", "ge.jetbrains.com", "build cache stats", "flaky tests", "failure groups", or asks about build trends, test stability, or CI health. Trigger even if the user doesn't say "Develocity" explicitly -- if they want to look at historical build data, cross-build test analysis, or failure aggregation, this is the right skill. Do NOT use this skill for running local Gradle builds -- use `running_gradle_builds` or `running_gradle_tests` instead. Do NOT use this skill for TeamCity build triggering or queue management -- use `use-teamcity`.
File YouTrack issues for the kotlinx-rpc project (KRPC). Use this skill whenever the user wants to create a bug report, feature request, task, or any issue in YouTrack for kotlinx-rpc. Also use it when the user mentions filing a ticket, reporting a bug, creating a task, logging an issue, or tracking work in YouTrack — even if they don't say "YouTrack" explicitly but the context is clearly about issue tracking for this project. Covers choosing the right issue type, scope, priority, tags, and writing well-structured descriptions that match the team's conventions.
Determine which LOCAL verification checks to run for kotlinx-rpc changes and execute them on the developer's machine. TeamCity builds and GitHub Actions workflows are out of scope -- this skill covers only what can and should be run locally before pushing. Use this skill whenever changes are made to the codebase and you need to verify correctness before committing or opening a PR. Also use it when the user asks to "run checks", "verify changes", "run verifications", "what checks do I need", "validate my changes", "pre-PR checks", or "local checks". Trigger proactively after completing any code modification task -- even if the user doesn't explicitly ask, suggest which verifications are relevant based on what changed.
Update kotlinx-rpc documentation — version bumps, content edits, Writerside topics, KDoc, README, skills, and internal workflows. Use this skill whenever the user wants to bump the Kotlin version in docs, bump the library version, update the changelog, edit documentation topics, add a migration guide, update the version switcher, fix version references, write or update KDoc on public APIs, update the README, update Claude skills, or modify CLAUDE.md. Also trigger when the user mentions "update docs", "doc version", "release docs", "Writerside", "v.list", "changelog", "KDoc", "Dokka", "README", "skill", "CLAUDE.md", or wants to sync documentation with a new release.
Interact with the kotlinx-rpc TeamCity CI/CD project using the `teamcity` CLI. Use this skill whenever the user wants to trigger builds, check build status, view build logs, monitor failures, manage the build queue, inspect agents, or do anything related to TeamCity CI. Also use it when the user mentions "TC", "TeamCity", "CI build", "run build", "build status", "build log", "trigger build", "check CI", or references a build configuration name or ID. Trigger even if the user doesn't say "TeamCity" explicitly -- if they ask about CI status, build failures, or want to run something on CI rather than locally, this is the right skill. Do NOT use this skill for local Gradle builds -- use `running_gradle_builds` or `running_gradle_tests` instead.