用途：在 WordPress 代码库中处理 PHPStan 静态分析，包括设置或更新 phpstan.neon / phpstan.neon.dist、生成或更新 phpstan-baseline.neon、通过兼容 WordPress 的 PHPDoc 修复 PHPStan 报错（REST 请求、钩子、查询结果），以及安全地处理第三方插件/主题类。
使用前提：需先获得 wp-project-triage 输出；需确认是否允许新增或更新 Composer 开发依赖（stubs）；需确认本任务是否允许改动基线文件。
主要流程：先运行 node skills/wp-phpstan/scripts/phpstan_inspect.mjs 检查 PHPStan 配置、基线与脚本，若仓库已有 composer 脚本（如 composer run phpstan）则优先使用。其次确保加载 WordPress 核心 stubs，szepeviktor/phpstan-wordpress 或 php-stubs/wordpress-stubs 对多数插件/主题仓库几乎是必需的，否则会出现大量未知核心函数的报错。然后保持 paths 聚焦第一方代码，排除 vendor/、node_modules/、构建产物等，ignoreErrors 条目应尽量窄并附说明。修复时优先修正类型而非忽略错误：REST 端点用 WP_REST_Request<...> 标注请求参数，为钩子回调补充准确的 @param 类型，数据库结果与可迭代对象使用 array/object shape，Action Scheduler 回调为 $args 添加数组形状类型。
第三方处理：仅在确认真实依赖后，优先使用仓库已有的插件专用 stubs（如 php-stubs/woocommerce-stubs、php-stubs/acf-pro-stubs）；仍无法解析类时，再为特定 vendor 前缀添加定向 ignoreErrors。
基线与验证：基线仅作为遗留代码的迁移工具，生成一次后逐步减少，不要把新引入的错误加入基线。用发现的命令运行 PHPStan，确认基线已包含且未意外增长，改动 ignoreErrors 后需重跑验证未掩盖无关问题。
常见问题：出现“Class not found”先确认自动加载与 stubs，或添加窄范围忽略；报错量过大可缩减 paths、添加 excludePaths、先降低级别再逐步提升；钩子/REST 参数类型不一致时补充显式 PHPDoc。若类型依赖无法确认的第三方插件 API，应先询问依赖版本或来源，不要臆造类型；新增 Composer 依赖前需先获得用户确认。