@ranger1/dx 0.1.105 → 0.1.106

package/skills/e2e-audit-fixer/SKILL.md

@@ -1,76 +0,0 @@
----
-name: e2e-audit-fixer
-description: 对 backend 的 E2E 用例进行中文名称、通用 fixture 重复实现与测试请求构建规范检查，并按可配置路径输出修复建议与可选自动修复。适用于需要审计或修复 E2E 测试中的中文用例名、手工请求构造、手工 JWT、以及本应复用通用测试基建的重复实现。
----
-
-# E2E 测试可维护性检查与修复
-
-## 触发场景
-
-- 需要检查 `apps/backend/e2e/**/*.e2e-spec.ts` 的 E2E 用例是否符合英文命名规范。
-- 需要识别直接操作 Prisma、手工 JWT、手工 API URL、手工请求实现，并区分哪些适合改用全局通用 fixture，哪些更适合抽成本地 helper。
-- 需要一次性生成问题清单并按规则应用可控修复。
-
-## 准备
-
-执行前确认项目有可读权限，并准备以下路径参数（全部可覆盖，避免硬编码）：
-
-1. `--workspace`：代码根目录，默认当前目录。
-2. `--e2e-glob`：扫描文件模式，默认 `apps/backend/e2e/**/*.e2e-spec.ts`。
-3. `--fixtures`：fixtures 文件路径，默认 `${workspace}/apps/backend/e2e/fixtures/fixtures.ts`。
-
-## 执行流程
-
-1. 先扫描问题：
-
-```bash
-CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
-python "$CODEX_HOME/skills/e2e-audit-fixer/scripts/e2e_e2e_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo
-```
-
-2. 生成输出 JSON 用于复核：
-
-```bash
-python "$CODEX_HOME/skills/e2e-audit-fixer/scripts/e2e_e2e_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo \
-  --output-json /tmp/e2e-audit.json
-```
-
-3. 按修复策略应用：
-
-   1. 中文测试名：先翻译为英文。可直接提供翻译映射：
-
-   ```bash
-   python "$CODEX_HOME/skills/e2e-audit-fixer/scripts/e2e_e2e_audit.py" \
-     --workspace /Users/a1/work/ai-monorepo \
-     --translation-map /tmp/name-map.json \
-     --apply
-   ```
-
-   2. fixture 重复实现：自动加注释提示并给出替换建议，保留原有逻辑不变。仅 `user` / `userCredential` 作为全局通用 fixture 候选，其余默认建议抽成本地 helper。
-
-4. 必要时清理：对比扫描结果再次运行，确保无回归。
-
-## 检查规则（脚本输出）
-
-- `e2e-chinese`：`describe/it/test/context` 名称包含中文字符。
-- `e2e-fixtures`：检测 `prisma.user.*`、`prisma.userCredential.*`、`jwtService.sign/jwt.sign`、未使用 `buildApiUrl()` 的 API URL 片段、未使用 `createAuthRequest/createAdminAuthRequest/createPublicRequest` 的手工请求调用。
-- `e2e-local-helper`：检测其他 `prisma.*.create*` / `upsert` 类重复实现，默认只建议在当前测试文件内抽成本地 helper，不建议直接上收为全局 fixtures。
-
-## 可选翻译入口
-
-支持三种方式之一：
-
-1. `--translation-map`：JSON 映射文件 `{ "中文原文": "English text" }`（推荐，稳定、可审计）。
-2. `--translate-service openai`：提供 `OPENAI_API_KEY` 后自动调用 OpenAI 批量翻译。
-3. 不提供翻译参数：仅输出中文字符串与建议，不改写文件。
-
-## 注意
-
-- 扫描不改变业务逻辑，只做问题检测与可控注释插入。
-- 自动修复默认只对中文测试名称做真实替换。
-- `user` / `userCredential` 以外的重复造数默认视为“本地 helper 候选”，不默认建议进入全局 fixtures。
-- fixture 与请求构造类问题仅插入 TODO 注释，不宣称已完成重构。
-- 翻译服务仅处理测试名称，不处理其他文本。
-- 扫描路径来源全部来自参数，不会固定死为 `apps/backend/e2e/**/*.e2e-spec.ts`。

