scripts 必须显式控制退出码才能拦截坏代码提交，如 phpcs 需加 --severity=5 或 --report=checkstyle，php-cs-fixer 检查用 --dry-run --diff，修复用 fix，且路径统一用 vendor/bin/；pre-commit 钩子应通过软链绑定 composer scripts，并确保 ci 环境路径、shell 和退出码逻辑一致。
composer.json 里 scripts 怎么写才真正生效
不加 --dry-run 或 --severity 的脚本，看起来在跑，其实根本拦不住坏代码提交。比如 "cs": "phpcs src/" 默认返回码永远是 0，Git 提交照常通过。
- 必须显式控制退出码：用
--severity=5（warning 及以上就失败）或--report=checkstyle配合 CI 解析 - 格式化工具要区分“检查”和“修复”：检查用
php-cs-fixer fix --dry-run --diff，修复用php-cs-fixer fix - 别直接写
phpcs—— Windows 没这个可执行文件，统一用vendor/bin/phpcs或确保 PATH 包含vendor/bin - 多命令组合推荐用数组写法：
"pre-commit": ["@cs", "@stan", "@test"]，比拼接字符串更易维护、错误定位更准
Git pre-commit 钩子怎么和 composer scripts 绑定
手动往 .git/hooks/pre-commit 里写脚本容易被覆盖，也难同步到团队。正确做法是把钩子脚本放项目内，再软链过去。
- 创建
scripts/pre-commit，开头必须是#!/bin/sh（不是#!/usr/bin/env bash，部分 Linux 默认没 bash） - 脚本里调用
composer run-script pre-commit，然后用if [ $? -ne 0 ]; then exit 1中断提交 - 给脚本加执行权限：
chmod +x scripts/pre-commit - 安装钩子：用
ln -sf ../../scripts/pre-commit .git/hooks/pre-commit，或写个install-hooks脚本供post-install-cmd自动触发
为什么本地能跑，CI 却总失败
常见原因是路径、环境变量、退出码逻辑三处不一致。CI 环境通常没交互终端、PATH 更窄、shell 是 dash 而非 bash。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
vendor/bin必须显式写全路径：./vendor/bin/phpstan，不能只写phpstan - 别用
sh -c "xxx | grep"这类管道——dash 不支持；改用&&串联，靠返回码判断 - CI YAML 里传参要小心：
script: composer phpcs -- --extensions=php，中间两个--缺一不可 - PHPStan/PHPCS 配置文件（如
phpstan.neon、phpcs.xml）必须放在项目根目录，否则 CI 找不到
scripts 里能不能做条件判断或传参
不能原生支持 if/else，但有替代方案；传参可行，但语法很关键。
- 条件逻辑交给外部 PHP 脚本：
"check-env": "php scripts/check-env.php"，在里面读$_SERVER['APP_ENV']再分支 - 传参必须用
$@占位："test": "phpunit --colors=always $@"，调用时写composer test -- --filter=testLogin - Windows 用户慎用
$@，可用cross-env包兜底，或统一要求用 WSL - 避免在 scripts 里硬编码数据库连接、API 密钥等敏感信息——这些该走环境变量或配置文件
实际跑起来最易忽略的点是：退出码是否真的由质量工具决定，而不是 shell 脚本本身。很多团队配完以为万事大吉，结果 CI 里 phpcs 报了一堆 warning 却仍显示 “success”，就是因为漏了 --severity 或用了不控制退出码的 --report 格式。
