Composer没有bump命令，运行必报“Command not found”；它非官方功能，实为第三方工具或自定义脚本的非正式叫法，核心是Git tag驱动版本管理而非修改composer.json的version字段。
Composer 没有 bump 命令，也不存在官方支持的“版本号自动递增”功能。所谓 “composer bump”，是开发者社区对第三方工具或自定义脚本的非正式叫法，不是 Composer 自身能力。
为什么 composer bump 会报错 “Command not found”
直接运行 composer bump 必然失败——Composer 核心命令列表里从没定义过这个指令。它既不是内置子命令，也不在任何稳定版（包括 v2.7.x 或 v3.0.x）中存在。你看到的教程或 CI 脚本里出现这个词，背后实际是：
- 调用了外部工具如
phpbump、conventional-changelog+standard-version等 - 用 shell 脚本解析并重写
composer.json中的"version"字段（注意：该字段仅在包被发布为私有仓库或 Packagist 包时才生效，项目根目录下通常不该设） - 误把
npm version的习惯套用到 Composer 场景
composer.json 里的 version 字段到底要不要填
绝大多数项目根本不需要手动设 "version"。填了反而容易引发问题：
- 如果你不是在开发一个要被其他项目
require的可发布包（比如私有 SDK 或开源组件），version字段纯属冗余，Composer 完全忽略它 - 一旦填了却没同步打 Git tag，
composer install可能因版本不匹配拒绝安装（尤其启用prefer-stable时） - CI 构建中若用
git describe --tags动态生成版本号，硬编码version会导致构建产物元信息矛盾
真正该关注的是 require 和 require-dev 中各依赖的约束写法，比如 "monolog/monolog": "^3.0" ——这才是 Composer 实际执行版本决策的地方。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
想自动化管理发布版本？别绕开 Git 和标准工具链
如果你的目标是“提交代码 → 自动生成新版本号 → 打 tag → 发布包”，靠 Composer 本身做不到。必须组合使用：
- Git tag 是唯一权威来源：
composer install拉取 packagist 包时，本质是按 tag 名解析语义化版本（如v3.2.1） - 用
standard-version（Node.js 工具）驱动整个流程：它读CHANGELOG.md+package.json（或composer.json）+ Git log，自动 bump 版本、更新日志、提交、打 tag - CI 中发布前加校验：
git describe --tags --exact-match HEAD || (echo "No exact tag match" >&2; exit 1)，确保只允许从带 tag 的 commit 发布
强行在 composer.json 里维护 version 并试图用脚本去 bump，等于把版本真相从 Git 移到 JSON 文件里，后续所有工具（Packagist 同步、GitHub Releases、依赖解析）都会脱节。
真正容易被忽略的是：Composer 本身不参与版本号生成，它只消费版本。所谓“bump”，永远发生在 Git tag 层或包元数据层，而不是 composer.json 文件内部。