package/skills/e2e-audit-fixer/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "E2E Audit Fixer"
-  short_description: "扫描 E2E 测试中文名称、手工请求与重复实现，并输出可控修复建议"
-  default_prompt: "使用 $e2e-audit-fixer 对 E2E 测试进行 e2e-chinese 与 e2e-fixtures 检查，并按修复建议输出可执行改动。"

package/skills/env-accessor-audit-fixer/SKILL.md

@@ -1,149 +0,0 @@
----
-name: env-accessor-audit-fixer
-description: Use when backend、NestJS、配置模块、E2E 测试或脚本中需要审计或修复 `process.env` 直读，判断项目是否已具备统一环境访问基础设施，并在缺少 EnvAccessor、EnvService、EnvModule 或统一配置接入时补齐最小可用实现。
----
-
-# 环境变量访问审计与修复
-
-## 概览
-
-先扫描 `process.env` 直读点，再判断仓库是否已有统一 env 访问基础设施。
-
-- 若已有 `EnvService`、`createEnvAccessor`、`defaultEnvAccessor` 或等价封装，优先复用现有方案并逐项迁移。
-- 若缺少统一入口，先补齐最小基础设施，再收口剩余直读点。
-
-## 快速开始
-
-先运行扫描脚本：
-
-```bash
-CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
-python "$CODEX_HOME/skills/env-accessor-audit-fixer/scripts/env_accessor_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo
-```
-
-需要结构化结果时输出 JSON：
-
-```bash
-python "$CODEX_HOME/skills/env-accessor-audit-fixer/scripts/env_accessor_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo \
-  --output-json /tmp/env-accessor-audit.json
-```
-
-若脚本显示尚未形成统一 env 入口，再读取 [references/bootstrap-env-foundation.md](./references/bootstrap-env-foundation.md)。
-
-## 执行流程
-
-1. 扫描 `apps/backend/src` 与 `apps/backend/e2e` 中的 `process.env`。
-2. 仅排除真正的基础封装文件：
-   - `env.accessor.ts`
-   - `env.service.ts`
-3. 不排除 `apps/backend/src/config/**/*.ts`，确保 `registerAs` 配置层也纳入审计。
-4. 优先识别当前基础设施状态：
-   - 是否存在 `createEnvAccessor`
-   - 是否存在 `defaultEnvAccessor`
-   - 是否存在 `EnvService`
-   - 是否存在 `EnvModule`
-   - 是否已有 `registerAs` 或配置层通过统一 env 入口读取变量
-5. 按场景为每个直读点选择迁移方式，而不是机械替换。
-6. 修复后重新扫描，并补跑最小验证，确认配置读取与运行行为一致。
-
-## 快速复核命令
-
-项目具备 `rg` 时，优先用下列命令复核：
-
-```bash
-rg "process\\.env" apps/backend/src apps/backend/e2e \
-  --glob '!*env.accessor.ts' \
-  --glob '!*env.service.ts'
-```
-
-## 修复准则
-
-### 配置层与 `registerAs`
-
-- 优先使用 `defaultEnvAccessor`
-- 仅在必须显式传入环境对象时使用 `createEnvAccessor(process.env)`
-- 不要继续裸读 `process.env.FOO`
-
-```typescript
-import { registerAs } from '@nestjs/config'
-import { defaultEnvAccessor } from '@/common/env/env.accessor'
-
-const env = defaultEnvAccessor
-
-export const redisConfig = registerAs('redis', () => ({
-  host: env.str('REDIS_HOST', 'localhost'),
-}))
-```
-
-### 运行期服务、控制器、提供者
-
-- 注入 `EnvService`
-- 优先使用 `getString`、`getInt`、`getBoolean`、`isProd`、`isE2E` 等 typed getter
-- 若模块尚未暴露 `EnvModule`，先补模块依赖，再迁移读取逻辑
-
-```typescript
-@Injectable()
-export class ExampleService {
-  constructor(private readonly env: EnvService) {}
-
-  getRedisHost() {
-    return this.env.getString('REDIS_HOST', 'localhost')
-  }
-}
-```
-
-### 独立脚本与 CLI
-
-- 在完成 dotenv 装载后显式创建 accessor
-
-```typescript
-const env = createEnvAccessor(process.env)
-```
-
-### 必须读取原始值
-
-- 使用 `EnvService.getAccessor().raw(key)`，或 accessor 的 `raw(key)`
-- 在代码中简短说明为何 typed getter 不适用
-
-## 缺失基础设施时的补齐顺序
-
-若扫描结果显示项目尚未形成统一 env 访问方案，按以下顺序补齐：
-
-1. 创建 `env.accessor.ts`
-   - 提供 `createEnvAccessor`
-   - 提供 `defaultEnvAccessor`
-   - 至少支持 `str`、`bool`、`int`、`num`、`raw`、`appEnv`、`snapshot`
-2. 创建 `env.service.ts`
-   - 包装 `ConfigService`
-   - 提供 typed getter 与常用环境判断方法
-3. 创建 `env.module.ts`
-   - 暴露 `EnvService`
-4. 将配置层迁移到 `registerAs + defaultEnvAccessor`
-5. 将运行期服务迁移到 `EnvService`
-6. 重新扫描剩余 `process.env` 直读点
-
-优先复用现有命名、目录与模块结构；若无统一基础设施，再参考 [references/bootstrap-env-foundation.md](./references/bootstrap-env-foundation.md)。
-
-## 例外与判断原则
-
-- `env.accessor.ts`、`env.service.ts` 本身允许访问 `process.env`
-- 负责 dotenv 装载、环境注入、测试环境临时覆写的底层入口可保留少量受控访问
-- 测试里对 `process.env` 的显式设值可视为受控例外，但优先复用公共 fixture 或 helper
-- 若某文件同时负责“装载环境”和“消费环境”，优先拆分职责，避免例外扩大
-
-## 输出要求
-
-最终输出至少包含：
-
-1. 基础设施状态
-2. `process.env` 直读文件清单
-3. 每个问题的推荐迁移方式
-4. 是否需要补齐基础设施
-5. 已修改内容、验证结果与剩余风险
-
-## 资源
-
-- 扫描脚本：`scripts/env_accessor_audit.py`
-- 补齐模板：`references/bootstrap-env-foundation.md`

