composer list 直接列出所有可用命令（含已安装插件），不依赖 composer.json 或环境，按字母排序并带简短说明；它比 composer help 更轻量，但不显示自定义脚本和上下文隐藏命令（如已有项目中 hide create-project）。
直接运行 composer list 就能看到全部命令
它不依赖当前目录有没有 composer.json，也不挑环境，空文件夹、项目根目录、甚至家目录都能跑，输出就是 Composer 当前能识别的所有命令（含插件注册的），按字母排序，带一行简短说明。
-
composer list比composer help更轻量，适合快速扫一眼有哪些可用命令 - 如果插件（比如
composer-normalize）已全局安装且激活，它的命令也会出现在列表里；没装就看不到，不是漏了 - 某些自定义脚本（写在
composer.json的"scripts"里）不会列出来——它们得用composer run-script xxx才能触发，不属于 CLI 命令范畴 - 旧版 Composer（1.x）可能只显示命令名，没描述；2.x+ 才补全了说明文字和默认值提示
查具体命令怎么用，必须加子命令名：比如 composer help require
composer help 不加参数时，其实只是个快捷入口，真正有用的细节全藏在子命令的帮助页里。比如你想跳过安装时的脚本执行，--no-scripts 这个选项只在 composer help install 或 composer help update 里出现，首页根本找不到。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 所有参数标注都遵循 Symfony Console 规范：
<package></package>是必填项，[--dev]是开关型选项，[--version=VERSION]表示可选但带默认值 -
composer help update会明确告诉你：默认行为是「只更新composer.lock中已有的包」，不会自动拉composer.json新增的依赖——这点不看帮助，很容易误以为update等价于“全量同步” - 部分命令支持别名写法，比如
dump-autoload和dumpautoload都行，但帮助里只写一种形式，实际用哪种都有效 - 想静默执行（跳过安全警告、交互提示等），所有命令都认
--no-interaction，但帮助文档通常只在init这类明显交互式命令里强调它
为什么有些命令死活不显示？上下文决定可见性
不是命令没了，也不是你拼错了，是 Composer 主动隐藏了语义冲突的命令。比如你在已有项目的根目录下运行 composer help，create-project 和 init 就不会出现——因为这两个命令的本意是“从零开始”，当前目录已有 composer.json，Composer 认为它们不适用。
- 想看到初始化类命令？换到一个空目录再试
composer help -
composer self-update永远不会出现在任何help或list输出里——它是内置逻辑，不是标准 Command 类实现 - 插件命令（如
phpstan analyse）要等插件装好、autoload 加载成功后才进列表；否则报错Command "analyse" is not defined - 某些高级选项（如
--no-cache）的帮助文本极简，甚至不提副作用：它不只是“不读缓存”，还会跳过整个composer cache目录的校验逻辑，CI 中常用，但本地频繁切分支时慎用
终端太长看不过来？用管道过滤关键词最实用
帮助输出动辄上百行，尤其插件一多，根本没法人工扫。与其硬看，不如直接搜你关心的词。
- 查开发依赖相关：
composer help require | grep -i "dev\|prefer" - 查镜像配置：
composer help config | grep -E "(repo|mirror)" - Windows 用户用
findstr替代：composer help update | findstr /i "lock" -
--format=json或--format=markdown能导出结构化帮助，但日常几乎用不到，仅限脚本集成或调试时需要
composer help xxx 里。但得注意上下文、版本差异和插件状态，否则看到的永远不是完整图景。
