← all publishers

KirillKlem

@kirillklem source repo

Report this profile Claim this profile

• 20 skills
• 0 followers
• 8 hours ago last updated

1. ▌
   Commit Push · kirillklem bundle

   Finalize local git changes into one or more logical commits and optionally push the current branch. Trigger when the user asks to commit, split changes into commits, prepare commit messages, push, or commit+push, including phrases like "закоммить", "закомить", "разбей на коммиты", "сделай коммиты", "подготовь коммиты", "запушь", "коммит+пуш", "commit", "push", "commit and push", or similar. Inspect the working tree, split changes into coherent commit groups, follow the repository's existing commit message style, create the commits, and push once at the end if the user asked to push. Do not use for rebase, merge conflict resolution, revert, cherry-pick, stash management, release tagging, branch renaming, or PR writing.
   0 installs
2. ▌
   Your Skill Name · kirillklem bundle

   Describe one bounded job this skill does, when to use it, and when not to use it. Keep the routing boundary explicit so the skill triggers for the right tasks and stays out of nearby tasks it should not handle.
   0 installs
3. ▌
   Minimal Validation · kirillklem bundle

   Build and run the smallest credible validation loop after code changes. Trigger when the user asks to verify, validate, sanity-check, smoke-test, run the minimal tests, check that a refactor or fix still works, or when code was just changed and the task needs a cheap proof of correctness but no explicit validation plan was given. Inspect the diff, changed files, local project conventions, and available validation commands, then choose the narrowest relevant checks: focused unit tests, file- or package-scoped lint and type checks, smoke checks, targeted local runs, or tiny repros. Prefer the cheapest validation that meaningfully exercises the changed behavior. Do not use for full CI, broad regression suites, performance benchmarking, load testing, or release validation unless the user explicitly asks for those.
   0 installs
4. ▌
   Research Deep Dive · kirillklem bundle

   Deeply analyze a research topic, paper, method family, or technical direction to determine what actually works, under which assumptions, where the approach breaks, and what is still uncertain. Trigger when the user wants a serious research investigation rather than a summary, including prompts about understanding a paper, comparing methods, evaluating a direction, checking whether an approach is worth trying, identifying assumptions or failure modes, or deciding what to take into work. Do not summarize passively. Formalize the problem, build a taxonomy of approaches, extract assumptions, identify fragile claims, compare with adjacent methods, and produce an evidence-based conclusion: what to adopt, what not to adopt, and what remains unknown. Use subagents for bounded literature or documentation exploration when the topic is broad. Do not use for casual overviews, translation, shallow explainers, or repository-local code analysis.
   0 installs
5. ▌
   Change Workflow Hub · kirillklem bundle

   Orchestrate a multi-stage research-to-architecture-to-implementation workflow for a non-trivial software change. Trigger when the user wants to start, continue, or structure a complex change involving research, architecture, module boundaries, adoption planning, or execution planning, including phrases like "давай соберем workflow", "сделай pipeline для этого изменения", "свяжи research и plan", "начнем change dossier", or similar. Create and maintain a change dossier under docs/changes/<slug>/, determine the correct current stage, explicitly route the work to the appropriate specialized skill, and keep INDEX.md synchronized across stages. Do not replace the specialized skills with one large analysis. Orchestrate them and maintain documentation continuity.
   0 installs
6. ▌
   Post Training Eval Report · kirillklem bundle

   Analyze post-training evaluation results using validation metrics, visualizations, qualitative artifacts, ablations, prediction outputs, checkpoints, and experiment context. Trigger when the user asks to analyze validation, interpret metrics or plots, review visualizations, compare experiments or checkpoints, explain confounders, assess result quality, or prepare an evaluation report, including phrases like "разбери валидацию", "посмотри визуализации", "что реально улучшилось", "сравни эксперименты", or "собери report по результатам". Verify evaluation comparability first, then interpret metric movement, slice/class behavior, qualitative evidence, and hidden confounders; separate strong signal from fragile or inconclusive gains; and return an evidence-based engineering report with verdict, surprises, missing analyses, and ranked next actions. Do not use for training-process log forensics during optimization, implementation work, paper reading, or broad research planning.
   0 installs