package/skills/env-accessor-audit-fixer/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "环境变量审计修复"
-  short_description: "审计并修复 process.env 直读，必要时补齐统一 env 访问基础设施"
-  default_prompt: "使用 $env-accessor-audit-fixer 扫描项目中的 process.env 直读，判断是否已具备统一 env 访问基础设施，并给出或实施修复方案。"
-
-policy:
-  allow_implicit_invocation: true

package/skills/error-handling-audit-fixer/SKILL.md

@@ -1,187 +0,0 @@
----
-name: error-handling-audit-fixer
-description: Use when backend、NestJS、领域异常治理或错误处理审查中，需要检查业务代码是否绕过 DomainException / ErrorCode 体系，区分生产代码与 E2E 测试中的异常写法，识别直接抛出 BadRequestException、HttpException、Error 或直接返回中文 DomainException，并在项目缺少统一异常基础设施时给出补齐路径。
----
-
-# 错误处理规范检查与修复建议
-
-## 概览
-
-先判断项目是否已经具备统一错误处理基础设施，再扫描业务代码是否绕过 `DomainException` / `ErrorCode` 体系。默认只输出审计结果和修复建议，不自动改代码；只有用户明确要求时才进入自动修复。
-
-## 扫描范围
-
-脚本不预设任何项目路径，需要通过 `--src-dir` / `--e2e-dir` 显式传入。执行前必须先完成项目探索（见下方步骤 0）。
-
-以下路径/后缀始终排除，不会产生误报：
-
-| 排除类别 | 路径/后缀 |
-|----------|-----------|
-| 单元测试 | `*.spec.ts`、`*.test.ts`、`*.e2e-spec.ts` |
-| 测试辅助 | `*.mock.ts`、`*.stub.ts`、`*.fixture.ts`、`fixtures/`、`test-utils/`、`testing/`、`__tests__/`、`__test__/` |
-| 基础设施 | `*/filters/`、`prisma/`、`scripts/` |
-| 异常定义 | `*.exception.ts` |
-| 入口文件 | `main.ts` |
-
-只有在用户**明确要求**评估测试债务时，才传 `--e2e-dir` + `--scope e2e` 扫描测试代码。
-
-## 快速开始
-
-### 步骤 0：项目探索（每个项目首次执行时必须完成）
-
-在调用脚本前，先探索项目结构，识别出后端生产代码和测试代码的实际路径。方法：
-
-1. 查看项目根目录结构（`ls` 或 Glob）
-2. 识别后端应用目录（可能是 `apps/backend/src`、`src`、`server/src` 等）
-3. 识别测试目录（可能是 `apps/backend/e2e`、`test`、`e2e`、`__tests__` 等）
-4. 如果是 monorepo，可能有多个后端服务，每个都需要单独传 `--src-dir`
-
-典型示例：
-
-| 项目类型 | 生产代码 | 测试代码 |
-|----------|----------|----------|
-| NestJS monorepo | `apps/backend/src` | `apps/backend/e2e` |
-| 单体 NestJS | `src` | `test` 或 `e2e` |
-| 多服务 monorepo | `apps/api/src`、`apps/worker/src` | `apps/api/e2e`、`apps/worker/e2e` |
-
-### 步骤 1：审计生产代码
-
-将探索到的路径传给脚本（`--src-dir` 可传多个）：
-
-```bash
-SKILL_HOME="${SKILL_HOME:-$HOME/.claude/skills}"
-python "$SKILL_HOME/error-handling-audit-fixer/scripts/error_handling_audit.py" \
-  --workspace "$PWD" \
-  --src-dir <探索到的生产代码路径>
-```
-
-示例（当前项目）：
-
-```bash
-python "$SKILL_HOME/error-handling-audit-fixer/scripts/error_handling_audit.py" \
-  --workspace "$PWD" \
-  --src-dir apps/backend/src
-```
-
-多服务示例：
-
-```bash
-python "$SKILL_HOME/error-handling-audit-fixer/scripts/error_handling_audit.py" \
-  --workspace "$PWD" \
-  --src-dir apps/api/src \
-  --src-dir apps/worker/src
-```
-
-### 步骤 2：（仅在用户明确要求时）审计测试代码
-
-```bash
-python "$SKILL_HOME/error-handling-audit-fixer/scripts/error_handling_audit.py" \
-  --workspace "$PWD" \
-  --e2e-dir <探索到的测试代码路径> \
-  --scope e2e \
-  --output-json /tmp/error-handling-audit.json
-```
-
-3. 当项目尚未具备 `DomainException` / `ErrorCode` / 领域异常目录等基础设施时，先阅读 [references/foundation-bootstrap.md](./references/foundation-bootstrap.md) 再决定是否补齐。
-
-4. 当项目基础设施齐全但出现违规抛错时，按 [references/error-handling-standard.md](./references/error-handling-standard.md) 给出替换建议；如用户明确要求，才实施自动修复。
-
-5. 当结果里 `e2e/raw-error` 数量很大时，不要直接把它和生产代码风险混在一起汇报；先给 `src` 结论，再决定是否单独治理 `e2e`。
-
-## 执行流程
-
-1. 默认只扫描 `apps/backend/src`（生产代码）。测试代码、E2E、prisma seed、脚本等非生产路径全部排除。只有在用户明确要求评估测试债务时，才传 `--scope e2e` 扫描测试代码。
-2. 先判断基础设施状态：
-   - 是否存在 `DomainException`
-   - 是否存在 `ErrorCode`
-   - 是否存在领域异常目录或模块异常类
-   - 是否存在全局异常过滤器或结构化错误输出链路
-3. 再识别四类问题：
-   - 直接实例化 Nest 标准异常，如 `BadRequestException`、`HttpException`
-   - `throw new Error(...)` 或 `Promise.reject(new Error(...))`
-   - 直接 `new DomainException(...)` 但 payload 中未显式带 `code`
-   - `DomainException` 直接返回中文 message
-4. 对每个命中项给出修复建议，优先级固定如下：
-   - 优先复用现有模块异常类
-   - 其次建议在模块 `exceptions/` 目录新增领域异常类
-   - 最后才允许直接使用 `DomainException`，且必须补齐 `code` 与 `args`
-5. 若基础设施缺失，不直接把全部命中项定性为“应立刻改业务代码”，而是先输出“需补齐基础设施”的诊断与最小落地路径。
-6. 只有在用户明确说“自动修复”“直接改”或等价表述时，才进入落代码阶段。
-7. 若脚本结果与实际代码不一致，必须抽样打开命中文件复核，不要把脚本结果当成绝对真相。
-
-## 审计命令（rg 快速复核）
-
-以下 rg 命令用于手工复核，将 `<SRC_DIR>` 替换为步骤 0 探索到的实际路径：
-
-```bash
-rg "new (BadRequestException|UnauthorizedException|ForbiddenException|NotFoundException|HttpException|InternalServerErrorException)\(" \
-  <SRC_DIR> \
-  --glob '!*spec.ts' --glob '!*test.ts' \
-  --glob '!*exception.ts' \
-  --glob '!*/filters/**' \
-  --glob '!*main.ts'
-```
-
-```bash
-rg "new Error\(" <SRC_DIR> --glob '!*spec.ts' --glob '!*test.ts'
-```
-
-```bash
-rg "new DomainException\([^)]*$" -A3 <SRC_DIR>
-```
-
-```bash
-rg "DomainException\([^)]*[\u4e00-\u9fa5]" <SRC_DIR> \
-  --glob '!*spec.ts' \
-  --glob '!*/common/exceptions/**'
-```
-
-## 修复准则
-
-### 1. 优先复用现有领域异常
-
-- 若模块 `exceptions/` 已有语义匹配的异常类，直接复用。
-- 不要把已可表达为领域异常的问题继续保留成裸 `BadRequestException('字符串')`。
-
-### 2. 缺少模块异常时新增领域异常类
-
-- 在模块 `exceptions/` 下新增异常类。
-- 异常类继承统一 `DomainException`。
-- 构造函数中显式指定 `ErrorCode`。
-- 把上下文放进 `args`，不要把业务文案直接写死到 message。
-- 为新增异常补最小单测。
-
-### 3. 临时直接使用 DomainException
-
-- 仅在尚未抽出专用异常类、但当前修复必须继续推进时使用。
-- payload 中必须显式包含 `code`。
-- `args` 中必须保留排障所需上下文。
-
-### 4. 基础设施缺失时的判断
-
-- 如果仓库里根本没有 `DomainException` 或 `ErrorCode`，优先建议补基础设施，不要直接发散式新增几十个本地异常实现。
-- 如果已有 `DomainException` 但没有统一 `ErrorCode`，先统一错误码来源，再扩展模块异常。
-- 如果已有异常类与错误码，但缺少结构化输出链路，优先补过滤器或输出映射，保证 `code`、`args`、`requestId` 可稳定透出。
-
-## 输出要求
-
-执行这个技能时，最终输出至少包含：
-
-1. 基础设施状态
-2. 命中文件清单
-3. 每个问题的类型、定位与建议替换方式
-4. 是否可复用现有领域异常
-5. 是否需要先补齐基础设施
-6. 若用户要求自动修复，列出拟修改文件、验证方式与剩余风险
-
-补充要求：
-
-7. 明确区分 `src` 与 `e2e` 命中数量，避免测试噪音淹没生产代码风险
-8. 标注哪些命中是脚本结果、哪些已经过源码抽样复核
-9. 若脚本疑似误报，要在结论里明确说明“脚本规则限制”而不是直接要求改代码
-
-## 资源
-
-- 扫描脚本：`scripts/error_handling_audit.py`
-- 规范参考：`references/error-handling-standard.md`
-- 基础设施补齐指南：`references/foundation-bootstrap.md`

