Composer命令行补全需手动注册completion脚本，仅对全局composer生效；漏配会导致composer req<TAB>无响应，因shell默认不识别其命令结构，须通过composer completion bash/zsh生成函数并写入配置后重载。
Composer 命令行自动补全不是“开箱即用”，必须手动注册官方 composer completion 脚本到 shell 配置中，且仅对全局安装的 composer 命令生效——敲 composer req<TAB> 没反应，99% 是这一步漏了。
为什么 composer req<TAB> 完全没反应
这不是 Composer 装错了，也不是网络或权限问题。根本原因是：shell（Bash/Zsh）本身不认识 composer 的命令结构，必须靠外部函数定义补全逻辑。默认安装的 Composer 不注入任何 shell 函数，composer completion 命令就是干这个的。
-
composer completion bash应输出以_composer_completion()开头的大段 shell 函数代码；如果报错Command "completion" is not defined，说明 Composer 版本低于 v2.5.0，先运行composer self-update - Bash 用户需系统级支持：
brew install bash-completion（macOS）或sudo apt install bash-completion（Ubuntu/Debian） - Zsh 用户要确认
compinit已加载——检查~/.zshrc是否含autoload -U compinit; compinit，且composer completion zsh的输出必须放在该行之后 - 局部调用如
php composer.phar require或./vendor/bin/composer install永远不会触发补全，这是设计行为，非配置失败
composer completion bash 和 composer completion zsh 怎么用
这两个命令不安装、不下载、不联网，只是把当前 Composer 版本支持的命令树“翻译”成对应 shell 能理解的函数。输出内容直接追加进 shell 配置文件即可。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 一次性写入：
composer completion bash >> ~/.bashrc或composer completion zsh >> ~/.zshrc - 写完务必重载：
source ~/.bashrc或source ~/.zshrc（新开终端也行） - Zsh + oh-my-zsh 用户额外注意：如果
plugins=( composer )存在，建议删掉该插件项，它会覆盖官方补全 - 验证是否成功：
type _composer_completion应返回函数定义；compgen -A function | grep composer应列出该函数
补全能提示什么？不能提示什么？
官方补全是静态、两级、无上下文的——它不读 composer.json，不查 Packagist，不解析当前项目依赖，只靠预编译的命令结构匹配。
- 能识别：
composer req<TAB>→ 补全为require；composer require --<TAB>→ 列出--dev、--no-interaction等所有 flag - 不能识别：包名（如
laravel/<TAB>）、版本约束（如^8.<TAB>）、自定义脚本名（composer run-script dev-<TAB>不补全） - 不读取内容，不依赖当前目录结构，也不连接 Packagist；不支持模糊匹配或子串搜索——拼错一个字符就失效
- 补全脚本本质是 shell 函数，它不联网、不解析 PHP、不读取项目文件，只靠预定义规则匹配命令树。最容易被忽略的是：它和
composer.json编辑时的包名补全完全无关，后者连脚本名都不支持补全——这点常让新用户反复试错
补全真正起效的前提，是你的 shell 环境已正确加载 compinit（Zsh）或 bash-completion（Bash），且 composer completion 输出的函数体完整写入配置末尾——少一行 complete -F _composer_completion composer，整个功能就静默失效。
