kolabse-skills

Coordinate one auditable change across implementation and separate canonical documentation repositories, including required infrastructure or operations repositories. Use when application behavior and authoritative documentation (including operational contracts) in another repository must change together, or publication must prove their exact revisions agree. Do not use for independent multi-repository edits, a digest, same-repository documentation, or repository synchronization alone.

Implement new testable behavior or behavioral fixes through recorded red-green-refactor cycles. Select automatically for such implementation work, and when the user requests TDD or project policy requires it. Exclude diagnosis-only requests, after-the-fact coverage, tests-only work, and documentation, formatting, or low-impact edits without behavioral change.

Investigate reported software errors, unexpected behavior, regressions, crashes, or flaky tests to explain their cause, including requests to fix a problem whose cause is unknown. Use for direct failure reports as well as explicit diagnosis requests; exclude implementing an established fix, copyediting error messages, and reviewing a PR.

Discover and rank reusable skill ideas from bounded project rules and user-approved evidence; export selected portable contribution packages or validate received skill-candidate JSON packages for maintainer review. Use when the user asks which rules, project patterns, Git history, documentation, current-chat practices, or approved summaries from supplied chat exports and sync-project-context handoffs should become skills; wants to compare ideas with existing skills, prepare an implementation brief, contribute an idea to kolabse/skills, or check an incoming candidate package. Do not use to create skills, validate unrelated JSON documents, enumerate chats implicitly, scan source code broadly, or turn secrets, organization policy, and one-off conventions into reusable workflows.

Plan, execute, and verify a standard or hotfix release through project-declared GitFlow branch roles and gates. Use when a repository has a persistent development line, protected production line, and an explicit GitFlow release contract. Do not use for trunk-based delivery, an undeclared branch model, generic push verification, or releases of this skill collection.

Plan and verify a project-declared development lifecycle from feature preparation through reviewed development integration, delegated production delivery, documentation completion, and proved cleanup. Use when a change must cross configured repository, test, review, pipeline, deployment, notification, and documentation gates. Do not use for ad hoc edits, provider-specific automation, or direct production execution.

Create and maintain a project documentation digest of completed user-visible changes, grouped by category under today's date. Use when the user asks for a digest, daily change summary, or nontechnical record of what changed for users. Do not use for technical work logs, release notes for a specific release, commit history, or planned work.

Maintain the canonical dated project work log at docs/reports/work-log.md. Use when the user or applicable project instructions require that log for the current task; when recording material changes, operations, diagnostics, decisions, verification, or blockers in an already configured work-log workflow; when initializing its policy in AGENTS.md or CLAUDE.md; or when reconstructing missing entries from Git history and available project conversations. Do not infer this skill from ordinary project work alone when no work-log requirement is present, and do not use it for application logs, time-tracking products, or personal notes.

Maintain a project's persistent active work plan: add or reorder tasks, preserve IDs and dependencies, reconcile verified completion with the work log, and synchronize dated plan items with the user's calendar. Use when the user or project rules require maintaining that plan, including its linked calendar events. Do not use for a one-off implementation outline, personal reminders unrelated to a project plan, or recording completed work only.

Send agent-task progress notifications to Telegram, configure routing, or enable and use experimental task-scoped Telegram replies in Codex or Claude Code on Windows. Use when the user requests Telegram updates, answering agent questions via Telegram, receiver setup or updates, or applicable instructions authorize task notifications there. Task duration, complexity, waiting, or deployment alone does not activate this skill. Exclude progress requested only in the current chat, building Telegram products, and unrelated business messages.

Operate project-scoped Yandex Cloud infrastructure safely. Use when the request explicitly targets Yandex Cloud or applicable project configuration, inventory, or instructions establish that the target resources are in Yandex Cloud. Covers Yandex Cloud CLI and OS Login; project-scoped SSH; Terraform, Ansible, Helm and Kubernetes; CI/CD, deployments and releases; DNS, networks, databases, storage, backups, monitoring, secrets, incidents, and read-only cloud discovery. Do not infer Yandex Cloud from generic Kubernetes, SSH, Terraform, or deployment work without that provider context.

