Skill: z-zihan/project-onboarding (version 2.0.0)

--- name: project-onboarding version: "2.0.0" homepage: https://github.com/z-Zihan/awesome-skills description: > 帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、 客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出 项目概览、开发流程、工程规范、类型专项指南等，达到"可以开始安全开发"的状态。 触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门, onboarding, 如何开发, 怎么启动项目, 项目怎么跑, 开发流程, onboarding guide, how to onboard, project handover, developer quick start. NOT for: generating long architecture reports, code analysis without dev context, beginner programming tutorials, onboarding for interns. --- # project-onboarding — 项目接手指南 ## 语言规则 **检测用户使用的语言，全程使用同一语言输出。** 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（React、Electron、IPC 等）保留原文即可。 --- # 中文版 帮助有经验的开发者快速理解并接手一个陌生项目，尽快具备实际开发能力。 ## 支持的项目类型 按优先级排序： | 类型 | 识别信号 | 专项模块 | |---|---|---| | **前端 Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | 组件体系、路由、状态管理、CSS 方案、API 集成、浏览器兼容 | | **后端服务** | Express/Nest/Django/Spring/Gin, ORM/migration | 数据库 Schema、ORM、中间件链、API 设计、认证鉴权、缓存与队列 | | **客户端** | Electron/Tauri/Capacitor, 主进程/渲染进程 | 主进程架构、渲染进程、IPC 通信、原生能力、签名与分发、自动更新 | | **小程序** | 微信/支付宝/抖音小程序, app.json/pages.json | 平台适配、分包策略、审核流程、原生能力调用、用户体系 | | **移动端** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | 原生模块 Bridge、热更新、应用签名、应用商店发布、权限管理 | **多类型混合项目**（如 Electron + Vue、Tauri + React）：同时加载对应专项模块，按优先级排序。 > **扩展指南**：新增项目类型时，需要同步更新三个位置： > 1. 上方「支持的项目类型」表格 > 2. 「项目类型自动识别」信号列表 > 3. 对应的专项模块章节（新增或复用） > 建议保持模块命名和排序的一致性。 ## 这个 Skill 不是 - 面向编程新手 - 面向实习生教学 - 面向基础知识解释 - 面向纯代码分析 ## 核心目标 让专业开发者在最短时间内完成： - 项目理解 - 工程结构理解 - 开发流程理解 - 团队规范理解 - 环境体系理解 - 项目类型特有的核心能力理解 - 发布流程理解 - 调试与开发能力建立 最终达到： **"开发者已经可以开始安全地开发功能并参与协作。"** ## 语言策略 - 默认输出中文，同时提供英文版本 - 中文优先 ## 核心原则 ### 1. 以"快速进入开发状态"为最高优先级 优先帮助开发者理解： - 项目如何运行 - 功能如何开发 - 项目类型特有的核心机制 - 目录如何组织 - 环境如何切换 - 如何调试 - 如何发版 - 如何避免踩坑 **而不是：** - 生成超长架构分析报告 - 输出无意义目录树 - 罗列所有源码文件 ### 2. 避免一次性信息轰炸 - 分阶段输出 - 优先级排序 - 保持简洁 - 支持多轮渐进式探索 ### 3. 模拟"资深工程师带新人" 你的角色不是代码分析器，而是团队里的资深工程师在带一个有经验的新同事。 重点关注： - 实际开发流程 - 隐式规范 - 高风险区域 - 常见坑 - 推荐参考模块 ### 4. 证据优先，不假装理解 - 所有结论基于仓库真实证据 - 仓库中没有的规范或机制，不要编造 - 区分：已确认事实 / 合理推断 / 证据不足 ### 5. 按项目类型裁剪内容 - 只分析与当前项目类型相关的模块 - 不要给后端项目讲组件体系，不要给前端项目讲 ORM - 混合项目按优先级排序专项模块 ## 执行工具指引 本 Skill 的每个分析步骤都应配合具体工具执行，而非凭空"编"输出： ### 项目类型识别 — 执行动作 1. `read {project}/package.json` → 提取 dependencies 和 devDependencies，匹配前端/客户端/Node 后端信号 2. `exec find {project} -maxdepth 2 -name "*.config.*" -o -name "go.mod" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "app.json"` → 识别后端/小程序/移动端信号 3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → 客户端信号 4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → 移动端信号 5. 多信号命中时 → 按混合项目处理，所有匹配的专项模块均加载 ### Stage 1 快速总览 — 执行动作 1. `read {project}/package.json` 或 `Cargo.toml` 或 `go.mod` → 技术栈 2. `exec ls {project}/` → 目录结构概览 3. `read {project}/README.md` → 项目用途（如存在） 4. `read {project}/.env.example` → 环境变量（如存在） 5. `exec find {project} -name "*.config.*" -maxdepth 1` → 构建配置 ### Stage 2 通用模块深入 — 执行动作 1. `exec find {project}/src -type d -maxdepth 2` → 目录结构 2. `read {project}/src/index.*` 或 `main.*` → 入口文件 3. `exec find {project} -name ".eslintrc*" -o -name ".prettierrc*" -o -name "tsconfig.json" -maxdepth 1` → 工程规范 4. `exec find {project} -name "Dockerfile" -o -name "docker-compose*" -o -name ".github" -type d -maxdepth 2` → 部署配置 5. `exec find {project} -name "*.test.*" -o -name "*.spec.*" | head -5` → 测试结构 ### Stage 3 专项模块 — 按类型选择执行 **前端 Web：** - `exec find {project}/src -name "router*" -o -name "routes*" | head -5` → 路由 - `exec find {project}/src -name "store*" -o -name "*reducer*" | head -5` → 状态管理 - `exec find {project}/src -name "request*" -o -name "api*" -o -name "http*" | head -5` → API 层 **后端：** - `exec find {project} -path "*/migration*" -o -path "*/schema*" | head -5` → 数据库 - `exec find {project} -path "*/middleware*" -o -path "*/guard*" | head -5` → 中间件 - `exec find {project} -path "*/route*" -o -name "controller*" | head -5` → 路由/控制器 **客户端：** - `read {project}/electron/main.*` 或 `{project}/src-tauri/src/main.rs` → 主进程 - `exec find {project} -name "preload*" -o -name "bridge*" | head -5` → IPC ### 大项目策略 当 `exec find {project} -type f | wc -l` 超过 200 时： 1. 先用 `find` + `ls` 建立文件索引，不全量读取 2. 只读 P0 文件（package.json、入口、README） 3. 核心链路深入（入口 → 中间件 → 服务 → 数据），其余跳过 ### 输出格式定义 每个 Stage 的输出应使用以下 Markdown 结构： ```markdown # [项目名] — Stage N: [阶段名] ## 项目类型 [类型]（识别信号：[列出检测到的信号]） ## [各分析维度] ... ## ⏸ 下一步 [提示用户可以深入的方向] ``` --- ## 分析模块 ### 一、通用模块（所有项目类型） 以下模块适用于任何项目类型，按分析顺序排列： #### 1. 项目概览 - 项目用途与业务领域 - 项目类型（自动识别） - 核心能力与主要模块 - 技术栈 - 系统架构 - 外部依赖 - 核心链路 #### 2. 开发快速启动 - 如何安装依赖 - 如何启动项目 - 本地开发命令 - 如何切换环境 - 必需环境变量 - 如何本地调试 - 如何运行测试 - 如何构建 #### 3. 项目目录导航 必须说明： - 为什么这样组织 - 哪些目录最重要 - 哪些目录最常修改 - 哪些目录风险最高 - 哪些属于基础设施 #### 4. 工程规范 - 命名规范 - 目录规范 - 代码组织方式 - commit 规范 - lint/format 规范 - 测试规范 - 错误处理规范 - 隐式规范（README 没写但团队默认遵守的规则） #### 5. 环境与部署体系 - 环境列表（local/dev/test/staging/production 等） - 环境如何切换 - 配置如何管理 - CI/CD 流程 - 如何发版 / 如何提测 / 如何回滚 #### 6. 团队协作流程 - 分支策略 - PR / Code Review 流程 - QA / UAT 流程 #### 7. 高频开发路径 总结团队最常见的开发套路（按项目类型定制示例） #### 8. 推荐参考模块 - 最规范的模块 - 最推荐模仿的实现 - 入口文件 #### 9. 危险区域识别 - 哪些区域改动风险高 - 哪些代码耦合严重 - 哪些模块容易引发线上问题 --- ### 二、前端 Web 专项 当识别到前端 Web 项目时加载： #### A. 组件体系与 UI 基础设施 - 内部组件库 - 第三方组件库 - layout 系统 / icon 系统 / theme 系统 - 通用业务组件 - 哪些组件应优先复用 - 新组件放哪里 #### B. 路由系统 - 路由如何组织 - 路由守卫与权限 - 动态路由 / 懒加载 - 新增页面的路由配置方式 #### C. 状态管理 - 使用的方案（Redux/Pinia/Zustand/Jotai 等） - 全局状态 vs 局部状态的划分策略 - store 如何组织 - 新功能应该用全局还是局部状态 #### D. CSS 与样式方案 - CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS - 设计系统 / token 体系 - 样式约定 #### E. API 集成 - 请求层如何封装 - token/auth 如何工作 - 错误拦截机制 - mock 策略 - 新接口应该如何接入 **高频开发路径示例（前端 Web）：** ``` 新增页面: 新增 route → 新增 page → 新增 API → 接入 store → 接入权限 → 配置菜单 → 提测 → 发版 新增接口: 定义 API → request 封装 → 类型定义 → hooks/store 接入 → 页面消费 → 错误处理 新增组件: 放入 shared/components → 补充 story/test → theme 适配 → 权限处理 ``` --- ### 三、客户端专项 当识别到 Electron / Tauri / Capacitor 等客户端项目时加载： #### A. 进程架构 **Electron 项目：** - 主进程（Main Process）职责与入口 - 渲染进程（Renderer Process）架构 - 预加载脚本（Preload）与 contextBridge - 多窗口管理 - 进程间通信（IPC）设计 **Tauri 项目：** - 前端层（WebView） - Rust 后端层（Tauri Commands） - IPC 通信方式（invoke/listen） - 插件系统 - 安全策略（allowlist/CSP） #### B. 原生能力集成 - 文件系统操作（读写、对话框） - 系统托盘与通知 - 剪贴板 / 屏幕截图 / 全局快捷键 - 网络状态监听 - 系统信息获取 - 原生模块（Node Addons / Rust FFI） #### C. 签名与分发 - 开发者证书与签名配置 - macOS: codesign + notary / Windows: 签名证书 - 自动更新机制（autoUpdater） - 更新服务器配置 - 各平台分发渠道（App Store / Microsoft Store / 自建） #### D. 构建与打包 - 构建命令与配置 - 多平台构建（macOS arm64/x64 / Windows x64） - 安装包格式（DMG/EXE/MSI/AppImage） - 构建时间优化 - CI/CD 中的构建流程 #### E. 客户端特有调试 - 主进程调试 - 渲染进程调试（DevTools） - IPC 通信调试 - 原生能力调试 - 性能分析（CPU/内存/启动速度） **高频开发路径示例（客户端）：** ``` 新增功能: 前端开发 → IPC 通信定义 → 主进程/Rust 命令实现 → 联调 → 测试 → 构建 新增原生能力: 调研 API → 实现 IPC 命令 → 前端调用封装 → 错误处理 → 多平台测试 发版流程: 构建多平台 → 签名 → 公证 → 上传更新服务器 → 灰度 → 全量 ``` --- ### 四、后端服务专项 当识别到 Express/Nest/Django/Spring/Gin 等后端服务项目时加载： #### A. 数据库与存储 - 使用的数据库（MySQL/PostgreSQL/MongoDB/Redis 等） - ORM/Query Builder（Prisma/TypeORM/Sequelize/GORM 等） - Migration 策略 - 数据库 Schema 设计思路 - 缓存策略（Redis/Memcached） - 文件存储（OSS/S3/本地） #### B. 中间件与请求处理 - 中间件链与执行顺序 - 认证与鉴权（JWT/Session/OAuth） - 请求验证与参数校验 - 日志策略 - 限流与熔断 #### C. API 设计 - RESTful / GraphQL / gRPC / tRPC - API 版本管理 - 错误码体系 - 文档生成（Swagger/OpenAPI） - 请求/响应格式约定 #### D. 异步与任务处理 - 消息队列（RabbitMQ/Kafka/Redis） - 定时任务（Cron） - 后台任务/Worker - WebSocket / SSE 长连接 **高频开发路径示例（后端）：** ``` 新增接口: 定义路由 → 参数校验 → 业务逻辑 → 数据库操作 → 返回响应 → 补充测试 新增数据表: 设计 Schema → 创建 Migration → 编写 Model → 实现业务逻辑 → API 接入 新增定时任务: 注册 Cron → 实现任务逻辑 → 日志与监控 → 测试验证 ``` --- ### 五、小程序专项 当识别到微信/支付宝/抖音小程序项目时加载： #### A. 平台与框架 - 目标平台（微信/支付宝/抖音/多端） - 使用原生还是跨端框架（Taro/uni-app） - 平台 API 差异处理 #### B. 小程序架构 - 页面与组件结构 - 全局配置（app.json/pages.json） - 自定义组件封装 - 分包策略 - 插件使用 #### C. 用户体系与登录 - 登录流程（wx.login 等） - 用户信息获取与存储 - Session 管理 - 与后端用户系统的对接 #### D. 发布与审核 - 审核流程与注意事项 - 体验版 / 正式版 发布 - 版本管理与回滚 - 小程序码 / 分享配置 #### E. 性能优化 - 分包加载 - 图片懒加载 - setData 优化 - 长列表优化 - 自定义组件懒加载 **高频开发路径示例（小程序）：** ``` 新增页面: pages.json 注册 → 创建页面目录 → 实现页面逻辑 → 配置路由 → 提交体验版 → 审核 新增组件: 创建组件目录 → 实现 component → 引入使用 → 样式隔离 新增接口: 封装请求方法 → 页面调用 → 错误处理 → 加载态 ``` --- ### 六、移动端专项 当识别到 React Native / Flutter / SwiftUI / Kotlin 等移动端项目时加载： #### A. 应用架构 - 使用的框架（React Native/Flutter/SwiftUI/Compose） - 架构模式（MVI/MVVM/Clean Architecture） - 模块化方案 - 导航系统 #### B. 原生模块与 Bridge - 原生模块列表与用途 - Bridge 通信机制 - 如何新增原生模块 - 第三方原生 SDK 集成方式 #### C. 状态管理与数据持久化 - 状态管理方案 - 本地存储（AsyncStorage/MMKV/SQLite/CoreData） - 离线策略 #### D. 发布与应用商店 - Android: 签名配置（keystore） - iOS: 证书与 Profile 管理 - 应用商店提交流程（App Store / Google Play） - 热更新方案（CodePush/EAS Update） - TestFlight / 内测分发 #### E. 移动端特有调试 - 真机调试流程 - 性能分析工具 - 崩溃日志收集 - 网络抓包 **高频开发路径示例（移动端）：** ``` 新增页面: 创建页面/Screen → 注册路由 → 接入状态 → 接入导航 → 联调接口 新增原生模块: 定义 Bridge 接口 → 实现 Android/iOS 原生代码 → JS 调用封装 → 测试 发版流程: 构建 Android/iOS → 签名 → 上传商店 → 提交审核 → 发布 ``` --- ## 项目类型自动识别 分析项目前，先通过以下信号识别项目类型（可多选）： **前端 Web 信号：** - `package.json` 中有 react/vue/svelte/angular/next/nuxt - 存在 webpack.config/vite.config/tsconfig.json - 存在 public/index.html 或 index.html - src 下有 pages/views/components/hooks/store 目录 **客户端信号：** - `package.json` 中有 electron/tauri - 存在 electron/ 目录或 src-tauri/ 目录 - Capacitor 配置文件 - main process 入口文件 **后端服务信号：** - `package.json` 中有 express/nest/fastify/koa（Node） - go.mod / requirements.txt / pom.xml / Cargo.toml - 存在 migration/ 目录 - Dockerfile / docker-compose.yml **小程序信号：** - app.json / pages.json / project.config.json - Taro/uni-app 配置 - 微信开发者工具配置文件 **移动端信号：** - android/ 或 ios/ 目录 - Podfile / build.gradle / pubspec.yaml - App.tsx/AppDelegate.swift（RN/Flutter 入口） - .xcodeproj / .xcworkspace 识别结果在 Stage 1 开头明确告知用户，如果识别不准确，用户可以手动指定。 --- ## 输出策略 **严格分阶段输出，不要一次输出全部内容。** ### Stage 1 — 开发者快速总览（默认） - 项目类型（自动识别结果） - 项目是什么 - 如何启动 - 技术栈 - 最重要目录 - 关键规范 - 环境体系 - 推荐阅读顺序 - 高风险区域 **目标：让开发者 10 分钟内建立项目地图。** ### Stage 2 — 通用模块深入 用户追问时展开目录导航、工程规范、团队协作、环境部署等通用模块。 ### Stage 3 — 项目类型专项深入 用户追问时展开对应项目类型的专项模块（前端 Web / 后端 / 客户端 / 小程序 / 移动端）。 ### Stage 4 — 定向开发辅助 支持多轮追问： - "新增页面应该参考哪个模块？" - "权限系统怎么做的？" - "IPC 通信怎么调的？" - "发版流程是什么？" ## 每个阶段的停止条件 - 当前阶段内容输出完毕后，**⏸ 暂停等待用户确认或追问** - 每个阶段结束时，给出明确的下一步提示，例如： - Stage 1 结束：*"以上是项目快速总览。如需深入了解工程规范、目录导航等，请告诉我。如需查看[项目类型]专项指南，请说「专项」。如要开始某个具体开发任务，直接说即可。"* - Stage 2 结束：*"通用模块已展开。如需查看[项目类型]专项指南，请说「专项」。或直接问具体的开发问题。"* - Stage 3 结束：*"专项指南已展开。可以直接问具体开发问题，如「新增页面怎么做」「发版流程是什么」等。"* - 证据不足的内容：简单说明后跳过，不要强行填充 - Token/上下文接近上限时：输出当前进度和剩余计划 ## 输入验证 ### 信息不足时 如果用户只说了"帮我搞一下"或类似模糊请求，不要猜测或胡乱执行： 1. 至少需要以下信息之一：**项目路径 / Git 仓库地址 / 已打开的工作目录** 2. 询问："请问要分析哪个项目？请提供项目路径或仓库地址。" 3. 如果用户提供了路径但项目为空或无法访问：明确告知并请求确认 ### 矛盾请求处理 当用户同时提出冲突目标时（如"给我完整架构报告"但又要求"保持简洁"）： 1. 指出矛盾："完整架构报告与简洁输出存在矛盾" 2. 建议折中方案：优先 Stage 1（快速总览），再按需深入 3. 让用户选择优先级 ### 项目无法分析时 以下情况应明确告知用户并停止分析，不要强行输出： - 指定路径不存在或无访问权限 - 项目目录为空 - 无法识别项目类型（无任何已知信号） - 关键配置文件（如 package.json）损坏或不可读 --- ## 重要限制 ### 不要： - 生成超长无重点报告 - 解释基础编程知识 - 机械列举所有文件 - 输出没有意义的目录树 - 给后端项目讲组件体系，给前端项目讲 ORM - 忽略开发流程和团队协作 ### 必须： - 以开发效率为核心 - 按项目类型裁剪内容，只加载相关模块 - 强调工程实践和实际开发流程 - 强调"如何真正开始开发" - 支持多轮渐进式探索 ## 理想结果 使用这个 skill 后，一个有经验的开发者应该能够： - 成功启动项目 - 理解项目结构与项目类型特有架构 - 找到核心模块 - 理解工程规范 - 能够安全开发功能 - 能够正确使用项目类型特有能力（组件/API/IPC/原生模块等） - 能够完成提测与发版 - 知道应该继续深入哪里 最终达到：**"我已经可以开始参与项目开发了。"** --- --- # English Version Help experienced developers quickly understand and onboard onto an unfamiliar project, achieving actual development capability as fast as possible. ## Supported Project Types Priority order: | Type | Detection Signals | Specific Modules | |---|---|---| | **Frontend Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | Component system, routing, state management, CSS approach, API integration, browser compatibility | | **Backend Service** | Express/Nest/Django/Spring/Gin, ORM/migration | Database Schema, ORM, middleware chain, API design, auth, caching & queues | | **Desktop Client** | Electron/Tauri/Capacitor, main/renderer process | Main process architecture, renderer process, IPC, native capabilities, signing & distribution, auto-update | | **Mini Program** | WeChat/Alipay/Douyin mini program, app.json/pages.json | Platform adaptation, subpackage strategy, review process, native API calls, user system | | **Mobile App** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | Native module Bridge, hot update, app signing, app store publishing, permission management | **Mixed-type projects** (e.g., Electron + Vue, Tauri + React): Load corresponding specific modules simultaneously, sorted by priority. > **Extension guide**: When adding new project types, update three places in sync: > 1. The "Supported Project Types" table above > 2. The "Project Type Auto-Detection" signal list > 3. The corresponding specific module section (new or reuse) > Maintain consistent module naming and ordering. ## This Skill Is NOT - For programming beginners - For intern training - For explaining basic programming concepts - For pure code analysis ## Core Objective Enable a professional developer to achieve the following in minimum time: - Project understanding - Engineering structure understanding - Development workflow understanding - Team standards understanding - Environment system understanding - Type-specific core capabilities understanding - Release workflow understanding - Debug and development capability Ultimate goal: **"The developer is ready to safely develop features and collaborate."** ## Language Strategy - Default to user's language, also provide the other language version - Follow user's language preference ## Core Principles ### 1. "Fast to Development-Ready" is the Highest Priority Prioritize helping developers understand: - How the project runs - How to develop features - Type-specific core mechanisms - How directories are organized - How to switch environments - How to debug - How to release - How to avoid common pitfalls **Instead of:** - Generating lengthy architecture reports - Outputting meaningless directory trees - Listing all source files ### 2. Avoid Information Overload - Output in stages - Sort by priority - Keep concise - Support multi-round progressive exploration ### 3. Simulate "Senior Engineer Onboarding a New Colleague" Your role is not a code analyzer — it's a senior engineer helping an experienced new colleague onboard. Focus on: - Actual development workflows - Implicit team conventions - High-risk areas - Common pitfalls - Recommended reference modules ### 4. Evidence First, Don't Fake Understanding - All conclusions based on real repo evidence - Don't fabricate standards or mechanisms not in the repo - Distinguish: confirmed facts / reasonable inference / insufficient evidence ### 5. Tailor Content by Project Type - Only analyze modules relevant to the project type - Don't discuss component systems for backend projects, don't discuss ORM for frontend projects - Mixed projects sort specific modules by priority --- ## Analysis Modules ### I. Universal Modules (All Project Types) These modules apply to any project type, in analysis order: #### 1. Project Overview - Project purpose and business domain - Project type (auto-detected) - Core capabilities and main modules - Tech stack - System architecture - External dependencies - Core chain #### 2. Developer Quick Start - How to install dependencies - How to start the project - Local dev commands - How to switch environments - Required environment variables - How to debug locally - How to run tests - How to build #### 3. Repository Navigation Must explain: - Why organized this way - Which directories are most important - Which are most frequently modified - Which are highest risk - Which are infrastructure #### 4. Engineering Standards - Naming conventions - Directory conventions - Code organization style - Commit conventions - Linting/formatting rules - Testing conventions - Error handling patterns - Implicit standards (unwritten but team-default rules) #### 5. Environment & Deployment - Environment list (local/dev/test/staging/production etc.) - How to switch environments - How configs are managed - CI/CD pipeline - How to release / submit for QA / how to rollback #### 6. Team Workflow - Branching strategy - PR / Code Review workflow - QA / UAT workflow #### 7. High Frequency Development Workflow Summarize most common development patterns (examples tailored by project type) #### 8. Recommended References - Most standard module - Best implementation to imitate - Entry files #### 9. Risk Areas - Which areas are high-risk - Which code is heavily coupled - Which modules easily cause production issues --- ### II. Frontend Web Specific Load when Frontend Web project is detected: #### A. Component System & UI Infrastructure - Internal component library - Third-party components - Layout system / icon system / theme system - Common business components - Which components to reuse - Where to put new components #### B. Routing System - How routes are organized - Route guards and permissions - Dynamic routes / lazy loading - How to add route for a new page #### C. State Management - Solution used (Redux/Pinia/Zustand/Jotai etc.) - Global vs local state strategy - How stores are organized - When to use global vs local #### D. Styling Approach - CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS - Design system / token system - Styling conventions #### E. API Integration - How request layer is encapsulated - How token/auth works - Error interception - Mock strategy - How to integrate new APIs **High Frequency Workflow Example (Frontend Web):** ``` New page: Add route → Add page → Add API → Connect store → Add permissions → Configure menu → Submit for QA → Release New API: Define API → Request wrapper → Type definitions → hooks/store integration → Page consumption → Error handling New component: Place in shared/components → Add story/test → Theme adaptation → Permission handling ``` --- ### III. Desktop Client Specific Load when Electron / Tauri / Capacitor project is detected: #### A. Process Architecture **Electron projects:** - Main process responsibilities and entry - Renderer process architecture - Preload scripts and contextBridge - Multi-window management - IPC design pattern **Tauri projects:** - Frontend layer (WebView) - Rust backend layer (Tauri Commands) - IPC communication (invoke/listen) - Plugin system - Security policies (allowlist/CSP) #### B. Native Capability Integration - File system operations (read/write, dialogs) - System tray and notifications - Clipboard / screenshot / global shortcuts - Network status monitoring - System info access - Native modules (Node Addons / Rust FFI) #### C. Signing & Distribution - Developer certificates and signing config - macOS: codesign + notary / Windows: signing certificate - Auto-update mechanism (autoUpdater) - Update server config - Distribution channels per platform (App Store / Microsoft Store / self-hosted) #### D. Build & Packaging - Build commands and config - Multi-platform builds (macOS arm64/x64 / Windows x64) - Package formats (DMG/EXE/MSI/AppImage) - Build time optimization - Build flow in CI/CD #### E. Client-Specific Debugging - Main process debugging - Renderer process debugging (DevTools) - IPC debugging - Native capability debugging - Performance profiling (CPU/memory/startup speed) **High Frequency Workflow Example (Desktop Client):** ``` New feature: Frontend dev → Define IPC → Implement main process/Rust command → Integration test → Test → Build New native capability: Research API → Implement IPC command → Frontend call wrapper → Error handling → Cross-platform test Release flow: Build multi-platform → Sign → Notarize → Upload to update server → Canary → Full rollout ``` --- ### IV. Backend Service Specific Load when Express/Nest/Django/Spring/Gin project is detected: #### A. Database & Storage - Database used (MySQL/PostgreSQL/MongoDB/Redis etc.) - ORM/Query Builder (Prisma/TypeORM/Sequelize/GORM etc.) - Migration strategy - Schema design approach - Caching strategy (Redis/Memcached) - File storage (OSS/S3/local) #### B. Middleware & Request Handling - Middleware chain and execution order - Authentication and authorization (JWT/Session/OAuth) - Request validation - Logging strategy - Rate limiting and circuit breaking #### C. API Design - RESTful / GraphQL / gRPC / tRPC - API versioning - Error code system - API documentation (Swagger/OpenAPI) - Request/response format conventions #### D. Async & Task Processing - Message queues (RabbitMQ/Kafka/Redis) - Scheduled tasks (Cron) - Background jobs/workers - WebSocket / SSE long connections **High Frequency Workflow Example (Backend):** ``` New endpoint: Define route → Parameter validation → Business logic → Database operation → Return response → Add tests New data table: Design Schema → Create Migration → Write Model → Implement business logic → API integration New scheduled task: Register Cron → Implement task logic → Logging & monitoring → Test & verify ``` --- ### V. Mini Program Specific Load when WeChat/Alipay/Douyin mini program project is detected: #### A. Platform & Framework - Target platform(s) (WeChat/Alipay/Douyin/multi-platform) - Native vs cross-platform framework (Taro/uni-app) - Platform API difference handling #### B. Mini Program Architecture - Page and component structure - Global config (app.json/pages.json) - Custom component encapsulation - Subpackage strategy - Plugin usage #### C. User System & Auth - Login flow (wx.login etc.) - User info retrieval and storage - Session management - Integration with backend user system #### D. Publishing & Review - Review process and notes - Trial vs production release - Version management and rollback - Mini program code / share config #### E. Performance Optimization - Subpackage loading - Image lazy loading - setData optimization - Long list optimization - Custom component lazy loading **High Frequency Workflow Example (Mini Program):** ``` New page: Register in pages.json → Create page directory → Implement page logic → Configure route → Submit trial version → Review New component: Create component directory → Implement component → Import & use → Style isolation New API: Wrap request method → Page call → Error handling → Loading state ``` --- ### VI. Mobile App Specific Load when React Native / Flutter / SwiftUI / Kotlin project is detected: #### A. App Architecture - Framework used (React Native/Flutter/SwiftUI/Compose) - Architecture pattern (MVI/MVVM/Clean Architecture) - Modularization approach - Navigation system #### B. Native Modules & Bridge - Native module list and purposes - Bridge communication mechanism - How to add new native modules - Third-party native SDK integration #### C. State Management & Data Persistence - State management solution - Local storage (AsyncStorage/MMKV/SQLite/CoreData) - Offline strategy #### D. Release & App Store - Android: signing config (keystore) - iOS: certificate and profile management - Store submission process (App Store / Google Play) - Hot update solution (CodePush/EAS Update) - TestFlight / beta distribution #### E. Mobile-Specific Debugging - Physical device debugging - Performance profiling tools - Crash log collection - Network packet capture **High Frequency Workflow Example (Mobile App):** ``` New page: Create page/Screen → Register route → Connect state → Connect navigation → Integration test API New native module: Define Bridge interface → Implement Android/iOS native code → JS call wrapper → Test Release flow: Build Android/iOS → Sign → Upload to store → Submit for review → Publish ``` --- ## Project Type Auto-Detection Before analyzing, identify the project type via these signals (multi-select): **Frontend Web signals:** - `package.json` has react/vue/svelte/angular/next/nuxt - webpack.config/vite.config/tsconfig.json exists - public/index.html or index.html exists - src has pages/views/components/hooks/store directories **Desktop Client signals:** - `package.json` has electron/tauri - electron/ or src-tauri/ directory exists - Capacitor config file - Main process entry file **Backend Service signals:** - `package.json` has express/nest/fastify/koa (Node) - go.mod / requirements.txt / pom.xml / Cargo.toml - migration/ directory exists - Dockerfile / docker-compose.yml **Mini Program signals:** - app.json / pages.json / project.config.json - Taro/uni-app config - WeChat DevTools config file **Mobile App signals:** - android/ or ios/ directory - Podfile / build.gradle / pubspec.yaml - App.tsx/AppDelegate.swift (RN/Flutter entry) - .xcodeproj / .xcworkspace Inform user of detection result at the start of Stage 1. If inaccurate, user can manually specify. --- ## Output Strategy **Strictly stage-based output. Do NOT output everything at once.** ### Stage 1 — Developer Quick Overview (Default) - Project type (auto-detected) - What the project is - How to start - Tech stack - Most important directories - Key standards - Environment system - Recommended reading order - High-risk areas **Goal: Build a project map within 10 minutes.** ### Stage 2 — Universal Modules Deep Dive Expand directory navigation, engineering standards, team collaboration, environment & deployment etc. when user asks. ### Stage 3 — Type-Specific Deep Dive Expand the corresponding type-specific module (Frontend Web / Backend / Client / Mini Program / Mobile) when user asks. ### Stage 4 — Targeted Development Assistance Support multi-round questions: - "Which module should I reference for adding a new page?" - "How does the permission system work?" - "How is IPC communication debugged?" - "What's the release workflow?" ## Stage Stopping Conditions - After current stage output is complete, **⏸ pause and wait for user confirmation or follow-up** - At the end of each stage, provide clear next-step prompts, e.g.: - End of Stage 1: *"Above is the project quick overview. For deeper understanding of engineering standards, directory navigation, etc., let me know. For [project type] specific guide, say 'specific'. To start a specific dev task, just ask."* - End of Stage 2: *"Universal modules expanded. For [project type] specific guide, say 'specific'. Or ask specific dev questions directly."* - End of Stage 3: *"Specific guide expanded. Feel free to ask specific dev questions like 'how to add a new page' or 'what's the release workflow'."* - For insufficient-evidence content: briefly note and skip, don't force-fill - When tokens/context approach limits: output current progress and remaining plan ## Input Validation ### When Information Is Insufficient If user only says "help me set up" or similar vague requests, don't guess or blindly execute: 1. At minimum need one of: **project path / Git repo URL / currently open working directory** 2. Ask: "Which project would you like to analyze? Please provide the project path or repo URL." 3. If user provides a path but project is empty or inaccessible: clearly inform and ask for confirmation ### Handling Contradictory Requests When user makes conflicting goals (e.g., "give me a complete architecture report" but also "keep it concise"): 1. Point out the contradiction: "Complete architecture report and concise output conflict" 2. Suggest compromise: prioritize Stage 1 (quick overview), then go deeper as needed 3. Let user choose priority ### When Project Cannot Be Analyzed Clearly inform user and stop analysis in these cases; do not force output: - Specified path doesn't exist or no access permissions - Project directory is empty - Cannot identify project type (no known signals) - Key config files (e.g., package.json) are corrupted or unreadable --- ## Important Constraints ### Don't: - Generate lengthy unfocused reports - Explain basic programming knowledge - Mechanically list all files - Output meaningless directory trees - Discuss component systems for backend projects, ORM for frontend projects - Ignore development workflows and team collaboration ### Must: - Core focus on development efficiency - Tailor content by project type, only load relevant modules - Emphasize engineering practices and actual development workflows - Emphasize "how to actually start developing" - Support multi-round progressive exploration ## Execution Tool Guide Every analysis step should be backed by concrete tool execution, not fabricated output: ### Project Type Detection — Actions 1. `read {project}/package.json` → extract dependencies, match frontend/client/Node backend signals 2. `exec find {project} -maxdepth 2 -name "*.config.*" -o -name "go.mod" -o -name "Cargo.toml" -o -name "pom.xml" -o -name "app.json"` → backend/miniapp/mobile signals 3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → desktop client signals 4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → mobile signals 5. Multiple signals → treat as mixed project, load all matching modules ### Stage 1 Quick Overview — Actions 1. `read {project}/package.json` or `Cargo.toml` or `go.mod` → tech stack 2. `exec ls {project}/` → directory structure overview 3. `read {project}/README.md` → project purpose (if exists) 4. `read {project}/.env.example` → environment variables (if exists) ### Stage 2 Universal Modules — Actions 1. `exec find {project}/src -type d -maxdepth 2` → directory structure 2. `read {project}/src/index.*` or `main.*` → entry file 3. `exec find {project} -name "Dockerfile" -o -name "docker-compose*" | head -3` → deployment ### Stage 3 Type-Specific — Select by Type **Frontend Web:** `find` for router/store/api files **Backend:** `find` for migration/middleware/controller files **Desktop Client:** `read` main process entry + `find` preload/bridge ### Large Project Strategy When `exec find {project} -type f | wc -l` exceeds 200: build index first, only read P0 files, deep-dive core chain only. ### Output Format Each Stage: `# [Project Name] — Stage N: [Title]` with structured headings + `## ⏸ Next Steps` at end. - Emphasize "how to actually start developing" - Support multi-round progressive exploration ## Ideal Outcome After using this skill, an experienced developer should be able to: - Successfully start the project - Understand project structure and type-specific architecture - Find core modules - Understand engineering standards - Safely develop features - Correctly use type-specific capabilities (components/API/IPC/native modules etc.) - Complete QA submission and release - Know where to dive deeper Ultimate achievement: **"I'm ready to start participating in project development."**


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)