package/skills/error-handling-audit-fixer/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "错误处理规范检查"
-  short_description: "按 src 与 e2e 分开审计后端异常是否绕过 DomainException 与 ErrorCode 体系"
-  default_prompt: "使用 $error-handling-audit-fixer 先审计 backend src，再按需审计 e2e，检查错误处理是否绕过 DomainException / ErrorCode 体系，并在基础设施缺失时给出补齐建议。"
-
-policy:
-  allow_implicit_invocation: true

package/skills/naming-audit-fixer/SKILL.md

@@ -1,149 +0,0 @@
----
-name: naming-audit-fixer
-description: 审计并修复任意 JS/TS 项目的文件和文件夹命名规范。由模型判断框架、源码目录和自定义约定，再调用脚本执行扫描。当用户提到"命名规范"、"文件命名检查"、"naming convention"、"rename files"、"文件名不规范"、"命名审计"，或讨论文件/文件夹命名最佳实践时触发。即使用户只是问"检查一下命名"也应触发。
----
-
-# 文件/文件夹命名规范审计与修复
-
-模型负责决策（判断框架、确定扫描范围、识别项目自定义约定），脚本负责执行（按规则遍历文件树、匹配违规、输出报告）。
-
-## 执行流程
-
-```
-模型分析项目 → 生成扫描配置 → 调用脚本 → 解读报告 → 展示给用户 → [用户确认] → 分批修复
-```
-
-### Step 1: 分析项目（模型完成）
-
-阅读以下文件来判断项目技术栈和目录结构：
-
-1. **`package.json`**（根目录和各 app 目录）— 识别依赖的框架
-2. **`pnpm-workspace.yaml`** 或 `package.json` 的 `workspaces` 字段 — 确定 monorepo 结构
-3. **`tsconfig.json`** — 确认源码目录（`rootDir`、`include`）
-4. **`CLAUDE.md` / `AGENTS.md`** — 识别项目自定义命名约定（优先级最高）
-5. **项目目录结构**（`ls` 快速浏览）— 确认实际源码位置
-
-根据分析结果，确定：
-- 每个 app 使用什么框架
-- 每个 app 的源码根目录
-- 是否有 Next.js app 目录（路由文件豁免需要）
-- 需要额外跳过的目录（如 `generated/`、`__generated__/`）
-- 需要额外豁免的文件（如项目特有的入口文件）
-
-### Step 2: 生成扫描配置并调用脚本
-
-构造 JSON 配置，通过 stdin 传给脚本：
-
-```bash
-echo '{
-  "scans": [
-    {
-      "root": "apps/backend/src",
-      "framework": "nestjs",
-      "extra_skip_dirs": [],
-      "extra_ok_files": []
-    },
-    {
-      "root": "apps/backend/e2e",
-      "framework": "nestjs",
-      "extra_skip_dirs": [],
-      "extra_ok_files": []
-    },
-    {
-      "root": "apps/front/src",
-      "framework": "nextjs-react",
-      "app_dir": "app",
-      "extra_skip_dirs": [],
-      "extra_ok_files": []
-    },
-    {
-      "root": "apps/admin/src",
-      "framework": "react",
-      "extra_skip_dirs": [],
-      "extra_ok_files": []
-    }
-  ]
-}' | python ~/.claude/skills/naming-audit-fixer/scripts/audit_naming.py
-```
-
-**配置字段说明：**
-
-| 字段 | 必填 | 说明 |
-|------|------|------|
-| `root` | 是 | 要扫描的目录（相对于项目根目录） |
-| `framework` | 是 | 命名规则集，见下方 |
-| `app_dir` | 否 | Next.js app 目录名（默认 `app`），仅 `nextjs-react` 需要 |
-| `extra_skip_dirs` | 否 | 额外要跳过的目录名 |
-| `extra_ok_files` | 否 | 额外要豁免的文件名 |
-
-**支持的 framework 值：**
-
-| 值 | 适用场景 | 核心规则 |
-|----|---------|---------|
-| `nestjs` | NestJS 后端 | `kebab-name.type.ts`，目录 kebab-case |
-| `nextjs-react` | Next.js + React | .tsx PascalCase，.ts kebab-case，路由文件豁免 |
-| `react` | React SPA / Vite | .tsx PascalCase，.ts kebab-case |
-| `vue` | Vue | .vue PascalCase 或 kebab-case，.ts kebab-case |
-| `angular` | Angular | `kebab-name.type.ts`，类似 NestJS |
-| `generic-ts` | 通用 TypeScript | 全 kebab-case |
-
-### Step 3: 解读并展示报告
-
-脚本输出 JSON，包含：
-- `total_violations` — 违规总数
-- `summary_by_rule` — 按规则分类的计数
-- `violations[]` — 每条违规（path / rule / current / suggested）
-- `fix_plan[]` — 可执行的 `git mv` 命令
-
-向用户展示：
-1. 按规则分类的汇总表
-2. 按目录分组的详细列表（当前名 → 建议名）
-3. 询问是否进入修复
-
-**不要在审计阶段自动改代码。**
-
-### Step 4: 修复（用户确认后）
-
-阅读 [references/fix-guide.md](./references/fix-guide.md) 获取详细步骤。要点：
-
-1. **目录优先** — 先 `git mv` 重命名目录
-2. **按模块分批** — 每次处理一个模块下的文件
-3. **同步引用** — 每次重命名后用 Grep 找所有 import/require 引用，用 Edit 更新
-4. **检查 barrel** — 更新 `index.ts` 的 re-export
-5. **增量验证** — 每个模块改完跑 lint + build
-6. **最终测试** — 全部完成后跑受影响的测试
-
-## 命名规则速查
-
-### NestJS
-
-| 正确 | 错误 | 原因 |
-|------|------|------|
-| `send-message.request.dto.ts` | `send.message.request.dto.ts` | name 部分用连字符 |
-| `ai-model/` | `ai.model/` | 目录用 kebab-case |
-| `message-not-found.exception.ts` | `message.not.found.exception.ts` | name 部分用连字符 |
-
-### Next.js + React
-
-| 文件类型 | 规范 | 示例 |
-|---------|------|------|
-| 组件 .tsx | PascalCase | `ChatPanel.tsx` |
-| 工具 .ts | kebab-case | `sort-mappings.ts` |
-| Hook .ts | camelCase | `useChat.ts` |
-| 路由文件 | 小写（豁免） | `page.tsx`, `layout.tsx` |
-| 目录 | kebab-case | `character/` |
-
-### Vue
-
-| 文件类型 | 规范 | 示例 |
-|---------|------|------|
-| 组件 .vue | PascalCase 或 kebab-case | `UserCard.vue` 或 `user-card.vue` |
-| 工具 .ts | kebab-case | `format-date.ts` |
-
-## 注意事项
-
-- **项目约定优先**：如果 CLAUDE.md / AGENTS.md 定义了自己的命名规范，以项目为准
-- 脚本结果可能有误报，展示前应抽查
-- 目录重命名影响大，建议单独 commit
-- 入口文件、声明文件、动态路由自动豁免
-- `node_modules/`、`dist/`、`migrations/` 等自动跳过

