菜单
Use when local Git work needs status inspection, user-work protection, safe branching, diff review, staging, commits, recovery, or publication prep.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Design OpenAPI component schemas with discriminated variants, constrained primitives, subtype/composition choices, nullability, examples, and invalid-state prevention.
Set up a repository for marketplace-driven AI tooling. Use when onboarding a new repo, refreshing a checked-in marketplace reference, installing core marketplace plugins, or documenting which configured marketplaces should be available by default.
Use when validation, authorization, normalization, or state checks produce facts later code must retain. Replace primitive contracts, flags, sentinel states, string protocols, and call-order conventions with proof-carrying values in any language.
Use when Kotlin work needs type-driven modeling, parse-dont-validate boundaries, semantic package layout, explicit failures, API review, or package cohesion checks.
Pkl engineering for typed configuration contracts, expressions, amendments, evaluation, formatting, tests, projects, dependencies, rendering, and packages. Use when a repository contains `.pkl` modules or `PklProject`, or when configuration behavior should be modeled and enforced with Apple Pkl.
Use when creating or validating referential plugin manifests, marketplace entries, primitive references, or payload-to-reference plugin conversions.
| name | git-change-flow |
| description | Use when local Git work needs status inspection, user-work protection, safe branching, diff review, staging, commits, recovery, or publication prep. |
Use this skill for local Git process. It is intentionally host-neutral: GitHub, GitLab, CI, and release workflows can compose it, but the skill must still be useful in any Git repository.
git status --short --branch and inspect relevant diffs before
changing version-control state.Orient. Check branch, remote, upstream, dirty files, ignored generated outputs, and whether the user asked for a commit, push, PR, or only local edits.
Isolate the work. Create or reuse an appropriate branch. Keep unrelated dirty files out of the change set and call out conflicts with the requested work.
Make and validate changes. Run the smallest meaningful checks for the edited surface. Broaden checks when shared contracts, generated outputs, or workflow files changed.
Review the diff.
Use git diff --stat, targeted git diff, and git diff --check before
staging. Confirm generated manifests are current when the repo owns them.
Stage intentionally.
Stage only files that belong to the requested change. Use pathspecs for a
mixed worktree. Use git add -A only when the whole dirty tree is in scope.
Commit or hand off. If the user requested a commit, use the repo's commit convention. Otherwise summarize changed files and validation, leaving the worktree uncommitted.