Coordinate explicitly requested subagents or parallel agent work by assigning bounded ownership, monitoring progress, reconciling outputs, and verifying the integrated result. Use when the user or project instructions request delegation or parallel agents; do not use merely because a task has several steps.

Plan, verify, audit, and safely clean up a deterministic release of a reusable skill collection. Use when preparing, checking, tagging, or publishing a collection release; validating commit-bound gate evidence; auditing immutable GitHub assets and attestations; or proving temporary release branches are represented upstream. Do not use for releasing an ordinary application, browsing releases without verification, or deleting branches without a completed release.

Prepare and optionally submit a privacy-bounded feedback report about an installed skill after separate user approvals for collection and external submission. Use when a user wants to report whether a skill triggered, completed its workflow, failed, required manual intervention, or should be improved. Do not collect whole chats, source code, secrets, identifying project data, or submit anything without preview and fresh approval.

Resolve explicitly requested Git merge, rebase, or cherry-pick conflicts path by path while preserving unrelated work and validating the semantic result. Use for an active conflict or a specifically authorized reconciliation; do not use for ordinary repository divergence or synchronization.

Plan and apply cleanup of a merged task's local and remote Git branches and explicitly selected inactive worktrees, using fresh GitHub PR or GitLab MR evidence and exact revision checks. Use when retiring completed task resources or assessing whether a squash/rebase-merged branch is safe to remove. Do not use for merging reviews, deleting unmerged work, generic file cleanup, or collection release cleanup.

Review a defined code change for actionable correctness, security, reliability, and compatibility defects with evidence-bound findings. Use for diffs, branches, commits, pull requests, and requests to merge or integrate a defined change; validate any current revision-bound review before reusing it. Do not use for general code explanation, merge-status questions, or requests only to implement review feedback.

Save, restore, or bidirectionally synchronize private, sanitized project and per-chat continuation state between computers, and reconcile explicitly declared project rules, skills, plugins, and safe settings that Git does not already provide. Use when the user asks to save or restore state, synchronize project chats, preserve exact chat titles, continue work on another computer, check whether project rules or dependencies are portable, or audit stored handoffs. Use either an approved synchronized folder or the connected Google Drive plugin, always outside the repository. Do not use for source-code or Git transfer, raw chat export, hidden chain-of-thought, credential or OAuth transfer, or upload to an unapproved account.

Safely establish remote freshness for one or more existing Git repositories without overwriting local work, and bootstrap an authorized publishable feature branch at a verified primary-branch SHA before the first code edit. Use when a repository has a configured remote or upstream and the task depends on current remote state: before analysis, edits, validation, commits, pushes, deployments, or remote execution when project policy requires synchronization; across related code, infrastructure, or documentation repositories; when the user asks to fetch, pull, update, compare with upstream, check whether repositories are current, or publish a feature branch before work; and when configuring a synchronization policy in AGENTS.md or CLAUDE.md. Do not use for local-only Git work, repository initialization, conceptual Git help, or destructive remote-ref operations unless synchronization is also requested.

Declare a shared kolabse skill set in project documentation and compare or align global installations for Codex and Claude Code while keeping project configuration local. Use when a team wants reproducible skills, onboarding parity, version-drift diagnosis, or installation from a reviewed team manifest. Do not synchronize secrets, global preferences, or arbitrary third-party tools.

Run project-declared checks and bind their results to the exact Git state before push. Use when configuring a repository pre-push verification policy; before pushing changes that require tests, lint, builds, migrations, or other quality gates; when generating or validating SHA-bound verification evidence across one or more repositories; and when implementing a fail-closed gate for explicitly protected repositories without blocking unrelated commands or repositories.