Khasky

Universal coding standards, naming, structure, and patterns for consistent code. Use when starting a project, refactoring, setting up lint/format, or enforcing conventions.

Generates changelogs and release notes from commits and tags. Use when releasing a version, writing release notes, or maintaining a CHANGELOG.

Requires running verification commands and confirming output before claiming work is complete, fixed, or passing. Use before committing, creating PRs, or marking any task done. Applies to any language, test runner, or build system.

Generates pull request title and description from branch name and diff. Use when opening a PR, drafting PR text, or when the user asks for a PR description.

Applies branch naming, merge strategy, and cleanup conventions. Use when creating branches, merging, or when the user asks about git workflow or branch strategy.

Debugs by reproducing, isolating root cause, then fixing. Use when fixing bugs, investigating failures, or when the user reports an error or unexpected behavior. Applies to any language, runtime, or system.

Applies consistent error handling, logging, and user-facing messages. Use when adding or refactoring error handling, or when the user asks for error handling patterns.

Generates conventional commit messages from git diffs. Use when writing commit messages, summarizing staged changes, or when the user mentions commits or changelog.

Deployment strategies, release safety, health checks, and rollback. Use when designing or documenting deploy/rollback, CI/CD, or production readiness. Applies to any stack or platform.

Database migration best practices for schema changes, data migrations, rollbacks, and zero-downtime deployments. Use when creating or altering tables, columns, indexes, or planning schema changes.

How to respond to code review feedback: verify before implementing, clarify unclear items, and push back with technical reasoning when needed. Use when receiving PR feedback or review comments. Applies to any team or culture.

Breaks large tasks or epics into subtasks with acceptance criteria and dependencies. Use when planning work, creating tickets, or when the user asks to break down a task. Applies to any project or team size.

Creates and updates README, API docs, runbooks, and in-code documentation. Use when documenting a project, API, or process, or when the user asks for docs. Applies to any project type or audience.

Maps and navigates unfamiliar codebases quickly. Use when onboarding to a repo, finding where a feature lives, or when the user asks how the codebase is structured.

Reviews code for correctness, security, and team standards. Use when reviewing pull requests, examining diffs, or when the user asks for a code review. Applies to any language or project.

Writes tests before implementation using red-green-refactor. Use when implementing features or bugfixes, or when the user asks for TDD.

Audits code for common vulnerabilities: injection, secrets, auth, and dependency CVEs. Use when reviewing security, before release, or when the user asks for a security check.

Creates and updates runbooks and incident response steps. Use when documenting ops procedures, incident response, or when the user asks for a runbook.

Documents and maintains environment variables and config (e.g. .env.example). Use when setting up config, onboarding, or when the user asks for env docs or .env.example.

Audits and suggests fixes for accessibility (WCAG, keyboard, screen readers). Use when checking a11y, before release, or when the user asks for accessibility review.

REST API design patterns: resource naming, status codes, pagination, filtering, errors, versioning, and rate limiting. Use when designing or reviewing APIs.

Applies structured logging, levels, and PII handling. Use when adding or reviewing logs, or when the user asks for logging standards.

Creates and maintains OpenAPI (Swagger) specs from code or design. Use when documenting APIs, generating client/server stubs, or when the user asks for OpenAPI or Swagger.

Upgrades dependencies safely and reviews breaking changes. Use when updating packages, resolving vulnerabilities, or when the user asks to bump or upgrade deps.

Refactors code in small, test-backed steps without changing behavior. Use when refactoring, improving structure, or when the user asks to refactor safely.