首頁

Skill

文件

wiki-onboarding

microsoft/skills

會在 /onboarding/ 資料夾中產生四份針對不同受眾量身打造的入職指南——貢獻者、資深工程師、高階主管及產品經理。當使用者需要針對某個程式碼庫的入職文件時，即可使用此功能。

...展開全部

更新時間 2026-09-11

# documentation # onboarding # mermaid diagrams # codebase documentation # contributor guide # executive guide # product manager guide # staff engineer guide

維基入門指南生成器

在onboarding/資料夾中產生四份針對不同受眾量身打造的入門文件，每份文件皆能讓不同的利害關係人精準掌握其所需的資訊。

來源儲存庫設定（必須先執行）

在生成任何指南之前，您必須先確定來源儲存庫的背景：

檢查 git remote：執行 `git remote get-url origin` 以偵測是否存在遠端儲存庫
詢問使用者：「這是僅限本地的儲存庫，還是您有來源儲存庫的 URL（例如 GitHub、Azure DevOps）？」
- 若提供遠端 URL → 儲存為REPO_URL，並使用連結引用格式：[檔案:行號](REPO_URL/blob/BRANCH/file#Lline)
- 僅限本機 →使用本機引用格式：(檔案路徑:行號)
確定預設分支：執行 `git rev-parse --abbrev-ref HEAD`
在來源儲存庫的上下文未解析前，請勿繼續

何時啟用

使用者要求提供入門文件或開始使用指南
使用者執行/deep-wiki:onboard指令
使用者希望協助新團隊成員理解程式碼庫

輸出結構

生成一個包含以下檔案的onboarding/資料夾：

onboarding/
├── index.md                    # 入職中心 — 連結至所有 4 份指南，並附有目標受眾說明
├── contributor-guide.md        # 適用於新貢獻者（假設具備 Python 或 JS 背景）
├── staff-engineer-guide.md     # 適用於資深／首席工程師
├── executive-guide.md          # 適用於副總裁／總監級工程領導者
└── product-manager-guide.md    # 適用於產品經理及非工程領域的利害關係人

`index.md`— 入職指南中心

一個包含以下內容的登陸頁面：

一段式的專案摘要
指南選擇表：

指南	目標受眾	您將學到什麼	時間
貢獻者指南	具備 Python/JS 經驗的新貢獻者	環境設定、首次提交拉取請求、程式碼庫模式	約 30 分鐘
資深工程師指南	資深／首席工程師	架構、設計決策、系統邊界	約 45 分鐘
高階主管指南	工程副總裁／工程總監	能力、風險、團隊架構、投資論點	約 20 分鐘
產品經理指南	產品經理	功能、使用者旅程、限制條件、資料模型	約 20 分鐘

語言偵測

掃描儲存庫中的建置檔案，以確定程式碼範例的主要語言：

package.json/tsconfig.json→ TypeScript/JavaScript
*.csproj/*.sln→ C# / .NET
Cargo.toml→ Rust
pyproject.toml/setup.py/requirements.txt→ Python
go.mod→ Go
pom.xml/build.gradle→ Java

指南 1：貢獻者指南

檔案：onboarding/contributor-guide.md 對象：加入本專案的工程師。假設讀者具備 Python 或 JavaScript 實務能力，並擁有一般軟體工程經驗。長度：1000–2500 行。逐步深入 — 每個章節皆建立在前一章節的基礎上。

必備章節

第一部分：基礎知識（若儲存庫使用 Python 或 JS，則可跳過）

針對 Python/JS 工程師的 {主要語言}— 語法對照表、非同步模型、集合、類型系統、套件管理。應提供具體的並列程式碼範例，而非抽象的描述。
{主要框架} 核心要點— 與等效的 Python/JS 框架（例如 FastAPI、Express）進行比較。請求處理流程、路由、依賴注入、配置。

第二部分：此程式碼庫 3.此專案的功能— 2 至 3 句的簡短說明 4.專案結構— 附註的目錄樹（哪些內容存放於何處以及原因）。包含圖表形式的 TB架構概覽。 5.核心概念— 透過程式碼範例解釋領域特定術語。使用erDiagram展示資料模型。 6.請求生命週期—序列圖（含自動編號），追蹤典型請求的端到端流程。 7.關鍵模式— 「若要新增 X，請遵循此模式」的範本，並附實際程式碼

第三部分：開始實作 8.先決條件與設定— 表格：工具、版本、安裝指令。附帶各步驟預期輸出的逐步指南。 9.您的第一個任務— 添加簡單功能的端到端實作指南 10.開發工作流程— 分支策略、提交規範、拉取請求流程。使用流程圖。 11.執行測試— 所有測試、單一檔案、單一測試、覆蓋率指令 12.除錯指南— 常見問題表：症狀、原因、解決方法 13.常見陷阱— 每位新貢獻者都會犯的錯誤及如何避免

附錄

術語表（40 多個術語）
關鍵檔案參考— 表格：路徑、用途、重要性、來源
快速參考卡— 最常用指令與模式的速查表

規則

所有程式碼範例均採用偵測到的主要語言撰寫
每個指令都必須可直接複製貼上，並附有預期輸出結果
至少包含 5 張 Mermaid 圖表（架構圖、ER 圖、序列圖、流程圖、狀態圖）
工作流程圖請使用 Mermaid（深色模式配色）——在每個圖後添加每個圖後添加註解區塊
所有陳述均須以實際程式碼為依據 — 請採用連結引用格式

指南 2：資深工程師指南

檔案：onboarding/staff-engineer-guide.md 目標讀者：需要了解每項決策背後「原因」的資深／首席工程師。具備深厚的系統經驗，但可能不熟悉此儲存庫所使用的程式語言。長度：800–1200 行。內容精煉、觀點鮮明、著重架構。

必備章節

執行摘要— 以一段簡潔的文字說明系統的本質。闡明系統負責處理的事項與委派的事項。
核心架構洞見— 唯一最重要的概念。請使用與該儲存庫不同的程式語言撰寫偽代碼。
系統架構— 完整的 Mermaid圖形 TB圖。標示出系統的「核心」。
領域模型— 核心實體的 MermaiderDiagram。資料不變式表格：實體、不變式、由誰強制執行、來源。
關鍵抽象與介面— 展示承載核心功能的抽象概念之classDiagram。
請求生命週期—序列圖（含自動編號），展示典型請求從進入到回應的流程。
狀態轉換— 針對具有具意義生命週期狀態之實體所繪製的stateDiagram-v2。
決策日誌— 表格：決策、考慮過的選項、理由、來源。
依賴關係理由— 表格：依賴關係、目的、取代的項目、來源。
資料流與狀態— 資料在系統中的流動方式。儲存方式比較表。
故障模式與錯誤處理— 錯誤傳播路徑的流程圖。
效能特性— 瓶頸、擴展極限、熱路徑。
安全性模型— 身份驗證、授權、信任邊界、資料敏感度。
測試策略— 測試範圍、不納入測試的項目、測試理念。
已知技術債務— 表格：問題、風險等級、受影響檔案、來源。
深入探究之處— 原始碼檔案的建議閱讀順序、維基頁面連結。

規則

使用不同語言的偽代碼來闡述概念
使用比較表來對應不熟悉的概念（例如：Task=Awaitable[T]）
內容紮實且包含表格的段落，而非膚淺的項目符號清單
每項論點均須附有連結至參考文獻
至少包含 5 張 Mermaid 圖（架構圖、實體關係圖、類別圖、序列圖、狀態圖、流程圖）
每個圖表後須附有註解區
積極運用表格——決策、依賴關係、技術債務均應以包含「來源」欄位的表格呈現
著重於「為何」做出決策，而非僅僅列出「什麼」存在

指南 3：高階主管指南

檔案：onboarding/executive-guide.md 目標讀者：工程副總裁／總監。需要功能概覽、風險評估及投資背景——而非程式碼層級的細節。長度：400–800 行。具戰略性、簡潔明瞭且以決策為導向。

必備章節

系統概覽— 用 2–3 句說明其功能、使用者群體及商業價值
功能地圖— 表格：功能、狀態（已建置／部分建置／規劃中）、成熟度、依賴關係。系統當前能做與不能做的事項。
架構一覽— 高階 Mermaid圖形 LR圖。服務、資料儲存庫、外部整合 — 切勿包含內部程式碼細節。重點在於部署單位與團隊邊界。
團隊拓撲— 哪些團隊／人員負責哪些組件。表格：組件、負責人、關鍵性、業務係數。
技術投資論述— 說明為何選擇這些技術。表格：技術、目的、曾考慮的替代方案、風險等級。
風險評估— 表格：風險、發生機率、影響、緩解措施、負責人。涵蓋可靠性、安全性、可擴展性及合規性。
成本與擴展模型— 成本如何隨使用量變化。瓶頸為何。何時需要進行下一次擴展投資。
依賴關係圖—圖形化展示關鍵外部依賴關係。表格：依賴關係、類型（服務／函式庫／平台）、無法使用時的風險。
關鍵指標與可觀察性— 測量項目、現有儀表板、警示覆蓋範圍。表格：指標、當前值、目標值、來源。
路線圖對齊— 工程工作流與業務優先級的對應關係。哪些項目正在進行中、哪些已規劃、哪些受阻。
技術債務摘要— 對業務影響最大的前 5 大債務項目。表格：問題、業務影響、修復所需工作量、優先級。
建議事項— 針對下個季度的 3 至 5 項可執行建議，依影響程度排序。

規則

禁止包含程式碼片段— 本指南是為工程領導者而設，而非程式設計師
圖表應以服務／團隊層級呈現，而非類別／函式層級
每項論點均須有證據支持— 請引用維基頁面、架構文件或原始碼檔案
至少包含 3 張 Mermaid 圖表（架構概覽、依賴關係圖、功能/路線圖）
每項結構化發現均須附表 — 此目標讀者群習慣閱讀表格，而非散文
使用商業用語——將技術概念轉化為具體影響（可靠性、速度、成本、風險）

指南 4：產品經理指南

檔案：onboarding/product-manager-guide.md 目標讀者：產品經理與非工程背景的利害關係人。需了解系統的功能、可實現的範圍及限制——而非其建構方式。篇幅：400–800 行。以使用者為中心、聚焦功能、兼顧限制條件。

必備章節

系統功能說明— 2–3 句以使用者易懂語言（無術語）撰寫的簡短說明
使用者旅程地圖—使用Mermaid繪製的 LR 圖或旅程圖，展示使用者在系統中的主要流程
功能能力圖— 表格：功能、狀態（上線／測試版／規劃中／無法實現）、使用者可見行為、限制。全面呈現已建置與未建置項目的清單。
資料模型（產品視圖）—— 簡化的 MermaiderDiagram，展示使用者互動的實體。請以商業術語說明（例如：「一個專案包含多個文件」，而非「外鍵關係」）。
設定與功能標誌— 表格：標誌／設定、控制對象、預設值、可修改者。列出無需工程開發即可切換的功能。
API 功能— 可實現哪些整合。表格：功能、端點／方法、驗證機制、速率限制。此內容是為整合合作夥伴撰寫，而非開發人員。
效能與服務水準協議 (SLA)— 回應時間、吞吐量限制、可用性目標。表格：操作、預期延遲、吞吐量限制、現行 SLA。
已知限制與限制條件— 誠實列出系統無法執行或表現不佳的事項。表格：限制、對用戶的影響、解決方法、預定修正方案。
資料與隱私— 收集哪些資料、儲存位置、保留政策、合規狀態。表格：資料類型、儲存位置、保留期限、合規狀態。
術語表— 以淺顯易懂的語言（而非工程術語）解釋領域專有名詞
常見問題— 產品經理可能會提出的 10 個以上常見問題，並以簡明方式回答

規則

零工程術語— 避免使用「中介軟體」、「依賴性注入」、「ORM」等詞彙。使用通俗易懂的語言。
以使用者為中心的敘事框架— 從使用者體驗的角度描述一切，而非著重於程式碼的運作方式
至少包含 3 張 Mermaid 圖表（使用者旅程、資料模型、功能地圖／功能概覽）
所有結構化發現均需以表格呈現 — 產品經理習慣瀏覽表格，而非長篇大論
若必須提及技術概念，請以一句話說明（例如：「功能標誌（Feature flags）—— 讓我們無需部署程式碼即可啟用／停用功能的開關」）
每項論點皆須有證據支持 — 請引用維基頁面或原始檔案以供查證

Mermaid 圖表規則（所有指南）

所有圖表必須使用深色模式配色：

節點填充色：#2d333b，邊框：#6d5dfc，文字：#e6edf3
子圖背景：#161b22，邊框：#30363d
線條：#8b949e
若使用內嵌樣式指令，請使用深色填充並指定`color:#e6edf3`
請勿在（請使用或換行符)

驗證

生成每份指南後，請確認：

指南中提及的所有檔案路徑確實存在於儲存庫中
所有類別／方法名稱均正確無誤（非虛構）
Mermaid 圖表可正常渲染（無語法錯誤）
程式碼圍欄外不得出現裸露的 HTML 樣式標籤（如List 等泛型標籤）——請以反引號包圍
每份指南的內容是否符合其目標受眾——高階主管／專案經理指南中不應包含程式碼

在 GitHub 上查看

---
name: wiki-onboarding
description: Generates four audience-tailored onboarding guides in an onboarding/ folder — Contributor, Staff Engineer, Executive, and Product Manager. Use when the user wants onboarding documentation for a codebase.
license: MIT
---

# Wiki Onboarding Guide Generator

Generate four audience-tailored onboarding documents in an `onboarding/` folder, each giving a different stakeholder exactly the understanding they need.

## Source Repository Resolution (MUST DO FIRST)

Before generating any guides, you MUST determine the source repository context:

1. **Check for git remote**: Run `git remote get-url origin` to detect if a remote exists
2. **Ask the user**: _"Is this a local-only repository, or do you have a source repository URL (e.g., GitHub, Azure DevOps)?"_
   - Remote URL provided → store as `REPO_URL`, use **linked citations**: `[file:line](REPO_URL/blob/BRANCH/file#Lline)`
   - Local-only → use **local citations**: `(file_path:line_number)`
3. **Determine default branch**: Run `git rev-parse --abbrev-ref HEAD`
4. **Do NOT proceed** until source repo context is resolved

## When to Activate

- User asks for onboarding docs or getting-started guides
- User runs `/deep-wiki:onboard` command
- User wants to help new team members understand a codebase

## Output Structure

Generate an `onboarding/` folder with these files:

```
onboarding/
├── index.md                    # Onboarding hub — links to all 4 guides with audience descriptions
├── contributor-guide.md        # For new contributors (assumes Python or JS background)
├── staff-engineer-guide.md     # For staff/principal engineers
├── executive-guide.md          # For VP/director-level engineering leaders
└── product-manager-guide.md    # For product managers and non-engineering stakeholders
```

### `index.md` — Onboarding Hub

A landing page with:
- **One-paragraph project summary**
- **Guide selector table**:

| Guide | Audience | What You'll Learn | Time |
|-------|----------|-------------------|------|
| [Contributor Guide](./contributor-guide.md) | New contributors with Python/JS experience | Setup, first PR, codebase patterns | ~30 min |
| [Staff Engineer Guide](./staff-engineer-guide.md) | Staff/principal engineers | Architecture, design decisions, system boundaries | ~45 min |
| [Executive Guide](./executive-guide.md) | VP/directors of engineering | Capabilities, risks, team topology, investment thesis | ~20 min |
| [Product Manager Guide](./product-manager-guide.md) | Product managers | Features, user journeys, constraints, data model | ~20 min |

## Language Detection

Scan the repository for build files to determine the primary language for code examples:
- `package.json` / `tsconfig.json` → TypeScript/JavaScript
- `*.csproj` / `*.sln` → C# / .NET
- `Cargo.toml` → Rust
- `pyproject.toml` / `setup.py` / `requirements.txt` → Python
- `go.mod` → Go
- `pom.xml` / `build.gradle` → Java

---

## Guide 1: Contributor Guide

**File**: `onboarding/contributor-guide.md`
**Audience**: Engineers joining the project. Assumes proficiency in Python or JavaScript and general software engineering experience.
**Length**: 1000–2500 lines. Progressive — each section builds on the last.

### Required Sections

**Part I: Foundations** (skip if repo uses Python or JS)
1. **{Primary Language} for Python/JS Engineers** — Syntax comparison tables, async model, collections, type system, package management. Concrete code side-by-side, NOT abstract descriptions.
2. **{Primary Framework} Essentials** — Compare to equivalent Python/JS frameworks (e.g., FastAPI, Express). Request pipeline, routing, DI, config.

**Part II: This Codebase**
3. **What This Project Does** — 2-3 sentence elevator pitch
4. **Project Structure** — Annotated directory tree (what lives where and why). Include `graph TB` architecture overview.
5. **Core Concepts** — Domain-specific terminology explained with code examples. Use `erDiagram` for data model.
6. **Request Lifecycle** — `sequenceDiagram` (with `autonumber`) tracing a typical request end-to-end.
7. **Key Patterns** — "If you want to add X, follow this pattern" templates with real code

**Part III: Getting Productive**
8. **Prerequisites & Setup** — Table: Tool, Version, Install Command. Step-by-step with expected output at each step.
9. **Your First Task** — End-to-end walkthrough of adding a simple feature
10. **Development Workflow** — Branch strategy, commit conventions, PR process. Use `flowchart` diagram.
11. **Running Tests** — All tests, single file, single test, coverage commands
12. **Debugging Guide** — Common issues table: Symptom, Cause, Fix
13. **Common Pitfalls** — Mistakes every new contributor makes and how to avoid them

**Appendices**
- **Glossary** (40+ terms)
- **Key File Reference** — Table: Path, Purpose, Why It Matters, Source
- **Quick Reference Card** — Cheat sheet of most-used commands and patterns

### Rules
- All code examples in the detected primary language
- Every command must be copy-pasteable with expected output
- **Minimum 5 Mermaid diagrams** (architecture, ER, sequence, flowchart, state)
- Use Mermaid for workflow diagrams (dark-mode colors) — add `<!-- Sources: ... -->` comment block after each
- Ground all claims in actual code — cite using linked format

---

## Guide 2: Staff Engineer Guide

**File**: `onboarding/staff-engineer-guide.md`
**Audience**: Staff/principal engineers who need the "why" behind every decision. Deep systems experience, may not know this repo's language.
**Length**: 800–1200 lines. Dense, opinionated, architectural.

### Required Sections

1. **Executive Summary** — What the system is in one dense paragraph. What it owns vs delegates.
2. **The Core Architectural Insight** — The SINGLE most important concept. Include pseudocode in a DIFFERENT language from the repo.
3. **System Architecture** — Full Mermaid `graph TB` diagram. Call out the "heart" of the system.
4. **Domain Model** — Mermaid `erDiagram` of core entities. Data invariants table: Entity, Invariant, Enforced By, Source.
5. **Key Abstractions & Interfaces** — `classDiagram` showing load-bearing abstractions.
6. **Request Lifecycle** — `sequenceDiagram` (with `autonumber`) showing typical request from entry to response.
7. **State Transitions** — `stateDiagram-v2` for entities with meaningful lifecycle states.
8. **Decision Log** — Table: Decision, Alternatives Considered, Rationale, Source.
9. **Dependency Rationale** — Table: Dependency, Purpose, What It Replaced, Source.
10. **Data Flow & State** — How data moves through the system. Storage comparison table.
11. **Failure Modes & Error Handling** — `flowchart` for error propagation paths.
12. **Performance Characteristics** — Bottlenecks, scaling limits, hot paths.
13. **Security Model** — Auth, authorization, trust boundaries, data sensitivity.
14. **Testing Strategy** — What's tested, what isn't, testing philosophy.
15. **Known Technical Debt** — Table: Issue, Risk Level, Affected Files, Source.
16. **Where to Go Deep** — Recommended reading order of source files, links to wiki sections.

### Rules
- Use **pseudocode in a different language** to explain concepts
- Use **comparison tables** to map unfamiliar concepts (e.g., `Task<T>` = `Awaitable[T]`)
- Dense prose with tables, NOT shallow bullet lists
- Every claim backed by linked citation
- **Minimum 5 Mermaid diagrams** (architecture, ER, class, sequence, state, flowchart)
- Each diagram followed by `<!-- Sources: ... -->` comment block
- **Use tables aggressively** — decisions, dependencies, debt should ALL be tables with Source columns
- Focus on WHY decisions were made, not just WHAT exists

---

## Guide 3: Executive Guide

**File**: `onboarding/executive-guide.md`
**Audience**: VP/director of engineering. Needs capability overview, risk assessment, and investment context — NOT code-level details.
**Length**: 400–800 lines. Strategic, concise, decision-oriented.

### Required Sections

1. **System Overview** — What it does, who uses it, business value in 2-3 sentences
2. **Capability Map** — Table: Capability, Status (Built/Partial/Planned), Maturity, Dependencies. What the system can and cannot do today.
3. **Architecture at a Glance** — High-level Mermaid `graph LR` diagram. Services, data stores, external integrations — NO internal code details. Focus on deployment units and team boundaries.
4. **Team Topology** — Which team/person owns which components. Table: Component, Owner, Criticality, Bus Factor.
5. **Technology Investment Thesis** — Why these technologies were chosen. Table: Technology, Purpose, Alternatives Considered, Risk Level.
6. **Risk Assessment** — Table: Risk, Likelihood, Impact, Mitigation, Owner. Cover reliability, security, scalability, compliance.
7. **Cost & Scaling Model** — How costs scale with usage. What the bottlenecks are. When the next scaling investment is needed.
8. **Dependency Map** — `graph TB` showing critical external dependencies. Table: Dependency, Type (Service/Library/Platform), Risk if Unavailable.
9. **Key Metrics & Observability** — What's measured, what dashboards exist, alerting coverage. Table: Metric, Current Value, Target, Source.
10. **Roadmap Alignment** — Engineering workstreams mapped to business priorities. What's in progress, what's planned, what's blocked.
11. **Technical Debt Summary** — Top 5 debt items with business impact. Table: Issue, Business Impact, Effort to Fix, Priority.
12. **Recommendations** — 3-5 actionable recommendations for the next quarter, prioritized by impact.

### Rules
- **NO code snippets** — this guide is for engineering leaders, not coders
- **Diagrams at service/team level**, not class/function level
- **Every claim backed by evidence** — cite wiki sections, architecture docs, or source files
- **Minimum 3 Mermaid diagrams** (architecture overview, dependency map, capability/roadmap)
- Tables for every structured finding — this audience reads tables, not prose
- **Business language** — translate technical concepts into impact (reliability, velocity, cost, risk)

---

## Guide 4: Product Manager Guide

**File**: `onboarding/product-manager-guide.md`
**Audience**: Product managers and non-engineering stakeholders. Needs to understand what the system does, what's possible, and where the boundaries are — NOT how it's built.
**Length**: 400–800 lines. User-centric, feature-focused, constraint-aware.

### Required Sections

1. **What This System Does** — 2-3 sentence elevator pitch in user-facing language (no jargon)
2. **User Journey Map** — Mermaid `graph LR` or `journey` diagram showing primary user flows through the system
3. **Feature Capability Map** — Table: Feature, Status (Live/Beta/Planned/Not Possible), User-Facing Behavior, Limitations. Comprehensive map of what's built and what's not.
4. **Data Model (Product View)** — Simplified Mermaid `erDiagram` showing entities users interact with. Explain in business terms (e.g., "A Project has many Documents" not "FK relationship").
5. **Configuration & Feature Flags** — Table: Flag/Config, What It Controls, Default, Who Can Change It. What can be toggled without engineering work.
6. **API Capabilities** — What integrations are possible. Table: Capability, Endpoint/Method, Authentication, Rate Limits. Written for integration partners, not developers.
7. **Performance & SLAs** — Response times, throughput limits, availability targets. Table: Operation, Expected Latency, Throughput Limit, Current SLA.
8. **Known Limitations & Constraints** — Honest list of what the system can't do or does poorly. Table: Limitation, User Impact, Workaround, Planned Fix.
9. **Data & Privacy** — What data is collected, where it's stored, retention policies, compliance status. Table: Data Type, Storage Location, Retention, Compliance.
10. **Glossary** — Domain terms explained in plain language (not engineering jargon)
11. **FAQ** — 10+ common questions a PM would ask, answered concisely

### Rules
- **ZERO engineering jargon** — no "middleware", "dependency injection", "ORM". Use plain language.
- **User-centric framing** — describe everything in terms of what users experience, not how code works
- **Minimum 3 Mermaid diagrams** (user journey, data model, feature map/capability overview)
- Tables for every structured finding — PMs scan tables, not prose
- If a technical concept must be mentioned, explain it in one sentence (e.g., "Feature flags — toggles that let us turn features on/off without deploying code")
- Every claim grounded in evidence — cite wiki sections or source files for verification

---

## Mermaid Diagram Rules (ALL guides)

ALL diagrams must use dark-mode colors:
- Node fills: `#2d333b`, borders: `#6d5dfc`, text: `#e6edf3`
- Subgraph backgrounds: `#161b22`, borders: `#30363d`
- Lines: `#8b949e`
- If using inline `style` directives, use dark fills with `,color:#e6edf3`
- Do NOT use `<br/>` in Mermaid labels (use `<br>` or line breaks)

## Validation

After generating each guide, verify:
- All file paths mentioned actually exist in the repo
- All class/method names are accurate (not hallucinated)
- Mermaid diagrams render (no syntax errors)
- No bare HTML-like tags (generics like `List<T>`) outside code fences — wrap in backticks
- Each guide is appropriate for its audience — no code in Executive/PM guides

所有檔案

0 個檔案

安裝 wiki-onboarding

請下載技能檔案，並將其解壓縮至您的 .claude/skills/ 目錄中。

下載 ZIP

複製儲存庫並將技能檔案複製到您的專案中。

git clone https://github.com/microsoft/skills/tree/main/.github/plugins/deep-wiki/skills/wiki-onboarding # Copy SKILL.md to your .claude/skills/ directory

複製

快速設定: 將技能資料夾複製到 .claude/skills/ Claude 會自動偵測並使用該技能

儲存庫 microsoft/skills

wiki-onboarding

維基入門指南生成器

來源儲存庫設定（必須先執行）

何時啟用

輸出結構

index.md— 入職指南中心

語言偵測

指南 1：貢獻者指南

必備章節

規則

指南 2：資深工程師指南

必備章節

規則

指南 3：高階主管指南

必備章節

規則

指南 4：產品經理指南

必備章節

規則

Mermaid 圖表規則（所有指南）

驗證

所有檔案

安裝 wiki-onboarding

相關技能

`index.md`— 入職指南中心