7. ▌
   Obsidian Project Normalizer · kirillklem bundle

   Normalize a project-specific slice of the Obsidian vault into a derived operational map that clarifies canonical notes, active planning notes, research notes, and missing structure. Use for one project cluster at a time, not for whole-vault atlases or direct note refactors.
   0 installs
8. ▌
   Obsidian Weekly State Rollup · kirillklem bundle

   Produce a bounded weekly rollup for the Obsidian vault by combining Backlog, the current weekly note, and a small recent daily window into a derived state summary under _codex. Use for short-horizon state synthesis, not for full vault mapping or long-range planning design.
   0 installs
9. ▌
   Architecture Options Analysis · kirillklem bundle

   Analyze 2-4 plausible architecture options for a non-trivial software change instead of jumping to a single design. Trigger when the user asks for an architecture plan, design options, trade-off analysis, solution variants, refactor strategy options, migration options, or phrases like "давай подумаем над архитектурой", "разложи варианты", "сравни варианты решения", "какой вариант архитектуры лучше", or similar. Start from the current state and real constraints, enumerate only realistic options, compare them on trade-offs, complexity, cost, risk, migration pain, testing implications, and scaling implications, then recommend one option and explicitly reject the others with concrete reasons. Keep the analysis implementation-oriented and minimal: do not invent unnecessary layers, subsystems, abstractions, or future-proofing unless they are justified by current constraints. Do not use for generic brainstorming, roadmap planning, or writing a full implementation plan after the architecture has already been chosen.
   0 installs
10. ▌
    Obsidian Definition Extractor · kirillklem bundle

    Extract definitions, formulas, and compact glossaries from concept-heavy Obsidian notes into derived companion notes under _codex. Use for term extraction and formula sheets, not for full note rewriting or broad topic atlases.
    0 installs
11. ▌
    Implementation Plan · kirillklem bundle

    Create an execution-ready implementation plan for a software change such as an architecture update, new module, migration, or non-trivial refactor. Trigger when the user asks for a plan, implementation plan, migration plan, refactor plan, architecture plan, or phased execution plan, including phrases like "давай сделаем план", "сделай план реализации", "спланируй рефактор", and "составь поэтапный план". Inspect the current codebase and docs, decompose the work into isolated, reasonably balanced milestones, write or update a repo plan document, and return the milestone plan with the document path. Each milestone must include scope, affected components, concrete steps, lightweight validation, and exit criteria. Keep it minimal and implementation-oriented; avoid speculative abstractions or invented future-proofing. Do not use for personal scheduling, product roadmaps, brainstorming, or direct coding tasks where no plan was requested.
    0 installs
12. ▌
    Performance Speedup · kirillklem bundle

    Audit and speed up a slow module, code path, query, batch job, pipeline, or request handler. Trigger when the user asks to speed up or optimize performance, reports that something is slow, shares logs, traces, timings, or profiles showing high latency or low throughput, or when the current coding task clearly depends on fixing a runtime bottleneck. Diagnose before changing code: identify the hot path, classify the bottleneck (algorithmic, CPU, I/O, database, network, memory, serialization, contention, logging, or redundant work), propose ranked optimizations, apply the highest-confidence improvements, and remeasure. Use profiling, query plans, logs, benchmarks, and suitable tools such as vectorization, batching, caching, indexing, concurrency, DuckDB, or Polars when justified by evidence. Do not use for generic bug fixing, correctness-only debugging, build or install speed, infra provisioning, or vague optimize requests with no performance signal.
    0 installs
13. ▌
    Repo Onboarding Map · kirillklem bundle

    Build a working mental model of a new or unfamiliar repository and write it down as a reusable repository map. Trigger when the user asks to understand a repo, onboard into a codebase, map the repository, explain how the repo is structured, identify entry points, data flow, module boundaries, test surface, risky areas, or important invariants, including phrases like "разбери репозиторий", "построй карту репо", "помоги быстро понять проект", "onboard me to this repo", "map this codebase", or similar. Inspect the current repository, read the key docs and entry points, identify the main execution flows and boundaries, then create or update a concise reusable repo-map document for future work. Do not use for feature implementation, refactor planning, bug fixing, or generic code explanation of one local function.
    0 installs