package/skills/pagination-dto-audit-fixer/SKILL.md

@@ -1,69 +0,0 @@
----
-name: pagination-dto-audit-fixer
-description: Use when backend 或 NestJS 接口涉及分页列表，需要检查或修复分页 Request DTO 未继承 BasePaginationRequestDto、分页 Response DTO 未继承 BasePaginationResponseDto、Controller/Service 手工拼装分页返回结构，或需要输出不符合统一分页规范的文件清单并按标准改造。
----
-
-# 分页 DTO 规范检查与修复
-
-## 概览
-
-对后端分页接口执行统一规范审计，先稳定识别非标准分页 DTO 和手工分页返回，再按统一基类完成改造。优先使用随技能提供的扫描脚本作为问题清单真值源，再根据结果实施代码修复。
-
-## 快速开始
-
-1. 先运行扫描脚本：
-
-```bash
-CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
-python "$CODEX_HOME/skills/pagination-dto-audit-fixer/scripts/pagination_dto_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo
-```
-
-2. 需要结构化结果时输出 JSON：
-
-```bash
-python "$CODEX_HOME/skills/pagination-dto-audit-fixer/scripts/pagination_dto_audit.py" \
-  --workspace /Users/a1/work/ai-monorepo \
-  --output-json /tmp/pagination-dto-audit.json
-```
-
-3. 根据扫描结果逐项修复，再重新运行扫描确认问题是否消失。
-
-## 执行流程
-
-1. 扫描 `apps/backend/src/**/*.ts`，必要时用 `--include-glob` 扩大范围。
-2. 优先识别三类问题：
-   - 请求 DTO 自己声明 `page/limit/pageSize/currentPage`，但未继承 `BasePaginationRequestDto`
-   - 响应 DTO 命中 `items/data/total/page/limit/pageSize/currentPage` 等分页字段，但未继承 `BasePaginationResponseDto`
-   - Controller / Service / UseCase 直接 `return { ... }` 手工拼装分页结构
-3. 输出问题清单后，再阅读 [references/pagination-standard.md](./references/pagination-standard.md) 对照修复。
-4. 修复时保持接口兼容性；若历史字段名不是标准字段，显式说明保留策略或转换策略。
-5. 修复完成后重新扫描，并按项目常规命令补跑测试或最小验证。
-
-## 修复准则
-
-- 请求 DTO：改为继承 `BasePaginationRequestDto`，仅保留额外查询参数。
-- 响应 DTO：优先改为 `extends BasePaginationResponseDto<ItemResponseDto>`，或改用工厂 `createPaginationResponseDto(ItemResponseDto)`。
-- 返回构造：优先返回统一分页 DTO 实例，不继续在 Controller 中拼 `{ items, total, page, limit }`。
-- OpenAPI：补齐 `@ApiProperty`，确保 `items` 的元素类型明确。
-- 兼容处理：若线上消费者依赖 `data/currentPage/pageSize`，在过渡期显式映射，不要静默删字段。
-
-## 判断原则
-
-- 同时出现 `total` 且出现 `items` 或 `data`，再叠加 `page/limit/pageSize/currentPage` 中任一字段，可视为强分页信号。
-- 若类名或返回变量名包含 `Pagination`、`Paginated`、`ListResponse`、`PageResult`，优先人工复核。
-- 若只是普通列表返回且没有总数或页码字段，不归入本技能。
-
-## 输出要求
-
-执行这个技能时，最终输出至少包含：
-
-1. 问题文件清单
-2. 每个问题的类型与定位
-3. 建议修复方式
-4. 已应用的修改与剩余风险
-
-## 资源
-
-- 扫描脚本：`scripts/pagination_dto_audit.py`
-- 参考规范：`references/pagination-standard.md`

package/skills/pagination-dto-audit-fixer/agents/openai.yaml

@@ -1,7 +0,0 @@
-interface:
-  display_name: "分页 DTO 检查修复"
-  short_description: "检查并修复后端分页 DTO 是否符合统一分页基类规范"
-  default_prompt: "使用 $pagination-dto-audit-fixer 检查 backend 中分页 DTO 和分页返回结构是否符合统一规范，并给出可执行修复建议。"
-
-policy:
-  allow_implicit_invocation: true