wiki-onboarding – Other skill for AI agents

Wiki Onboarding Guide Generator

Generate two complementary onboarding documents that together give any engineer — from newcomer to principal — a complete understanding of a codebase.

When to Use

• 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

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: Principal-Level Onboarding

Audience: Senior/staff+ engineers who need the "why" behind decisions.

Required Sections

1. System Philosophy & Design Principles — What invariants does the system maintain? What were the key design choices and why?

2. Architecture Overview — Component map with Mermaid diagram. What owns what, communication patterns.

3. Key Abstractions & Interfaces — The load-bearing abstractions everything depends on

4. Decision Log — Major architectural decisions with context, alternatives considered, trade-offs

5. Dependency Rationale — Why each major dependency was chosen, what it replaced

6. Data Flow & State — How data moves through the system (traced from actual code, not guessed)

7. Failure Modes & Error Handling — What breaks, how errors propagate, recovery patterns

8. Performance Characteristics — Bottlenecks, scaling limits, hot paths

9. Security Model — Auth, authorization, trust boundaries, data sensitivity

10. Testing Strategy — What's tested, what isn't, testing philosophy

11. Operational Concerns — Deployment, monitoring, feature flags, configuration

12. Known Technical Debt — Honest assessment of shortcuts and their risks

Rules

• Every claim backed by (file_path:line_number) citation
• Minimum 3 Mermaid diagrams (architecture, data flow, dependency graph)
• All Mermaid diagrams use dark-mode colors (see wiki-vitepress skill)
• Focus on WHY only when commit history, ADRs or owner evidence supports the rationale. Mark inferred rationale and unknown performance/security properties explicitly; source structure alone cannot establish intent or measured limits.

Guide 2: Zero-to-Hero Contributor Guide

Audience: New contributors who need step-by-step practical guidance.

Required Sections

1. What This Project Does — 2-3 sentence elevator pitch

2. Prerequisites — Tools, versions, accounts needed

3. Environment Setup — Step-by-step with exact commands, expected output at each step

4. Project Structure — Annotated directory tree (what lives where and why)

5. Your First Task — End-to-end walkthrough of adding a simple feature

6. Development Workflow — Branch strategy, commit conventions, PR process

7. Running Tests — How to run tests, what to test, how to add a test

8. Debugging Guide — Common issues and how to diagnose them

9. Key Concepts — Domain-specific terminology explained with code examples

10. Code Patterns — "If you want to add X, follow this pattern" templates

11. Common Pitfalls — Mistakes every new contributor makes and how to avoid them

12. Where to Get Help — Communication channels, documentation, key contacts

13. Glossary — Terms used in the codebase that aren't obvious

14. 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
• Include expected output for verification steps
• Use Mermaid for workflow diagrams (dark-mode colors)
• Ground all claims in actual code — cite (file_path:line_number)

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

Example

User request:

> Create onboarding documentation that helps a new engineer run, understand, and safely change this codebase.

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.