{"id":"954292fe-66c0-43b2-8a32-30c78eede333","entityType":"agent","slug":"clawhub-z-zihan-project-onboarding","name":"Project Onboarding","canonicalUrl":"https://www.xpersona.co/agent/clawhub-z-zihan-project-onboarding","canonicalPath":"/agent/clawhub-z-zihan-project-onboarding","generatedAt":"2026-10-11T01:48:24.112Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T22:37:45.059Z","emptyReason":null},"description":"帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、 客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出 项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。 触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门,... Skill: Project Onboarding Owner: z-zihan Summary: 帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、 客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出 项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。 触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门,... Tags: latest:2.0.0 Version history: v2.0.0 | 2026-05-18T12:47:54.003Z | user Auto-publish from commit dc4421fe7970ce27a9e172af29c59ab38d8373a3 v0.3.0 | 2026-05-18T08:11:02.001Z | user Auto-publish from commit 5","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17bsrqjkb5zv8sm90kdv3zawn83g42h:project-onboarding","sourceUrl":"https://clawhub.ai/z-zihan/project-onboarding","homepage":"https://clawhub.ai/z-zihan/skills/project-onboarding","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/z-zihan/project-onboarding","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/z-zihan/skills/project-onboarding","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":62,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、 客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出 项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。 触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门,... "},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T22:37:45.059Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T22:37:45.059Z","emptyReason":null},"stars":null,"forks":null,"downloads":1240,"packageName":null,"latestVersion":"2.0.0","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T22:37:44.988Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T22:37:45.059Z","lastCrawledAt":"2026-10-10T22:37:44.988Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T22:37:44.988Z","lastVerifiedAt":null,"highlights":[{"version":"2.0.0","createdAt":"2026-05-18T12:47:54.003Z","changelog":"Auto-publish from commit dc4421fe7970ce27a9e172af29c59ab38d8373a3","fileCount":3,"zipByteSize":17148},{"version":"0.3.0","createdAt":"2026-05-18T08:11:02.001Z","changelog":"Auto-publish from commit 5b27ac4957173e2b02bfd6ba2b7bec399aaa54be","fileCount":2,"zipByteSize":16003},{"version":"1.2.1","createdAt":"2026-05-18T07:45:54.296Z","changelog":"No changes detected in this release. - Version bump only; no code or documentation changes. - The skill's contents, features, and behavior remain the same as the previous version.","fileCount":2,"zipByteSize":16004},{"version":"1.2.0","createdAt":"2026-05-16T13:32:29.869Z","changelog":"**Summary:** 引入了详细的工具指引和执行动作，明确要求每个分析步骤都基于真实文件和命令行结果，提升输出的严谨性与步骤可追溯性。 - 新增“执行工具指引”章节，明确各阶段需通过 read/exec/find 等具体动作分析仓库真实内容。 - 细化混合类型及大项目（文件数 >200）时的执行与输出策略。 - 定义各阶段输出的标准 Markdown 格式，规范交付内容。 - 强调所有分析和结论必须基于实际仓库证据，杜绝虚构和主观臆断。 - 保持原有分阶段、专项模块结构，仅增加执行方法及标准化流程说明，老用户无需调整使用方式。","fileCount":2,"zipByteSize":16004},{"version":"1.1.0","createdAt":"2026-05-16T11:55:17.846Z","changelog":"Bilingual restructure","fileCount":2,"zipByteSize":14420},{"version":"0.1.99","createdAt":"2026-05-16T03:23:26.234Z","changelog":"Auto-publish from commit 926041209e8cad0642bea27605a45317279cea93","fileCount":2,"zipByteSize":11136},{"version":"0.1.92","createdAt":"2026-05-15T12:35:21.709Z","changelog":"Auto-publish from commit 4bfb02e060e62fd0cb5e7e60d863806baef1ac83","fileCount":2,"zipByteSize":11123},{"version":"0.1.43","createdAt":"2026-05-14T01:32:10.746Z","changelog":"Auto-publish from commit 94ecb7d552fb1fee9d8728c268cfa8fd0b223288","fileCount":2,"zipByteSize":10258}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17bsrqjkb5zv8sm90kdv3zawn83g42h:project-onboarding","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T01:48:24.108Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-z-zihan-project-onboarding/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T22:37:45.059Z","emptyReason":null},"readme":"Skill: Project Onboarding\n\nOwner: z-zihan\n\nSummary: 帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、 客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出 项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。 触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门,...\n\nTags: latest:2.0.0\n\nVersion history:\n\nv2.0.0 | 2026-05-18T12:47:54.003Z | user\n\nAuto-publish from commit dc4421fe7970ce27a9e172af29c59ab38d8373a3\n\nv0.3.0 | 2026-05-18T08:11:02.001Z | user\n\nAuto-publish from commit 5b27ac4957173e2b02bfd6ba2b7bec399aaa54be\n\nv1.2.1 | 2026-05-18T07:45:54.296Z | auto\n\nNo changes detected in this release.\n\n- Version bump only; no code or documentation changes.\n- The skill's contents, features, and behavior remain the same as the previous version.\n\nv1.2.0 | 2026-05-16T13:32:29.869Z | auto\n\n**Summary:**  \n引入了详细的工具指引和执行动作，明确要求每个分析步骤都基于真实文件和命令行结果，提升输出的严谨性与步骤可追溯性。\n\n- 新增“执行工具指引”章节，明确各阶段需通过 read/exec/find 等具体动作分析仓库真实内容。\n- 细化混合类型及大项目（文件数 >200）时的执行与输出策略。\n- 定义各阶段输出的标准 Markdown 格式，规范交付内容。\n- 强调所有分析和结论必须基于实际仓库证据，杜绝虚构和主观臆断。\n- 保持原有分阶段、专项模块结构，仅增加执行方法及标准化流程说明，老用户无需调整使用方式。\n\nv1.1.0 | 2026-05-16T11:55:17.846Z | user\n\nBilingual restructure\n\nv0.1.99 | 2026-05-16T03:23:26.234Z | user\n\nAuto-publish from commit 926041209e8cad0642bea27605a45317279cea93\n\nv0.1.92 | 2026-05-15T12:35:21.709Z | user\n\nAuto-publish from commit 4bfb02e060e62fd0cb5e7e60d863806baef1ac83\n\nv0.1.43 | 2026-05-14T01:32:10.746Z | user\n\nAuto-publish from commit 94ecb7d552fb1fee9d8728c268cfa8fd0b223288\n\nv0.1.42 | 2026-05-14T01:31:10.344Z | user\n\nAuto-publish from commit df0fbfd8c747195b022b0e7751835cccdc1786d9\n\nv0.1.26 | 2026-05-13T13:34:04.095Z | user\n\nAuto-publish from commit 5dceed266108802504831653de56fc1fde8f0fd4\n\nArchive index:\n\nArchive v2.0.0: 3 files, 17148 bytes\n\nFiles: skill-card.md (2040b), SKILL.md (39562b), _meta.json (137b)\n\nFile v2.0.0:SKILL.md\n\n---\nname: project-onboarding\nversion: \"2.0.0\"\nhomepage: https://github.com/z-Zihan/awesome-skills\ndescription: >\n  帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、\n  客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出\n  项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。\n  触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门, onboarding,\n  如何开发, 怎么启动项目, 项目怎么跑, 开发流程, onboarding guide,\n  how to onboard, project handover, developer quick start.\n  NOT for: generating long architecture reports, code analysis without dev context,\n  beginner programming tutorials, onboarding for interns.\n---\n\n# project-onboarding — 项目接手指南\n\n## 语言规则\n\n**检测用户使用的语言，全程使用同一语言输出。** 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（React、Electron、IPC 等）保留原文即可。\n\n---\n\n# 中文版\n\n帮助有经验的开发者快速理解并接手一个陌生项目，尽快具备实际开发能力。\n\n## 支持的项目类型\n\n按优先级排序：\n\n| 类型 | 识别信号 | 专项模块 |\n|---|---|---|\n| **前端 Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | 组件体系、路由、状态管理、CSS 方案、API 集成、浏览器兼容 |\n| **后端服务** | Express/Nest/Django/Spring/Gin, ORM/migration | 数据库 Schema、ORM、中间件链、API 设计、认证鉴权、缓存与队列 |\n| **客户端** | Electron/Tauri/Capacitor, 主进程/渲染进程 | 主进程架构、渲染进程、IPC 通信、原生能力、签名与分发、自动更新 |\n| **小程序** | 微信/支付宝/抖音小程序, app.json/pages.json | 平台适配、分包策略、审核流程、原生能力调用、用户体系 |\n| **移动端** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | 原生模块 Bridge、热更新、应用签名、应用商店发布、权限管理 |\n\n**多类型混合项目**（如 Electron + Vue、Tauri + React）：同时加载对应专项模块，按优先级排序。\n\n> **扩展指南**：新增项目类型时，需要同步更新三个位置：\n> 1. 上方「支持的项目类型」表格\n> 2. 「项目类型自动识别」信号列表\n> 3. 对应的专项模块章节（新增或复用）\n> 建议保持模块命名和排序的一致性。\n\n## 这个 Skill 不是\n\n- 面向编程新手\n- 面向实习生教学\n- 面向基础知识解释\n- 面向纯代码分析\n\n## 核心目标\n\n让专业开发者在最短时间内完成：\n\n- 项目理解\n- 工程结构理解\n- 开发流程理解\n- 团队规范理解\n- 环境体系理解\n- 项目类型特有的核心能力理解\n- 发布流程理解\n- 调试与开发能力建立\n\n最终达到：\n\n**\"开发者已经可以开始安全地开发功能并参与协作。\"**\n\n## 语言策略\n\n- 默认输出中文，同时提供英文版本\n- 中文优先\n\n## 核心原则\n\n### 1. 以\"快速进入开发状态\"为最高优先级\n\n优先帮助开发者理解：\n\n- 项目如何运行\n- 功能如何开发\n- 项目类型特有的核心机制\n- 目录如何组织\n- 环境如何切换\n- 如何调试\n- 如何发版\n- 如何避免踩坑\n\n**而不是：**\n\n- 生成超长架构分析报告\n- 输出无意义目录树\n- 罗列所有源码文件\n\n### 2. 避免一次性信息轰炸\n\n- 分阶段输出\n- 优先级排序\n- 保持简洁\n- 支持多轮渐进式探索\n\n### 3. 模拟\"资深工程师带新人\"\n\n你的角色不是代码分析器，而是团队里的资深工程师在带一个有经验的新同事。\n\n重点关注：\n\n- 实际开发流程\n- 隐式规范\n- 高风险区域\n- 常见坑\n- 推荐参考模块\n\n### 4. 证据优先，不假装理解\n\n- 所有结论基于仓库真实证据\n- 仓库中没有的规范或机制，不要编造\n- 区分：已确认事实 / 合理推断 / 证据不足\n\n### 5. 按项目类型裁剪内容\n\n- 只分析与当前项目类型相关的模块\n- 不要给后端项目讲组件体系，不要给前端项目讲 ORM\n- 混合项目按优先级排序专项模块\n\n## 执行工具指引\n\n本 Skill 的每个分析步骤都应配合具体工具执行，而非凭空\"编\"输出：\n\n### 项目类型识别 — 执行动作\n\n1. `read {project}/package.json` → 提取 dependencies 和 devDependencies，匹配前端/客户端/Node 后端信号\n2. `exec find {project} -maxdepth 2 -name \"*.config.*\" -o -name \"go.mod\" -o -name \"Cargo.toml\" -o -name \"pom.xml\" -o -name \"app.json\"` → 识别后端/小程序/移动端信号\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → 客户端信号\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → 移动端信号\n5. 多信号命中时 → 按混合项目处理，所有匹配的专项模块均加载\n\n### Stage 1 快速总览 — 执行动作\n\n1. `read {project}/package.json` 或 `Cargo.toml` 或 `go.mod` → 技术栈\n2. `exec ls {project}/` → 目录结构概览\n3. `read {project}/README.md` → 项目用途（如存在）\n4. `read {project}/.env.example` → 环境变量（如存在）\n5. `exec find {project} -name \"*.config.*\" -maxdepth 1` → 构建配置\n\n### Stage 2 通用模块深入 — 执行动作\n\n1. `exec find {project}/src -type d -maxdepth 2` → 目录结构\n2. `read {project}/src/index.*` 或 `main.*` → 入口文件\n3. `exec find {project} -name \".eslintrc*\" -o -name \".prettierrc*\" -o -name \"tsconfig.json\" -maxdepth 1` → 工程规范\n4. `exec find {project} -name \"Dockerfile\" -o -name \"docker-compose*\" -o -name \".github\" -type d -maxdepth 2` → 部署配置\n5. `exec find {project} -name \"*.test.*\" -o -name \"*.spec.*\" | head -5` → 测试结构\n\n### Stage 3 专项模块 — 按类型选择执行\n\n**前端 Web：**\n- `exec find {project}/src -name \"router*\" -o -name \"routes*\" | head -5` → 路由\n- `exec find {project}/src -name \"store*\" -o -name \"*reducer*\" | head -5` → 状态管理\n- `exec find {project}/src -name \"request*\" -o -name \"api*\" -o -name \"http*\" | head -5` → API 层\n\n**后端：**\n- `exec find {project} -path \"*/migration*\" -o -path \"*/schema*\" | head -5` → 数据库\n- `exec find {project} -path \"*/middleware*\" -o -path \"*/guard*\" | head -5` → 中间件\n- `exec find {project} -path \"*/route*\" -o -name \"controller*\" | head -5` → 路由/控制器\n\n**客户端：**\n- `read {project}/electron/main.*` 或 `{project}/src-tauri/src/main.rs` → 主进程\n- `exec find {project} -name \"preload*\" -o -name \"bridge*\" | head -5` → IPC\n\n### 大项目策略\n\n当 `exec find {project} -type f | wc -l` 超过 200 时：\n1. 先用 `find` + `ls` 建立文件索引，不全量读取\n2. 只读 P0 文件（package.json、入口、README）\n3. 核心链路深入（入口 → 中间件 → 服务 → 数据），其余跳过\n\n### 输出格式定义\n\n每个 Stage 的输出应使用以下 Markdown 结构：\n\n```markdown\n# [项目名] — Stage N: [阶段名]\n\n## 项目类型\n[类型]（识别信号：[列出检测到的信号]）\n\n## [各分析维度]\n...\n\n## ⏸ 下一步\n[提示用户可以深入的方向]\n```\n\n---\n\n## 分析模块\n\n### 一、通用模块（所有项目类型）\n\n以下模块适用于任何项目类型，按分析顺序排列：\n\n#### 1. 项目概览\n\n- 项目用途与业务领域\n- 项目类型（自动识别）\n- 核心能力与主要模块\n- 技术栈\n- 系统架构\n- 外部依赖\n- 核心链路\n\n#### 2. 开发快速启动\n\n- 如何安装依赖\n- 如何启动项目\n- 本地开发命令\n- 如何切换环境\n- 必需环境变量\n- 如何本地调试\n- 如何运行测试\n- 如何构建\n\n#### 3. 项目目录导航\n\n必须说明：\n\n- 为什么这样组织\n- 哪些目录最重要\n- 哪些目录最常修改\n- 哪些目录风险最高\n- 哪些属于基础设施\n\n#### 4. 工程规范\n\n- 命名规范\n- 目录规范\n- 代码组织方式\n- commit 规范\n- lint/format 规范\n- 测试规范\n- 错误处理规范\n- 隐式规范（README 没写但团队默认遵守的规则）\n\n#### 5. 环境与部署体系\n\n- 环境列表（local/dev/test/staging/production 等）\n- 环境如何切换\n- 配置如何管理\n- CI/CD 流程\n- 如何发版 / 如何提测 / 如何回滚\n\n#### 6. 团队协作流程\n\n- 分支策略\n- PR / Code Review 流程\n- QA / UAT 流程\n\n#### 7. 高频开发路径\n\n总结团队最常见的开发套路（按项目类型定制示例）\n\n#### 8. 推荐参考模块\n\n- 最规范的模块\n- 最推荐模仿的实现\n- 入口文件\n\n#### 9. 危险区域识别\n\n- 哪些区域改动风险高\n- 哪些代码耦合严重\n- 哪些模块容易引发线上问题\n\n---\n\n### 二、前端 Web 专项\n\n当识别到前端 Web 项目时加载：\n\n#### A. 组件体系与 UI 基础设施\n\n- 内部组件库\n- 第三方组件库\n- layout 系统 / icon 系统 / theme 系统\n- 通用业务组件\n- 哪些组件应优先复用\n- 新组件放哪里\n\n#### B. 路由系统\n\n- 路由如何组织\n- 路由守卫与权限\n- 动态路由 / 懒加载\n- 新增页面的路由配置方式\n\n#### C. 状态管理\n\n- 使用的方案（Redux/Pinia/Zustand/Jotai 等）\n- 全局状态 vs 局部状态的划分策略\n- store 如何组织\n- 新功能应该用全局还是局部状态\n\n#### D. CSS 与样式方案\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- 设计系统 / token 体系\n- 样式约定\n\n#### E. API 集成\n\n- 请求层如何封装\n- token/auth 如何工作\n- 错误拦截机制\n- mock 策略\n- 新接口应该如何接入\n\n**高频开发路径示例（前端 Web）：**\n\n```\n新增页面: 新增 route → 新增 page → 新增 API → 接入 store → 接入权限 → 配置菜单 → 提测 → 发版\n新增接口: 定义 API → request 封装 → 类型定义 → hooks/store 接入 → 页面消费 → 错误处理\n新增组件: 放入 shared/components → 补充 story/test → theme 适配 → 权限处理\n```\n\n---\n\n### 三、客户端专项\n\n当识别到 Electron / Tauri / Capacitor 等客户端项目时加载：\n\n#### A. 进程架构\n\n**Electron 项目：**\n- 主进程（Main Process）职责与入口\n- 渲染进程（Renderer Process）架构\n- 预加载脚本（Preload）与 contextBridge\n- 多窗口管理\n- 进程间通信（IPC）设计\n\n**Tauri 项目：**\n- 前端层（WebView）\n- Rust 后端层（Tauri Commands）\n- IPC 通信方式（invoke/listen）\n- 插件系统\n- 安全策略（allowlist/CSP）\n\n#### B. 原生能力集成\n\n- 文件系统操作（读写、对话框）\n- 系统托盘与通知\n- 剪贴板 / 屏幕截图 / 全局快捷键\n- 网络状态监听\n- 系统信息获取\n- 原生模块（Node Addons / Rust FFI）\n\n#### C. 签名与分发\n\n- 开发者证书与签名配置\n- macOS: codesign + notary / Windows: 签名证书\n- 自动更新机制（autoUpdater）\n- 更新服务器配置\n- 各平台分发渠道（App Store / Microsoft Store / 自建）\n\n#### D. 构建与打包\n\n- 构建命令与配置\n- 多平台构建（macOS arm64/x64 / Windows x64）\n- 安装包格式（DMG/EXE/MSI/AppImage）\n- 构建时间优化\n- CI/CD 中的构建流程\n\n#### E. 客户端特有调试\n\n- 主进程调试\n- 渲染进程调试（DevTools）\n- IPC 通信调试\n- 原生能力调试\n- 性能分析（CPU/内存/启动速度）\n\n**高频开发路径示例（客户端）：**\n\n```\n新增功能: 前端开发 → IPC 通信定义 → 主进程/Rust 命令实现 → 联调 → 测试 → 构建\n新增原生能力: 调研 API → 实现 IPC 命令 → 前端调用封装 → 错误处理 → 多平台测试\n发版流程: 构建多平台 → 签名 → 公证 → 上传更新服务器 → 灰度 → 全量\n```\n\n---\n\n### 四、后端服务专项\n\n当识别到 Express/Nest/Django/Spring/Gin 等后端服务项目时加载：\n\n#### A. 数据库与存储\n\n- 使用的数据库（MySQL/PostgreSQL/MongoDB/Redis 等）\n- ORM/Query Builder（Prisma/TypeORM/Sequelize/GORM 等）\n- Migration 策略\n- 数据库 Schema 设计思路\n- 缓存策略（Redis/Memcached）\n- 文件存储（OSS/S3/本地）\n\n#### B. 中间件与请求处理\n\n- 中间件链与执行顺序\n- 认证与鉴权（JWT/Session/OAuth）\n- 请求验证与参数校验\n- 日志策略\n- 限流与熔断\n\n#### C. API 设计\n\n- RESTful / GraphQL / gRPC / tRPC\n- API 版本管理\n- 错误码体系\n- 文档生成（Swagger/OpenAPI）\n- 请求/响应格式约定\n\n#### D. 异步与任务处理\n\n- 消息队列（RabbitMQ/Kafka/Redis）\n- 定时任务（Cron）\n- 后台任务/Worker\n- WebSocket / SSE 长连接\n\n**高频开发路径示例（后端）：**\n\n```\n新增接口: 定义路由 → 参数校验 → 业务逻辑 → 数据库操作 → 返回响应 → 补充测试\n新增数据表: 设计 Schema → 创建 Migration → 编写 Model → 实现业务逻辑 → API 接入\n新增定时任务: 注册 Cron → 实现任务逻辑 → 日志与监控 → 测试验证\n```\n\n---\n\n### 五、小程序专项\n\n当识别到微信/支付宝/抖音小程序项目时加载：\n\n#### A. 平台与框架\n\n- 目标平台（微信/支付宝/抖音/多端）\n- 使用原生还是跨端框架（Taro/uni-app）\n- 平台 API 差异处理\n\n#### B. 小程序架构\n\n- 页面与组件结构\n- 全局配置（app.json/pages.json）\n- 自定义组件封装\n- 分包策略\n- 插件使用\n\n#### C. 用户体系与登录\n\n- 登录流程（wx.login 等）\n- 用户信息获取与存储\n- Session 管理\n- 与后端用户系统的对接\n\n#### D. 发布与审核\n\n- 审核流程与注意事项\n- 体验版 / 正式版 发布\n- 版本管理与回滚\n- 小程序码 / 分享配置\n\n#### E. 性能优化\n\n- 分包加载\n- 图片懒加载\n- setData 优化\n- 长列表优化\n- 自定义组件懒加载\n\n**高频开发路径示例（小程序）：**\n\n```\n新增页面: pages.json 注册 → 创建页面目录 → 实现页面逻辑 → 配置路由 → 提交体验版 → 审核\n新增组件: 创建组件目录 → 实现 component → 引入使用 → 样式隔离\n新增接口: 封装请求方法 → 页面调用 → 错误处理 → 加载态\n```\n\n---\n\n### 六、移动端专项\n\n当识别到 React Native / Flutter / SwiftUI / Kotlin 等移动端项目时加载：\n\n#### A. 应用架构\n\n- 使用的框架（React Native/Flutter/SwiftUI/Compose）\n- 架构模式（MVI/MVVM/Clean Architecture）\n- 模块化方案\n- 导航系统\n\n#### B. 原生模块与 Bridge\n\n- 原生模块列表与用途\n- Bridge 通信机制\n- 如何新增原生模块\n- 第三方原生 SDK 集成方式\n\n#### C. 状态管理与数据持久化\n\n- 状态管理方案\n- 本地存储（AsyncStorage/MMKV/SQLite/CoreData）\n- 离线策略\n\n#### D. 发布与应用商店\n\n- Android: 签名配置（keystore）\n- iOS: 证书与 Profile 管理\n- 应用商店提交流程（App Store / Google Play）\n- 热更新方案（CodePush/EAS Update）\n- TestFlight / 内测分发\n\n#### E. 移动端特有调试\n\n- 真机调试流程\n- 性能分析工具\n- 崩溃日志收集\n- 网络抓包\n\n**高频开发路径示例（移动端）：**\n\n```\n新增页面: 创建页面/Screen → 注册路由 → 接入状态 → 接入导航 → 联调接口\n新增原生模块: 定义 Bridge 接口 → 实现 Android/iOS 原生代码 → JS 调用封装 → 测试\n发版流程: 构建 Android/iOS → 签名 → 上传商店 → 提交审核 → 发布\n```\n\n---\n\n## 项目类型自动识别\n\n分析项目前，先通过以下信号识别项目类型（可多选）：\n\n**前端 Web 信号：**\n- `package.json` 中有 react/vue/svelte/angular/next/nuxt\n- 存在 webpack.config/vite.config/tsconfig.json\n- 存在 public/index.html 或 index.html\n- src 下有 pages/views/components/hooks/store 目录\n\n**客户端信号：**\n- `package.json` 中有 electron/tauri\n- 存在 electron/ 目录或 src-tauri/ 目录\n- Capacitor 配置文件\n- main process 入口文件\n\n**后端服务信号：**\n- `package.json` 中有 express/nest/fastify/koa（Node）\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- 存在 migration/ 目录\n- Dockerfile / docker-compose.yml\n\n**小程序信号：**\n- app.json / pages.json / project.config.json\n- Taro/uni-app 配置\n- 微信开发者工具配置文件\n\n**移动端信号：**\n- android/ 或 ios/ 目录\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift（RN/Flutter 入口）\n- .xcodeproj / .xcworkspace\n\n识别结果在 Stage 1 开头明确告知用户，如果识别不准确，用户可以手动指定。\n\n---\n\n## 输出策略\n\n**严格分阶段输出，不要一次输出全部内容。**\n\n### Stage 1 — 开发者快速总览（默认）\n\n- 项目类型（自动识别结果）\n- 项目是什么\n- 如何启动\n- 技术栈\n- 最重要目录\n- 关键规范\n- 环境体系\n- 推荐阅读顺序\n- 高风险区域\n\n**目标：让开发者 10 分钟内建立项目地图。**\n\n### Stage 2 — 通用模块深入\n\n用户追问时展开目录导航、工程规范、团队协作、环境部署等通用模块。\n\n### Stage 3 — 项目类型专项深入\n\n用户追问时展开对应项目类型的专项模块（前端 Web / 后端 / 客户端 / 小程序 / 移动端）。\n\n### Stage 4 — 定向开发辅助\n\n支持多轮追问：\n\n- \"新增页面应该参考哪个模块？\"\n- \"权限系统怎么做的？\"\n- \"IPC 通信怎么调的？\"\n- \"发版流程是什么？\"\n\n## 每个阶段的停止条件\n\n- 当前阶段内容输出完毕后，**⏸ 暂停等待用户确认或追问**\n- 每个阶段结束时，给出明确的下一步提示，例如：\n  - Stage 1 结束：*\"以上是项目快速总览。如需深入了解工程规范、目录导航等，请告诉我。如需查看[项目类型]专项指南，请说「专项」。如要开始某个具体开发任务，直接说即可。\"*\n  - Stage 2 结束：*\"通用模块已展开。如需查看[项目类型]专项指南，请说「专项」。或直接问具体的开发问题。\"*\n  - Stage 3 结束：*\"专项指南已展开。可以直接问具体开发问题，如「新增页面怎么做」「发版流程是什么」等。\"*\n- 证据不足的内容：简单说明后跳过，不要强行填充\n- Token/上下文接近上限时：输出当前进度和剩余计划\n\n## 输入验证\n\n### 信息不足时\n\n如果用户只说了\"帮我搞一下\"或类似模糊请求，不要猜测或胡乱执行：\n1. 至少需要以下信息之一：**项目路径 / Git 仓库地址 / 已打开的工作目录**\n2. 询问：\"请问要分析哪个项目？请提供项目路径或仓库地址。\"\n3. 如果用户提供了路径但项目为空或无法访问：明确告知并请求确认\n\n### 矛盾请求处理\n\n当用户同时提出冲突目标时（如\"给我完整架构报告\"但又要求\"保持简洁\"）：\n1. 指出矛盾：\"完整架构报告与简洁输出存在矛盾\"\n2. 建议折中方案：优先 Stage 1（快速总览），再按需深入\n3. 让用户选择优先级\n\n### 项目无法分析时\n\n以下情况应明确告知用户并停止分析，不要强行输出：\n- 指定路径不存在或无访问权限\n- 项目目录为空\n- 无法识别项目类型（无任何已知信号）\n- 关键配置文件（如 package.json）损坏或不可读\n\n---\n\n## 重要限制\n\n### 不要：\n- 生成超长无重点报告\n- 解释基础编程知识\n- 机械列举所有文件\n- 输出没有意义的目录树\n- 给后端项目讲组件体系，给前端项目讲 ORM\n- 忽略开发流程和团队协作\n\n### 必须：\n- 以开发效率为核心\n- 按项目类型裁剪内容，只加载相关模块\n- 强调工程实践和实际开发流程\n- 强调\"如何真正开始开发\"\n- 支持多轮渐进式探索\n\n## 理想结果\n\n使用这个 skill 后，一个有经验的开发者应该能够：\n\n- 成功启动项目\n- 理解项目结构与项目类型特有架构\n- 找到核心模块\n- 理解工程规范\n- 能够安全开发功能\n- 能够正确使用项目类型特有能力（组件/API/IPC/原生模块等）\n- 能够完成提测与发版\n- 知道应该继续深入哪里\n\n最终达到：**\"我已经可以开始参与项目开发了。\"**\n\n---\n---\n\n# English Version\n\nHelp experienced developers quickly understand and onboard onto an unfamiliar project, achieving actual development capability as fast as possible.\n\n## Supported Project Types\n\nPriority order:\n\n| Type | Detection Signals | Specific Modules |\n|---|---|---|\n| **Frontend Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | Component system, routing, state management, CSS approach, API integration, browser compatibility |\n| **Backend Service** | Express/Nest/Django/Spring/Gin, ORM/migration | Database Schema, ORM, middleware chain, API design, auth, caching & queues |\n| **Desktop Client** | Electron/Tauri/Capacitor, main/renderer process | Main process architecture, renderer process, IPC, native capabilities, signing & distribution, auto-update |\n| **Mini Program** | WeChat/Alipay/Douyin mini program, app.json/pages.json | Platform adaptation, subpackage strategy, review process, native API calls, user system |\n| **Mobile App** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | Native module Bridge, hot update, app signing, app store publishing, permission management |\n\n**Mixed-type projects** (e.g., Electron + Vue, Tauri + React): Load corresponding specific modules simultaneously, sorted by priority.\n\n> **Extension guide**: When adding new project types, update three places in sync:\n> 1. The \"Supported Project Types\" table above\n> 2. The \"Project Type Auto-Detection\" signal list\n> 3. The corresponding specific module section (new or reuse)\n> Maintain consistent module naming and ordering.\n\n## This Skill Is NOT\n\n- For programming beginners\n- For intern training\n- For explaining basic programming concepts\n- For pure code analysis\n\n## Core Objective\n\nEnable a professional developer to achieve the following in minimum time:\n\n- Project understanding\n- Engineering structure understanding\n- Development workflow understanding\n- Team standards understanding\n- Environment system understanding\n- Type-specific core capabilities understanding\n- Release workflow understanding\n- Debug and development capability\n\nUltimate goal:\n\n**\"The developer is ready to safely develop features and collaborate.\"**\n\n## Language Strategy\n\n- Default to user's language, also provide the other language version\n- Follow user's language preference\n\n## Core Principles\n\n### 1. \"Fast to Development-Ready\" is the Highest Priority\n\nPrioritize helping developers understand:\n\n- How the project runs\n- How to develop features\n- Type-specific core mechanisms\n- How directories are organized\n- How to switch environments\n- How to debug\n- How to release\n- How to avoid common pitfalls\n\n**Instead of:**\n\n- Generating lengthy architecture reports\n- Outputting meaningless directory trees\n- Listing all source files\n\n### 2. Avoid Information Overload\n\n- Output in stages\n- Sort by priority\n- Keep concise\n- Support multi-round progressive exploration\n\n### 3. Simulate \"Senior Engineer Onboarding a New Colleague\"\n\nYour role is not a code analyzer — it's a senior engineer helping an experienced new colleague onboard.\n\nFocus on:\n\n- Actual development workflows\n- Implicit team conventions\n- High-risk areas\n- Common pitfalls\n- Recommended reference modules\n\n### 4. Evidence First, Don't Fake Understanding\n\n- All conclusions based on real repo evidence\n- Don't fabricate standards or mechanisms not in the repo\n- Distinguish: confirmed facts / reasonable inference / insufficient evidence\n\n### 5. Tailor Content by Project Type\n\n- Only analyze modules relevant to the project type\n- Don't discuss component systems for backend projects, don't discuss ORM for frontend projects\n- Mixed projects sort specific modules by priority\n\n---\n\n## Analysis Modules\n\n### I. Universal Modules (All Project Types)\n\nThese modules apply to any project type, in analysis order:\n\n#### 1. Project Overview\n\n- Project purpose and business domain\n- Project type (auto-detected)\n- Core capabilities and main modules\n- Tech stack\n- System architecture\n- External dependencies\n- Core chain\n\n#### 2. Developer Quick Start\n\n- How to install dependencies\n- How to start the project\n- Local dev commands\n- How to switch environments\n- Required environment variables\n- How to debug locally\n- How to run tests\n- How to build\n\n#### 3. Repository Navigation\n\nMust explain:\n\n- Why organized this way\n- Which directories are most important\n- Which are most frequently modified\n- Which are highest risk\n- Which are infrastructure\n\n#### 4. Engineering Standards\n\n- Naming conventions\n- Directory conventions\n- Code organization style\n- Commit conventions\n- Linting/formatting rules\n- Testing conventions\n- Error handling patterns\n- Implicit standards (unwritten but team-default rules)\n\n#### 5. Environment & Deployment\n\n- Environment list (local/dev/test/staging/production etc.)\n- How to switch environments\n- How configs are managed\n- CI/CD pipeline\n- How to release / submit for QA / how to rollback\n\n#### 6. Team Workflow\n\n- Branching strategy\n- PR / Code Review workflow\n- QA / UAT workflow\n\n#### 7. High Frequency Development Workflow\n\nSummarize most common development patterns (examples tailored by project type)\n\n#### 8. Recommended References\n\n- Most standard module\n- Best implementation to imitate\n- Entry files\n\n#### 9. Risk Areas\n\n- Which areas are high-risk\n- Which code is heavily coupled\n- Which modules easily cause production issues\n\n---\n\n### II. Frontend Web Specific\n\nLoad when Frontend Web project is detected:\n\n#### A. Component System & UI Infrastructure\n\n- Internal component library\n- Third-party components\n- Layout system / icon system / theme system\n- Common business components\n- Which components to reuse\n- Where to put new components\n\n#### B. Routing System\n\n- How routes are organized\n- Route guards and permissions\n- Dynamic routes / lazy loading\n- How to add route for a new page\n\n#### C. State Management\n\n- Solution used (Redux/Pinia/Zustand/Jotai etc.)\n- Global vs local state strategy\n- How stores are organized\n- When to use global vs local\n\n#### D. Styling Approach\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- Design system / token system\n- Styling conventions\n\n#### E. API Integration\n\n- How request layer is encapsulated\n- How token/auth works\n- Error interception\n- Mock strategy\n- How to integrate new APIs\n\n**High Frequency Workflow Example (Frontend Web):**\n\n```\nNew page: Add route → Add page → Add API → Connect store → Add permissions → Configure menu → Submit for QA → Release\nNew API: Define API → Request wrapper → Type definitions → hooks/store integration → Page consumption → Error handling\nNew component: Place in shared/components → Add story/test → Theme adaptation → Permission handling\n```\n\n---\n\n### III. Desktop Client Specific\n\nLoad when Electron / Tauri / Capacitor project is detected:\n\n#### A. Process Architecture\n\n**Electron projects:**\n- Main process responsibilities and entry\n- Renderer process architecture\n- Preload scripts and contextBridge\n- Multi-window management\n- IPC design pattern\n\n**Tauri projects:**\n- Frontend layer (WebView)\n- Rust backend layer (Tauri Commands)\n- IPC communication (invoke/listen)\n- Plugin system\n- Security policies (allowlist/CSP)\n\n#### B. Native Capability Integration\n\n- File system operations (read/write, dialogs)\n- System tray and notifications\n- Clipboard / screenshot / global shortcuts\n- Network status monitoring\n- System info access\n- Native modules (Node Addons / Rust FFI)\n\n#### C. Signing & Distribution\n\n- Developer certificates and signing config\n- macOS: codesign + notary / Windows: signing certificate\n- Auto-update mechanism (autoUpdater)\n- Update server config\n- Distribution channels per platform (App Store / Microsoft Store / self-hosted)\n\n#### D. Build & Packaging\n\n- Build commands and config\n- Multi-platform builds (macOS arm64/x64 / Windows x64)\n- Package formats (DMG/EXE/MSI/AppImage)\n- Build time optimization\n- Build flow in CI/CD\n\n#### E. Client-Specific Debugging\n\n- Main process debugging\n- Renderer process debugging (DevTools)\n- IPC debugging\n- Native capability debugging\n- Performance profiling (CPU/memory/startup speed)\n\n**High Frequency Workflow Example (Desktop Client):**\n\n```\nNew feature: Frontend dev → Define IPC → Implement main process/Rust command → Integration test → Test → Build\nNew native capability: Research API → Implement IPC command → Frontend call wrapper → Error handling → Cross-platform test\nRelease flow: Build multi-platform → Sign → Notarize → Upload to update server → Canary → Full rollout\n```\n\n---\n\n### IV. Backend Service Specific\n\nLoad when Express/Nest/Django/Spring/Gin project is detected:\n\n#### A. Database & Storage\n\n- Database used (MySQL/PostgreSQL/MongoDB/Redis etc.)\n- ORM/Query Builder (Prisma/TypeORM/Sequelize/GORM etc.)\n- Migration strategy\n- Schema design approach\n- Caching strategy (Redis/Memcached)\n- File storage (OSS/S3/local)\n\n#### B. Middleware & Request Handling\n\n- Middleware chain and execution order\n- Authentication and authorization (JWT/Session/OAuth)\n- Request validation\n- Logging strategy\n- Rate limiting and circuit breaking\n\n#### C. API Design\n\n- RESTful / GraphQL / gRPC / tRPC\n- API versioning\n- Error code system\n- API documentation (Swagger/OpenAPI)\n- Request/response format conventions\n\n#### D. Async & Task Processing\n\n- Message queues (RabbitMQ/Kafka/Redis)\n- Scheduled tasks (Cron)\n- Background jobs/workers\n- WebSocket / SSE long connections\n\n**High Frequency Workflow Example (Backend):**\n\n```\nNew endpoint: Define route → Parameter validation → Business logic → Database operation → Return response → Add tests\nNew data table: Design Schema → Create Migration → Write Model → Implement business logic → API integration\nNew scheduled task: Register Cron → Implement task logic → Logging & monitoring → Test & verify\n```\n\n---\n\n### V. Mini Program Specific\n\nLoad when WeChat/Alipay/Douyin mini program project is detected:\n\n#### A. Platform & Framework\n\n- Target platform(s) (WeChat/Alipay/Douyin/multi-platform)\n- Native vs cross-platform framework (Taro/uni-app)\n- Platform API difference handling\n\n#### B. Mini Program Architecture\n\n- Page and component structure\n- Global config (app.json/pages.json)\n- Custom component encapsulation\n- Subpackage strategy\n- Plugin usage\n\n#### C. User System & Auth\n\n- Login flow (wx.login etc.)\n- User info retrieval and storage\n- Session management\n- Integration with backend user system\n\n#### D. Publishing & Review\n\n- Review process and notes\n- Trial vs production release\n- Version management and rollback\n- Mini program code / share config\n\n#### E. Performance Optimization\n\n- Subpackage loading\n- Image lazy loading\n- setData optimization\n- Long list optimization\n- Custom component lazy loading\n\n**High Frequency Workflow Example (Mini Program):**\n\n```\nNew page: Register in pages.json → Create page directory → Implement page logic → Configure route → Submit trial version → Review\nNew component: Create component directory → Implement component → Import & use → Style isolation\nNew API: Wrap request method → Page call → Error handling → Loading state\n```\n\n---\n\n### VI. Mobile App Specific\n\nLoad when React Native / Flutter / SwiftUI / Kotlin project is detected:\n\n#### A. App Architecture\n\n- Framework used (React Native/Flutter/SwiftUI/Compose)\n- Architecture pattern (MVI/MVVM/Clean Architecture)\n- Modularization approach\n- Navigation system\n\n#### B. Native Modules & Bridge\n\n- Native module list and purposes\n- Bridge communication mechanism\n- How to add new native modules\n- Third-party native SDK integration\n\n#### C. State Management & Data Persistence\n\n- State management solution\n- Local storage (AsyncStorage/MMKV/SQLite/CoreData)\n- Offline strategy\n\n#### D. Release & App Store\n\n- Android: signing config (keystore)\n- iOS: certificate and profile management\n- Store submission process (App Store / Google Play)\n- Hot update solution (CodePush/EAS Update)\n- TestFlight / beta distribution\n\n#### E. Mobile-Specific Debugging\n\n- Physical device debugging\n- Performance profiling tools\n- Crash log collection\n- Network packet capture\n\n**High Frequency Workflow Example (Mobile App):**\n\n```\nNew page: Create page/Screen → Register route → Connect state → Connect navigation → Integration test API\nNew native module: Define Bridge interface → Implement Android/iOS native code → JS call wrapper → Test\nRelease flow: Build Android/iOS → Sign → Upload to store → Submit for review → Publish\n```\n\n---\n\n## Project Type Auto-Detection\n\nBefore analyzing, identify the project type via these signals (multi-select):\n\n**Frontend Web signals:**\n- `package.json` has react/vue/svelte/angular/next/nuxt\n- webpack.config/vite.config/tsconfig.json exists\n- public/index.html or index.html exists\n- src has pages/views/components/hooks/store directories\n\n**Desktop Client signals:**\n- `package.json` has electron/tauri\n- electron/ or src-tauri/ directory exists\n- Capacitor config file\n- Main process entry file\n\n**Backend Service signals:**\n- `package.json` has express/nest/fastify/koa (Node)\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- migration/ directory exists\n- Dockerfile / docker-compose.yml\n\n**Mini Program signals:**\n- app.json / pages.json / project.config.json\n- Taro/uni-app config\n- WeChat DevTools config file\n\n**Mobile App signals:**\n- android/ or ios/ directory\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift (RN/Flutter entry)\n- .xcodeproj / .xcworkspace\n\nInform user of detection result at the start of Stage 1. If inaccurate, user can manually specify.\n\n---\n\n## Output Strategy\n\n**Strictly stage-based output. Do NOT output everything at once.**\n\n### Stage 1 — Developer Quick Overview (Default)\n\n- Project type (auto-detected)\n- What the project is\n- How to start\n- Tech stack\n- Most important directories\n- Key standards\n- Environment system\n- Recommended reading order\n- High-risk areas\n\n**Goal: Build a project map within 10 minutes.**\n\n### Stage 2 — Universal Modules Deep Dive\n\nExpand directory navigation, engineering standards, team collaboration, environment & deployment etc. when user asks.\n\n### Stage 3 — Type-Specific Deep Dive\n\nExpand the corresponding type-specific module (Frontend Web / Backend / Client / Mini Program / Mobile) when user asks.\n\n### Stage 4 — Targeted Development Assistance\n\nSupport multi-round questions:\n\n- \"Which module should I reference for adding a new page?\"\n- \"How does the permission system work?\"\n- \"How is IPC communication debugged?\"\n- \"What's the release workflow?\"\n\n## Stage Stopping Conditions\n\n- After current stage output is complete, **⏸ pause and wait for user confirmation or follow-up**\n- At the end of each stage, provide clear next-step prompts, e.g.:\n  - 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.\"*\n  - End of Stage 2: *\"Universal modules expanded. For [project type] specific guide, say 'specific'. Or ask specific dev questions directly.\"*\n  - 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'.\"*\n- For insufficient-evidence content: briefly note and skip, don't force-fill\n- When tokens/context approach limits: output current progress and remaining plan\n\n## Input Validation\n\n### When Information Is Insufficient\n\nIf user only says \"help me set up\" or similar vague requests, don't guess or blindly execute:\n1. At minimum need one of: **project path / Git repo URL / currently open working directory**\n2. Ask: \"Which project would you like to analyze? Please provide the project path or repo URL.\"\n3. If user provides a path but project is empty or inaccessible: clearly inform and ask for confirmation\n\n### Handling Contradictory Requests\n\nWhen user makes conflicting goals (e.g., \"give me a complete architecture report\" but also \"keep it concise\"):\n1. Point out the contradiction: \"Complete architecture report and concise output conflict\"\n2. Suggest compromise: prioritize Stage 1 (quick overview), then go deeper as needed\n3. Let user choose priority\n\n### When Project Cannot Be Analyzed\n\nClearly inform user and stop analysis in these cases; do not force output:\n- Specified path doesn't exist or no access permissions\n- Project directory is empty\n- Cannot identify project type (no known signals)\n- Key config files (e.g., package.json) are corrupted or unreadable\n\n---\n\n## Important Constraints\n\n### Don't:\n- Generate lengthy unfocused reports\n- Explain basic programming knowledge\n- Mechanically list all files\n- Output meaningless directory trees\n- Discuss component systems for backend projects, ORM for frontend projects\n- Ignore development workflows and team collaboration\n\n### Must:\n- Core focus on development efficiency\n- Tailor content by project type, only load relevant modules\n- Emphasize engineering practices and actual development workflows\n- Emphasize \"how to actually start developing\"\n- Support multi-round progressive exploration\n\n## Execution Tool Guide\n\nEvery analysis step should be backed by concrete tool execution, not fabricated output:\n\n### Project Type Detection — Actions\n1. `read {project}/package.json` → extract dependencies, match frontend/client/Node backend signals\n2. `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\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → desktop client signals\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → mobile signals\n5. Multiple signals → treat as mixed project, load all matching modules\n\n### Stage 1 Quick Overview — Actions\n1. `read {project}/package.json` or `Cargo.toml` or `go.mod` → tech stack\n2. `exec ls {project}/` → directory structure overview\n3. `read {project}/README.md` → project purpose (if exists)\n4. `read {project}/.env.example` → environment variables (if exists)\n\n### Stage 2 Universal Modules — Actions\n1. `exec find {project}/src -type d -maxdepth 2` → directory structure\n2. `read {project}/src/index.*` or `main.*` → entry file\n3. `exec find {project} -name \"Dockerfile\" -o -name \"docker-compose*\" | head -3` → deployment\n\n### Stage 3 Type-Specific — Select by Type\n**Frontend Web:** `find` for router/store/api files\n**Backend:** `find` for migration/middleware/controller files\n**Desktop Client:** `read` main process entry + `find` preload/bridge\n\n### Large Project Strategy\nWhen `exec find {project} -type f | wc -l` exceeds 200: build index first, only read P0 files, deep-dive core chain only.\n\n### Output Format\nEach Stage: `# [Project Name] — Stage N: [Title]` with structured headings + `## ⏸ Next Steps` at end.\n- Emphasize \"how to actually start developing\"\n- Support multi-round progressive exploration\n\n## Ideal Outcome\n\nAfter using this skill, an experienced developer should be able to:\n\n- Successfully start the project\n- Understand project structure and type-specific architecture\n- Find core modules\n- Understand engineering standards\n- Safely develop features\n- Correctly use type-specific capabilities (components/API/IPC/native modules etc.)\n- Complete QA submission and release\n- Know where to dive deeper\n\nUltimate achievement: **\"I'm ready to start participating in project development.\"**\n\nFile v2.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn76af6ccjftr7hsds21j60xnn82q1qd\",\n  \"slug\": \"project-onboarding\",\n  \"version\": \"2.0.0\",\n  \"publishedAt\": 1779108474003\n}\n\nFile v2.0.0:skill-card.md\n\n## Description:\n\nHelps experienced developers quickly onboard to unfamiliar software projects by identifying project type and producing staged, evidence-based development guidance.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[z-zihan](https://clawhub.ai/user/z-zihan)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to get a fast, practical onboarding map for an unfamiliar repository, including project type, startup flow, directory navigation, engineering standards, risk areas, and type-specific development paths.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Project paths may be inserted into shell commands during repository inspection.\n\nMitigation: Constrain analysis to approved workspace paths, use safe argument passing, and require user confirmation before commands that inspect or execute against a supplied path.\n\nRisk: Repository URLs may be supplied without a defined safe fetch workflow.\n\nMitigation: Only fetch trusted repositories in a sandboxed workspace, confirm the URL with the user, and review files before running any project commands.\n\n## Reference(s):\n\n- [Project Onboarding ClawHub listing](https://clawhub.ai/z-zihan/skills/project-onboarding)\n- [Homepage from ClawHub metadata](https://github.com/z-Zihan/awesome-skills)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, guidance]\n\n**Output Format:** [Staged Markdown onboarding guidance with command examples and repository findings]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Adapts output language to the user and pauses between staged analysis passes.]\n\n## Skill Version(s):\n\n2.0.0 (source: frontmatter and ClawHub release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.3.0: 2 files, 16003 bytes\n\nFiles: SKILL.md (39562b), _meta.json (137b)\n\nFile v0.3.0:SKILL.md\n\n---\nname: project-onboarding\nversion: \"1.2.0\"\nhomepage: https://github.com/z-Zihan/awesome-skills\ndescription: >\n  帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、\n  客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出\n  项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。\n  触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门, onboarding,\n  如何开发, 怎么启动项目, 项目怎么跑, 开发流程, onboarding guide,\n  how to onboard, project handover, developer quick start.\n  NOT for: generating long architecture reports, code analysis without dev context,\n  beginner programming tutorials, onboarding for interns.\n---\n\n# project-onboarding — 项目接手指南\n\n## 语言规则\n\n**检测用户使用的语言，全程使用同一语言输出。** 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（React、Electron、IPC 等）保留原文即可。\n\n---\n\n# 中文版\n\n帮助有经验的开发者快速理解并接手一个陌生项目，尽快具备实际开发能力。\n\n## 支持的项目类型\n\n按优先级排序：\n\n| 类型 | 识别信号 | 专项模块 |\n|---|---|---|\n| **前端 Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | 组件体系、路由、状态管理、CSS 方案、API 集成、浏览器兼容 |\n| **后端服务** | Express/Nest/Django/Spring/Gin, ORM/migration | 数据库 Schema、ORM、中间件链、API 设计、认证鉴权、缓存与队列 |\n| **客户端** | Electron/Tauri/Capacitor, 主进程/渲染进程 | 主进程架构、渲染进程、IPC 通信、原生能力、签名与分发、自动更新 |\n| **小程序** | 微信/支付宝/抖音小程序, app.json/pages.json | 平台适配、分包策略、审核流程、原生能力调用、用户体系 |\n| **移动端** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | 原生模块 Bridge、热更新、应用签名、应用商店发布、权限管理 |\n\n**多类型混合项目**（如 Electron + Vue、Tauri + React）：同时加载对应专项模块，按优先级排序。\n\n> **扩展指南**：新增项目类型时，需要同步更新三个位置：\n> 1. 上方「支持的项目类型」表格\n> 2. 「项目类型自动识别」信号列表\n> 3. 对应的专项模块章节（新增或复用）\n> 建议保持模块命名和排序的一致性。\n\n## 这个 Skill 不是\n\n- 面向编程新手\n- 面向实习生教学\n- 面向基础知识解释\n- 面向纯代码分析\n\n## 核心目标\n\n让专业开发者在最短时间内完成：\n\n- 项目理解\n- 工程结构理解\n- 开发流程理解\n- 团队规范理解\n- 环境体系理解\n- 项目类型特有的核心能力理解\n- 发布流程理解\n- 调试与开发能力建立\n\n最终达到：\n\n**\"开发者已经可以开始安全地开发功能并参与协作。\"**\n\n## 语言策略\n\n- 默认输出中文，同时提供英文版本\n- 中文优先\n\n## 核心原则\n\n### 1. 以\"快速进入开发状态\"为最高优先级\n\n优先帮助开发者理解：\n\n- 项目如何运行\n- 功能如何开发\n- 项目类型特有的核心机制\n- 目录如何组织\n- 环境如何切换\n- 如何调试\n- 如何发版\n- 如何避免踩坑\n\n**而不是：**\n\n- 生成超长架构分析报告\n- 输出无意义目录树\n- 罗列所有源码文件\n\n### 2. 避免一次性信息轰炸\n\n- 分阶段输出\n- 优先级排序\n- 保持简洁\n- 支持多轮渐进式探索\n\n### 3. 模拟\"资深工程师带新人\"\n\n你的角色不是代码分析器，而是团队里的资深工程师在带一个有经验的新同事。\n\n重点关注：\n\n- 实际开发流程\n- 隐式规范\n- 高风险区域\n- 常见坑\n- 推荐参考模块\n\n### 4. 证据优先，不假装理解\n\n- 所有结论基于仓库真实证据\n- 仓库中没有的规范或机制，不要编造\n- 区分：已确认事实 / 合理推断 / 证据不足\n\n### 5. 按项目类型裁剪内容\n\n- 只分析与当前项目类型相关的模块\n- 不要给后端项目讲组件体系，不要给前端项目讲 ORM\n- 混合项目按优先级排序专项模块\n\n## 执行工具指引\n\n本 Skill 的每个分析步骤都应配合具体工具执行，而非凭空\"编\"输出：\n\n### 项目类型识别 — 执行动作\n\n1. `read {project}/package.json` → 提取 dependencies 和 devDependencies，匹配前端/客户端/Node 后端信号\n2. `exec find {project} -maxdepth 2 -name \"*.config.*\" -o -name \"go.mod\" -o -name \"Cargo.toml\" -o -name \"pom.xml\" -o -name \"app.json\"` → 识别后端/小程序/移动端信号\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → 客户端信号\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → 移动端信号\n5. 多信号命中时 → 按混合项目处理，所有匹配的专项模块均加载\n\n### Stage 1 快速总览 — 执行动作\n\n1. `read {project}/package.json` 或 `Cargo.toml` 或 `go.mod` → 技术栈\n2. `exec ls {project}/` → 目录结构概览\n3. `read {project}/README.md` → 项目用途（如存在）\n4. `read {project}/.env.example` → 环境变量（如存在）\n5. `exec find {project} -name \"*.config.*\" -maxdepth 1` → 构建配置\n\n### Stage 2 通用模块深入 — 执行动作\n\n1. `exec find {project}/src -type d -maxdepth 2` → 目录结构\n2. `read {project}/src/index.*` 或 `main.*` → 入口文件\n3. `exec find {project} -name \".eslintrc*\" -o -name \".prettierrc*\" -o -name \"tsconfig.json\" -maxdepth 1` → 工程规范\n4. `exec find {project} -name \"Dockerfile\" -o -name \"docker-compose*\" -o -name \".github\" -type d -maxdepth 2` → 部署配置\n5. `exec find {project} -name \"*.test.*\" -o -name \"*.spec.*\" | head -5` → 测试结构\n\n### Stage 3 专项模块 — 按类型选择执行\n\n**前端 Web：**\n- `exec find {project}/src -name \"router*\" -o -name \"routes*\" | head -5` → 路由\n- `exec find {project}/src -name \"store*\" -o -name \"*reducer*\" | head -5` → 状态管理\n- `exec find {project}/src -name \"request*\" -o -name \"api*\" -o -name \"http*\" | head -5` → API 层\n\n**后端：**\n- `exec find {project} -path \"*/migration*\" -o -path \"*/schema*\" | head -5` → 数据库\n- `exec find {project} -path \"*/middleware*\" -o -path \"*/guard*\" | head -5` → 中间件\n- `exec find {project} -path \"*/route*\" -o -name \"controller*\" | head -5` → 路由/控制器\n\n**客户端：**\n- `read {project}/electron/main.*` 或 `{project}/src-tauri/src/main.rs` → 主进程\n- `exec find {project} -name \"preload*\" -o -name \"bridge*\" | head -5` → IPC\n\n### 大项目策略\n\n当 `exec find {project} -type f | wc -l` 超过 200 时：\n1. 先用 `find` + `ls` 建立文件索引，不全量读取\n2. 只读 P0 文件（package.json、入口、README）\n3. 核心链路深入（入口 → 中间件 → 服务 → 数据），其余跳过\n\n### 输出格式定义\n\n每个 Stage 的输出应使用以下 Markdown 结构：\n\n```markdown\n# [项目名] — Stage N: [阶段名]\n\n## 项目类型\n[类型]（识别信号：[列出检测到的信号]）\n\n## [各分析维度]\n...\n\n## ⏸ 下一步\n[提示用户可以深入的方向]\n```\n\n---\n\n## 分析模块\n\n### 一、通用模块（所有项目类型）\n\n以下模块适用于任何项目类型，按分析顺序排列：\n\n#### 1. 项目概览\n\n- 项目用途与业务领域\n- 项目类型（自动识别）\n- 核心能力与主要模块\n- 技术栈\n- 系统架构\n- 外部依赖\n- 核心链路\n\n#### 2. 开发快速启动\n\n- 如何安装依赖\n- 如何启动项目\n- 本地开发命令\n- 如何切换环境\n- 必需环境变量\n- 如何本地调试\n- 如何运行测试\n- 如何构建\n\n#### 3. 项目目录导航\n\n必须说明：\n\n- 为什么这样组织\n- 哪些目录最重要\n- 哪些目录最常修改\n- 哪些目录风险最高\n- 哪些属于基础设施\n\n#### 4. 工程规范\n\n- 命名规范\n- 目录规范\n- 代码组织方式\n- commit 规范\n- lint/format 规范\n- 测试规范\n- 错误处理规范\n- 隐式规范（README 没写但团队默认遵守的规则）\n\n#### 5. 环境与部署体系\n\n- 环境列表（local/dev/test/staging/production 等）\n- 环境如何切换\n- 配置如何管理\n- CI/CD 流程\n- 如何发版 / 如何提测 / 如何回滚\n\n#### 6. 团队协作流程\n\n- 分支策略\n- PR / Code Review 流程\n- QA / UAT 流程\n\n#### 7. 高频开发路径\n\n总结团队最常见的开发套路（按项目类型定制示例）\n\n#### 8. 推荐参考模块\n\n- 最规范的模块\n- 最推荐模仿的实现\n- 入口文件\n\n#### 9. 危险区域识别\n\n- 哪些区域改动风险高\n- 哪些代码耦合严重\n- 哪些模块容易引发线上问题\n\n---\n\n### 二、前端 Web 专项\n\n当识别到前端 Web 项目时加载：\n\n#### A. 组件体系与 UI 基础设施\n\n- 内部组件库\n- 第三方组件库\n- layout 系统 / icon 系统 / theme 系统\n- 通用业务组件\n- 哪些组件应优先复用\n- 新组件放哪里\n\n#### B. 路由系统\n\n- 路由如何组织\n- 路由守卫与权限\n- 动态路由 / 懒加载\n- 新增页面的路由配置方式\n\n#### C. 状态管理\n\n- 使用的方案（Redux/Pinia/Zustand/Jotai 等）\n- 全局状态 vs 局部状态的划分策略\n- store 如何组织\n- 新功能应该用全局还是局部状态\n\n#### D. CSS 与样式方案\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- 设计系统 / token 体系\n- 样式约定\n\n#### E. API 集成\n\n- 请求层如何封装\n- token/auth 如何工作\n- 错误拦截机制\n- mock 策略\n- 新接口应该如何接入\n\n**高频开发路径示例（前端 Web）：**\n\n```\n新增页面: 新增 route → 新增 page → 新增 API → 接入 store → 接入权限 → 配置菜单 → 提测 → 发版\n新增接口: 定义 API → request 封装 → 类型定义 → hooks/store 接入 → 页面消费 → 错误处理\n新增组件: 放入 shared/components → 补充 story/test → theme 适配 → 权限处理\n```\n\n---\n\n### 三、客户端专项\n\n当识别到 Electron / Tauri / Capacitor 等客户端项目时加载：\n\n#### A. 进程架构\n\n**Electron 项目：**\n- 主进程（Main Process）职责与入口\n- 渲染进程（Renderer Process）架构\n- 预加载脚本（Preload）与 contextBridge\n- 多窗口管理\n- 进程间通信（IPC）设计\n\n**Tauri 项目：**\n- 前端层（WebView）\n- Rust 后端层（Tauri Commands）\n- IPC 通信方式（invoke/listen）\n- 插件系统\n- 安全策略（allowlist/CSP）\n\n#### B. 原生能力集成\n\n- 文件系统操作（读写、对话框）\n- 系统托盘与通知\n- 剪贴板 / 屏幕截图 / 全局快捷键\n- 网络状态监听\n- 系统信息获取\n- 原生模块（Node Addons / Rust FFI）\n\n#### C. 签名与分发\n\n- 开发者证书与签名配置\n- macOS: codesign + notary / Windows: 签名证书\n- 自动更新机制（autoUpdater）\n- 更新服务器配置\n- 各平台分发渠道（App Store / Microsoft Store / 自建）\n\n#### D. 构建与打包\n\n- 构建命令与配置\n- 多平台构建（macOS arm64/x64 / Windows x64）\n- 安装包格式（DMG/EXE/MSI/AppImage）\n- 构建时间优化\n- CI/CD 中的构建流程\n\n#### E. 客户端特有调试\n\n- 主进程调试\n- 渲染进程调试（DevTools）\n- IPC 通信调试\n- 原生能力调试\n- 性能分析（CPU/内存/启动速度）\n\n**高频开发路径示例（客户端）：**\n\n```\n新增功能: 前端开发 → IPC 通信定义 → 主进程/Rust 命令实现 → 联调 → 测试 → 构建\n新增原生能力: 调研 API → 实现 IPC 命令 → 前端调用封装 → 错误处理 → 多平台测试\n发版流程: 构建多平台 → 签名 → 公证 → 上传更新服务器 → 灰度 → 全量\n```\n\n---\n\n### 四、后端服务专项\n\n当识别到 Express/Nest/Django/Spring/Gin 等后端服务项目时加载：\n\n#### A. 数据库与存储\n\n- 使用的数据库（MySQL/PostgreSQL/MongoDB/Redis 等）\n- ORM/Query Builder（Prisma/TypeORM/Sequelize/GORM 等）\n- Migration 策略\n- 数据库 Schema 设计思路\n- 缓存策略（Redis/Memcached）\n- 文件存储（OSS/S3/本地）\n\n#### B. 中间件与请求处理\n\n- 中间件链与执行顺序\n- 认证与鉴权（JWT/Session/OAuth）\n- 请求验证与参数校验\n- 日志策略\n- 限流与熔断\n\n#### C. API 设计\n\n- RESTful / GraphQL / gRPC / tRPC\n- API 版本管理\n- 错误码体系\n- 文档生成（Swagger/OpenAPI）\n- 请求/响应格式约定\n\n#### D. 异步与任务处理\n\n- 消息队列（RabbitMQ/Kafka/Redis）\n- 定时任务（Cron）\n- 后台任务/Worker\n- WebSocket / SSE 长连接\n\n**高频开发路径示例（后端）：**\n\n```\n新增接口: 定义路由 → 参数校验 → 业务逻辑 → 数据库操作 → 返回响应 → 补充测试\n新增数据表: 设计 Schema → 创建 Migration → 编写 Model → 实现业务逻辑 → API 接入\n新增定时任务: 注册 Cron → 实现任务逻辑 → 日志与监控 → 测试验证\n```\n\n---\n\n### 五、小程序专项\n\n当识别到微信/支付宝/抖音小程序项目时加载：\n\n#### A. 平台与框架\n\n- 目标平台（微信/支付宝/抖音/多端）\n- 使用原生还是跨端框架（Taro/uni-app）\n- 平台 API 差异处理\n\n#### B. 小程序架构\n\n- 页面与组件结构\n- 全局配置（app.json/pages.json）\n- 自定义组件封装\n- 分包策略\n- 插件使用\n\n#### C. 用户体系与登录\n\n- 登录流程（wx.login 等）\n- 用户信息获取与存储\n- Session 管理\n- 与后端用户系统的对接\n\n#### D. 发布与审核\n\n- 审核流程与注意事项\n- 体验版 / 正式版 发布\n- 版本管理与回滚\n- 小程序码 / 分享配置\n\n#### E. 性能优化\n\n- 分包加载\n- 图片懒加载\n- setData 优化\n- 长列表优化\n- 自定义组件懒加载\n\n**高频开发路径示例（小程序）：**\n\n```\n新增页面: pages.json 注册 → 创建页面目录 → 实现页面逻辑 → 配置路由 → 提交体验版 → 审核\n新增组件: 创建组件目录 → 实现 component → 引入使用 → 样式隔离\n新增接口: 封装请求方法 → 页面调用 → 错误处理 → 加载态\n```\n\n---\n\n### 六、移动端专项\n\n当识别到 React Native / Flutter / SwiftUI / Kotlin 等移动端项目时加载：\n\n#### A. 应用架构\n\n- 使用的框架（React Native/Flutter/SwiftUI/Compose）\n- 架构模式（MVI/MVVM/Clean Architecture）\n- 模块化方案\n- 导航系统\n\n#### B. 原生模块与 Bridge\n\n- 原生模块列表与用途\n- Bridge 通信机制\n- 如何新增原生模块\n- 第三方原生 SDK 集成方式\n\n#### C. 状态管理与数据持久化\n\n- 状态管理方案\n- 本地存储（AsyncStorage/MMKV/SQLite/CoreData）\n- 离线策略\n\n#### D. 发布与应用商店\n\n- Android: 签名配置（keystore）\n- iOS: 证书与 Profile 管理\n- 应用商店提交流程（App Store / Google Play）\n- 热更新方案（CodePush/EAS Update）\n- TestFlight / 内测分发\n\n#### E. 移动端特有调试\n\n- 真机调试流程\n- 性能分析工具\n- 崩溃日志收集\n- 网络抓包\n\n**高频开发路径示例（移动端）：**\n\n```\n新增页面: 创建页面/Screen → 注册路由 → 接入状态 → 接入导航 → 联调接口\n新增原生模块: 定义 Bridge 接口 → 实现 Android/iOS 原生代码 → JS 调用封装 → 测试\n发版流程: 构建 Android/iOS → 签名 → 上传商店 → 提交审核 → 发布\n```\n\n---\n\n## 项目类型自动识别\n\n分析项目前，先通过以下信号识别项目类型（可多选）：\n\n**前端 Web 信号：**\n- `package.json` 中有 react/vue/svelte/angular/next/nuxt\n- 存在 webpack.config/vite.config/tsconfig.json\n- 存在 public/index.html 或 index.html\n- src 下有 pages/views/components/hooks/store 目录\n\n**客户端信号：**\n- `package.json` 中有 electron/tauri\n- 存在 electron/ 目录或 src-tauri/ 目录\n- Capacitor 配置文件\n- main process 入口文件\n\n**后端服务信号：**\n- `package.json` 中有 express/nest/fastify/koa（Node）\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- 存在 migration/ 目录\n- Dockerfile / docker-compose.yml\n\n**小程序信号：**\n- app.json / pages.json / project.config.json\n- Taro/uni-app 配置\n- 微信开发者工具配置文件\n\n**移动端信号：**\n- android/ 或 ios/ 目录\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift（RN/Flutter 入口）\n- .xcodeproj / .xcworkspace\n\n识别结果在 Stage 1 开头明确告知用户，如果识别不准确，用户可以手动指定。\n\n---\n\n## 输出策略\n\n**严格分阶段输出，不要一次输出全部内容。**\n\n### Stage 1 — 开发者快速总览（默认）\n\n- 项目类型（自动识别结果）\n- 项目是什么\n- 如何启动\n- 技术栈\n- 最重要目录\n- 关键规范\n- 环境体系\n- 推荐阅读顺序\n- 高风险区域\n\n**目标：让开发者 10 分钟内建立项目地图。**\n\n### Stage 2 — 通用模块深入\n\n用户追问时展开目录导航、工程规范、团队协作、环境部署等通用模块。\n\n### Stage 3 — 项目类型专项深入\n\n用户追问时展开对应项目类型的专项模块（前端 Web / 后端 / 客户端 / 小程序 / 移动端）。\n\n### Stage 4 — 定向开发辅助\n\n支持多轮追问：\n\n- \"新增页面应该参考哪个模块？\"\n- \"权限系统怎么做的？\"\n- \"IPC 通信怎么调的？\"\n- \"发版流程是什么？\"\n\n## 每个阶段的停止条件\n\n- 当前阶段内容输出完毕后，**⏸ 暂停等待用户确认或追问**\n- 每个阶段结束时，给出明确的下一步提示，例如：\n  - Stage 1 结束：*\"以上是项目快速总览。如需深入了解工程规范、目录导航等，请告诉我。如需查看[项目类型]专项指南，请说「专项」。如要开始某个具体开发任务，直接说即可。\"*\n  - Stage 2 结束：*\"通用模块已展开。如需查看[项目类型]专项指南，请说「专项」。或直接问具体的开发问题。\"*\n  - Stage 3 结束：*\"专项指南已展开。可以直接问具体开发问题，如「新增页面怎么做」「发版流程是什么」等。\"*\n- 证据不足的内容：简单说明后跳过，不要强行填充\n- Token/上下文接近上限时：输出当前进度和剩余计划\n\n## 输入验证\n\n### 信息不足时\n\n如果用户只说了\"帮我搞一下\"或类似模糊请求，不要猜测或胡乱执行：\n1. 至少需要以下信息之一：**项目路径 / Git 仓库地址 / 已打开的工作目录**\n2. 询问：\"请问要分析哪个项目？请提供项目路径或仓库地址。\"\n3. 如果用户提供了路径但项目为空或无法访问：明确告知并请求确认\n\n### 矛盾请求处理\n\n当用户同时提出冲突目标时（如\"给我完整架构报告\"但又要求\"保持简洁\"）：\n1. 指出矛盾：\"完整架构报告与简洁输出存在矛盾\"\n2. 建议折中方案：优先 Stage 1（快速总览），再按需深入\n3. 让用户选择优先级\n\n### 项目无法分析时\n\n以下情况应明确告知用户并停止分析，不要强行输出：\n- 指定路径不存在或无访问权限\n- 项目目录为空\n- 无法识别项目类型（无任何已知信号）\n- 关键配置文件（如 package.json）损坏或不可读\n\n---\n\n## 重要限制\n\n### 不要：\n- 生成超长无重点报告\n- 解释基础编程知识\n- 机械列举所有文件\n- 输出没有意义的目录树\n- 给后端项目讲组件体系，给前端项目讲 ORM\n- 忽略开发流程和团队协作\n\n### 必须：\n- 以开发效率为核心\n- 按项目类型裁剪内容，只加载相关模块\n- 强调工程实践和实际开发流程\n- 强调\"如何真正开始开发\"\n- 支持多轮渐进式探索\n\n## 理想结果\n\n使用这个 skill 后，一个有经验的开发者应该能够：\n\n- 成功启动项目\n- 理解项目结构与项目类型特有架构\n- 找到核心模块\n- 理解工程规范\n- 能够安全开发功能\n- 能够正确使用项目类型特有能力（组件/API/IPC/原生模块等）\n- 能够完成提测与发版\n- 知道应该继续深入哪里\n\n最终达到：**\"我已经可以开始参与项目开发了。\"**\n\n---\n---\n\n# English Version\n\nHelp experienced developers quickly understand and onboard onto an unfamiliar project, achieving actual development capability as fast as possible.\n\n## Supported Project Types\n\nPriority order:\n\n| Type | Detection Signals | Specific Modules |\n|---|---|---|\n| **Frontend Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | Component system, routing, state management, CSS approach, API integration, browser compatibility |\n| **Backend Service** | Express/Nest/Django/Spring/Gin, ORM/migration | Database Schema, ORM, middleware chain, API design, auth, caching & queues |\n| **Desktop Client** | Electron/Tauri/Capacitor, main/renderer process | Main process architecture, renderer process, IPC, native capabilities, signing & distribution, auto-update |\n| **Mini Program** | WeChat/Alipay/Douyin mini program, app.json/pages.json | Platform adaptation, subpackage strategy, review process, native API calls, user system |\n| **Mobile App** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | Native module Bridge, hot update, app signing, app store publishing, permission management |\n\n**Mixed-type projects** (e.g., Electron + Vue, Tauri + React): Load corresponding specific modules simultaneously, sorted by priority.\n\n> **Extension guide**: When adding new project types, update three places in sync:\n> 1. The \"Supported Project Types\" table above\n> 2. The \"Project Type Auto-Detection\" signal list\n> 3. The corresponding specific module section (new or reuse)\n> Maintain consistent module naming and ordering.\n\n## This Skill Is NOT\n\n- For programming beginners\n- For intern training\n- For explaining basic programming concepts\n- For pure code analysis\n\n## Core Objective\n\nEnable a professional developer to achieve the following in minimum time:\n\n- Project understanding\n- Engineering structure understanding\n- Development workflow understanding\n- Team standards understanding\n- Environment system understanding\n- Type-specific core capabilities understanding\n- Release workflow understanding\n- Debug and development capability\n\nUltimate goal:\n\n**\"The developer is ready to safely develop features and collaborate.\"**\n\n## Language Strategy\n\n- Default to user's language, also provide the other language version\n- Follow user's language preference\n\n## Core Principles\n\n### 1. \"Fast to Development-Ready\" is the Highest Priority\n\nPrioritize helping developers understand:\n\n- How the project runs\n- How to develop features\n- Type-specific core mechanisms\n- How directories are organized\n- How to switch environments\n- How to debug\n- How to release\n- How to avoid common pitfalls\n\n**Instead of:**\n\n- Generating lengthy architecture reports\n- Outputting meaningless directory trees\n- Listing all source files\n\n### 2. Avoid Information Overload\n\n- Output in stages\n- Sort by priority\n- Keep concise\n- Support multi-round progressive exploration\n\n### 3. Simulate \"Senior Engineer Onboarding a New Colleague\"\n\nYour role is not a code analyzer — it's a senior engineer helping an experienced new colleague onboard.\n\nFocus on:\n\n- Actual development workflows\n- Implicit team conventions\n- High-risk areas\n- Common pitfalls\n- Recommended reference modules\n\n### 4. Evidence First, Don't Fake Understanding\n\n- All conclusions based on real repo evidence\n- Don't fabricate standards or mechanisms not in the repo\n- Distinguish: confirmed facts / reasonable inference / insufficient evidence\n\n### 5. Tailor Content by Project Type\n\n- Only analyze modules relevant to the project type\n- Don't discuss component systems for backend projects, don't discuss ORM for frontend projects\n- Mixed projects sort specific modules by priority\n\n---\n\n## Analysis Modules\n\n### I. Universal Modules (All Project Types)\n\nThese modules apply to any project type, in analysis order:\n\n#### 1. Project Overview\n\n- Project purpose and business domain\n- Project type (auto-detected)\n- Core capabilities and main modules\n- Tech stack\n- System architecture\n- External dependencies\n- Core chain\n\n#### 2. Developer Quick Start\n\n- How to install dependencies\n- How to start the project\n- Local dev commands\n- How to switch environments\n- Required environment variables\n- How to debug locally\n- How to run tests\n- How to build\n\n#### 3. Repository Navigation\n\nMust explain:\n\n- Why organized this way\n- Which directories are most important\n- Which are most frequently modified\n- Which are highest risk\n- Which are infrastructure\n\n#### 4. Engineering Standards\n\n- Naming conventions\n- Directory conventions\n- Code organization style\n- Commit conventions\n- Linting/formatting rules\n- Testing conventions\n- Error handling patterns\n- Implicit standards (unwritten but team-default rules)\n\n#### 5. Environment & Deployment\n\n- Environment list (local/dev/test/staging/production etc.)\n- How to switch environments\n- How configs are managed\n- CI/CD pipeline\n- How to release / submit for QA / how to rollback\n\n#### 6. Team Workflow\n\n- Branching strategy\n- PR / Code Review workflow\n- QA / UAT workflow\n\n#### 7. High Frequency Development Workflow\n\nSummarize most common development patterns (examples tailored by project type)\n\n#### 8. Recommended References\n\n- Most standard module\n- Best implementation to imitate\n- Entry files\n\n#### 9. Risk Areas\n\n- Which areas are high-risk\n- Which code is heavily coupled\n- Which modules easily cause production issues\n\n---\n\n### II. Frontend Web Specific\n\nLoad when Frontend Web project is detected:\n\n#### A. Component System & UI Infrastructure\n\n- Internal component library\n- Third-party components\n- Layout system / icon system / theme system\n- Common business components\n- Which components to reuse\n- Where to put new components\n\n#### B. Routing System\n\n- How routes are organized\n- Route guards and permissions\n- Dynamic routes / lazy loading\n- How to add route for a new page\n\n#### C. State Management\n\n- Solution used (Redux/Pinia/Zustand/Jotai etc.)\n- Global vs local state strategy\n- How stores are organized\n- When to use global vs local\n\n#### D. Styling Approach\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- Design system / token system\n- Styling conventions\n\n#### E. API Integration\n\n- How request layer is encapsulated\n- How token/auth works\n- Error interception\n- Mock strategy\n- How to integrate new APIs\n\n**High Frequency Workflow Example (Frontend Web):**\n\n```\nNew page: Add route → Add page → Add API → Connect store → Add permissions → Configure menu → Submit for QA → Release\nNew API: Define API → Request wrapper → Type definitions → hooks/store integration → Page consumption → Error handling\nNew component: Place in shared/components → Add story/test → Theme adaptation → Permission handling\n```\n\n---\n\n### III. Desktop Client Specific\n\nLoad when Electron / Tauri / Capacitor project is detected:\n\n#### A. Process Architecture\n\n**Electron projects:**\n- Main process responsibilities and entry\n- Renderer process architecture\n- Preload scripts and contextBridge\n- Multi-window management\n- IPC design pattern\n\n**Tauri projects:**\n- Frontend layer (WebView)\n- Rust backend layer (Tauri Commands)\n- IPC communication (invoke/listen)\n- Plugin system\n- Security policies (allowlist/CSP)\n\n#### B. Native Capability Integration\n\n- File system operations (read/write, dialogs)\n- System tray and notifications\n- Clipboard / screenshot / global shortcuts\n- Network status monitoring\n- System info access\n- Native modules (Node Addons / Rust FFI)\n\n#### C. Signing & Distribution\n\n- Developer certificates and signing config\n- macOS: codesign + notary / Windows: signing certificate\n- Auto-update mechanism (autoUpdater)\n- Update server config\n- Distribution channels per platform (App Store / Microsoft Store / self-hosted)\n\n#### D. Build & Packaging\n\n- Build commands and config\n- Multi-platform builds (macOS arm64/x64 / Windows x64)\n- Package formats (DMG/EXE/MSI/AppImage)\n- Build time optimization\n- Build flow in CI/CD\n\n#### E. Client-Specific Debugging\n\n- Main process debugging\n- Renderer process debugging (DevTools)\n- IPC debugging\n- Native capability debugging\n- Performance profiling (CPU/memory/startup speed)\n\n**High Frequency Workflow Example (Desktop Client):**\n\n```\nNew feature: Frontend dev → Define IPC → Implement main process/Rust command → Integration test → Test → Build\nNew native capability: Research API → Implement IPC command → Frontend call wrapper → Error handling → Cross-platform test\nRelease flow: Build multi-platform → Sign → Notarize → Upload to update server → Canary → Full rollout\n```\n\n---\n\n### IV. Backend Service Specific\n\nLoad when Express/Nest/Django/Spring/Gin project is detected:\n\n#### A. Database & Storage\n\n- Database used (MySQL/PostgreSQL/MongoDB/Redis etc.)\n- ORM/Query Builder (Prisma/TypeORM/Sequelize/GORM etc.)\n- Migration strategy\n- Schema design approach\n- Caching strategy (Redis/Memcached)\n- File storage (OSS/S3/local)\n\n#### B. Middleware & Request Handling\n\n- Middleware chain and execution order\n- Authentication and authorization (JWT/Session/OAuth)\n- Request validation\n- Logging strategy\n- Rate limiting and circuit breaking\n\n#### C. API Design\n\n- RESTful / GraphQL / gRPC / tRPC\n- API versioning\n- Error code system\n- API documentation (Swagger/OpenAPI)\n- Request/response format conventions\n\n#### D. Async & Task Processing\n\n- Message queues (RabbitMQ/Kafka/Redis)\n- Scheduled tasks (Cron)\n- Background jobs/workers\n- WebSocket / SSE long connections\n\n**High Frequency Workflow Example (Backend):**\n\n```\nNew endpoint: Define route → Parameter validation → Business logic → Database operation → Return response → Add tests\nNew data table: Design Schema → Create Migration → Write Model → Implement business logic → API integration\nNew scheduled task: Register Cron → Implement task logic → Logging & monitoring → Test & verify\n```\n\n---\n\n### V. Mini Program Specific\n\nLoad when WeChat/Alipay/Douyin mini program project is detected:\n\n#### A. Platform & Framework\n\n- Target platform(s) (WeChat/Alipay/Douyin/multi-platform)\n- Native vs cross-platform framework (Taro/uni-app)\n- Platform API difference handling\n\n#### B. Mini Program Architecture\n\n- Page and component structure\n- Global config (app.json/pages.json)\n- Custom component encapsulation\n- Subpackage strategy\n- Plugin usage\n\n#### C. User System & Auth\n\n- Login flow (wx.login etc.)\n- User info retrieval and storage\n- Session management\n- Integration with backend user system\n\n#### D. Publishing & Review\n\n- Review process and notes\n- Trial vs production release\n- Version management and rollback\n- Mini program code / share config\n\n#### E. Performance Optimization\n\n- Subpackage loading\n- Image lazy loading\n- setData optimization\n- Long list optimization\n- Custom component lazy loading\n\n**High Frequency Workflow Example (Mini Program):**\n\n```\nNew page: Register in pages.json → Create page directory → Implement page logic → Configure route → Submit trial version → Review\nNew component: Create component directory → Implement component → Import & use → Style isolation\nNew API: Wrap request method → Page call → Error handling → Loading state\n```\n\n---\n\n### VI. Mobile App Specific\n\nLoad when React Native / Flutter / SwiftUI / Kotlin project is detected:\n\n#### A. App Architecture\n\n- Framework used (React Native/Flutter/SwiftUI/Compose)\n- Architecture pattern (MVI/MVVM/Clean Architecture)\n- Modularization approach\n- Navigation system\n\n#### B. Native Modules & Bridge\n\n- Native module list and purposes\n- Bridge communication mechanism\n- How to add new native modules\n- Third-party native SDK integration\n\n#### C. State Management & Data Persistence\n\n- State management solution\n- Local storage (AsyncStorage/MMKV/SQLite/CoreData)\n- Offline strategy\n\n#### D. Release & App Store\n\n- Android: signing config (keystore)\n- iOS: certificate and profile management\n- Store submission process (App Store / Google Play)\n- Hot update solution (CodePush/EAS Update)\n- TestFlight / beta distribution\n\n#### E. Mobile-Specific Debugging\n\n- Physical device debugging\n- Performance profiling tools\n- Crash log collection\n- Network packet capture\n\n**High Frequency Workflow Example (Mobile App):**\n\n```\nNew page: Create page/Screen → Register route → Connect state → Connect navigation → Integration test API\nNew native module: Define Bridge interface → Implement Android/iOS native code → JS call wrapper → Test\nRelease flow: Build Android/iOS → Sign → Upload to store → Submit for review → Publish\n```\n\n---\n\n## Project Type Auto-Detection\n\nBefore analyzing, identify the project type via these signals (multi-select):\n\n**Frontend Web signals:**\n- `package.json` has react/vue/svelte/angular/next/nuxt\n- webpack.config/vite.config/tsconfig.json exists\n- public/index.html or index.html exists\n- src has pages/views/components/hooks/store directories\n\n**Desktop Client signals:**\n- `package.json` has electron/tauri\n- electron/ or src-tauri/ directory exists\n- Capacitor config file\n- Main process entry file\n\n**Backend Service signals:**\n- `package.json` has express/nest/fastify/koa (Node)\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- migration/ directory exists\n- Dockerfile / docker-compose.yml\n\n**Mini Program signals:**\n- app.json / pages.json / project.config.json\n- Taro/uni-app config\n- WeChat DevTools config file\n\n**Mobile App signals:**\n- android/ or ios/ directory\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift (RN/Flutter entry)\n- .xcodeproj / .xcworkspace\n\nInform user of detection result at the start of Stage 1. If inaccurate, user can manually specify.\n\n---\n\n## Output Strategy\n\n**Strictly stage-based output. Do NOT output everything at once.**\n\n### Stage 1 — Developer Quick Overview (Default)\n\n- Project type (auto-detected)\n- What the project is\n- How to start\n- Tech stack\n- Most important directories\n- Key standards\n- Environment system\n- Recommended reading order\n- High-risk areas\n\n**Goal: Build a project map within 10 minutes.**\n\n### Stage 2 — Universal Modules Deep Dive\n\nExpand directory navigation, engineering standards, team collaboration, environment & deployment etc. when user asks.\n\n### Stage 3 — Type-Specific Deep Dive\n\nExpand the corresponding type-specific module (Frontend Web / Backend / Client / Mini Program / Mobile) when user asks.\n\n### Stage 4 — Targeted Development Assistance\n\nSupport multi-round questions:\n\n- \"Which module should I reference for adding a new page?\"\n- \"How does the permission system work?\"\n- \"How is IPC communication debugged?\"\n- \"What's the release workflow?\"\n\n## Stage Stopping Conditions\n\n- After current stage output is complete, **⏸ pause and wait for user confirmation or follow-up**\n- At the end of each stage, provide clear next-step prompts, e.g.:\n  - 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.\"*\n  - End of Stage 2: *\"Universal modules expanded. For [project type] specific guide, say 'specific'. Or ask specific dev questions directly.\"*\n  - 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'.\"*\n- For insufficient-evidence content: briefly note and skip, don't force-fill\n- When tokens/context approach limits: output current progress and remaining plan\n\n## Input Validation\n\n### When Information Is Insufficient\n\nIf user only says \"help me set up\" or similar vague requests, don't guess or blindly execute:\n1. At minimum need one of: **project path / Git repo URL / currently open working directory**\n2. Ask: \"Which project would you like to analyze? Please provide the project path or repo URL.\"\n3. If user provides a path but project is empty or inaccessible: clearly inform and ask for confirmation\n\n### Handling Contradictory Requests\n\nWhen user makes conflicting goals (e.g., \"give me a complete architecture report\" but also \"keep it concise\"):\n1. Point out the contradiction: \"Complete architecture report and concise output conflict\"\n2. Suggest compromise: prioritize Stage 1 (quick overview), then go deeper as needed\n3. Let user choose priority\n\n### When Project Cannot Be Analyzed\n\nClearly inform user and stop analysis in these cases; do not force output:\n- Specified path doesn't exist or no access permissions\n- Project directory is empty\n- Cannot identify project type (no known signals)\n- Key config files (e.g., package.json) are corrupted or unreadable\n\n---\n\n## Important Constraints\n\n### Don't:\n- Generate lengthy unfocused reports\n- Explain basic programming knowledge\n- Mechanically list all files\n- Output meaningless directory trees\n- Discuss component systems for backend projects, ORM for frontend projects\n- Ignore development workflows and team collaboration\n\n### Must:\n- Core focus on development efficiency\n- Tailor content by project type, only load relevant modules\n- Emphasize engineering practices and actual development workflows\n- Emphasize \"how to actually start developing\"\n- Support multi-round progressive exploration\n\n## Execution Tool Guide\n\nEvery analysis step should be backed by concrete tool execution, not fabricated output:\n\n### Project Type Detection — Actions\n1. `read {project}/package.json` → extract dependencies, match frontend/client/Node backend signals\n2. `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\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → desktop client signals\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → mobile signals\n5. Multiple signals → treat as mixed project, load all matching modules\n\n### Stage 1 Quick Overview — Actions\n1. `read {project}/package.json` or `Cargo.toml` or `go.mod` → tech stack\n2. `exec ls {project}/` → directory structure overview\n3. `read {project}/README.md` → project purpose (if exists)\n4. `read {project}/.env.example` → environment variables (if exists)\n\n### Stage 2 Universal Modules — Actions\n1. `exec find {project}/src -type d -maxdepth 2` → directory structure\n2. `read {project}/src/index.*` or `main.*` → entry file\n3. `exec find {project} -name \"Dockerfile\" -o -name \"docker-compose*\" | head -3` → deployment\n\n### Stage 3 Type-Specific — Select by Type\n**Frontend Web:** `find` for router/store/api files\n**Backend:** `find` for migration/middleware/controller files\n**Desktop Client:** `read` main process entry + `find` preload/bridge\n\n### Large Project Strategy\nWhen `exec find {project} -type f | wc -l` exceeds 200: build index first, only read P0 files, deep-dive core chain only.\n\n### Output Format\nEach Stage: `# [Project Name] — Stage N: [Title]` with structured headings + `## ⏸ Next Steps` at end.\n- Emphasize \"how to actually start developing\"\n- Support multi-round progressive exploration\n\n## Ideal Outcome\n\nAfter using this skill, an experienced developer should be able to:\n\n- Successfully start the project\n- Understand project structure and type-specific architecture\n- Find core modules\n- Understand engineering standards\n- Safely develop features\n- Correctly use type-specific capabilities (components/API/IPC/native modules etc.)\n- Complete QA submission and release\n- Know where to dive deeper\n\nUltimate achievement: **\"I'm ready to start participating in project development.\"**\n\nFile v0.3.0:_meta.json\n\n{\n  \"ownerId\": \"kn76af6ccjftr7hsds21j60xnn82q1qd\",\n  \"slug\": \"project-onboarding\",\n  \"version\": \"0.3.0\",\n  \"publishedAt\": 1779091862001\n}\n\nArchive v1.2.1: 2 files, 16004 bytes\n\nFiles: SKILL.md (39562b), _meta.json (137b)\n\nFile v1.2.1:SKILL.md\n\n---\nname: project-onboarding\nversion: \"1.2.0\"\nhomepage: https://github.com/z-Zihan/awesome-skills\ndescription: >\n  帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、\n  客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出\n  项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。\n  触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门, onboarding,\n  如何开发, 怎么启动项目, 项目怎么跑, 开发流程, onboarding guide,\n  how to onboard, project handover, developer quick start.\n  NOT for: generating long architecture reports, code analysis without dev context,\n  beginner programming tutorials, onboarding for interns.\n---\n\n# project-onboarding — 项目接手指南\n\n## 语言规则\n\n**检测用户使用的语言，全程使用同一语言输出。** 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（React、Electron、IPC 等）保留原文即可。\n\n---\n\n# 中文版\n\n帮助有经验的开发者快速理解并接手一个陌生项目，尽快具备实际开发能力。\n\n## 支持的项目类型\n\n按优先级排序：\n\n| 类型 | 识别信号 | 专项模块 |\n|---|---|---|\n| **前端 Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | 组件体系、路由、状态管理、CSS 方案、API 集成、浏览器兼容 |\n| **后端服务** | Express/Nest/Django/Spring/Gin, ORM/migration | 数据库 Schema、ORM、中间件链、API 设计、认证鉴权、缓存与队列 |\n| **客户端** | Electron/Tauri/Capacitor, 主进程/渲染进程 | 主进程架构、渲染进程、IPC 通信、原生能力、签名与分发、自动更新 |\n| **小程序** | 微信/支付宝/抖音小程序, app.json/pages.json | 平台适配、分包策略、审核流程、原生能力调用、用户体系 |\n| **移动端** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | 原生模块 Bridge、热更新、应用签名、应用商店发布、权限管理 |\n\n**多类型混合项目**（如 Electron + Vue、Tauri + React）：同时加载对应专项模块，按优先级排序。\n\n> **扩展指南**：新增项目类型时，需要同步更新三个位置：\n> 1. 上方「支持的项目类型」表格\n> 2. 「项目类型自动识别」信号列表\n> 3. 对应的专项模块章节（新增或复用）\n> 建议保持模块命名和排序的一致性。\n\n## 这个 Skill 不是\n\n- 面向编程新手\n- 面向实习生教学\n- 面向基础知识解释\n- 面向纯代码分析\n\n## 核心目标\n\n让专业开发者在最短时间内完成：\n\n- 项目理解\n- 工程结构理解\n- 开发流程理解\n- 团队规范理解\n- 环境体系理解\n- 项目类型特有的核心能力理解\n- 发布流程理解\n- 调试与开发能力建立\n\n最终达到：\n\n**\"开发者已经可以开始安全地开发功能并参与协作。\"**\n\n## 语言策略\n\n- 默认输出中文，同时提供英文版本\n- 中文优先\n\n## 核心原则\n\n### 1. 以\"快速进入开发状态\"为最高优先级\n\n优先帮助开发者理解：\n\n- 项目如何运行\n- 功能如何开发\n- 项目类型特有的核心机制\n- 目录如何组织\n- 环境如何切换\n- 如何调试\n- 如何发版\n- 如何避免踩坑\n\n**而不是：**\n\n- 生成超长架构分析报告\n- 输出无意义目录树\n- 罗列所有源码文件\n\n### 2. 避免一次性信息轰炸\n\n- 分阶段输出\n- 优先级排序\n- 保持简洁\n- 支持多轮渐进式探索\n\n### 3. 模拟\"资深工程师带新人\"\n\n你的角色不是代码分析器，而是团队里的资深工程师在带一个有经验的新同事。\n\n重点关注：\n\n- 实际开发流程\n- 隐式规范\n- 高风险区域\n- 常见坑\n- 推荐参考模块\n\n### 4. 证据优先，不假装理解\n\n- 所有结论基于仓库真实证据\n- 仓库中没有的规范或机制，不要编造\n- 区分：已确认事实 / 合理推断 / 证据不足\n\n### 5. 按项目类型裁剪内容\n\n- 只分析与当前项目类型相关的模块\n- 不要给后端项目讲组件体系，不要给前端项目讲 ORM\n- 混合项目按优先级排序专项模块\n\n## 执行工具指引\n\n本 Skill 的每个分析步骤都应配合具体工具执行，而非凭空\"编\"输出：\n\n### 项目类型识别 — 执行动作\n\n1. `read {project}/package.json` → 提取 dependencies 和 devDependencies，匹配前端/客户端/Node 后端信号\n2. `exec find {project} -maxdepth 2 -name \"*.config.*\" -o -name \"go.mod\" -o -name \"Cargo.toml\" -o -name \"pom.xml\" -o -name \"app.json\"` → 识别后端/小程序/移动端信号\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → 客户端信号\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → 移动端信号\n5. 多信号命中时 → 按混合项目处理，所有匹配的专项模块均加载\n\n### Stage 1 快速总览 — 执行动作\n\n1. `read {project}/package.json` 或 `Cargo.toml` 或 `go.mod` → 技术栈\n2. `exec ls {project}/` → 目录结构概览\n3. `read {project}/README.md` → 项目用途（如存在）\n4. `read {project}/.env.example` → 环境变量（如存在）\n5. `exec find {project} -name \"*.config.*\" -maxdepth 1` → 构建配置\n\n### Stage 2 通用模块深入 — 执行动作\n\n1. `exec find {project}/src -type d -maxdepth 2` → 目录结构\n2. `read {project}/src/index.*` 或 `main.*` → 入口文件\n3. `exec find {project} -name \".eslintrc*\" -o -name \".prettierrc*\" -o -name \"tsconfig.json\" -maxdepth 1` → 工程规范\n4. `exec find {project} -name \"Dockerfile\" -o -name \"docker-compose*\" -o -name \".github\" -type d -maxdepth 2` → 部署配置\n5. `exec find {project} -name \"*.test.*\" -o -name \"*.spec.*\" | head -5` → 测试结构\n\n### Stage 3 专项模块 — 按类型选择执行\n\n**前端 Web：**\n- `exec find {project}/src -name \"router*\" -o -name \"routes*\" | head -5` → 路由\n- `exec find {project}/src -name \"store*\" -o -name \"*reducer*\" | head -5` → 状态管理\n- `exec find {project}/src -name \"request*\" -o -name \"api*\" -o -name \"http*\" | head -5` → API 层\n\n**后端：**\n- `exec find {project} -path \"*/migration*\" -o -path \"*/schema*\" | head -5` → 数据库\n- `exec find {project} -path \"*/middleware*\" -o -path \"*/guard*\" | head -5` → 中间件\n- `exec find {project} -path \"*/route*\" -o -name \"controller*\" | head -5` → 路由/控制器\n\n**客户端：**\n- `read {project}/electron/main.*` 或 `{project}/src-tauri/src/main.rs` → 主进程\n- `exec find {project} -name \"preload*\" -o -name \"bridge*\" | head -5` → IPC\n\n### 大项目策略\n\n当 `exec find {project} -type f | wc -l` 超过 200 时：\n1. 先用 `find` + `ls` 建立文件索引，不全量读取\n2. 只读 P0 文件（package.json、入口、README）\n3. 核心链路深入（入口 → 中间件 → 服务 → 数据），其余跳过\n\n### 输出格式定义\n\n每个 Stage 的输出应使用以下 Markdown 结构：\n\n```markdown\n# [项目名] — Stage N: [阶段名]\n\n## 项目类型\n[类型]（识别信号：[列出检测到的信号]）\n\n## [各分析维度]\n...\n\n## ⏸ 下一步\n[提示用户可以深入的方向]\n```\n\n---\n\n## 分析模块\n\n### 一、通用模块（所有项目类型）\n\n以下模块适用于任何项目类型，按分析顺序排列：\n\n#### 1. 项目概览\n\n- 项目用途与业务领域\n- 项目类型（自动识别）\n- 核心能力与主要模块\n- 技术栈\n- 系统架构\n- 外部依赖\n- 核心链路\n\n#### 2. 开发快速启动\n\n- 如何安装依赖\n- 如何启动项目\n- 本地开发命令\n- 如何切换环境\n- 必需环境变量\n- 如何本地调试\n- 如何运行测试\n- 如何构建\n\n#### 3. 项目目录导航\n\n必须说明：\n\n- 为什么这样组织\n- 哪些目录最重要\n- 哪些目录最常修改\n- 哪些目录风险最高\n- 哪些属于基础设施\n\n#### 4. 工程规范\n\n- 命名规范\n- 目录规范\n- 代码组织方式\n- commit 规范\n- lint/format 规范\n- 测试规范\n- 错误处理规范\n- 隐式规范（README 没写但团队默认遵守的规则）\n\n#### 5. 环境与部署体系\n\n- 环境列表（local/dev/test/staging/production 等）\n- 环境如何切换\n- 配置如何管理\n- CI/CD 流程\n- 如何发版 / 如何提测 / 如何回滚\n\n#### 6. 团队协作流程\n\n- 分支策略\n- PR / Code Review 流程\n- QA / UAT 流程\n\n#### 7. 高频开发路径\n\n总结团队最常见的开发套路（按项目类型定制示例）\n\n#### 8. 推荐参考模块\n\n- 最规范的模块\n- 最推荐模仿的实现\n- 入口文件\n\n#### 9. 危险区域识别\n\n- 哪些区域改动风险高\n- 哪些代码耦合严重\n- 哪些模块容易引发线上问题\n\n---\n\n### 二、前端 Web 专项\n\n当识别到前端 Web 项目时加载：\n\n#### A. 组件体系与 UI 基础设施\n\n- 内部组件库\n- 第三方组件库\n- layout 系统 / icon 系统 / theme 系统\n- 通用业务组件\n- 哪些组件应优先复用\n- 新组件放哪里\n\n#### B. 路由系统\n\n- 路由如何组织\n- 路由守卫与权限\n- 动态路由 / 懒加载\n- 新增页面的路由配置方式\n\n#### C. 状态管理\n\n- 使用的方案（Redux/Pinia/Zustand/Jotai 等）\n- 全局状态 vs 局部状态的划分策略\n- store 如何组织\n- 新功能应该用全局还是局部状态\n\n#### D. CSS 与样式方案\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- 设计系统 / token 体系\n- 样式约定\n\n#### E. API 集成\n\n- 请求层如何封装\n- token/auth 如何工作\n- 错误拦截机制\n- mock 策略\n- 新接口应该如何接入\n\n**高频开发路径示例（前端 Web）：**\n\n```\n新增页面: 新增 route → 新增 page → 新增 API → 接入 store → 接入权限 → 配置菜单 → 提测 → 发版\n新增接口: 定义 API → request 封装 → 类型定义 → hooks/store 接入 → 页面消费 → 错误处理\n新增组件: 放入 shared/components → 补充 story/test → theme 适配 → 权限处理\n```\n\n---\n\n### 三、客户端专项\n\n当识别到 Electron / Tauri / Capacitor 等客户端项目时加载：\n\n#### A. 进程架构\n\n**Electron 项目：**\n- 主进程（Main Process）职责与入口\n- 渲染进程（Renderer Process）架构\n- 预加载脚本（Preload）与 contextBridge\n- 多窗口管理\n- 进程间通信（IPC）设计\n\n**Tauri 项目：**\n- 前端层（WebView）\n- Rust 后端层（Tauri Commands）\n- IPC 通信方式（invoke/listen）\n- 插件系统\n- 安全策略（allowlist/CSP）\n\n#### B. 原生能力集成\n\n- 文件系统操作（读写、对话框）\n- 系统托盘与通知\n- 剪贴板 / 屏幕截图 / 全局快捷键\n- 网络状态监听\n- 系统信息获取\n- 原生模块（Node Addons / Rust FFI）\n\n#### C. 签名与分发\n\n- 开发者证书与签名配置\n- macOS: codesign + notary / Windows: 签名证书\n- 自动更新机制（autoUpdater）\n- 更新服务器配置\n- 各平台分发渠道（App Store / Microsoft Store / 自建）\n\n#### D. 构建与打包\n\n- 构建命令与配置\n- 多平台构建（macOS arm64/x64 / Windows x64）\n- 安装包格式（DMG/EXE/MSI/AppImage）\n- 构建时间优化\n- CI/CD 中的构建流程\n\n#### E. 客户端特有调试\n\n- 主进程调试\n- 渲染进程调试（DevTools）\n- IPC 通信调试\n- 原生能力调试\n- 性能分析（CPU/内存/启动速度）\n\n**高频开发路径示例（客户端）：**\n\n```\n新增功能: 前端开发 → IPC 通信定义 → 主进程/Rust 命令实现 → 联调 → 测试 → 构建\n新增原生能力: 调研 API → 实现 IPC 命令 → 前端调用封装 → 错误处理 → 多平台测试\n发版流程: 构建多平台 → 签名 → 公证 → 上传更新服务器 → 灰度 → 全量\n```\n\n---\n\n### 四、后端服务专项\n\n当识别到 Express/Nest/Django/Spring/Gin 等后端服务项目时加载：\n\n#### A. 数据库与存储\n\n- 使用的数据库（MySQL/PostgreSQL/MongoDB/Redis 等）\n- ORM/Query Builder（Prisma/TypeORM/Sequelize/GORM 等）\n- Migration 策略\n- 数据库 Schema 设计思路\n- 缓存策略（Redis/Memcached）\n- 文件存储（OSS/S3/本地）\n\n#### B. 中间件与请求处理\n\n- 中间件链与执行顺序\n- 认证与鉴权（JWT/Session/OAuth）\n- 请求验证与参数校验\n- 日志策略\n- 限流与熔断\n\n#### C. API 设计\n\n- RESTful / GraphQL / gRPC / tRPC\n- API 版本管理\n- 错误码体系\n- 文档生成（Swagger/OpenAPI）\n- 请求/响应格式约定\n\n#### D. 异步与任务处理\n\n- 消息队列（RabbitMQ/Kafka/Redis）\n- 定时任务（Cron）\n- 后台任务/Worker\n- WebSocket / SSE 长连接\n\n**高频开发路径示例（后端）：**\n\n```\n新增接口: 定义路由 → 参数校验 → 业务逻辑 → 数据库操作 → 返回响应 → 补充测试\n新增数据表: 设计 Schema → 创建 Migration → 编写 Model → 实现业务逻辑 → API 接入\n新增定时任务: 注册 Cron → 实现任务逻辑 → 日志与监控 → 测试验证\n```\n\n---\n\n### 五、小程序专项\n\n当识别到微信/支付宝/抖音小程序项目时加载：\n\n#### A. 平台与框架\n\n- 目标平台（微信/支付宝/抖音/多端）\n- 使用原生还是跨端框架（Taro/uni-app）\n- 平台 API 差异处理\n\n#### B. 小程序架构\n\n- 页面与组件结构\n- 全局配置（app.json/pages.json）\n- 自定义组件封装\n- 分包策略\n- 插件使用\n\n#### C. 用户体系与登录\n\n- 登录流程（wx.login 等）\n- 用户信息获取与存储\n- Session 管理\n- 与后端用户系统的对接\n\n#### D. 发布与审核\n\n- 审核流程与注意事项\n- 体验版 / 正式版 发布\n- 版本管理与回滚\n- 小程序码 / 分享配置\n\n#### E. 性能优化\n\n- 分包加载\n- 图片懒加载\n- setData 优化\n- 长列表优化\n- 自定义组件懒加载\n\n**高频开发路径示例（小程序）：**\n\n```\n新增页面: pages.json 注册 → 创建页面目录 → 实现页面逻辑 → 配置路由 → 提交体验版 → 审核\n新增组件: 创建组件目录 → 实现 component → 引入使用 → 样式隔离\n新增接口: 封装请求方法 → 页面调用 → 错误处理 → 加载态\n```\n\n---\n\n### 六、移动端专项\n\n当识别到 React Native / Flutter / SwiftUI / Kotlin 等移动端项目时加载：\n\n#### A. 应用架构\n\n- 使用的框架（React Native/Flutter/SwiftUI/Compose）\n- 架构模式（MVI/MVVM/Clean Architecture）\n- 模块化方案\n- 导航系统\n\n#### B. 原生模块与 Bridge\n\n- 原生模块列表与用途\n- Bridge 通信机制\n- 如何新增原生模块\n- 第三方原生 SDK 集成方式\n\n#### C. 状态管理与数据持久化\n\n- 状态管理方案\n- 本地存储（AsyncStorage/MMKV/SQLite/CoreData）\n- 离线策略\n\n#### D. 发布与应用商店\n\n- Android: 签名配置（keystore）\n- iOS: 证书与 Profile 管理\n- 应用商店提交流程（App Store / Google Play）\n- 热更新方案（CodePush/EAS Update）\n- TestFlight / 内测分发\n\n#### E. 移动端特有调试\n\n- 真机调试流程\n- 性能分析工具\n- 崩溃日志收集\n- 网络抓包\n\n**高频开发路径示例（移动端）：**\n\n```\n新增页面: 创建页面/Screen → 注册路由 → 接入状态 → 接入导航 → 联调接口\n新增原生模块: 定义 Bridge 接口 → 实现 Android/iOS 原生代码 → JS 调用封装 → 测试\n发版流程: 构建 Android/iOS → 签名 → 上传商店 → 提交审核 → 发布\n```\n\n---\n\n## 项目类型自动识别\n\n分析项目前，先通过以下信号识别项目类型（可多选）：\n\n**前端 Web 信号：**\n- `package.json` 中有 react/vue/svelte/angular/next/nuxt\n- 存在 webpack.config/vite.config/tsconfig.json\n- 存在 public/index.html 或 index.html\n- src 下有 pages/views/components/hooks/store 目录\n\n**客户端信号：**\n- `package.json` 中有 electron/tauri\n- 存在 electron/ 目录或 src-tauri/ 目录\n- Capacitor 配置文件\n- main process 入口文件\n\n**后端服务信号：**\n- `package.json` 中有 express/nest/fastify/koa（Node）\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- 存在 migration/ 目录\n- Dockerfile / docker-compose.yml\n\n**小程序信号：**\n- app.json / pages.json / project.config.json\n- Taro/uni-app 配置\n- 微信开发者工具配置文件\n\n**移动端信号：**\n- android/ 或 ios/ 目录\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift（RN/Flutter 入口）\n- .xcodeproj / .xcworkspace\n\n识别结果在 Stage 1 开头明确告知用户，如果识别不准确，用户可以手动指定。\n\n---\n\n## 输出策略\n\n**严格分阶段输出，不要一次输出全部内容。**\n\n### Stage 1 — 开发者快速总览（默认）\n\n- 项目类型（自动识别结果）\n- 项目是什么\n- 如何启动\n- 技术栈\n- 最重要目录\n- 关键规范\n- 环境体系\n- 推荐阅读顺序\n- 高风险区域\n\n**目标：让开发者 10 分钟内建立项目地图。**\n\n### Stage 2 — 通用模块深入\n\n用户追问时展开目录导航、工程规范、团队协作、环境部署等通用模块。\n\n### Stage 3 — 项目类型专项深入\n\n用户追问时展开对应项目类型的专项模块（前端 Web / 后端 / 客户端 / 小程序 / 移动端）。\n\n### Stage 4 — 定向开发辅助\n\n支持多轮追问：\n\n- \"新增页面应该参考哪个模块？\"\n- \"权限系统怎么做的？\"\n- \"IPC 通信怎么调的？\"\n- \"发版流程是什么？\"\n\n## 每个阶段的停止条件\n\n- 当前阶段内容输出完毕后，**⏸ 暂停等待用户确认或追问**\n- 每个阶段结束时，给出明确的下一步提示，例如：\n  - Stage 1 结束：*\"以上是项目快速总览。如需深入了解工程规范、目录导航等，请告诉我。如需查看[项目类型]专项指南，请说「专项」。如要开始某个具体开发任务，直接说即可。\"*\n  - Stage 2 结束：*\"通用模块已展开。如需查看[项目类型]专项指南，请说「专项」。或直接问具体的开发问题。\"*\n  - Stage 3 结束：*\"专项指南已展开。可以直接问具体开发问题，如「新增页面怎么做」「发版流程是什么」等。\"*\n- 证据不足的内容：简单说明后跳过，不要强行填充\n- Token/上下文接近上限时：输出当前进度和剩余计划\n\n## 输入验证\n\n### 信息不足时\n\n如果用户只说了\"帮我搞一下\"或类似模糊请求，不要猜测或胡乱执行：\n1. 至少需要以下信息之一：**项目路径 / Git 仓库地址 / 已打开的工作目录**\n2. 询问：\"请问要分析哪个项目？请提供项目路径或仓库地址。\"\n3. 如果用户提供了路径但项目为空或无法访问：明确告知并请求确认\n\n### 矛盾请求处理\n\n当用户同时提出冲突目标时（如\"给我完整架构报告\"但又要求\"保持简洁\"）：\n1. 指出矛盾：\"完整架构报告与简洁输出存在矛盾\"\n2. 建议折中方案：优先 Stage 1（快速总览），再按需深入\n3. 让用户选择优先级\n\n### 项目无法分析时\n\n以下情况应明确告知用户并停止分析，不要强行输出：\n- 指定路径不存在或无访问权限\n- 项目目录为空\n- 无法识别项目类型（无任何已知信号）\n- 关键配置文件（如 package.json）损坏或不可读\n\n---\n\n## 重要限制\n\n### 不要：\n- 生成超长无重点报告\n- 解释基础编程知识\n- 机械列举所有文件\n- 输出没有意义的目录树\n- 给后端项目讲组件体系，给前端项目讲 ORM\n- 忽略开发流程和团队协作\n\n### 必须：\n- 以开发效率为核心\n- 按项目类型裁剪内容，只加载相关模块\n- 强调工程实践和实际开发流程\n- 强调\"如何真正开始开发\"\n- 支持多轮渐进式探索\n\n## 理想结果\n\n使用这个 skill 后，一个有经验的开发者应该能够：\n\n- 成功启动项目\n- 理解项目结构与项目类型特有架构\n- 找到核心模块\n- 理解工程规范\n- 能够安全开发功能\n- 能够正确使用项目类型特有能力（组件/API/IPC/原生模块等）\n- 能够完成提测与发版\n- 知道应该继续深入哪里\n\n最终达到：**\"我已经可以开始参与项目开发了。\"**\n\n---\n---\n\n# English Version\n\nHelp experienced developers quickly understand and onboard onto an unfamiliar project, achieving actual development capability as fast as possible.\n\n## Supported Project Types\n\nPriority order:\n\n| Type | Detection Signals | Specific Modules |\n|---|---|---|\n| **Frontend Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | Component system, routing, state management, CSS approach, API integration, browser compatibility |\n| **Backend Service** | Express/Nest/Django/Spring/Gin, ORM/migration | Database Schema, ORM, middleware chain, API design, auth, caching & queues |\n| **Desktop Client** | Electron/Tauri/Capacitor, main/renderer process | Main process architecture, renderer process, IPC, native capabilities, signing & distribution, auto-update |\n| **Mini Program** | WeChat/Alipay/Douyin mini program, app.json/pages.json | Platform adaptation, subpackage strategy, review process, native API calls, user system |\n| **Mobile App** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | Native module Bridge, hot update, app signing, app store publishing, permission management |\n\n**Mixed-type projects** (e.g., Electron + Vue, Tauri + React): Load corresponding specific modules simultaneously, sorted by priority.\n\n> **Extension guide**: When adding new project types, update three places in sync:\n> 1. The \"Supported Project Types\" table above\n> 2. The \"Project Type Auto-Detection\" signal list\n> 3. The corresponding specific module section (new or reuse)\n> Maintain consistent module naming and ordering.\n\n## This Skill Is NOT\n\n- For programming beginners\n- For intern training\n- For explaining basic programming concepts\n- For pure code analysis\n\n## Core Objective\n\nEnable a professional developer to achieve the following in minimum time:\n\n- Project understanding\n- Engineering structure understanding\n- Development workflow understanding\n- Team standards understanding\n- Environment system understanding\n- Type-specific core capabilities understanding\n- Release workflow understanding\n- Debug and development capability\n\nUltimate goal:\n\n**\"The developer is ready to safely develop features and collaborate.\"**\n\n## Language Strategy\n\n- Default to user's language, also provide the other language version\n- Follow user's language preference\n\n## Core Principles\n\n### 1. \"Fast to Development-Ready\" is the Highest Priority\n\nPrioritize helping developers understand:\n\n- How the project runs\n- How to develop features\n- Type-specific core mechanisms\n- How directories are organized\n- How to switch environments\n- How to debug\n- How to release\n- How to avoid common pitfalls\n\n**Instead of:**\n\n- Generating lengthy architecture reports\n- Outputting meaningless directory trees\n- Listing all source files\n\n### 2. Avoid Information Overload\n\n- Output in stages\n- Sort by priority\n- Keep concise\n- Support multi-round progressive exploration\n\n### 3. Simulate \"Senior Engineer Onboarding a New Colleague\"\n\nYour role is not a code analyzer — it's a senior engineer helping an experienced new colleague onboard.\n\nFocus on:\n\n- Actual development workflows\n- Implicit team conventions\n- High-risk areas\n- Common pitfalls\n- Recommended reference modules\n\n### 4. Evidence First, Don't Fake Understanding\n\n- All conclusions based on real repo evidence\n- Don't fabricate standards or mechanisms not in the repo\n- Distinguish: confirmed facts / reasonable inference / insufficient evidence\n\n### 5. Tailor Content by Project Type\n\n- Only analyze modules relevant to the project type\n- Don't discuss component systems for backend projects, don't discuss ORM for frontend projects\n- Mixed projects sort specific modules by priority\n\n---\n\n## Analysis Modules\n\n### I. Universal Modules (All Project Types)\n\nThese modules apply to any project type, in analysis order:\n\n#### 1. Project Overview\n\n- Project purpose and business domain\n- Project type (auto-detected)\n- Core capabilities and main modules\n- Tech stack\n- System architecture\n- External dependencies\n- Core chain\n\n#### 2. Developer Quick Start\n\n- How to install dependencies\n- How to start the project\n- Local dev commands\n- How to switch environments\n- Required environment variables\n- How to debug locally\n- How to run tests\n- How to build\n\n#### 3. Repository Navigation\n\nMust explain:\n\n- Why organized this way\n- Which directories are most important\n- Which are most frequently modified\n- Which are highest risk\n- Which are infrastructure\n\n#### 4. Engineering Standards\n\n- Naming conventions\n- Directory conventions\n- Code organization style\n- Commit conventions\n- Linting/formatting rules\n- Testing conventions\n- Error handling patterns\n- Implicit standards (unwritten but team-default rules)\n\n#### 5. Environment & Deployment\n\n- Environment list (local/dev/test/staging/production etc.)\n- How to switch environments\n- How configs are managed\n- CI/CD pipeline\n- How to release / submit for QA / how to rollback\n\n#### 6. Team Workflow\n\n- Branching strategy\n- PR / Code Review workflow\n- QA / UAT workflow\n\n#### 7. High Frequency Development Workflow\n\nSummarize most common development patterns (examples tailored by project type)\n\n#### 8. Recommended References\n\n- Most standard module\n- Best implementation to imitate\n- Entry files\n\n#### 9. Risk Areas\n\n- Which areas are high-risk\n- Which code is heavily coupled\n- Which modules easily cause production issues\n\n---\n\n### II. Frontend Web Specific\n\nLoad when Frontend Web project is detected:\n\n#### A. Component System & UI Infrastructure\n\n- Internal component library\n- Third-party components\n- Layout system / icon system / theme system\n- Common business components\n- Which components to reuse\n- Where to put new components\n\n#### B. Routing System\n\n- How routes are organized\n- Route guards and permissions\n- Dynamic routes / lazy loading\n- How to add route for a new page\n\n#### C. State Management\n\n- Solution used (Redux/Pinia/Zustand/Jotai etc.)\n- Global vs local state strategy\n- How stores are organized\n- When to use global vs local\n\n#### D. Styling Approach\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- Design system / token system\n- Styling conventions\n\n#### E. API Integration\n\n- How request layer is encapsulated\n- How token/auth works\n- Error interception\n- Mock strategy\n- How to integrate new APIs\n\n**High Frequency Workflow Example (Frontend Web):**\n\n```\nNew page: Add route → Add page → Add API → Connect store → Add permissions → Configure menu → Submit for QA → Release\nNew API: Define API → Request wrapper → Type definitions → hooks/store integration → Page consumption → Error handling\nNew component: Place in shared/components → Add story/test → Theme adaptation → Permission handling\n```\n\n---\n\n### III. Desktop Client Specific\n\nLoad when Electron / Tauri / Capacitor project is detected:\n\n#### A. Process Architecture\n\n**Electron projects:**\n- Main process responsibilities and entry\n- Renderer process architecture\n- Preload scripts and contextBridge\n- Multi-window management\n- IPC design pattern\n\n**Tauri projects:**\n- Frontend layer (WebView)\n- Rust backend layer (Tauri Commands)\n- IPC communication (invoke/listen)\n- Plugin system\n- Security policies (allowlist/CSP)\n\n#### B. Native Capability Integration\n\n- File system operations (read/write, dialogs)\n- System tray and notifications\n- Clipboard / screenshot / global shortcuts\n- Network status monitoring\n- System info access\n- Native modules (Node Addons / Rust FFI)\n\n#### C. Signing & Distribution\n\n- Developer certificates and signing config\n- macOS: codesign + notary / Windows: signing certificate\n- Auto-update mechanism (autoUpdater)\n- Update server config\n- Distribution channels per platform (App Store / Microsoft Store / self-hosted)\n\n#### D. Build & Packaging\n\n- Build commands and config\n- Multi-platform builds (macOS arm64/x64 / Windows x64)\n- Package formats (DMG/EXE/MSI/AppImage)\n- Build time optimization\n- Build flow in CI/CD\n\n#### E. Client-Specific Debugging\n\n- Main process debugging\n- Renderer process debugging (DevTools)\n- IPC debugging\n- Native capability debugging\n- Performance profiling (CPU/memory/startup speed)\n\n**High Frequency Workflow Example (Desktop Client):**\n\n```\nNew feature: Frontend dev → Define IPC → Implement main process/Rust command → Integration test → Test → Build\nNew native capability: Research API → Implement IPC command → Frontend call wrapper → Error handling → Cross-platform test\nRelease flow: Build multi-platform → Sign → Notarize → Upload to update server → Canary → Full rollout\n```\n\n---\n\n### IV. Backend Service Specific\n\nLoad when Express/Nest/Django/Spring/Gin project is detected:\n\n#### A. Database & Storage\n\n- Database used (MySQL/PostgreSQL/MongoDB/Redis etc.)\n- ORM/Query Builder (Prisma/TypeORM/Sequelize/GORM etc.)\n- Migration strategy\n- Schema design approach\n- Caching strategy (Redis/Memcached)\n- File storage (OSS/S3/local)\n\n#### B. Middleware & Request Handling\n\n- Middleware chain and execution order\n- Authentication and authorization (JWT/Session/OAuth)\n- Request validation\n- Logging strategy\n- Rate limiting and circuit breaking\n\n#### C. API Design\n\n- RESTful / GraphQL / gRPC / tRPC\n- API versioning\n- Error code system\n- API documentation (Swagger/OpenAPI)\n- Request/response format conventions\n\n#### D. Async & Task Processing\n\n- Message queues (RabbitMQ/Kafka/Redis)\n- Scheduled tasks (Cron)\n- Background jobs/workers\n- WebSocket / SSE long connections\n\n**High Frequency Workflow Example (Backend):**\n\n```\nNew endpoint: Define route → Parameter validation → Business logic → Database operation → Return response → Add tests\nNew data table: Design Schema → Create Migration → Write Model → Implement business logic → API integration\nNew scheduled task: Register Cron → Implement task logic → Logging & monitoring → Test & verify\n```\n\n---\n\n### V. Mini Program Specific\n\nLoad when WeChat/Alipay/Douyin mini program project is detected:\n\n#### A. Platform & Framework\n\n- Target platform(s) (WeChat/Alipay/Douyin/multi-platform)\n- Native vs cross-platform framework (Taro/uni-app)\n- Platform API difference handling\n\n#### B. Mini Program Architecture\n\n- Page and component structure\n- Global config (app.json/pages.json)\n- Custom component encapsulation\n- Subpackage strategy\n- Plugin usage\n\n#### C. User System & Auth\n\n- Login flow (wx.login etc.)\n- User info retrieval and storage\n- Session management\n- Integration with backend user system\n\n#### D. Publishing & Review\n\n- Review process and notes\n- Trial vs production release\n- Version management and rollback\n- Mini program code / share config\n\n#### E. Performance Optimization\n\n- Subpackage loading\n- Image lazy loading\n- setData optimization\n- Long list optimization\n- Custom component lazy loading\n\n**High Frequency Workflow Example (Mini Program):**\n\n```\nNew page: Register in pages.json → Create page directory → Implement page logic → Configure route → Submit trial version → Review\nNew component: Create component directory → Implement component → Import & use → Style isolation\nNew API: Wrap request method → Page call → Error handling → Loading state\n```\n\n---\n\n### VI. Mobile App Specific\n\nLoad when React Native / Flutter / SwiftUI / Kotlin project is detected:\n\n#### A. App Architecture\n\n- Framework used (React Native/Flutter/SwiftUI/Compose)\n- Architecture pattern (MVI/MVVM/Clean Architecture)\n- Modularization approach\n- Navigation system\n\n#### B. Native Modules & Bridge\n\n- Native module list and purposes\n- Bridge communication mechanism\n- How to add new native modules\n- Third-party native SDK integration\n\n#### C. State Management & Data Persistence\n\n- State management solution\n- Local storage (AsyncStorage/MMKV/SQLite/CoreData)\n- Offline strategy\n\n#### D. Release & App Store\n\n- Android: signing config (keystore)\n- iOS: certificate and profile management\n- Store submission process (App Store / Google Play)\n- Hot update solution (CodePush/EAS Update)\n- TestFlight / beta distribution\n\n#### E. Mobile-Specific Debugging\n\n- Physical device debugging\n- Performance profiling tools\n- Crash log collection\n- Network packet capture\n\n**High Frequency Workflow Example (Mobile App):**\n\n```\nNew page: Create page/Screen → Register route → Connect state → Connect navigation → Integration test API\nNew native module: Define Bridge interface → Implement Android/iOS native code → JS call wrapper → Test\nRelease flow: Build Android/iOS → Sign → Upload to store → Submit for review → Publish\n```\n\n---\n\n## Project Type Auto-Detection\n\nBefore analyzing, identify the project type via these signals (multi-select):\n\n**Frontend Web signals:**\n- `package.json` has react/vue/svelte/angular/next/nuxt\n- webpack.config/vite.config/tsconfig.json exists\n- public/index.html or index.html exists\n- src has pages/views/components/hooks/store directories\n\n**Desktop Client signals:**\n- `package.json` has electron/tauri\n- electron/ or src-tauri/ directory exists\n- Capacitor config file\n- Main process entry file\n\n**Backend Service signals:**\n- `package.json` has express/nest/fastify/koa (Node)\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- migration/ directory exists\n- Dockerfile / docker-compose.yml\n\n**Mini Program signals:**\n- app.json / pages.json / project.config.json\n- Taro/uni-app config\n- WeChat DevTools config file\n\n**Mobile App signals:**\n- android/ or ios/ directory\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift (RN/Flutter entry)\n- .xcodeproj / .xcworkspace\n\nInform user of detection result at the start of Stage 1. If inaccurate, user can manually specify.\n\n---\n\n## Output Strategy\n\n**Strictly stage-based output. Do NOT output everything at once.**\n\n### Stage 1 — Developer Quick Overview (Default)\n\n- Project type (auto-detected)\n- What the project is\n- How to start\n- Tech stack\n- Most important directories\n- Key standards\n- Environment system\n- Recommended reading order\n- High-risk areas\n\n**Goal: Build a project map within 10 minutes.**\n\n### Stage 2 — Universal Modules Deep Dive\n\nExpand directory navigation, engineering standards, team collaboration, environment & deployment etc. when user asks.\n\n### Stage 3 — Type-Specific Deep Dive\n\nExpand the corresponding type-specific module (Frontend Web / Backend / Client / Mini Program / Mobile) when user asks.\n\n### Stage 4 — Targeted Development Assistance\n\nSupport multi-round questions:\n\n- \"Which module should I reference for adding a new page?\"\n- \"How does the permission system work?\"\n- \"How is IPC communication debugged?\"\n- \"What's the release workflow?\"\n\n## Stage Stopping Conditions\n\n- After current stage output is complete, **⏸ pause and wait for user confirmation or follow-up**\n- At the end of each stage, provide clear next-step prompts, e.g.:\n  - 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.\"*\n  - End of Stage 2: *\"Universal modules expanded. For [project type] specific guide, say 'specific'. Or ask specific dev questions directly.\"*\n  - 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'.\"*\n- For insufficient-evidence content: briefly note and skip, don't force-fill\n- When tokens/context approach limits: output current progress and remaining plan\n\n## Input Validation\n\n### When Information Is Insufficient\n\nIf user only says \"help me set up\" or similar vague requests, don't guess or blindly execute:\n1. At minimum need one of: **project path / Git repo URL / currently open working directory**\n2. Ask: \"Which project would you like to analyze? Please provide the project path or repo URL.\"\n3. If user provides a path but project is empty or inaccessible: clearly inform and ask for confirmation\n\n### Handling Contradictory Requests\n\nWhen user makes conflicting goals (e.g., \"give me a complete architecture report\" but also \"keep it concise\"):\n1. Point out the contradiction: \"Complete architecture report and concise output conflict\"\n2. Suggest compromise: prioritize Stage 1 (quick overview), then go deeper as needed\n3. Let user choose priority\n\n### When Project Cannot Be Analyzed\n\nClearly inform user and stop analysis in these cases; do not force output:\n- Specified path doesn't exist or no access permissions\n- Project directory is empty\n- Cannot identify project type (no known signals)\n- Key config files (e.g., package.json) are corrupted or unreadable\n\n---\n\n## Important Constraints\n\n### Don't:\n- Generate lengthy unfocused reports\n- Explain basic programming knowledge\n- Mechanically list all files\n- Output meaningless directory trees\n- Discuss component systems for backend projects, ORM for frontend projects\n- Ignore development workflows and team collaboration\n\n### Must:\n- Core focus on development efficiency\n- Tailor content by project type, only load relevant modules\n- Emphasize engineering practices and actual development workflows\n- Emphasize \"how to actually start developing\"\n- Support multi-round progressive exploration\n\n## Execution Tool Guide\n\nEvery analysis step should be backed by concrete tool execution, not fabricated output:\n\n### Project Type Detection — Actions\n1. `read {project}/package.json` → extract dependencies, match frontend/client/Node backend signals\n2. `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\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → desktop client signals\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → mobile signals\n5. Multiple signals → treat as mixed project, load all matching modules\n\n### Stage 1 Quick Overview — Actions\n1. `read {project}/package.json` or `Cargo.toml` or `go.mod` → tech stack\n2. `exec ls {project}/` → directory structure overview\n3. `read {project}/README.md` → project purpose (if exists)\n4. `read {project}/.env.example` → environment variables (if exists)\n\n### Stage 2 Universal Modules — Actions\n1. `exec find {project}/src -type d -maxdepth 2` → directory structure\n2. `read {project}/src/index.*` or `main.*` → entry file\n3. `exec find {project} -name \"Dockerfile\" -o -name \"docker-compose*\" | head -3` → deployment\n\n### Stage 3 Type-Specific — Select by Type\n**Frontend Web:** `find` for router/store/api files\n**Backend:** `find` for migration/middleware/controller files\n**Desktop Client:** `read` main process entry + `find` preload/bridge\n\n### Large Project Strategy\nWhen `exec find {project} -type f | wc -l` exceeds 200: build index first, only read P0 files, deep-dive core chain only.\n\n### Output Format\nEach Stage: `# [Project Name] — Stage N: [Title]` with structured headings + `## ⏸ Next Steps` at end.\n- Emphasize \"how to actually start developing\"\n- Support multi-round progressive exploration\n\n## Ideal Outcome\n\nAfter using this skill, an experienced developer should be able to:\n\n- Successfully start the project\n- Understand project structure and type-specific architecture\n- Find core modules\n- Understand engineering standards\n- Safely develop features\n- Correctly use type-specific capabilities (components/API/IPC/native modules etc.)\n- Complete QA submission and release\n- Know where to dive deeper\n\nUltimate achievement: **\"I'm ready to start participating in project development.\"**\n\nFile v1.2.1:_meta.json\n\n{\n  \"ownerId\": \"kn76af6ccjftr7hsds21j60xnn82q1qd\",\n  \"slug\": \"project-onboarding\",\n  \"version\": \"1.2.1\",\n  \"publishedAt\": 1779090354296\n}\n\nArchive v1.2.0: 2 files, 16004 bytes\n\nFiles: SKILL.md (39562b), _meta.json (137b)\n\nFile v1.2.0:SKILL.md\n\n---\nname: project-onboarding\nversion: \"1.2.0\"\nhomepage: https://github.com/z-Zihan/awesome-skills\ndescription: >\n  帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、\n  客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出\n  项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。\n  触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门, onboarding,\n  如何开发, 怎么启动项目, 项目怎么跑, 开发流程, onboarding guide,\n  how to onboard, project handover, developer quick start.\n  NOT for: generating long architecture reports, code analysis without dev context,\n  beginner programming tutorials, onboarding for interns.\n---\n\n# project-onboarding — 项目接手指南\n\n## 语言规则\n\n**检测用户使用的语言，全程使用同一语言输出。** 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（React、Electron、IPC 等）保留原文即可。\n\n---\n\n# 中文版\n\n帮助有经验的开发者快速理解并接手一个陌生项目，尽快具备实际开发能力。\n\n## 支持的项目类型\n\n按优先级排序：\n\n| 类型 | 识别信号 | 专项模块 |\n|---|---|---|\n| **前端 Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | 组件体系、路由、状态管理、CSS 方案、API 集成、浏览器兼容 |\n| **后端服务** | Express/Nest/Django/Spring/Gin, ORM/migration | 数据库 Schema、ORM、中间件链、API 设计、认证鉴权、缓存与队列 |\n| **客户端** | Electron/Tauri/Capacitor, 主进程/渲染进程 | 主进程架构、渲染进程、IPC 通信、原生能力、签名与分发、自动更新 |\n| **小程序** | 微信/支付宝/抖音小程序, app.json/pages.json | 平台适配、分包策略、审核流程、原生能力调用、用户体系 |\n| **移动端** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | 原生模块 Bridge、热更新、应用签名、应用商店发布、权限管理 |\n\n**多类型混合项目**（如 Electron + Vue、Tauri + React）：同时加载对应专项模块，按优先级排序。\n\n> **扩展指南**：新增项目类型时，需要同步更新三个位置：\n> 1. 上方「支持的项目类型」表格\n> 2. 「项目类型自动识别」信号列表\n> 3. 对应的专项模块章节（新增或复用）\n> 建议保持模块命名和排序的一致性。\n\n## 这个 Skill 不是\n\n- 面向编程新手\n- 面向实习生教学\n- 面向基础知识解释\n- 面向纯代码分析\n\n## 核心目标\n\n让专业开发者在最短时间内完成：\n\n- 项目理解\n- 工程结构理解\n- 开发流程理解\n- 团队规范理解\n- 环境体系理解\n- 项目类型特有的核心能力理解\n- 发布流程理解\n- 调试与开发能力建立\n\n最终达到：\n\n**\"开发者已经可以开始安全地开发功能并参与协作。\"**\n\n## 语言策略\n\n- 默认输出中文，同时提供英文版本\n- 中文优先\n\n## 核心原则\n\n### 1. 以\"快速进入开发状态\"为最高优先级\n\n优先帮助开发者理解：\n\n- 项目如何运行\n- 功能如何开发\n- 项目类型特有的核心机制\n- 目录如何组织\n- 环境如何切换\n- 如何调试\n- 如何发版\n- 如何避免踩坑\n\n**而不是：**\n\n- 生成超长架构分析报告\n- 输出无意义目录树\n- 罗列所有源码文件\n\n### 2. 避免一次性信息轰炸\n\n- 分阶段输出\n- 优先级排序\n- 保持简洁\n- 支持多轮渐进式探索\n\n### 3. 模拟\"资深工程师带新人\"\n\n你的角色不是代码分析器，而是团队里的资深工程师在带一个有经验的新同事。\n\n重点关注：\n\n- 实际开发流程\n- 隐式规范\n- 高风险区域\n- 常见坑\n- 推荐参考模块\n\n### 4. 证据优先，不假装理解\n\n- 所有结论基于仓库真实证据\n- 仓库中没有的规范或机制，不要编造\n- 区分：已确认事实 / 合理推断 / 证据不足\n\n### 5. 按项目类型裁剪内容\n\n- 只分析与当前项目类型相关的模块\n- 不要给后端项目讲组件体系，不要给前端项目讲 ORM\n- 混合项目按优先级排序专项模块\n\n## 执行工具指引\n\n本 Skill 的每个分析步骤都应配合具体工具执行，而非凭空\"编\"输出：\n\n### 项目类型识别 — 执行动作\n\n1. `read {project}/package.json` → 提取 dependencies 和 devDependencies，匹配前端/客户端/Node 后端信号\n2. `exec find {project} -maxdepth 2 -name \"*.config.*\" -o -name \"go.mod\" -o -name \"Cargo.toml\" -o -name \"pom.xml\" -o -name \"app.json\"` → 识别后端/小程序/移动端信号\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → 客户端信号\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → 移动端信号\n5. 多信号命中时 → 按混合项目处理，所有匹配的专项模块均加载\n\n### Stage 1 快速总览 — 执行动作\n\n1. `read {project}/package.json` 或 `Cargo.toml` 或 `go.mod` → 技术栈\n2. `exec ls {project}/` → 目录结构概览\n3. `read {project}/README.md` → 项目用途（如存在）\n4. `read {project}/.env.example` → 环境变量（如存在）\n5. `exec find {project} -name \"*.config.*\" -maxdepth 1` → 构建配置\n\n### Stage 2 通用模块深入 — 执行动作\n\n1. `exec find {project}/src -type d -maxdepth 2` → 目录结构\n2. `read {project}/src/index.*` 或 `main.*` → 入口文件\n3. `exec find {project} -name \".eslintrc*\" -o -name \".prettierrc*\" -o -name \"tsconfig.json\" -maxdepth 1` → 工程规范\n4. `exec find {project} -name \"Dockerfile\" -o -name \"docker-compose*\" -o -name \".github\" -type d -maxdepth 2` → 部署配置\n5. `exec find {project} -name \"*.test.*\" -o -name \"*.spec.*\" | head -5` → 测试结构\n\n### Stage 3 专项模块 — 按类型选择执行\n\n**前端 Web：**\n- `exec find {project}/src -name \"router*\" -o -name \"routes*\" | head -5` → 路由\n- `exec find {project}/src -name \"store*\" -o -name \"*reducer*\" | head -5` → 状态管理\n- `exec find {project}/src -name \"request*\" -o -name \"api*\" -o -name \"http*\" | head -5` → API 层\n\n**后端：**\n- `exec find {project} -path \"*/migration*\" -o -path \"*/schema*\" | head -5` → 数据库\n- `exec find {project} -path \"*/middleware*\" -o -path \"*/guard*\" | head -5` → 中间件\n- `exec find {project} -path \"*/route*\" -o -name \"controller*\" | head -5` → 路由/控制器\n\n**客户端：**\n- `read {project}/electron/main.*` 或 `{project}/src-tauri/src/main.rs` → 主进程\n- `exec find {project} -name \"preload*\" -o -name \"bridge*\" | head -5` → IPC\n\n### 大项目策略\n\n当 `exec find {project} -type f | wc -l` 超过 200 时：\n1. 先用 `find` + `ls` 建立文件索引，不全量读取\n2. 只读 P0 文件（package.json、入口、README）\n3. 核心链路深入（入口 → 中间件 → 服务 → 数据），其余跳过\n\n### 输出格式定义\n\n每个 Stage 的输出应使用以下 Markdown 结构：\n\n```markdown\n# [项目名] — Stage N: [阶段名]\n\n## 项目类型\n[类型]（识别信号：[列出检测到的信号]）\n\n## [各分析维度]\n...\n\n## ⏸ 下一步\n[提示用户可以深入的方向]\n```\n\n---\n\n## 分析模块\n\n### 一、通用模块（所有项目类型）\n\n以下模块适用于任何项目类型，按分析顺序排列：\n\n#### 1. 项目概览\n\n- 项目用途与业务领域\n- 项目类型（自动识别）\n- 核心能力与主要模块\n- 技术栈\n- 系统架构\n- 外部依赖\n- 核心链路\n\n#### 2. 开发快速启动\n\n- 如何安装依赖\n- 如何启动项目\n- 本地开发命令\n- 如何切换环境\n- 必需环境变量\n- 如何本地调试\n- 如何运行测试\n- 如何构建\n\n#### 3. 项目目录导航\n\n必须说明：\n\n- 为什么这样组织\n- 哪些目录最重要\n- 哪些目录最常修改\n- 哪些目录风险最高\n- 哪些属于基础设施\n\n#### 4. 工程规范\n\n- 命名规范\n- 目录规范\n- 代码组织方式\n- commit 规范\n- lint/format 规范\n- 测试规范\n- 错误处理规范\n- 隐式规范（README 没写但团队默认遵守的规则）\n\n#### 5. 环境与部署体系\n\n- 环境列表（local/dev/test/staging/production 等）\n- 环境如何切换\n- 配置如何管理\n- CI/CD 流程\n- 如何发版 / 如何提测 / 如何回滚\n\n#### 6. 团队协作流程\n\n- 分支策略\n- PR / Code Review 流程\n- QA / UAT 流程\n\n#### 7. 高频开发路径\n\n总结团队最常见的开发套路（按项目类型定制示例）\n\n#### 8. 推荐参考模块\n\n- 最规范的模块\n- 最推荐模仿的实现\n- 入口文件\n\n#### 9. 危险区域识别\n\n- 哪些区域改动风险高\n- 哪些代码耦合严重\n- 哪些模块容易引发线上问题\n\n---\n\n### 二、前端 Web 专项\n\n当识别到前端 Web 项目时加载：\n\n#### A. 组件体系与 UI 基础设施\n\n- 内部组件库\n- 第三方组件库\n- layout 系统 / icon 系统 / theme 系统\n- 通用业务组件\n- 哪些组件应优先复用\n- 新组件放哪里\n\n#### B. 路由系统\n\n- 路由如何组织\n- 路由守卫与权限\n- 动态路由 / 懒加载\n- 新增页面的路由配置方式\n\n#### C. 状态管理\n\n- 使用的方案（Redux/Pinia/Zustand/Jotai 等）\n- 全局状态 vs 局部状态的划分策略\n- store 如何组织\n- 新功能应该用全局还是局部状态\n\n#### D. CSS 与样式方案\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- 设计系统 / token 体系\n- 样式约定\n\n#### E. API 集成\n\n- 请求层如何封装\n- token/auth 如何工作\n- 错误拦截机制\n- mock 策略\n- 新接口应该如何接入\n\n**高频开发路径示例（前端 Web）：**\n\n```\n新增页面: 新增 route → 新增 page → 新增 API → 接入 store → 接入权限 → 配置菜单 → 提测 → 发版\n新增接口: 定义 API → request 封装 → 类型定义 → hooks/store 接入 → 页面消费 → 错误处理\n新增组件: 放入 shared/components → 补充 story/test → theme 适配 → 权限处理\n```\n\n---\n\n### 三、客户端专项\n\n当识别到 Electron / Tauri / Capacitor 等客户端项目时加载：\n\n#### A. 进程架构\n\n**Electron 项目：**\n- 主进程（Main Process）职责与入口\n- 渲染进程（Renderer Process）架构\n- 预加载脚本（Preload）与 contextBridge\n- 多窗口管理\n- 进程间通信（IPC）设计\n\n**Tauri 项目：**\n- 前端层（WebView）\n- Rust 后端层（Tauri Commands）\n- IPC 通信方式（invoke/listen）\n- 插件系统\n- 安全策略（allowlist/CSP）\n\n#### B. 原生能力集成\n\n- 文件系统操作（读写、对话框）\n- 系统托盘与通知\n- 剪贴板 / 屏幕截图 / 全局快捷键\n- 网络状态监听\n- 系统信息获取\n- 原生模块（Node Addons / Rust FFI）\n\n#### C. 签名与分发\n\n- 开发者证书与签名配置\n- macOS: codesign + notary / Windows: 签名证书\n- 自动更新机制（autoUpdater）\n- 更新服务器配置\n- 各平台分发渠道（App Store / Microsoft Store / 自建）\n\n#### D. 构建与打包\n\n- 构建命令与配置\n- 多平台构建（macOS arm64/x64 / Windows x64）\n- 安装包格式（DMG/EXE/MSI/AppImage）\n- 构建时间优化\n- CI/CD 中的构建流程\n\n#### E. 客户端特有调试\n\n- 主进程调试\n- 渲染进程调试（DevTools）\n- IPC 通信调试\n- 原生能力调试\n- 性能分析（CPU/内存/启动速度）\n\n**高频开发路径示例（客户端）：**\n\n```\n新增功能: 前端开发 → IPC 通信定义 → 主进程/Rust 命令实现 → 联调 → 测试 → 构建\n新增原生能力: 调研 API → 实现 IPC 命令 → 前端调用封装 → 错误处理 → 多平台测试\n发版流程: 构建多平台 → 签名 → 公证 → 上传更新服务器 → 灰度 → 全量\n```\n\n---\n\n### 四、后端服务专项\n\n当识别到 Express/Nest/Django/Spring/Gin 等后端服务项目时加载：\n\n#### A. 数据库与存储\n\n- 使用的数据库（MySQL/PostgreSQL/MongoDB/Redis 等）\n- ORM/Query Builder（Prisma/TypeORM/Sequelize/GORM 等）\n- Migration 策略\n- 数据库 Schema 设计思路\n- 缓存策略（Redis/Memcached）\n- 文件存储（OSS/S3/本地）\n\n#### B. 中间件与请求处理\n\n- 中间件链与执行顺序\n- 认证与鉴权（JWT/Session/OAuth）\n- 请求验证与参数校验\n- 日志策略\n- 限流与熔断\n\n#### C. API 设计\n\n- RESTful / GraphQL / gRPC / tRPC\n- API 版本管理\n- 错误码体系\n- 文档生成（Swagger/OpenAPI）\n- 请求/响应格式约定\n\n#### D. 异步与任务处理\n\n- 消息队列（RabbitMQ/Kafka/Redis）\n- 定时任务（Cron）\n- 后台任务/Worker\n- WebSocket / SSE 长连接\n\n**高频开发路径示例（后端）：**\n\n```\n新增接口: 定义路由 → 参数校验 → 业务逻辑 → 数据库操作 → 返回响应 → 补充测试\n新增数据表: 设计 Schema → 创建 Migration → 编写 Model → 实现业务逻辑 → API 接入\n新增定时任务: 注册 Cron → 实现任务逻辑 → 日志与监控 → 测试验证\n```\n\n---\n\n### 五、小程序专项\n\n当识别到微信/支付宝/抖音小程序项目时加载：\n\n#### A. 平台与框架\n\n- 目标平台（微信/支付宝/抖音/多端）\n- 使用原生还是跨端框架（Taro/uni-app）\n- 平台 API 差异处理\n\n#### B. 小程序架构\n\n- 页面与组件结构\n- 全局配置（app.json/pages.json）\n- 自定义组件封装\n- 分包策略\n- 插件使用\n\n#### C. 用户体系与登录\n\n- 登录流程（wx.login 等）\n- 用户信息获取与存储\n- Session 管理\n- 与后端用户系统的对接\n\n#### D. 发布与审核\n\n- 审核流程与注意事项\n- 体验版 / 正式版 发布\n- 版本管理与回滚\n- 小程序码 / 分享配置\n\n#### E. 性能优化\n\n- 分包加载\n- 图片懒加载\n- setData 优化\n- 长列表优化\n- 自定义组件懒加载\n\n**高频开发路径示例（小程序）：**\n\n```\n新增页面: pages.json 注册 → 创建页面目录 → 实现页面逻辑 → 配置路由 → 提交体验版 → 审核\n新增组件: 创建组件目录 → 实现 component → 引入使用 → 样式隔离\n新增接口: 封装请求方法 → 页面调用 → 错误处理 → 加载态\n```\n\n---\n\n### 六、移动端专项\n\n当识别到 React Native / Flutter / SwiftUI / Kotlin 等移动端项目时加载：\n\n#### A. 应用架构\n\n- 使用的框架（React Native/Flutter/SwiftUI/Compose）\n- 架构模式（MVI/MVVM/Clean Architecture）\n- 模块化方案\n- 导航系统\n\n#### B. 原生模块与 Bridge\n\n- 原生模块列表与用途\n- Bridge 通信机制\n- 如何新增原生模块\n- 第三方原生 SDK 集成方式\n\n#### C. 状态管理与数据持久化\n\n- 状态管理方案\n- 本地存储（AsyncStorage/MMKV/SQLite/CoreData）\n- 离线策略\n\n#### D. 发布与应用商店\n\n- Android: 签名配置（keystore）\n- iOS: 证书与 Profile 管理\n- 应用商店提交流程（App Store / Google Play）\n- 热更新方案（CodePush/EAS Update）\n- TestFlight / 内测分发\n\n#### E. 移动端特有调试\n\n- 真机调试流程\n- 性能分析工具\n- 崩溃日志收集\n- 网络抓包\n\n**高频开发路径示例（移动端）：**\n\n```\n新增页面: 创建页面/Screen → 注册路由 → 接入状态 → 接入导航 → 联调接口\n新增原生模块: 定义 Bridge 接口 → 实现 Android/iOS 原生代码 → JS 调用封装 → 测试\n发版流程: 构建 Android/iOS → 签名 → 上传商店 → 提交审核 → 发布\n```\n\n---\n\n## 项目类型自动识别\n\n分析项目前，先通过以下信号识别项目类型（可多选）：\n\n**前端 Web 信号：**\n- `package.json` 中有 react/vue/svelte/angular/next/nuxt\n- 存在 webpack.config/vite.config/tsconfig.json\n- 存在 public/index.html 或 index.html\n- src 下有 pages/views/components/hooks/store 目录\n\n**客户端信号：**\n- `package.json` 中有 electron/tauri\n- 存在 electron/ 目录或 src-tauri/ 目录\n- Capacitor 配置文件\n- main process 入口文件\n\n**后端服务信号：**\n- `package.json` 中有 express/nest/fastify/koa（Node）\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- 存在 migration/ 目录\n- Dockerfile / docker-compose.yml\n\n**小程序信号：**\n- app.json / pages.json / project.config.json\n- Taro/uni-app 配置\n- 微信开发者工具配置文件\n\n**移动端信号：**\n- android/ 或 ios/ 目录\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift（RN/Flutter 入口）\n- .xcodeproj / .xcworkspace\n\n识别结果在 Stage 1 开头明确告知用户，如果识别不准确，用户可以手动指定。\n\n---\n\n## 输出策略\n\n**严格分阶段输出，不要一次输出全部内容。**\n\n### Stage 1 — 开发者快速总览（默认）\n\n- 项目类型（自动识别结果）\n- 项目是什么\n- 如何启动\n- 技术栈\n- 最重要目录\n- 关键规范\n- 环境体系\n- 推荐阅读顺序\n- 高风险区域\n\n**目标：让开发者 10 分钟内建立项目地图。**\n\n### Stage 2 — 通用模块深入\n\n用户追问时展开目录导航、工程规范、团队协作、环境部署等通用模块。\n\n### Stage 3 — 项目类型专项深入\n\n用户追问时展开对应项目类型的专项模块（前端 Web / 后端 / 客户端 / 小程序 / 移动端）。\n\n### Stage 4 — 定向开发辅助\n\n支持多轮追问：\n\n- \"新增页面应该参考哪个模块？\"\n- \"权限系统怎么做的？\"\n- \"IPC 通信怎么调的？\"\n- \"发版流程是什么？\"\n\n## 每个阶段的停止条件\n\n- 当前阶段内容输出完毕后，**⏸ 暂停等待用户确认或追问**\n- 每个阶段结束时，给出明确的下一步提示，例如：\n  - Stage 1 结束：*\"以上是项目快速总览。如需深入了解工程规范、目录导航等，请告诉我。如需查看[项目类型]专项指南，请说「专项」。如要开始某个具体开发任务，直接说即可。\"*\n  - Stage 2 结束：*\"通用模块已展开。如需查看[项目类型]专项指南，请说「专项」。或直接问具体的开发问题。\"*\n  - Stage 3 结束：*\"专项指南已展开。可以直接问具体开发问题，如「新增页面怎么做」「发版流程是什么」等。\"*\n- 证据不足的内容：简单说明后跳过，不要强行填充\n- Token/上下文接近上限时：输出当前进度和剩余计划\n\n## 输入验证\n\n### 信息不足时\n\n如果用户只说了\"帮我搞一下\"或类似模糊请求，不要猜测或胡乱执行：\n1. 至少需要以下信息之一：**项目路径 / Git 仓库地址 / 已打开的工作目录**\n2. 询问：\"请问要分析哪个项目？请提供项目路径或仓库地址。\"\n3. 如果用户提供了路径但项目为空或无法访问：明确告知并请求确认\n\n### 矛盾请求处理\n\n当用户同时提出冲突目标时（如\"给我完整架构报告\"但又要求\"保持简洁\"）：\n1. 指出矛盾：\"完整架构报告与简洁输出存在矛盾\"\n2. 建议折中方案：优先 Stage 1（快速总览），再按需深入\n3. 让用户选择优先级\n\n### 项目无法分析时\n\n以下情况应明确告知用户并停止分析，不要强行输出：\n- 指定路径不存在或无访问权限\n- 项目目录为空\n- 无法识别项目类型（无任何已知信号）\n- 关键配置文件（如 package.json）损坏或不可读\n\n---\n\n## 重要限制\n\n### 不要：\n- 生成超长无重点报告\n- 解释基础编程知识\n- 机械列举所有文件\n- 输出没有意义的目录树\n- 给后端项目讲组件体系，给前端项目讲 ORM\n- 忽略开发流程和团队协作\n\n### 必须：\n- 以开发效率为核心\n- 按项目类型裁剪内容，只加载相关模块\n- 强调工程实践和实际开发流程\n- 强调\"如何真正开始开发\"\n- 支持多轮渐进式探索\n\n## 理想结果\n\n使用这个 skill 后，一个有经验的开发者应该能够：\n\n- 成功启动项目\n- 理解项目结构与项目类型特有架构\n- 找到核心模块\n- 理解工程规范\n- 能够安全开发功能\n- 能够正确使用项目类型特有能力（组件/API/IPC/原生模块等）\n- 能够完成提测与发版\n- 知道应该继续深入哪里\n\n最终达到：**\"我已经可以开始参与项目开发了。\"**\n\n---\n---\n\n# English Version\n\nHelp experienced developers quickly understand and onboard onto an unfamiliar project, achieving actual development capability as fast as possible.\n\n## Supported Project Types\n\nPriority order:\n\n| Type | Detection Signals | Specific Modules |\n|---|---|---|\n| **Frontend Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | Component system, routing, state management, CSS approach, API integration, browser compatibility |\n| **Backend Service** | Express/Nest/Django/Spring/Gin, ORM/migration | Database Schema, ORM, middleware chain, API design, auth, caching & queues |\n| **Desktop Client** | Electron/Tauri/Capacitor, main/renderer process | Main process architecture, renderer process, IPC, native capabilities, signing & distribution, auto-update |\n| **Mini Program** | WeChat/Alipay/Douyin mini program, app.json/pages.json | Platform adaptation, subpackage strategy, review process, native API calls, user system |\n| **Mobile App** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | Native module Bridge, hot update, app signing, app store publishing, permission management |\n\n**Mixed-type projects** (e.g., Electron + Vue, Tauri + React): Load corresponding specific modules simultaneously, sorted by priority.\n\n> **Extension guide**: When adding new project types, update three places in sync:\n> 1. The \"Supported Project Types\" table above\n> 2. The \"Project Type Auto-Detection\" signal list\n> 3. The corresponding specific module section (new or reuse)\n> Maintain consistent module naming and ordering.\n\n## This Skill Is NOT\n\n- For programming beginners\n- For intern training\n- For explaining basic programming concepts\n- For pure code analysis\n\n## Core Objective\n\nEnable a professional developer to achieve the following in minimum time:\n\n- Project understanding\n- Engineering structure understanding\n- Development workflow understanding\n- Team standards understanding\n- Environment system understanding\n- Type-specific core capabilities understanding\n- Release workflow understanding\n- Debug and development capability\n\nUltimate goal:\n\n**\"The developer is ready to safely develop features and collaborate.\"**\n\n## Language Strategy\n\n- Default to user's language, also provide the other language version\n- Follow user's language preference\n\n## Core Principles\n\n### 1. \"Fast to Development-Ready\" is the Highest Priority\n\nPrioritize helping developers understand:\n\n- How the project runs\n- How to develop features\n- Type-specific core mechanisms\n- How directories are organized\n- How to switch environments\n- How to debug\n- How to release\n- How to avoid common pitfalls\n\n**Instead of:**\n\n- Generating lengthy architecture reports\n- Outputting meaningless directory trees\n- Listing all source files\n\n### 2. Avoid Information Overload\n\n- Output in stages\n- Sort by priority\n- Keep concise\n- Support multi-round progressive exploration\n\n### 3. Simulate \"Senior Engineer Onboarding a New Colleague\"\n\nYour role is not a code analyzer — it's a senior engineer helping an experienced new colleague onboard.\n\nFocus on:\n\n- Actual development workflows\n- Implicit team conventions\n- High-risk areas\n- Common pitfalls\n- Recommended reference modules\n\n### 4. Evidence First, Don't Fake Understanding\n\n- All conclusions based on real repo evidence\n- Don't fabricate standards or mechanisms not in the repo\n- Distinguish: confirmed facts / reasonable inference / insufficient evidence\n\n### 5. Tailor Content by Project Type\n\n- Only analyze modules relevant to the project type\n- Don't discuss component systems for backend projects, don't discuss ORM for frontend projects\n- Mixed projects sort specific modules by priority\n\n---\n\n## Analysis Modules\n\n### I. Universal Modules (All Project Types)\n\nThese modules apply to any project type, in analysis order:\n\n#### 1. Project Overview\n\n- Project purpose and business domain\n- Project type (auto-detected)\n- Core capabilities and main modules\n- Tech stack\n- System architecture\n- External dependencies\n- Core chain\n\n#### 2. Developer Quick Start\n\n- How to install dependencies\n- How to start the project\n- Local dev commands\n- How to switch environments\n- Required environment variables\n- How to debug locally\n- How to run tests\n- How to build\n\n#### 3. Repository Navigation\n\nMust explain:\n\n- Why organized this way\n- Which directories are most important\n- Which are most frequently modified\n- Which are highest risk\n- Which are infrastructure\n\n#### 4. Engineering Standards\n\n- Naming conventions\n- Directory conventions\n- Code organization style\n- Commit conventions\n- Linting/formatting rules\n- Testing conventions\n- Error handling patterns\n- Implicit standards (unwritten but team-default rules)\n\n#### 5. Environment & Deployment\n\n- Environment list (local/dev/test/staging/production etc.)\n- How to switch environments\n- How configs are managed\n- CI/CD pipeline\n- How to release / submit for QA / how to rollback\n\n#### 6. Team Workflow\n\n- Branching strategy\n- PR / Code Review workflow\n- QA / UAT workflow\n\n#### 7. High Frequency Development Workflow\n\nSummarize most common development patterns (examples tailored by project type)\n\n#### 8. Recommended References\n\n- Most standard module\n- Best implementation to imitate\n- Entry files\n\n#### 9. Risk Areas\n\n- Which areas are high-risk\n- Which code is heavily coupled\n- Which modules easily cause production issues\n\n---\n\n### II. Frontend Web Specific\n\nLoad when Frontend Web project is detected:\n\n#### A. Component System & UI Infrastructure\n\n- Internal component library\n- Third-party components\n- Layout system / icon system / theme system\n- Common business components\n- Which components to reuse\n- Where to put new components\n\n#### B. Routing System\n\n- How routes are organized\n- Route guards and permissions\n- Dynamic routes / lazy loading\n- How to add route for a new page\n\n#### C. State Management\n\n- Solution used (Redux/Pinia/Zustand/Jotai etc.)\n- Global vs local state strategy\n- How stores are organized\n- When to use global vs local\n\n#### D. Styling Approach\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- Design system / token system\n- Styling conventions\n\n#### E. API Integration\n\n- How request layer is encapsulated\n- How token/auth works\n- Error interception\n- Mock strategy\n- How to integrate new APIs\n\n**High Frequency Workflow Example (Frontend Web):**\n\n```\nNew page: Add route → Add page → Add API → Connect store → Add permissions → Configure menu → Submit for QA → Release\nNew API: Define API → Request wrapper → Type definitions → hooks/store integration → Page consumption → Error handling\nNew component: Place in shared/components → Add story/test → Theme adaptation → Permission handling\n```\n\n---\n\n### III. Desktop Client Specific\n\nLoad when Electron / Tauri / Capacitor project is detected:\n\n#### A. Process Architecture\n\n**Electron projects:**\n- Main process responsibilities and entry\n- Renderer process architecture\n- Preload scripts and contextBridge\n- Multi-window management\n- IPC design pattern\n\n**Tauri projects:**\n- Frontend layer (WebView)\n- Rust backend layer (Tauri Commands)\n- IPC communication (invoke/listen)\n- Plugin system\n- Security policies (allowlist/CSP)\n\n#### B. Native Capability Integration\n\n- File system operations (read/write, dialogs)\n- System tray and notifications\n- Clipboard / screenshot / global shortcuts\n- Network status monitoring\n- System info access\n- Native modules (Node Addons / Rust FFI)\n\n#### C. Signing & Distribution\n\n- Developer certificates and signing config\n- macOS: codesign + notary / Windows: signing certificate\n- Auto-update mechanism (autoUpdater)\n- Update server config\n- Distribution channels per platform (App Store / Microsoft Store / self-hosted)\n\n#### D. Build & Packaging\n\n- Build commands and config\n- Multi-platform builds (macOS arm64/x64 / Windows x64)\n- Package formats (DMG/EXE/MSI/AppImage)\n- Build time optimization\n- Build flow in CI/CD\n\n#### E. Client-Specific Debugging\n\n- Main process debugging\n- Renderer process debugging (DevTools)\n- IPC debugging\n- Native capability debugging\n- Performance profiling (CPU/memory/startup speed)\n\n**High Frequency Workflow Example (Desktop Client):**\n\n```\nNew feature: Frontend dev → Define IPC → Implement main process/Rust command → Integration test → Test → Build\nNew native capability: Research API → Implement IPC command → Frontend call wrapper → Error handling → Cross-platform test\nRelease flow: Build multi-platform → Sign → Notarize → Upload to update server → Canary → Full rollout\n```\n\n---\n\n### IV. Backend Service Specific\n\nLoad when Express/Nest/Django/Spring/Gin project is detected:\n\n#### A. Database & Storage\n\n- Database used (MySQL/PostgreSQL/MongoDB/Redis etc.)\n- ORM/Query Builder (Prisma/TypeORM/Sequelize/GORM etc.)\n- Migration strategy\n- Schema design approach\n- Caching strategy (Redis/Memcached)\n- File storage (OSS/S3/local)\n\n#### B. Middleware & Request Handling\n\n- Middleware chain and execution order\n- Authentication and authorization (JWT/Session/OAuth)\n- Request validation\n- Logging strategy\n- Rate limiting and circuit breaking\n\n#### C. API Design\n\n- RESTful / GraphQL / gRPC / tRPC\n- API versioning\n- Error code system\n- API documentation (Swagger/OpenAPI)\n- Request/response format conventions\n\n#### D. Async & Task Processing\n\n- Message queues (RabbitMQ/Kafka/Redis)\n- Scheduled tasks (Cron)\n- Background jobs/workers\n- WebSocket / SSE long connections\n\n**High Frequency Workflow Example (Backend):**\n\n```\nNew endpoint: Define route → Parameter validation → Business logic → Database operation → Return response → Add tests\nNew data table: Design Schema → Create Migration → Write Model → Implement business logic → API integration\nNew scheduled task: Register Cron → Implement task logic → Logging & monitoring → Test & verify\n```\n\n---\n\n### V. Mini Program Specific\n\nLoad when WeChat/Alipay/Douyin mini program project is detected:\n\n#### A. Platform & Framework\n\n- Target platform(s) (WeChat/Alipay/Douyin/multi-platform)\n- Native vs cross-platform framework (Taro/uni-app)\n- Platform API difference handling\n\n#### B. Mini Program Architecture\n\n- Page and component structure\n- Global config (app.json/pages.json)\n- Custom component encapsulation\n- Subpackage strategy\n- Plugin usage\n\n#### C. User System & Auth\n\n- Login flow (wx.login etc.)\n- User info retrieval and storage\n- Session management\n- Integration with backend user system\n\n#### D. Publishing & Review\n\n- Review process and notes\n- Trial vs production release\n- Version management and rollback\n- Mini program code / share config\n\n#### E. Performance Optimization\n\n- Subpackage loading\n- Image lazy loading\n- setData optimization\n- Long list optimization\n- Custom component lazy loading\n\n**High Frequency Workflow Example (Mini Program):**\n\n```\nNew page: Register in pages.json → Create page directory → Implement page logic → Configure route → Submit trial version → Review\nNew component: Create component directory → Implement component → Import & use → Style isolation\nNew API: Wrap request method → Page call → Error handling → Loading state\n```\n\n---\n\n### VI. Mobile App Specific\n\nLoad when React Native / Flutter / SwiftUI / Kotlin project is detected:\n\n#### A. App Architecture\n\n- Framework used (React Native/Flutter/SwiftUI/Compose)\n- Architecture pattern (MVI/MVVM/Clean Architecture)\n- Modularization approach\n- Navigation system\n\n#### B. Native Modules & Bridge\n\n- Native module list and purposes\n- Bridge communication mechanism\n- How to add new native modules\n- Third-party native SDK integration\n\n#### C. State Management & Data Persistence\n\n- State management solution\n- Local storage (AsyncStorage/MMKV/SQLite/CoreData)\n- Offline strategy\n\n#### D. Release & App Store\n\n- Android: signing config (keystore)\n- iOS: certificate and profile management\n- Store submission process (App Store / Google Play)\n- Hot update solution (CodePush/EAS Update)\n- TestFlight / beta distribution\n\n#### E. Mobile-Specific Debugging\n\n- Physical device debugging\n- Performance profiling tools\n- Crash log collection\n- Network packet capture\n\n**High Frequency Workflow Example (Mobile App):**\n\n```\nNew page: Create page/Screen → Register route → Connect state → Connect navigation → Integration test API\nNew native module: Define Bridge interface → Implement Android/iOS native code → JS call wrapper → Test\nRelease flow: Build Android/iOS → Sign → Upload to store → Submit for review → Publish\n```\n\n---\n\n## Project Type Auto-Detection\n\nBefore analyzing, identify the project type via these signals (multi-select):\n\n**Frontend Web signals:**\n- `package.json` has react/vue/svelte/angular/next/nuxt\n- webpack.config/vite.config/tsconfig.json exists\n- public/index.html or index.html exists\n- src has pages/views/components/hooks/store directories\n\n**Desktop Client signals:**\n- `package.json` has electron/tauri\n- electron/ or src-tauri/ directory exists\n- Capacitor config file\n- Main process entry file\n\n**Backend Service signals:**\n- `package.json` has express/nest/fastify/koa (Node)\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- migration/ directory exists\n- Dockerfile / docker-compose.yml\n\n**Mini Program signals:**\n- app.json / pages.json / project.config.json\n- Taro/uni-app config\n- WeChat DevTools config file\n\n**Mobile App signals:**\n- android/ or ios/ directory\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift (RN/Flutter entry)\n- .xcodeproj / .xcworkspace\n\nInform user of detection result at the start of Stage 1. If inaccurate, user can manually specify.\n\n---\n\n## Output Strategy\n\n**Strictly stage-based output. Do NOT output everything at once.**\n\n### Stage 1 — Developer Quick Overview (Default)\n\n- Project type (auto-detected)\n- What the project is\n- How to start\n- Tech stack\n- Most important directories\n- Key standards\n- Environment system\n- Recommended reading order\n- High-risk areas\n\n**Goal: Build a project map within 10 minutes.**\n\n### Stage 2 — Universal Modules Deep Dive\n\nExpand directory navigation, engineering standards, team collaboration, environment & deployment etc. when user asks.\n\n### Stage 3 — Type-Specific Deep Dive\n\nExpand the corresponding type-specific module (Frontend Web / Backend / Client / Mini Program / Mobile) when user asks.\n\n### Stage 4 — Targeted Development Assistance\n\nSupport multi-round questions:\n\n- \"Which module should I reference for adding a new page?\"\n- \"How does the permission system work?\"\n- \"How is IPC communication debugged?\"\n- \"What's the release workflow?\"\n\n## Stage Stopping Conditions\n\n- After current stage output is complete, **⏸ pause and wait for user confirmation or follow-up**\n- At the end of each stage, provide clear next-step prompts, e.g.:\n  - 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.\"*\n  - End of Stage 2: *\"Universal modules expanded. For [project type] specific guide, say 'specific'. Or ask specific dev questions directly.\"*\n  - 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'.\"*\n- For insufficient-evidence content: briefly note and skip, don't force-fill\n- When tokens/context approach limits: output current progress and remaining plan\n\n## Input Validation\n\n### When Information Is Insufficient\n\nIf user only says \"help me set up\" or similar vague requests, don't guess or blindly execute:\n1. At minimum need one of: **project path / Git repo URL / currently open working directory**\n2. Ask: \"Which project would you like to analyze? Please provide the project path or repo URL.\"\n3. If user provides a path but project is empty or inaccessible: clearly inform and ask for confirmation\n\n### Handling Contradictory Requests\n\nWhen user makes conflicting goals (e.g., \"give me a complete architecture report\" but also \"keep it concise\"):\n1. Point out the contradiction: \"Complete architecture report and concise output conflict\"\n2. Suggest compromise: prioritize Stage 1 (quick overview), then go deeper as needed\n3. Let user choose priority\n\n### When Project Cannot Be Analyzed\n\nClearly inform user and stop analysis in these cases; do not force output:\n- Specified path doesn't exist or no access permissions\n- Project directory is empty\n- Cannot identify project type (no known signals)\n- Key config files (e.g., package.json) are corrupted or unreadable\n\n---\n\n## Important Constraints\n\n### Don't:\n- Generate lengthy unfocused reports\n- Explain basic programming knowledge\n- Mechanically list all files\n- Output meaningless directory trees\n- Discuss component systems for backend projects, ORM for frontend projects\n- Ignore development workflows and team collaboration\n\n### Must:\n- Core focus on development efficiency\n- Tailor content by project type, only load relevant modules\n- Emphasize engineering practices and actual development workflows\n- Emphasize \"how to actually start developing\"\n- Support multi-round progressive exploration\n\n## Execution Tool Guide\n\nEvery analysis step should be backed by concrete tool execution, not fabricated output:\n\n### Project Type Detection — Actions\n1. `read {project}/package.json` → extract dependencies, match frontend/client/Node backend signals\n2. `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\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → desktop client signals\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → mobile signals\n5. Multiple signals → treat as mixed project, load all matching modules\n\n### Stage 1 Quick Overview — Actions\n1. `read {project}/package.json` or `Cargo.toml` or `go.mod` → tech stack\n2. `exec ls {project}/` → directory structure overview\n3. `read {project}/README.md` → project purpose (if exists)\n4. `read {project}/.env.example` → environment variables (if exists)\n\n### Stage 2 Universal Modules — Actions\n1. `exec find {project}/src -type d -maxdepth 2` → directory structure\n2. `read {project}/src/index.*` or `main.*` → entry file\n3. `exec find {project} -name \"Dockerfile\" -o -name \"docker-compose*\" | head -3` → deployment\n\n### Stage 3 Type-Specific — Select by Type\n**Frontend Web:** `find` for router/store/api files\n**Backend:** `find` for migration/middleware/controller files\n**Desktop Client:** `read` main process entry + `find` preload/bridge\n\n### Large Project Strategy\nWhen `exec find {project} -type f | wc -l` exceeds 200: build index first, only read P0 files, deep-dive core chain only.\n\n### Output Format\nEach Stage: `# [Project Name] — Stage N: [Title]` with structured headings + `## ⏸ Next Steps` at end.\n- Emphasize \"how to actually start developing\"\n- Support multi-round progressive exploration\n\n## Ideal Outcome\n\nAfter using this skill, an experienced developer should be able to:\n\n- Successfully start the project\n- Understand project structure and type-specific architecture\n- Find core modules\n- Understand engineering standards\n- Safely develop features\n- Correctly use type-specific capabilities (components/API/IPC/native modules etc.)\n- Complete QA submission and release\n- Know where to dive deeper\n\nUltimate achievement: **\"I'm ready to start participating in project development.\"**\n\nFile v1.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn76af6ccjftr7hsds21j60xnn82q1qd\",\n  \"slug\": \"project-onboarding\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1778938349869\n}\n\nArchive v1.1.0: 2 files, 14420 bytes\n\nFiles: SKILL.md (34730b), _meta.json (137b)\n\nFile v1.1.0:SKILL.md\n\n---\nname: project-onboarding\nversion: \"1.1.0\"\nhomepage: https://github.com/z-Zihan/awesome-skills\ndescription: >\n  帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、\n  客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出\n  项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。\n  触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门, onboarding,\n  如何开发, 怎么启动项目, 项目怎么跑, 开发流程, onboarding guide,\n  how to onboard, project handover, developer quick start.\n  NOT for: generating long architecture reports, code analysis without dev context,\n  beginner programming tutorials, onboarding for interns.\n---\n\n# project-onboarding — 项目接手指南\n\n## 语言规则\n\n**检测用户使用的语言，全程使用同一语言输出。** 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（React、Electron、IPC 等）保留原文即可。\n\n---\n\n# 中文版\n\n帮助有经验的开发者快速理解并接手一个陌生项目，尽快具备实际开发能力。\n\n## 支持的项目类型\n\n按优先级排序：\n\n| 类型 | 识别信号 | 专项模块 |\n|---|---|---|\n| **前端 Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | 组件体系、路由、状态管理、CSS 方案、API 集成、浏览器兼容 |\n| **后端服务** | Express/Nest/Django/Spring/Gin, ORM/migration | 数据库 Schema、ORM、中间件链、API 设计、认证鉴权、缓存与队列 |\n| **客户端** | Electron/Tauri/Capacitor, 主进程/渲染进程 | 主进程架构、渲染进程、IPC 通信、原生能力、签名与分发、自动更新 |\n| **小程序** | 微信/支付宝/抖音小程序, app.json/pages.json | 平台适配、分包策略、审核流程、原生能力调用、用户体系 |\n| **移动端** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | 原生模块 Bridge、热更新、应用签名、应用商店发布、权限管理 |\n\n**多类型混合项目**（如 Electron + Vue、Tauri + React）：同时加载对应专项模块，按优先级排序。\n\n> **扩展指南**：新增项目类型时，需要同步更新三个位置：\n> 1. 上方「支持的项目类型」表格\n> 2. 「项目类型自动识别」信号列表\n> 3. 对应的专项模块章节（新增或复用）\n> 建议保持模块命名和排序的一致性。\n\n## 这个 Skill 不是\n\n- 面向编程新手\n- 面向实习生教学\n- 面向基础知识解释\n- 面向纯代码分析\n\n## 核心目标\n\n让专业开发者在最短时间内完成：\n\n- 项目理解\n- 工程结构理解\n- 开发流程理解\n- 团队规范理解\n- 环境体系理解\n- 项目类型特有的核心能力理解\n- 发布流程理解\n- 调试与开发能力建立\n\n最终达到：\n\n**\"开发者已经可以开始安全地开发功能并参与协作。\"**\n\n## 语言策略\n\n- 默认输出中文，同时提供英文版本\n- 中文优先\n\n## 核心原则\n\n### 1. 以\"快速进入开发状态\"为最高优先级\n\n优先帮助开发者理解：\n\n- 项目如何运行\n- 功能如何开发\n- 项目类型特有的核心机制\n- 目录如何组织\n- 环境如何切换\n- 如何调试\n- 如何发版\n- 如何避免踩坑\n\n**而不是：**\n\n- 生成超长架构分析报告\n- 输出无意义目录树\n- 罗列所有源码文件\n\n### 2. 避免一次性信息轰炸\n\n- 分阶段输出\n- 优先级排序\n- 保持简洁\n- 支持多轮渐进式探索\n\n### 3. 模拟\"资深工程师带新人\"\n\n你的角色不是代码分析器，而是团队里的资深工程师在带一个有经验的新同事。\n\n重点关注：\n\n- 实际开发流程\n- 隐式规范\n- 高风险区域\n- 常见坑\n- 推荐参考模块\n\n### 4. 证据优先，不假装理解\n\n- 所有结论基于仓库真实证据\n- 仓库中没有的规范或机制，不要编造\n- 区分：已确认事实 / 合理推断 / 证据不足\n\n### 5. 按项目类型裁剪内容\n\n- 只分析与当前项目类型相关的模块\n- 不要给后端项目讲组件体系，不要给前端项目讲 ORM\n- 混合项目按优先级排序专项模块\n\n---\n\n## 分析模块\n\n### 一、通用模块（所有项目类型）\n\n以下模块适用于任何项目类型，按分析顺序排列：\n\n#### 1. 项目概览\n\n- 项目用途与业务领域\n- 项目类型（自动识别）\n- 核心能力与主要模块\n- 技术栈\n- 系统架构\n- 外部依赖\n- 核心链路\n\n#### 2. 开发快速启动\n\n- 如何安装依赖\n- 如何启动项目\n- 本地开发命令\n- 如何切换环境\n- 必需环境变量\n- 如何本地调试\n- 如何运行测试\n- 如何构建\n\n#### 3. 项目目录导航\n\n必须说明：\n\n- 为什么这样组织\n- 哪些目录最重要\n- 哪些目录最常修改\n- 哪些目录风险最高\n- 哪些属于基础设施\n\n#### 4. 工程规范\n\n- 命名规范\n- 目录规范\n- 代码组织方式\n- commit 规范\n- lint/format 规范\n- 测试规范\n- 错误处理规范\n- 隐式规范（README 没写但团队默认遵守的规则）\n\n#### 5. 环境与部署体系\n\n- 环境列表（local/dev/test/staging/production 等）\n- 环境如何切换\n- 配置如何管理\n- CI/CD 流程\n- 如何发版 / 如何提测 / 如何回滚\n\n#### 6. 团队协作流程\n\n- 分支策略\n- PR / Code Review 流程\n- QA / UAT 流程\n\n#### 7. 高频开发路径\n\n总结团队最常见的开发套路（按项目类型定制示例）\n\n#### 8. 推荐参考模块\n\n- 最规范的模块\n- 最推荐模仿的实现\n- 入口文件\n\n#### 9. 危险区域识别\n\n- 哪些区域改动风险高\n- 哪些代码耦合严重\n- 哪些模块容易引发线上问题\n\n---\n\n### 二、前端 Web 专项\n\n当识别到前端 Web 项目时加载：\n\n#### A. 组件体系与 UI 基础设施\n\n- 内部组件库\n- 第三方组件库\n- layout 系统 / icon 系统 / theme 系统\n- 通用业务组件\n- 哪些组件应优先复用\n- 新组件放哪里\n\n#### B. 路由系统\n\n- 路由如何组织\n- 路由守卫与权限\n- 动态路由 / 懒加载\n- 新增页面的路由配置方式\n\n#### C. 状态管理\n\n- 使用的方案（Redux/Pinia/Zustand/Jotai 等）\n- 全局状态 vs 局部状态的划分策略\n- store 如何组织\n- 新功能应该用全局还是局部状态\n\n#### D. CSS 与样式方案\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- 设计系统 / token 体系\n- 样式约定\n\n#### E. API 集成\n\n- 请求层如何封装\n- token/auth 如何工作\n- 错误拦截机制\n- mock 策略\n- 新接口应该如何接入\n\n**高频开发路径示例（前端 Web）：**\n\n```\n新增页面: 新增 route → 新增 page → 新增 API → 接入 store → 接入权限 → 配置菜单 → 提测 → 发版\n新增接口: 定义 API → request 封装 → 类型定义 → hooks/store 接入 → 页面消费 → 错误处理\n新增组件: 放入 shared/components → 补充 story/test → theme 适配 → 权限处理\n```\n\n---\n\n### 三、客户端专项\n\n当识别到 Electron / Tauri / Capacitor 等客户端项目时加载：\n\n#### A. 进程架构\n\n**Electron 项目：**\n- 主进程（Main Process）职责与入口\n- 渲染进程（Renderer Process）架构\n- 预加载脚本（Preload）与 contextBridge\n- 多窗口管理\n- 进程间通信（IPC）设计\n\n**Tauri 项目：**\n- 前端层（WebView）\n- Rust 后端层（Tauri Commands）\n- IPC 通信方式（invoke/listen）\n- 插件系统\n- 安全策略（allowlist/CSP）\n\n#### B. 原生能力集成\n\n- 文件系统操作（读写、对话框）\n- 系统托盘与通知\n- 剪贴板 / 屏幕截图 / 全局快捷键\n- 网络状态监听\n- 系统信息获取\n- 原生模块（Node Addons / Rust FFI）\n\n#### C. 签名与分发\n\n- 开发者证书与签名配置\n- macOS: codesign + notary / Windows: 签名证书\n- 自动更新机制（autoUpdater）\n- 更新服务器配置\n- 各平台分发渠道（App Store / Microsoft Store / 自建）\n\n#### D. 构建与打包\n\n- 构建命令与配置\n- 多平台构建（macOS arm64/x64 / Windows x64）\n- 安装包格式（DMG/EXE/MSI/AppImage）\n- 构建时间优化\n- CI/CD 中的构建流程\n\n#### E. 客户端特有调试\n\n- 主进程调试\n- 渲染进程调试（DevTools）\n- IPC 通信调试\n- 原生能力调试\n- 性能分析（CPU/内存/启动速度）\n\n**高频开发路径示例（客户端）：**\n\n```\n新增功能: 前端开发 → IPC 通信定义 → 主进程/Rust 命令实现 → 联调 → 测试 → 构建\n新增原生能力: 调研 API → 实现 IPC 命令 → 前端调用封装 → 错误处理 → 多平台测试\n发版流程: 构建多平台 → 签名 → 公证 → 上传更新服务器 → 灰度 → 全量\n```\n\n---\n\n### 四、后端服务专项\n\n当识别到 Express/Nest/Django/Spring/Gin 等后端服务项目时加载：\n\n#### A. 数据库与存储\n\n- 使用的数据库（MySQL/PostgreSQL/MongoDB/Redis 等）\n- ORM/Query Builder（Prisma/TypeORM/Sequelize/GORM 等）\n- Migration 策略\n- 数据库 Schema 设计思路\n- 缓存策略（Redis/Memcached）\n- 文件存储（OSS/S3/本地）\n\n#### B. 中间件与请求处理\n\n- 中间件链与执行顺序\n- 认证与鉴权（JWT/Session/OAuth）\n- 请求验证与参数校验\n- 日志策略\n- 限流与熔断\n\n#### C. API 设计\n\n- RESTful / GraphQL / gRPC / tRPC\n- API 版本管理\n- 错误码体系\n- 文档生成（Swagger/OpenAPI）\n- 请求/响应格式约定\n\n#### D. 异步与任务处理\n\n- 消息队列（RabbitMQ/Kafka/Redis）\n- 定时任务（Cron）\n- 后台任务/Worker\n- WebSocket / SSE 长连接\n\n**高频开发路径示例（后端）：**\n\n```\n新增接口: 定义路由 → 参数校验 → 业务逻辑 → 数据库操作 → 返回响应 → 补充测试\n新增数据表: 设计 Schema → 创建 Migration → 编写 Model → 实现业务逻辑 → API 接入\n新增定时任务: 注册 Cron → 实现任务逻辑 → 日志与监控 → 测试验证\n```\n\n---\n\n### 五、小程序专项\n\n当识别到微信/支付宝/抖音小程序项目时加载：\n\n#### A. 平台与框架\n\n- 目标平台（微信/支付宝/抖音/多端）\n- 使用原生还是跨端框架（Taro/uni-app）\n- 平台 API 差异处理\n\n#### B. 小程序架构\n\n- 页面与组件结构\n- 全局配置（app.json/pages.json）\n- 自定义组件封装\n- 分包策略\n- 插件使用\n\n#### C. 用户体系与登录\n\n- 登录流程（wx.login 等）\n- 用户信息获取与存储\n- Session 管理\n- 与后端用户系统的对接\n\n#### D. 发布与审核\n\n- 审核流程与注意事项\n- 体验版 / 正式版 发布\n- 版本管理与回滚\n- 小程序码 / 分享配置\n\n#### E. 性能优化\n\n- 分包加载\n- 图片懒加载\n- setData 优化\n- 长列表优化\n- 自定义组件懒加载\n\n**高频开发路径示例（小程序）：**\n\n```\n新增页面: pages.json 注册 → 创建页面目录 → 实现页面逻辑 → 配置路由 → 提交体验版 → 审核\n新增组件: 创建组件目录 → 实现 component → 引入使用 → 样式隔离\n新增接口: 封装请求方法 → 页面调用 → 错误处理 → 加载态\n```\n\n---\n\n### 六、移动端专项\n\n当识别到 React Native / Flutter / SwiftUI / Kotlin 等移动端项目时加载：\n\n#### A. 应用架构\n\n- 使用的框架（React Native/Flutter/SwiftUI/Compose）\n- 架构模式（MVI/MVVM/Clean Architecture）\n- 模块化方案\n- 导航系统\n\n#### B. 原生模块与 Bridge\n\n- 原生模块列表与用途\n- Bridge 通信机制\n- 如何新增原生模块\n- 第三方原生 SDK 集成方式\n\n#### C. 状态管理与数据持久化\n\n- 状态管理方案\n- 本地存储（AsyncStorage/MMKV/SQLite/CoreData）\n- 离线策略\n\n#### D. 发布与应用商店\n\n- Android: 签名配置（keystore）\n- iOS: 证书与 Profile 管理\n- 应用商店提交流程（App Store / Google Play）\n- 热更新方案（CodePush/EAS Update）\n- TestFlight / 内测分发\n\n#### E. 移动端特有调试\n\n- 真机调试流程\n- 性能分析工具\n- 崩溃日志收集\n- 网络抓包\n\n**高频开发路径示例（移动端）：**\n\n```\n新增页面: 创建页面/Screen → 注册路由 → 接入状态 → 接入导航 → 联调接口\n新增原生模块: 定义 Bridge 接口 → 实现 Android/iOS 原生代码 → JS 调用封装 → 测试\n发版流程: 构建 Android/iOS → 签名 → 上传商店 → 提交审核 → 发布\n```\n\n---\n\n## 项目类型自动识别\n\n分析项目前，先通过以下信号识别项目类型（可多选）：\n\n**前端 Web 信号：**\n- `package.json` 中有 react/vue/svelte/angular/next/nuxt\n- 存在 webpack.config/vite.config/tsconfig.json\n- 存在 public/index.html 或 index.html\n- src 下有 pages/views/components/hooks/store 目录\n\n**客户端信号：**\n- `package.json` 中有 electron/tauri\n- 存在 electron/ 目录或 src-tauri/ 目录\n- Capacitor 配置文件\n- main process 入口文件\n\n**后端服务信号：**\n- `package.json` 中有 express/nest/fastify/koa（Node）\n- go.mod / requirements.txt / pom.xml / Cargo.toml\n- 存在 migration/ 目录\n- Dockerfile / docker-compose.yml\n\n**小程序信号：**\n- app.json / pages.json / project.config.json\n- Taro/uni-app 配置\n- 微信开发者工具配置文件\n\n**移动端信号：**\n- android/ 或 ios/ 目录\n- Podfile / build.gradle / pubspec.yaml\n- App.tsx/AppDelegate.swift（RN/Flutter 入口）\n- .xcodeproj / .xcworkspace\n\n识别结果在 Stage 1 开头明确告知用户，如果识别不准确，用户可以手动指定。\n\n---\n\n## 输出策略\n\n**严格分阶段输出，不要一次输出全部内容。**\n\n### Stage 1 — 开发者快速总览（默认）\n\n- 项目类型（自动识别结果）\n- 项目是什么\n- 如何启动\n- 技术栈\n- 最重要目录\n- 关键规范\n- 环境体系\n- 推荐阅读顺序\n- 高风险区域\n\n**目标：让开发者 10 分钟内建立项目地图。**\n\n### Stage 2 — 通用模块深入\n\n用户追问时展开目录导航、工程规范、团队协作、环境部署等通用模块。\n\n### Stage 3 — 项目类型专项深入\n\n用户追问时展开对应项目类型的专项模块（前端 Web / 后端 / 客户端 / 小程序 / 移动端）。\n\n### Stage 4 — 定向开发辅助\n\n支持多轮追问：\n\n- \"新增页面应该参考哪个模块？\"\n- \"权限系统怎么做的？\"\n- \"IPC 通信怎么调的？\"\n- \"发版流程是什么？\"\n\n## 每个阶段的停止条件\n\n- 当前阶段内容输出完毕后，**⏸ 暂停等待用户确认或追问**\n- 每个阶段结束时，给出明确的下一步提示，例如：\n  - Stage 1 结束：*\"以上是项目快速总览。如需深入了解工程规范、目录导航等，请告诉我。如需查看[项目类型]专项指南，请说「专项」。如要开始某个具体开发任务，直接说即可。\"*\n  - Stage 2 结束：*\"通用模块已展开。如需查看[项目类型]专项指南，请说「专项」。或直接问具体的开发问题。\"*\n  - Stage 3 结束：*\"专项指南已展开。可以直接问具体开发问题，如「新增页面怎么做」「发版流程是什么」等。\"*\n- 证据不足的内容：简单说明后跳过，不要强行填充\n- Token/上下文接近上限时：输出当前进度和剩余计划\n\n## 输入验证\n\n### 信息不足时\n\n如果用户只说了\"帮我搞一下\"或类似模糊请求，不要猜测或胡乱执行：\n1. 至少需要以下信息之一：**项目路径 / Git 仓库地址 / 已打开的工作目录**\n2. 询问：\"请问要分析哪个项目？请提供项目路径或仓库地址。\"\n3. 如果用户提供了路径但项目为空或无法访问：明确告知并请求确认\n\n### 矛盾请求处理\n\n当用户同时提出冲突目标时（如\"给我完整架构报告\"但又要求\"保持简洁\"）：\n1. 指出矛盾：\"完整架构报告与简洁输出存在矛盾\"\n2. 建议折中方案：优先 Stage 1（快速总览），再按需深入\n3. 让用户选择优先级\n\n### 项目无法分析时\n\n以下情况应明确告知用户并停止分析，不要强行输出：\n- 指定路径不存在或无访问权限\n- 项目目录为空\n- 无法识别项目类型（无任何已知信号）\n- 关键配置文件（如 package.json）损坏或不可读\n\n---\n\n## 重要限制\n\n### 不要：\n- 生成超长无重点报告\n- 解释基础编程知识\n- 机械列举所有文件\n- 输出没有意义的目录树\n- 给后端项目讲组件体系，给前端项目讲 ORM\n- 忽略开发流程和团队协作\n\n### 必须：\n- 以开发效率为核心\n- 按项目类型裁剪内容，只加载相关模块\n- 强调工程实践和实际开发流程\n- 强调\"如何真正开始开发\"\n- 支持多轮渐进式探索\n\n## 理想结果\n\n使用这个 skill 后，一个有经验的开发者应该能够：\n\n- 成功启动项目\n- 理解项目结构与项目类型特有架构\n- 找到核心模块\n- 理解工程规范\n- 能够安全开发功能\n- 能够正确使用项目类型特有能力（组件/API/IPC/原生模块等）\n- 能够完成提测与发版\n- 知道应该继续深入哪里\n\n最终达到：**\"我已经可以开始参与项目开发了。\"**\n\n---\n---\n\n# English Version\n\nHelp experienced developers quickly understand and onboard onto an unfamiliar project, achieving actual development capability as fast as possible.\n\n## Supported Project Types\n\nPriority order:\n\n| Type | Detection Signals | Specific Modules |\n|---|---|---|\n| **Frontend Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | Component system, routing, state management, CSS approach, API integration, browser compatibility |\n| **Backend Service** | Express/Nest/Django/Spring/Gin, ORM/migration | Database Schema, ORM, middleware chain, API design, auth, caching & queues |\n| **Desktop Client** | Electron/Tauri/Capacitor, main/renderer process | Main process architecture, renderer process, IPC, native capabilities, signing & distribution, auto-update |\n| **Mini Program** | WeChat/Alipay/Douyin mini program, app.json/pages.json | Platform adaptation, subpackage strategy, review process, native API calls, user system |\n| **Mobile App** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | Native module Bridge, hot update, app signing, app store publishing, permission management |\n\n**Mixed-type projects** (e.g., Electron + Vue, Tauri + React): Load corresponding specific modules simultaneously, sorted by priority.\n\n> **Extension guide**: When adding new project types, update three places in sync:\n> 1. The \"Supported Project Types\" table above\n> 2. The \"Project Type Auto-Detection\" signal list\n> 3. The corresponding specific module section (new or reuse)\n> Maintain consistent module naming and ordering.\n\n## This Skill Is NOT\n\n- For programming beginners\n- For intern training\n- For explaining basic programming concepts\n- For pure code analysis\n\n## Core Objective\n\nEnable a professional developer to achieve the following in minimum time:\n\n- Project understanding\n- Engineering structure understanding\n- Development workflow understanding\n- Team standards understanding\n- Environment system understanding\n- Type-specific core capabilities understanding\n- Release workflow understanding\n- Debug and development capability\n\nUltimate goal:\n\n**\"The developer is ready to safely develop features and collaborate.\"**\n\n## Language Strategy\n\n- Default to user's language, also provide the other language version\n- Follow user's language preference\n\n## Core Principles\n\n### 1. \"Fast to Development-Ready\" is the Highest Priority\n\nPrioritize helping developers understand:\n\n- How the project runs\n- How to develop features\n- Type-specific core mechanisms\n- How directories are organized\n- How to switch environments\n- How to debug\n- How to release\n- How to avoid common pitfalls\n\n**Instead of:**\n\n- Generating lengthy architecture reports\n- Outputting meaningless directory trees\n- Listing all source files\n\n### 2. Avoid Information Overload\n\n- Output in stages\n- Sort by priority\n- Keep concise\n- Support multi-round progressive exploration\n\n### 3. Simulate \"Senior Engineer Onboarding a New Colleague\"\n\nYour role is not a code analyzer — it's a senior engineer helping an experienced new colleague onboard.\n\nFocus on:\n\n- Actual development workflows\n- Implicit team conventions\n- High-risk areas\n- Common pitfalls\n- Recommended reference modules\n\n### 4. Evidence First, Don't Fake Understanding\n\n- All conclusions based on real repo evidence\n- Don't fabricate standards or mechanisms not in the repo\n- Distinguish: confirmed facts / reasonable inference / insufficient evidence\n\n### 5. Tailor Content by Project Type\n\n- Only analyze modules relevant to the project type\n- Don't discuss component systems for backend projects, don't discuss ORM for frontend projects\n- Mixed projects sort specific modules by priority\n\n---\n\n## Analysis Modules\n\n### I. Universal Modules (All Project Types)\n\nThese modules apply to any project type, in analysis order:\n\n#### 1. Project Overview\n\n- Project purpose and business domain\n- Project type (auto-detected)\n- Core capabilities and main modules\n- Tech stack\n- System architecture\n- External dependencies\n- Core chain\n\n#### 2. Developer Quick Start\n\n- How to install dependencies\n- How to start the project\n- Local dev commands\n- How to switch environments\n- Required environment variables\n- How to debug locally\n- How to run tests\n- How to build\n\n#### 3. Repository Navigation\n\nMust explain:\n\n- Why organized this way\n- Which directories are most important\n- Which are most frequently modified\n- Which are highest risk\n- Which are infrastructure\n\n#### 4. Engineering Standards\n\n- Naming conventions\n- Directory conventions\n- Code organization style\n- Commit conventions\n- Linting/formatting rules\n- Testing conventions\n- Error handling patterns\n- Implicit standards (unwritten but team-default rules)\n\n#### 5. Environment & Deployment\n\n- Environment list (local/dev/test/staging/production etc.)\n- How to switch environments\n- How configs are managed\n- CI/CD pipeline\n- How to release / submit for QA / how to rollback\n\n#### 6. Team Workflow\n\n- Branching strategy\n- PR / Code Review workflow\n- QA / UAT workflow\n\n#### 7. High Frequency Development Workflow\n\nSummarize most common development patterns (examples tailored by project type)\n\n#### 8. Recommended References\n\n- Most standard module\n- Best implementation to imitate\n- Entry files\n\n#### 9. Risk Areas\n\n- Which areas are high-risk\n- Which code is heavily coupled\n- Which modules easily cause production issues\n\n---\n\n### II. Frontend Web Specific\n\nLoad when Frontend Web project is detected:\n\n#### A. Component System & UI Infrastructure\n\n- Internal component library\n- Third-party components\n- Layout system / icon system / theme system\n- Common business components\n- Which components to reuse\n- Where to put new components\n\n#### B. Routing System\n\n- How routes are organized\n- Route guards and permissions\n- Dynamic routes / lazy loading\n- How to add route for a new page\n\n#### C. State Management\n\n- Solution used (Redux/Pinia/Zustand/Jotai etc.)\n- Global vs local state strategy\n- How stores are organized\n- When to use global vs local\n\n#### D. Styling Approach\n\n- CSS Modules / Tailwind / CSS-in-JS / styled-components / SCSS\n- Design system / token system\n- Styling conventions\n\n#### E. API Integration\n\n- How request layer is encapsulated\n- How token/auth works\n- Error interception\n- Mock strategy\n- How to integrate new APIs\n\n**High Frequency Workflow Example (Frontend Web):**\n\n```\nNew page: Add route → Add page → Add API → Connect store → Add permissions → Configure menu → Submit for QA → Release\nNew API: Define \n\nArchive v0.1.99: 2 files, 11136 bytes\n\nFiles: SKILL.md (24597b), _meta.json (138b)\n\nArchive v0.1.92: 2 files, 11123 bytes\n\nFiles: SKILL.md (24580b), _meta.json (138b)\n\nArchive v0.1.43: 2 files, 10258 bytes\n\nFiles: SKILL.md (22553b), _meta.json (138b)\n\nArchive v0.1.42: 2 files, 10253 bytes\n\nFiles: SKILL.md (22553b), _meta.json (138b)\n\nArchive v0.1.26: 2 files, 7182 bytes\n\nFiles: SKILL.md (15226b), _meta.json (138b)","readmeExcerpt":"Skill: Project Onboarding Owner: z-zihan Summary: 帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、 客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出 项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。 触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门,... Tags: latest:2.0.0 Version history: v2.0.0 | 2026-05-18T12:47:54.003Z | user Auto-publish from commit dc4421fe7970ce27a9e172af29c59ab38d8373a3 v0.3.0 | 2026-05-18T08:11:02.001Z | user Auto-publish from commit 5","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"# [项目名] — Stage N: [阶段名]\n\n## 项目类型\n[类型]（识别信号：[列出检测到的信号]）\n\n## [各分析维度]\n...\n\n## ⏸ 下一步\n[提示用户可以深入的方向]"},{"language":"text","snippet":"新增页面: 新增 route → 新增 page → 新增 API → 接入 store → 接入权限 → 配置菜单 → 提测 → 发版\n新增接口: 定义 API → request 封装 → 类型定义 → hooks/store 接入 → 页面消费 → 错误处理\n新增组件: 放入 shared/components → 补充 story/test → theme 适配 → 权限处理"},{"language":"text","snippet":"新增功能: 前端开发 → IPC 通信定义 → 主进程/Rust 命令实现 → 联调 → 测试 → 构建\n新增原生能力: 调研 API → 实现 IPC 命令 → 前端调用封装 → 错误处理 → 多平台测试\n发版流程: 构建多平台 → 签名 → 公证 → 上传更新服务器 → 灰度 → 全量"},{"language":"text","snippet":"新增接口: 定义路由 → 参数校验 → 业务逻辑 → 数据库操作 → 返回响应 → 补充测试\n新增数据表: 设计 Schema → 创建 Migration → 编写 Model → 实现业务逻辑 → API 接入\n新增定时任务: 注册 Cron → 实现任务逻辑 → 日志与监控 → 测试验证"},{"language":"text","snippet":"新增页面: pages.json 注册 → 创建页面目录 → 实现页面逻辑 → 配置路由 → 提交体验版 → 审核\n新增组件: 创建组件目录 → 实现 component → 引入使用 → 样式隔离\n新增接口: 封装请求方法 → 页面调用 → 错误处理 → 加载态"},{"language":"text","snippet":"新增页面: 创建页面/Screen → 注册路由 → 接入状态 → 接入导航 → 联调接口\n新增原生模块: 定义 Bridge 接口 → 实现 Android/iOS 原生代码 → JS 调用封装 → 测试\n发版流程: 构建 Android/iOS → 签名 → 上传商店 → 提交审核 → 发布"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: project-onboarding\nversion: \"2.0.0\"\nhomepage: https://github.com/z-Zihan/awesome-skills\ndescription: >\n  帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、\n  客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出\n  项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。\n  触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门, onboarding,\n  如何开发, 怎么启动项目, 项目怎么跑, 开发流程, onboarding guide,\n  how to onboard, project handover, developer quick start.\n  NOT for: generating long architecture reports, code analysis without dev context,\n  beginner programming tutorials, onboarding for interns.\n---\n\n# project-onboarding — 项目接手指南\n\n## 语言规则\n\n**检测用户使用的语言，全程使用同一语言输出。** 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（React、Electron、IPC 等）保留原文即可。\n\n---\n\n# 中文版\n\n帮助有经验的开发者快速理解并接手一个陌生项目，尽快具备实际开发能力。\n\n## 支持的项目类型\n\n按优先级排序：\n\n| 类型 | 识别信号 | 专项模块 |\n|---|---|---|\n| **前端 Web** | React/Vue/Svelte/Angular, webpack/vite/nextjs | 组件体系、路由、状态管理、CSS 方案、API 集成、浏览器兼容 |\n| **后端服务** | Express/Nest/Django/Spring/Gin, ORM/migration | 数据库 Schema、ORM、中间件链、API 设计、认证鉴权、缓存与队列 |\n| **客户端** | Electron/Tauri/Capacitor, 主进程/渲染进程 | 主进程架构、渲染进程、IPC 通信、原生能力、签名与分发、自动更新 |\n| **小程序** | 微信/支付宝/抖音小程序, app.json/pages.json | 平台适配、分包策略、审核流程、原生能力调用、用户体系 |\n| **移动端** | React Native/Flutter/SwiftUI/Kotlin, podfile/gradle | 原生模块 Bridge、热更新、应用签名、应用商店发布、权限管理 |\n\n**多类型混合项目**（如 Electron + Vue、Tauri + React）：同时加载对应专项模块，按优先级排序。\n\n> **扩展指南**：新增项目类型时，需要同步更新三个位置：\n> 1. 上方「支持的项目类型」表格\n> 2. 「项目类型自动识别」信号列表\n> 3. 对应的专项模块章节（新增或复用）\n> 建议保持模块命名和排序的一致性。\n\n## 这个 Skill 不是\n\n- 面向编程新手\n- 面向实习生教学\n- 面向基础知识解释\n- 面向纯代码分析\n\n## 核心目标\n\n让专业开发者在最短时间内完成：\n\n- 项目理解\n- 工程结构理解\n- 开发流程理解\n- 团队规范理解\n- 环境体系理解\n- 项目类型特有的核心能力理解\n- 发布流程理解\n- 调试与开发能力建立\n\n最终达到：\n\n**\"开发者已经可以开始安全地开发功能并参与协作。\"**\n\n## 语言策略\n\n- 默认输出中文，同时提供英文版本\n- 中文优先\n\n## 核心原则\n\n### 1. 以\"快速进入开发状态\"为最高优先级\n\n优先帮助开发者理解：\n\n- 项目如何运行\n- 功能如何开发\n- 项目类型特有的核心机制\n- 目录如何组织\n- 环境如何切换\n- 如何调试\n- 如何发版\n- 如何避免踩坑\n\n**而不是：**\n\n- 生成超长架构分析报告\n- 输出无意义目录树\n- 罗列所有源码文件\n\n### 2. 避免一次性信息轰炸\n\n- 分阶段输出\n- 优先级排序\n- 保持简洁\n- 支持多轮渐进式探索\n\n### 3. 模拟\"资深工程师带新人\"\n\n你的角色不是代码分析器，而是团队里的资深工程师在带一个有经验的新同事。\n\n重点关注：\n\n- 实际开发流程\n- 隐式规范\n- 高风险区域\n- 常见坑\n- 推荐参考模块\n\n### 4. 证据优先，不假装理解\n\n- 所有结论基于仓库真实证据\n- 仓库中没有的规范或机制，不要编造\n- 区分：已确认事实 / 合理推断 / 证据不足\n\n### 5. 按项目类型裁剪内容\n\n- 只分析与当前项目类型相关的模块\n- 不要给后端项目讲组件体系，不要给前端项目讲 ORM\n- 混合项目按优先级排序专项模块\n\n## 执行工具指引\n\n本 Skill 的每个分析步骤都应配合具体工具执行，而非凭空\"编\"输出：\n\n### 项目类型识别 — 执行动作\n\n1. `read {project}/package.json` → 提取 dependencies 和 devDependencies，匹配前端/客户端/Node 后端信号\n2. `exec find {project} -maxdepth 2 -name \"*.config.*\" -o -name \"go.mod\" -o -name \"Cargo.toml\" -o -name \"pom.xml\" -o -name \"app.json\"` → 识别后端/小程序/移动端信号\n3. `exec ls {project}/src-tauri/ {project}/electron/ 2>/dev/null` → 客户端信号\n4. `exec ls {project}/android/ {project}/ios/ 2>/dev/null` → 移动端信号\n5. 多信号命中时 → 按混合项目处理，所有匹配的专项模块均加载\n\n### Stage 1 快速总览 — 执行动作\n\n1. `read {project}/package.json` 或 `Cargo.toml` 或 `go.mod` → 技术栈\n2. `exec ls {project}/` → 目录结构概览\n3. `read {project}/README.md` → 项目用途（如存在）\n4. `read {project}/.env.example` → 环境变量（如存在）\n5. `exec find {project} -name \"*.config.*\" -maxdepth 1` → 构建配置\n\n### Stage 2 通用模块深入 — 执行动作\n\n1. `exec find"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn76af6ccjftr7hsds21j60xnn82q1qd\",\n  \"slug\": \"project-onboarding\",\n  \"version\": \"2.0.0\",\n  \"publishedAt\": 1779108474003\n}"},{"path":"skill-card.md","content":"## Description:\n\nHelps experienced developers quickly onboard to unfamiliar software projects by identifying project type and producing staged, evidence-based development guidance.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[z-zihan](https://clawhub.ai/user/z-zihan)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to get a fast, practical onboarding map for an unfamiliar repository, including project type, startup flow, directory navigation, engineering standards, risk areas, and type-specific development paths.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Project paths may be inserted into shell commands during repository inspection.\n\nMitigation: Constrain analysis to approved workspace paths, use safe argument passing, and require user confirmation before commands that inspect or execute against a supplied path.\n\nRisk: Repository URLs may be supplied without a defined safe fetch workflow.\n\nMitigation: Only fetch trusted repositories in a sandboxed workspace, confirm the URL with the user, and review files before running any project commands.\n\n## Reference(s):\n\n- [Project Onboarding ClawHub listing](https://clawhub.ai/z-zihan/skills/project-onboarding)\n- [Homepage from ClawHub metadata](https://github.com/z-Zihan/awesome-skills)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, guidance]\n\n**Output Format:** [Staged Markdown onboarding guidance with command examples and repository findings]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Adapts output language to the user and pauses between staged analysis passes.]\n\n## Skill Version(s):\n\n2.0.0 (source: frontmatter and ClawHub release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、 客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出 项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。 触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门,... Skill: Project Onboarding Owner: z-zihan Summary: 帮助有经验的开发者快速接手陌生项目，支持前端 Web、后端服务、 客户端（Electron/Tauri）、小程序、移动端等多种项目类型。自动识别项目类型，分阶段输出 项目概览、开发流程、工程规范、类型专项指南等，达到\"可以开始安全开发\"的状态。 触发词：接手项目, 项目上手, 快速上手, 新人接手, 项目入门,... Tags: latest:2.0.0 Version history: v2.0.0 | 2026-05-18T12:47:54.003Z | user Auto-publish from commit dc4421fe7970ce27a9e172af29c59ab38d8373a3 v0.3.0 | 2026-05-18T08:11:02.001Z | user Auto-publish from commit 5","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":838,"uniquenessScore":61,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T22:37:45.059Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T22:37:45.059Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T01:48:24.112Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}