菜单
Scaffolds a new lightweight change spec by copying the spec template directory into a named spec folder. Use this when the user wants to start a spec, plan a change/feature, or create a design doc before implementing (e.g. "spec out the checkout redesign", "create a spec for the new auth flow").
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Instantiates this template into a real project through a guided interview — detects whether the project is new or existing, fills in the placeholders, adapts the docs to the project type, and decides the permissions policy. Use this when someone clones/adopts this template and wants to configure it for their project (e.g. "instantiate this template", "set up this template for my project", "bootstrap the project from this base").
Ports the current branch's change to this template's sibling variants (es/en × with-AI/no-AI) — translates the content, adapts or removes the AI layer depending on the target, and leaves each variant with a PR-ready branch. Use this when a template change must be replicated in the other variants (e.g. "port this change to the Spanish template", "replicate this in the variants").
Cuts a new version — moves the CHANGELOG's Unreleased section to a dated SemVer version, creates the commit and the tag, and optionally the GitHub release. Use this when someone asks to publish/cut a version or prepare a release (e.g. "cut version 1.2.0", "prepare the release", "publish a new version"). Does not push without confirmation.
Brings into this project the improvements its origin template received after instantiation — reads .template-origin, computes the tooling diff (skills, hooks, scripts, workflows) against the current template and offers to apply it. Use this when someone wants to update/sync the project with the template (e.g. "update the template", "pull in the template's new improvements").
Drafts and creates a GitHub issue by filling out the right template from .github/ISSUE_TEMPLATE/ based on the type (bug, feature, documentation, task, or question). Use this when the user asks to open/create an issue, report a bug, or record a task/request (e.g. "open an issue for this bug", "create an issue for the new feature", "log this task"). Does not close or comment on existing issues.
Reviews a database migration before it ships to make sure it is safe — reversible, non-destructive, and backward-compatible — following the project's database conventions. Use this whenever you create, review, or approve a schema or data migration (e.g. "check this migration", "is this migration safe to deploy?").
| name | new-spec |
| description | Scaffolds a new lightweight change spec by copying the spec template directory into a named spec folder. Use this when the user wants to start a spec, plan a change/feature, or create a design doc before implementing (e.g. "spec out the checkout redesign", "create a spec for the new auth flow"). |
| argument-hint | [change name] |
Create a new change spec named in $ARGUMENTS.
specs/README.md to learn the spec workflow, the folder naming convention, and what each template section expects. Follow that doc if it differs from the steps below.$ARGUMENTS into <change-name> (lowercase, hyphen-separated).NNNN: the highest existing 4-digit numeric prefix across specs/ and
specs/archive/ (if it exists), plus one; if there are none, 0001.specs/_template/ directory to specs/NNNN-<change-name>/ (preserve every file in the template).$ARGUMENTS)DraftYYYY-MM-DD)specs/README.md maintains an index of specs, add an entry for the new spec.Example: /new-spec checkout redesign → specs/0007-checkout-redesign/ (if the
latest spec was 0006).
Do NOT start implementing the change, and do NOT delete or overwrite an existing spec folder — if specs/<change-name>/ already exists, stop and ask.