description字段应一句话精准说明包功能，如“生成并验证ULID和UUID v4的轻量工具，无框架依赖”，长度≤120字符，避免营销话术与空泛表述。
description 字段只影响 Packagist 页面展示和搜索匹配，不参与依赖解析或安装逻辑。它不是必填项，但空着会让包在搜索结果里缺乏上下文。
description 字段怎么写才有效
用户搜包时，第一眼看到的是 name 和 description。如果写成「一个基于 Laravel 的 UUID 工具」，等于没说——没人知道你到底干啥、能不能直接用。
- 用一句话说清「这个包是干什么的」，比如：
"生成并验证 ULID 和 UUID v4 的轻量工具，无框架依赖" - 删掉所有营销话术：「最强大」「零配置」「业界领先」——Packagist 不渲染加粗，也不支持 Markdown
- 长度控制在 120 字符内，超长会被截断；
composer show命令通常只显示前 80 字左右 - 避免缩写歧义，比如
laravel-uuid的 description 不能只写「Laravel UUID 支持」，得点明「提供 Laravel Artisan 命令 + Model trait + Blade 指令」
name 字段错位会导致 autoload 失败
name 不只是“名字”，它直接决定 PSR-4 自动加载的根命名空间推导逻辑。写错就 class not found，而且错误提示根本不提 name。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须是
vendor/name格式，全小写，用短横线分隔，例如："acme/http-client" - 对应 autoload 中的命名空间是严格转换的：
acme/http-client→AcmeHttpClient（短横线变大驼峰，斜杠变反斜杠） - 如果你的
autoload写的是"MyTool\Core\": "src/"，但name是"mytool/core"，Composer 就会按MytoolCore去找类——首字母大小写不一致，直接失败 - 本地改过
name后，记得删掉vendor/并重装，否则旧的 autoload 文件仍保留错误映射
keywords 字段影响 Packagist 搜索排序但不校验格式
keywords 是纯字符串数组，Composer 不做任何语法检查，但 Packagist 会用它加权搜索结果。填错等于主动把自己埋进冷门区。
- 选 3–5 个真实用户可能搜的词，比如 HTTP client 场景下填
["http", "curl", "psr-7", "guzzle", "async"] - 不要填泛词：
["php", "library", "tool"]没有任何区分度 - 不要重复
name或vendor名，acme/http-client再写"acme"或"http-client"是冗余 - 含空格或符号的词（如
"psr-7"）必须带双引号，否则 JSON 解析失败
type 字段填错会让项目无法被正确归类
type 决定 Packagist 上的分类标签，也影响某些工具链行为。填错会导致发布失败或 CI 构建异常。
- 常见合法值：
"library"（默认）、"project"（完整应用）、"metapackage"（仅依赖）、"wordpress-plugin"、"composer-plugin" - 如果是 Laravel 包但没注册 Service Provider，别硬写
"laravel-package"——Packagist 不认这个 type，且部分 Laravel 工具链会跳过处理 - 私有项目或本地开发不发包，也建议填
"project"，避免将来迁移时被误判为库而触发自动加载规则
最容易被忽略的其实是 name 和 autoload 的耦合关系——它不报错，但一运行就 Class not found，排查时往往先怀疑路径、命名空间、文件名，最后才发现是 name 里一个短横线写成了下划线。
