菜单
This skill should be used BEFORE running any git commit command. Triggers when about to run `git commit`. Ensures commit messages follow Conventional Commits specification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Analyze the resource usage of a Kubernetes Deployment, StatefulSet, or DaemonSet over the last 30 days and recommend right-sized CPU/memory requests and limits plus autoscaling (KEDA/HPA) improvements. Triggers when the user asks to "right-size", "analyze resource usage", "tune requests/limits", "is this workload over/under-provisioned", or "improve autoscaling" for a named workload. Reads live cluster spec and 30-day metrics through a single Grafana instance (delegating to the sre-grafana and sre-kubernetes skills), treats the live cluster as authoritative and an optional manifest as the verification + apply target, and never edits cluster resources directly. Detects common database and JVM engines (MongoDB, PostgreSQL, Redis, Kafka, ClickHouse, Elasticsearch/OpenSearch, generic JVM) and sizes memory from the engine cache/heap model instead of raw working set. Also recognises page-cache-sensitive services (Vault, etcd, Loki) that thrash without OOM/PSI, using major page faults as the memory guard.
Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.
Use when addressing the review feedback left on a GitHub pull request - reads all review comments, suggestions, and conversation, validates each one, and implements the valid ones as local edits after per-item confirmation. Triggers on "address PR review comments", "implement review feedback", "apply PR suggestions", "go through / resolve the comments on my PR", or "fix review comments". This skill CONSUMES and IMPLEMENTS reviewer feedback - it does NOT author review comments (that is the github-pr-review skill).
Use when reviewing GitHub pull requests with gh CLI - creates pending reviews with code suggestions, batches comments, and chooses appropriate event types (COMMENT/APPROVE/REQUEST_CHANGES)
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
This skill should be used when the user wants to write, create, or generate a Jira ticket. It produces well-structured tickets with a user story, background paragraph, and acceptance criteria checklist — shown as Markdown and created in Jira via Atlassian Document Format (ADF) so they render cleanly in the web UI.
| name | git-commit |
| description | This skill should be used BEFORE running any git commit command. Triggers when about to run `git commit`. Ensures commit messages follow Conventional Commits specification. |
| metadata | {"source":"https://github.com/fredrikaverpil/dotfiles/blob/main/stow/shared/.claude/skills/git-commit/SKILL.md"} |
Write commit messages following the Conventional Commits specification.
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
| Type | Purpose |
|---|---|
feat | New feature |
fix | Bug fix |
docs | Documentation only |
style | Code style (formatting, no logic change) |
refactor | Code change that neither fixes a bug nor adds a feature |
perf | Performance improvement |
test | Adding or correcting tests |
build | Build system or external dependencies |
ci | CI configuration |
chore | Maintenance tasks |
revert | Reverts a previous commit |
Add ! after type/scope or include BREAKING CHANGE: in footer:
feat(api)!: remove deprecated endpoints
BREAKING CHANGE: The /v1/users endpoint has been removed.
Optional. Use to specify area of change (e.g., api, ui, auth, db).
After committing, check whether a pull request already exists for the current branch and offer to create one if it does not.
Check for an existing pull request:
gh pr view --json url
If this succeeds, a pull request already exists — do nothing further.
If no pull request exists (the command above fails), ask the user whether a pull request should be created. Only continue if the user confirms.
Create the pull request as a draft, using the commit subject as the title and the commit body as the body:
gh pr create --draft --title "<commit subject>" --body "<commit body>"
--title is the <type>(<scope>): <description> subject line.--body is the commit body. If the commit has no body, pass an empty
string (--body "").