14. ▌
    Training Run Triage · kirillklem bundle

    Analyze a machine learning training run using logs, metrics, artifacts, config, and system telemetry. Trigger when the user asks to analyze a training run, ClearML task, degradation, instability, divergence, weak results, bottlenecks, surprising metrics, or compare runs, including phrases like "разбери логи обучения", "посмотри clearml run", "что случилось с обучением", "почему деградировало", "где instability", "почему обучение медленное", and "проинтерпретируй метрики". Fetch relevant run data, reconstruct run context and timeline, check metric/log integrity, diagnose learning quality, instability, efficiency, and bottlenecks, then return an evidence-based triage report with surprises, missing instrumentation, and ranked next actions. Do not use for code review, experiment-roadmap planning, paper reading, or direct model implementation.
    0 installs
15. ▌
    Obsidian Topic Atlas · kirillklem bundle

    Build or refresh a thematic atlas for the user's Obsidian vault or one bounded subtree, identifying clusters, hubs, weakly linked areas, and navigation entry points. Use for vault mapping, not for note rewriting, generic summaries, or cross-machine discovery.
    0 installs
16. ▌
    Post Research To Plan · kirillklem bundle

    Convert completed research, option analysis, or architecture work into an execution-ready implementation plan. Trigger when the user wants to move from research to delivery, including phrases like "сделай план внедрения", "переведи ресёрч в план", "что делать дальше", "разложи это на этапы реализации", "из этого нужен план", or similar. Start from what is already known, separate proven conclusions from open hypotheses, identify the cheapest first experiments, decide where spike or POC is necessary, and build a phased implementation plan with the right validation depth at each stage. Keep the plan minimal and evidence-aware: do not pretend that uncertain parts are solved, and do not propose heavy validation where lightweight checks are enough. Do not use for raw research analysis, architecture option comparison, or generic milestone planning with no prior technical investigation.
    0 installs
17. ▌
    Module Boundary Design · kirillklem bundle

    Design a new module or split a large code area into coherent modules with explicit boundaries. Trigger when the user wants to introduce a module, carve out a subsystem, split a large component, reduce coupling, clarify ownership, or phrases like "выдели модуль", "разрежь это на модули", "спроектируй границы", "как правильно выделить новый модуль", or similar. Define responsibilities, boundaries, ownership, input/output contracts, state model, extension points, anti-coupling rules, test strategy, and phased adoption plan. Keep the design concrete and implementation-oriented. Prevent vague helper, service, or utils architectures by making responsibilities and dependency directions explicit. Do not use for broad architecture option comparison, full implementation planning, or generic code cleanup.
    0 installs
18. ▌
    Architecture Spec Writer · kirillklem bundle

    Write a concrete architecture spec, design doc, or tech spec for an already chosen software architecture or technical direction. Trigger when the user asks to write a design doc, tech spec, architecture spec, implementation spec, or phrases like "собери design doc", "напиши tech spec", "оформи архитектуру в документ", "сделай инженерный спек", or similar. The document must act as an engineering contract for implementation: define the goal, non-goals, invariants, interfaces, data flow, dependencies, failure modes, rollout plan, observability, validation plan, and open questions. Keep it concrete and implementation-oriented. Do not produce corporate filler, vague future-proofing, or decorative sections with no execution value. Do not use for architecture option comparison, generic brainstorming, product requirements docs, or a detailed milestone plan after the design is already fixed.
    0 installs
19. ▌
    Verify External API Docs · kirillklem bundle

    Verify external library, framework, language, standard library, CLI, or configuration behavior against official online documentation during implementation, refactoring, debugging, migration, or code review. Trigger not only when the user explicitly asks to check documentation, but whenever the current coding task depends on exact external API details that should not be guessed: method signatures, parameter names or defaults, supported options, return values, exceptions, deprecations, migration changes, version-specific behavior, language semantics, or configuration syntax. Use this for third-party or platform behavior outside the current repository. Spawn a docs-focused subagent, wait for its result, then continue the main task using only the verified facts. Do not use for repository-internal APIs, generic product research, package selection, dependency installation, or unrelated web browsing.
    0 installs
20. ▌
    Obsidian Link Hub Builder · kirillklem bundle

    Build additive companion hub notes for one bounded Obsidian topic cluster, improving navigation and link structure through derived notes under _codex. Use for companion hubs, not for broad atlases, direct note editing, or project-wide normalization.
    0 installs