원클릭으로
version
Bump the project version (major, minor, or patch) across all manifest files and add a changelog entry. Use when preparing a release.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Bump the project version (major, minor, or patch) across all manifest files and add a changelog entry. Use when preparing a release.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Execute a Trellis task list by dispatching each task to a Claude Code subagent in its own context window. Use when the user says "build with sub-agents", "build with subagents", or when a feature has 5-20 tasks with dependencies between them. Reads `.specs/<feature>/tasks.md` produced by the tasks skill. Each subagent gets focused context (guidelines + plan + task + learnings) and returns results to the orchestrating session. Supports parallel execution of independent tasks via background subagents with worktree isolation.
Execute a Trellis task list using Claude Code's /batch command for bulk, patterned changes across many files. Use when the user says "build with batch" or when a feature involves repetitive changes across dozens or hundreds of files (e.g., migrating from one library to another, applying naming conventions, adding error handling patterns). Reads `.specs/<feature>/tasks.md` produced by the tasks skill. Translates the task list into one or more /batch invocations with worktree-isolated parallel agents.
Creates or updates .specs/guidelines.md with project-wide stack, conventions, and principles. Use when starting a project or when a fundamental technology decision has changed.
Use when user wants to Creates a pitch document at .specs/{feature}/pitch.md defining a problem domain with constraints, appetite, and solution shape. Use to frame a feature before writing a spec.
Use when user wants to Creates a technical plan at .specs/{feature}/plan.md translating a spec's functional requirements into architecture, technology, and code decisions.
Use when user wants to Creates a lightweight experiment document at .specs/sketches/{slug}.md to test a technical hypothesis before committing to a larger initiative.
| name | version |
| description | Bump the project version (major, minor, or patch) across all manifest files and add a changelog entry. Use when preparing a release. |
| allowed-tools | Read, Edit, Bash(git:*) |
Bump the project version using semver. Accepts one argument: major, minor, or patch.
Given a version MAJOR.MINOR.PATCH:
patch → increment PATCH, e.g. 0.4.6 → 0.4.7minor → increment MINOR, reset PATCH, e.g. 0.4.6 → 0.5.0major → increment MAJOR, reset MINOR and PATCH, e.g. 0.4.6 → 1.0.0All three files must be updated to the new version:
package.json — top-level "version" field.claude-plugin/plugin.json — top-level "version" field.claude-plugin/marketplace.json — "version" inside plugins[0]CHANGELOG.md — new version section inserted at the topIf no argument is provided, ask the user which bump type they want (major, minor, or patch).
Read package.json to get the current version.
Compute the new version according to the semver rules above.
Tell the user: "Bumping version from X.Y.Z to A.B.C"
Update all three manifest files using the Edit tool.
Run git log --format='%s%n%n%b' <last-bump-hash>..HEAD where <last-bump-hash> is the most recent commit matching chore: bump version to (find it with git log --oneline --grep='chore: bump version to' -1). Use the commit subjects and body descriptions as context to write a concise bullet-point list of significant changes for the new version entry.
Read CHANGELOG.md and insert a new version section immediately after the # Changelog heading (before the first existing ## entry) using the Edit tool:
## A.B.C
- Summary of change 1
- Summary of change 2
Report the updated version.
Stage the changed files and commit with the message: chore: bump version to A.B.C