**参考文献（存档）：** [SCAFFOLD_SKILLS_ARCHIVE_MAP.md]() — Auto-Claude-develop 的 ProjectAnalyzer monorepo/service 检测分析/分析器。 ### 第 1 步：确定项目根通过查找清单文件找到项目根目录： 1. **搜索包管理器文件**： * `package.json` (Node.js/JavaScript/TypeScript) * `requirements.txt`、`pyproject.toml`、`setup.py` (Python) * `go.mod`（围棋） * `Cargo.toml` (Rust) * `pom.xml`、`build.gradle` (Java/Maven/Gradle) * `composer.json` (PHP) 2. **识别项目根**： * 包含主包管理器文件的目录 * 处理 monorepos（多个 package.json 文件） * 检测工作区配置 3. **验证项目根**： * 检查`.git`目录 * 验证源代码目录是否存在 * 确保清单文件是可解析的 ### 第 2 步：检测项目类型根据清单文件和目录结构对项目进行分类： 1. **前端项目**： * 指标：React、Vue、Angular、Svelte 依赖项 * 目录: `src/components/`, `public/`, `assets/` * 框架：Next.js、Nuxt.js、Gatsby、Vite 2. **后端项目**： * 指标：Express、FastAPI、Django、Flask、Gin 依赖项 * 目录：`routes/`、`controllers/`、`models/`、`api/` * 框架：Next.js API 路由、FastAPI、Express 3. **全栈项目**： * 指标：前端和后端框架 * 目录：前端+后端组合结构 * 框架：Next.js、Remix、SvelteKit、Nuxt.js 4. **库/包项目**： * 指标：无特定于应用程序的目录 * 文件：`index.ts`、`lib/`、`dist/`、`build/` * 清单：package.json 中的 `library` 字段 5. **CLI 项目**： * 指标：package.json中的`bin`字段 * 文件：CLI 入口点、命令解析器 * 依赖项：指挥官、亚格斯、询问者 6. **移动项目**： * 指标：React Native、Flutter、Ionic 依赖 * 文件：`android/`、`ios/`、`mobile/` * 框架：React Native、Expo、Flutter 7. **Monorepo 项目**： * 指标：package.json 中的“workspaces”、“pnpm-workspace.yaml” * 结构：子目录中的多个包 * 工具：Turborepo、Nx、Lerna 8. **微服务项目**： * 指标：多个服务目录 * 文件：`docker-compose.yml`，服务配置 * 结构：服务型组织 ### 步骤 3：框架检测从清单文件和导入中识别框架： 1. **读取package.json依赖关系**（Node.js）： * 解析`dependency`和`devDependency` * 检测框架版本 * 按类型分类（框架、ui 库、测试等） 2. **阅读requirements.txt**（Python）： * 解析Python依赖关系 * 检测FastAPI、Django、Flask * 确定版本限制 3. **分析导入**（可选深度扫描）： * 扫描源文件中的导入语句 * 检测使用与声明的依赖关系 * 识别特定于框架的模式 4. **框架类别**： * **框架**：React、Next.js、FastAPI、Express * **UI 库** ：Material-UI、Ant Design、Chakra UI * **状态管理**：Redux、Zustand、Pinia * **测试**：Jest、Vitest、Cypress、Playwright * **构建工具** : Vite、Webpack、Rollup、esbuild * **数据库**：Prisma、TypeORM、SQLAlchemy * **ORM** ：Prisma、Sequelize、Mongoose * **API**：tRPC、GraphQL、REST * **Auth** ：NextAuth、Auth0、职员 * **记录**：温斯顿、皮诺、班扬 * **监控**：Sentry、Datadog、New Relic 5. **置信度评分** : * **1.0** ：依赖项中列出的框架 * **0.8** ：从导入中检测到的框架 * **0.6** ：从结构推断出的框架 ### 步骤 4：文件统计生成定量项目统计数据： 1. **按类型统计文件** : * 对通用扩展使用 glob 模式 * 排除：`node_modules/`、`.git/`、`dist/`、`build/` * 按语言/文件类型分组 2. **计算代码行数** : * 读取源文件并计算行数 * 排除空行和注释（可选） * 计算每种语言的总 LOC 3. **识别最大的文件**： * 跟踪文件大小（行数） * 报告前 10 个最大文件 * 标志文件>1000行（违反微服务原则） 4. **计算平均值**： * 平均文件大小（行） * 平均目录深度 * 每个目录的文件 5. **语言检测** : * 将扩展映射到语言： * `.ts`、`.tsx` → TypeScript * `.js`, `.jsx` → JavaScript * `.py` → Python * `.go` → 去 * `.rs` → Rust * `.java` → Java * `.md` → Markdown * `.json` → JSON * `.yaml`, `.yml` → YAML ### 步骤 5：结构分析分析项目结构和架构： 1. **识别根目录** : * 按用途对目录进行分类： * **来源** : `src/`, `app/`, `lib/` * **测试** : `test/`, `__tests__/`, `cypress/` * **配置** : `config/`, `.config/` * **文档** : `文档/`, `文档/` * **构建** : `dist/`, `build/`, `out/` * **脚本** : `scripts/`, `bin/` * **资产** : `资产/`、`静态/`、`公共/` 2. **检测入口点** : * 主条目：`index.ts`、`main.py`、`app.py` * 应用入口：`app.ts`、`server.ts`、`app/page.tsx` * 处理程序：`handler.ts`、`lambda.ts` * CLI: `cli.ts`, `bin/` 3. **检测架构模式**： * **MVC** ：`模型/`、`视图/`、`控制器/` * **分层** ：`演示/`、`业务/`、`数据/` * **六角形**：`域/`、`应用程序/`、`基础设施/` * **微服务** : 多个服务目录 * **模块化**：基于功能的组织 * **Flat** : src/ 中的所有文件 4. **检测模块系统** : * 检查 `package.json` 中的 `"type": "module"` (ESM) * 扫描 `import`/`export` (ESM) 与 `require` (CommonJS) * 识别混合模块系统 ### 第 6 步：依赖性分析分析依赖性健康状况： 1. **计算依赖关系** : * 生产依赖 * 开发依赖 * 总依赖计数 2. **检查是否有过期的软件包**（可选）： * 运行 `npm outdated` 或同等版本 * 解析过时包的输出 * 识别主要版本更新（重大更改） 3. **安全扫描**（可选）： * 运行“npmaudit”或等效命令 * 按严重程度识别漏洞 * 标记关键安全问题 ### 步骤 7：代码质量指标检测代码质量工具： 1. **检查配置**： * 检测：`.eslintrc.json`、`eslint.config.js`、`ruff.toml` * 工具：ESLint、Ruff、Flake8、Pylint * 如果配置则运行linter（可选） 2. **格式化配置**： * 检测：`.prettierrc`、`pyproject.toml`（黑色/拉夫） * 工具：Prettier、黑色、Ruff 3. **测试框架**： * 检测：Jest、Vitest、Pytest、Cypress * 统计测试文件数量 * 检查覆盖配置 4. **类型安全**： * 检测 TypeScript：`tsconfig.json` * 检查严格模式: `"strict": true` * 检测 Python 类型：mypy、pyright ### 步骤 8：模式检测识别常见模式和反模式： 1. **良好实践**： * 模块化组件结构 * 全面的测试覆盖率 * 启用 TypeScript 严格模式 * 存在 CI/CD 配置 2. **反模式**： * 大文件（> 1000 行） * 缺少测试 * 过时的依赖项 * 无 linting 配置 3. **中性模式**： * 具体架构选择 * 特定于框架的模式 ### 步骤 9：技术债务分析计算技术债务分数： 1. **债务指标**： * **过时的依赖项** : 统计过时的包 * **缺少测试**：测试文件比率低 * **死代码**：未使用的导入/导出（可选） * **复杂性**：大文件，深度嵌套 * **文档**：缺少自述文件、文档 * **安全**：已知漏洞 * **性能**：捆绑包大小、加载时间 2. **债务评分**（0-100）： * 0-20：健康状况良好 * 21-40：身体健康，有小问题 * 41-60：债务中等，需要关注 * 61-80：高负债，建议重构 * 81-100：严重债务，需要重大改革 3. **补救措施**： * **琐碎**：< 1 小时 * **次要**：1-4 小时 * **中等**：1-3 天 * **专业**：1-2周 * **大规模** ：> 2 周 ### 第 10 步：生成建议创建优先改进建议： 1. **对建议进行分类**： * **安全**：严重漏洞、过时的身份验证 * **性能** ：捆绑优化、延迟加载 * **可维护性** ：重构大文件，添加测试 * **测试** ：增加覆盖范围，添加E2E测试 * **文档** : 添加自述文件、API 文档 * **架构**：提高模块化、关注点分离 * **依赖项** ：更新包，删除未使用的包 2. **按影响确定优先级**： * **P0** ：关键安全性，阻止生产 * **P1** ：高冲击力，影响可靠性 * **P2** ：中等影响，提高质量 * **P3** ：低影响，值得拥有 3. **估计工作量和影响**： * 努力：微不足道、次要、中等、主要、大量 * 影响：低、中、高、严重 ### 步骤 11：验证输出根据模式验证分析输出： 1. **架构验证**： * 针对“project-analysis.schema.json”进行验证 * 确保所有必填字段都存在 * 检查数据类型和格式 2. **输出元数据** : * 分析仪版本 * 分析持续时间（毫秒） * 分析的文件数 * 文件跳过计数 * 遇到的错误 * **目标**：典型项目 < 30 秒（< 10k 文件） * **优化**： * 跳过大目录：`node_modules/`、`.git/`、`dist/` * 使用并行文件处理 * 缓存结果以供增量分析 * 限制对重要文件的深度扫描 * 对大文件数使用流式传输 **与其他技能的整合**： * **规则选择器** ：根据检测到的框架自动选择规则 * **repo-rag** ：架构模式的语义搜索 * **dependency-analyzer** ：深度依赖分析 <最佳实践> 1. **渐进式披露**：从清单分析开始，如果需要，添加深度扫描 2. **性能第一**：跳过大型项目的昂贵操作 3. **优雅地失败**：处理丢失的文件，解析错误 4. **验证输出**：始终根据模式进行验证 5. **缓存结果**：存储分析输出以供重用 6. **增量更新**：仅重新分析更改的文件 # 分析当前项目节点.claude/tools/analysis/project-analyzer/analyzer.mjs # 分析具体目录节点 .claude/tools/analysis/project-analyzer/analyzer.mjs /path/to/project # 输出到文件节点 .claude/tools/analysis/project-analyzer/analyzer.mjs --output .claude/context/artifacts/project-analysis.json **代理调用**： # 分析当前项目分析这个项目 # 生成综合分析执行完整的项目分析并保存到工件 # 快速分析（仅限清单）快速检测项目类型 **示例输出** (`.claude/context/artifacts/project-analysis.json`)： { “analysis_id”：“分析-llm-rules-20250115”， "project_type": "全栈", “analyzed_at”：“2025-01-15T10：30：00.000Z”， "project_root": "C:\\dev\\projects\\LLM-RULES", “统计”：{ “总文件数”：1243， “总行数”：125430， “语言”：{ “JavaScript”：45230， “打字稿”：38120， “降价”：25680， “JSON”：12400， “YAML”：4000 }, “文件类型”：{ “.js”：234， “.mjs”：156， “.ts”：89， “.md”：312， “.json”：145 }, “目录”：87， “平均文件大小行”：101， “最大的文件”：[ { “路径”：“.claude/tools/enforcement-gate.mjs”， “行”：1520 } ] }, “框架”：[ { “名称”：“nextjs”， “版本”：“14.0.0”， “类别”：“框架”， “置信度”：1.0， “来源”：“package.json” }, { “名称”：“反应”， “版本”：“18.2.0”， “类别”：“框架”， “置信度”：1.0， “来源”：“package.json” } ], “结构”：{ “根目录”：[ { "名字": ".克劳德", “目的”：“配置”， “文件计数”：543 }, { "name": "指挥-主", “目的”：“来源”， “文件计数”：234 } ], “入口点”：[ { “路径”：“conductor-main/src/index.ts”， “类型”：“主要” } ], "architecture_pattern": "模块化", “模块系统”：“esm” }, “依赖项”：{ “生产”：45， “发展”：23 }, “代码质量”：{ “棉绒”：{ “配置”：正确， “工具”：“eslint” }, “格式化”：{ “配置”：正确， “工具”：“更漂亮” }, “测试”：{ “框架”：“维斯特”， “测试文件”：89， “coverage_configured”：true }, “类型安全”：{ “打字稿”：正确， “严格模式”：真 } }, “技术债务”：{ “分数”：35， “指标”：[ { “类别”：“复杂性”， “严重性”：“中”， "description": "3个文件超过1000行", "remediation_effort": "中等" } ] }, “建议”：[ { “优先级”：“P1”， "category": "可维护性", "title": "重构大文件", "description": "将超过 1000 行的文件分解为更小的模块", “努力”：“适度”， “影响”：“高” } ], “元数据”：{ “analyzer_version”：“1.0.0”， “分析持续时间毫秒”：2340， “文件分析”：1243， “文件跳过”：3420， “错误”：[] } } ## 参考文献有关从 Auto-Claude 分析框架中提取的其他检测模式，请参阅： * `references/auto-claude-patterns.md` \- Monorepo 指标、SERVICE_INDICATORS、SERVICE_ROOT_FILES、基础设施检测、约定检测 * `references/service-patterns.md` \- 服务类型检测（前端、后端、库）、特定于框架的模式、入口点检测 * `references/database-patterns.md` \- 数据库配置文件模式、ORM 检测（Prisma、SQLAlchemy、TypeORM、Drizzle、Mongoose）、连接字符串模式 * `references/route-patterns.md` \- Express、FastAPI、Flask、Django、Next.js、Go、Rust API 路由检测模式这些参考文献为棕地代码库分析提供了全面的正则表达式模式和检测逻辑。 ## 内存协议（强制） **开始之前：**阅读 `.claude/context/memory/learnings.md` **完成后：** * 新模式 -> `.claude/context/memory/learnings.md` * 发现问题 -> `.claude/context/memory/issues.md` * 做出决定 -> `.claude/context/memory/decisions.md` > 假设中断：如果它不在内存中，则它没有发生。

项目分析器

包含技能