الدليل ← Skill
SkilloptionalHermes Optional Skills

Code Wiki

Code Wiki: مهارة ينشرها Teknium (teknium1), Hermes Agent. مجالها الذاكرة وقواعد المعرفة. يوفّر السجل أمر تثبيت جاهزًا يظهر في هذه الصفحة. الرخصة MIT. الإصدار الموثّق 0.1.0. تُفعَّل بأمر `hermes skills install code-wiki` بعد مراجعة ما تطلبه. تدعم: linux، macos، windows.

DocumentationMermaidArchitectureDiagramsWikiCode-AnalysisOptionalHermes skill
آخر تحقق من السجل2026-08-18v0.1.0Teknium (teknium1), Hermes Agent
افتح المصدر الأصلي ↗Read in English
المعنى ببساطة

ماذا يضيف إلى Hermes؟

Code Wiki: مهارة ينشرها Teknium (teknium1), Hermes Agent. مجالها الذاكرة وقواعد المعرفة. يوفّر السجل أمر تثبيت جاهزًا يظهر في هذه الصفحة. الرخصة MIT. الإصدار الموثّق 0.1.0. تُفعَّل بأمر hermes skills install code-wiki بعد مراجعة ما تطلبه. تدعم: linux، macos، windows.

Code Wiki هي مهارة مرتبطة بمجال الذاكرة والمعرفة. يساعد Hermes على العثور على معلومات سابقة أو معرفة محفوظة بدل إعادة شرح كل شيء في كل جلسة.

هذا تفسير مبسّط مبني على وصف الناشر. أبقينا الوصف الإنجليزي بجانبه حتى تستطيع مقارنة المعنى بالمصدر.

استخدمه عندما

استخدمه عندما يكون هدفك واضحًا في الذاكرة والمعرفة وتستطيع تحديد البيانات والأفعال التي يحتاجها فقط.

لا تحتاجه عندما

لا تضفه لمجرد التجربة إذا كان لديك طريق أبسط داخل Hermes، أو إذا لم تستطع مراجعة المصدر والصلاحيات.

لمن يناسب؟

مناسب لمن يريد طريقة عمل قابلة للتكرار داخل Hermes.

أول اختبار آمن

أضف ملاحظة غير حساسة، ابدأ جلسة جديدة، ثم تحقق أن الاسترجاع يعيد المعنى الصحيح ولا يخترع تفاصيل.

الوصف الأصلي من الناشر، من دون ترجمة تغيّر المعنى

Generate wiki docs + Mermaid diagrams for any codebase

✓
مصدر البيانات

فُهرس هذا الإدخال من Hermes Optional Skills. الشرح العربي يفسّر النوع والمجال ولا يضيف وظيفة غير مذكورة في المصدر.

!
مراجعة الأمان

المصدر رسمي أو خضع لمراجعة تحريرية، لكن ذلك لا يغني عن مراجعة الصلاحيات والإصدار.

مسار تثبيت آمن

افحص، ثبّت، ثم اختبر.

  1. 01
    افتح المصدر

    طابق اسم الناشر والرخصة والوصف مع حاجتك، وراجع آخر تحديث فعلي.

  2. 02
    راجع الصلاحيات والأسرار

    لا تلصق قيمة سر داخل الموقع. استخدم أسماء متغيرات البيئة وامنح أقل نطاق ممكن.

  3. 03
    انسخ الإعداد فقط بعد المراجعة

    الأزرار أدناه تنسخ نصًا إلى الحافظة ولا تشغّل أمرًا على جهازك.

  4. 04
    اختبر بمهمة غير حساسة

    تحقق من الأدوات الظاهرة، ثم استبعد أدوات الكتابة أو الحذف التي لا تحتاجها.

أمر التثبيت

راجع الأمر ثم انسخه.

hermes skills install code-wiki

لا ينفّذ Hermes بالعربي هذا الأمر. التثبيت يحدث داخل جهازك ويظل خاضعًا لفحص Hermes ومراجعتك.

تعريف المهارة كاملًا

ما الذي يحمّله Hermes بالضبط عند تشغيل هذه المهارة.

منقول من التوثيق الرسمي. اقرأه قبل تفعيل المهارة، فهذا النص يصبح تعليمات الوكيل نفسه.

Generate wiki docs + Mermaid diagrams for any codebase.

Skill metadata

جدول مرجعي. لا تقرأه كله، ابحث عن السطر الذي يخصّك فقط.

SourceOptional — install with hermes skills install official/software-development/code-wiki
Pathoptional-skills/software-development/code-wiki
Version0.1.0
AuthorTeknium (teknium1), Hermes Agent
LicenseMIT
Platformslinux, macos, windows
TagsDocumentation, Mermaid, Architecture, Diagrams, Wiki, Code-Analysis
Related skillscodebase-inspection, github-repo-management

Reference: full SKILL.md

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

Generate a full wiki for any codebase — overview, architecture, per-module deep-dives, Mermaid class and sequence diagrams. Inspired by Google CodeWiki, but works on local repos, private repos, and any language. Uses only existing Hermes tools (terminal, read_file, search_files, write_file); no Docker, no external services, no extra dependencies.

This skill produces reference documentation (what/how). It does not produce strategic narrative (why — that's a different skill).

When to Use

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

  • User says "document this codebase", "generate a wiki", "make architecture diagrams"
  • Onboarding to an unfamiliar repo and wants a structured reference
  • User points at a GitHub URL and asks for documentation
  • Need a stable artifact (markdown + Mermaid) that renders on GitHub

Do NOT use this for:

  • Single-file or single-function documentation — just answer directly
  • API reference for one specific endpoint — use read_file and answer inline
  • Strategic "why does this exist" narrative — different skill, different purpose
  • Codebases the user is actively developing in this session — just answer questions as they come

Prerequisites

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

  • No env vars required.
  • git on PATH for repo SHA tracking and remote clones.
  • Optional: pygount for language-breakdown stats (see the codebase-inspection skill).

How to Run

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

Invoke through the terminal tool from the target repo's root, then use read_file / search_files / write_file to produce the wiki. Default output location is ~/.hermes/wikis/<repo-name>/. Only write into the repo (docs/wiki/) when the user explicitly requests it.

Quick Reference

جدول مرجعي. لا تقرأه كله، ابحث عن السطر الذي يخصّك فقط.

StepAction
1Resolve target — local cwd, given path, or git clone --depth 50 <url> to a temp dir
2Scan structure — ls, find -maxdepth 3, manifest files, README
3Pick 8–10 modules to document
4Write README.md (overview + module map)
5Write architecture.md with Mermaid flowchart
6Write per-module docs in modules/
7Write diagrams/class-diagram.md (Mermaid classDiagram)
8Write diagrams/sequences.md (Mermaid sequenceDiagram, 2–4 workflows)
9Write getting-started.md
10Write api.md if applicable, else skip
11Write .codewiki-state.json
12Report paths to user

Procedure

إعدادات تضبطها مرة وتنساها. غيّر واحدًا في كل مرة حتى تعرف أثر كل تغيير. تضبط WIKI_TMP، REPO_SHA خارج المحادثة، في بيئة التشغيل.

1. Resolve the target

For a GitHub URL:

Shell5 أسطر
WIKI_TMP=$(mktemp -d)
git clone --depth 50 <url> "$WIKI_TMP/repo"
cd "$WIKI_TMP/repo"
REPO_SHA=$(git rev-parse HEAD)
REPO_NAME=$(basename <url> .git)

For a local path (or cwd if none given):

Shell3 أسطر
cd <path>
REPO_SHA=$(git rev-parse HEAD 2>/dev/null || echo "uncommitted")
REPO_NAME=$(basename "$PWD")

Then set the output dir:

Shellسطران
OUTPUT_DIR="$HOME/.hermes/wikis/$REPO_NAME"
mkdir -p "$OUTPUT_DIR/modules" "$OUTPUT_DIR/diagrams"

2. Scan repo structure

Use the terminal tool for the shell work, read_file for manifests:

Shell18 سطرًا
# Shallow tree first
ls -la

# Deeper tree, noise filtered
find . -type d \
  -not -path '*/\.*' \
  -not -path '*/node_modules*' \
  -not -path '*/venv*' \
  -not -path '*/__pycache__*' \
  -not -path '*/dist*' \
  -not -path '*/build*' \
  -not -path '*/target*' \
  -maxdepth 3 | sort

# Language breakdown (skip if pygount unavailable)
pygount --format=summary \
  --folders-to-skip=".git,node_modules,venv,.venv,__pycache__,.cache,dist,build,target" \
  . 2>/dev/null || true

Then read_file the relevant manifests (package.json, pyproject.toml, setup.py, Cargo.toml, go.mod, pom.xml, build.gradle) and the project README. Use search_files target='files' to find them rather than guessing names.

3. Pick modules to document

Cap initial pass at 8–10 modules. Heuristics by language:

  • Python: top-level packages (dirs with __init__.py), plus subsystem dirs
  • JS/TS: src/<subdir>, top-level workspace dirs
  • Rust: each crate in a workspace, or top-level src/<module> dirs
  • Go: each top-level package directory
  • Mixed/unfamiliar: top-level directories that contain source code (not config, not tests)

For very large repos, prioritize by:

  1. Imported-from count (a module imported by many is core)
  2. LOC (bigger modules usually warrant their own doc)
  3. Mentions in README / top-level docs

State the module list to the user before generating per-module docs on big repos — gives them a chance to redirect.

4. Write README.md

read_file the actual project README plus the top 2–3 entry-point files. Then write_file:

MARKDOWN30 سطرًا
# <Project Name>

<One paragraph: what it is and what it's for. Self-contained — don't assume the
reader has the source README.>

## Key Concepts

- **<Concept 1>** — <one line>
- **<Concept 2>** — <one line>

## Entry Points

- [`path/to/main.py`](https://github.com/NousResearch/hermes-agent/blob/main/optional-skills/software-development/code-wiki/<link>) — <what runs when you start it>
- [`path/to/cli.py`](https://github.com/NousResearch/hermes-agent/blob/main/optional-skills/software-development/code-wiki/<link>) — <CLI surface>

## High-Level Architecture

<2-3 sentences. Detail goes in architecture.md.>

See [architecture.md](https://github.com/NousResearch/hermes-agent/blob/main/optional-skills/software-development/code-wiki/architecture.md).

## Module Map

| Module | Purpose |
|---|---|
| [`<module>`](https://github.com/NousResearch/hermes-agent/blob/main/optional-skills/software-development/code-wiki/modules/<module>.md) | <one-line purpose> |

## Getting Started

See [getting-started.md](https://github.com/NousResearch/hermes-agent/blob/main/optional-skills/software-development/code-wiki/getting-started.md).

For link targets in local mode use relative paths. For cloned repos use https://github.com/<owner>/<repo>/blob/<sha>/<path> so links survive future commits.

5. Write architecture.md

MARKDOWN17 سطرًا
# Architecture

<2-3 paragraphs: shape of the system. What talks to what. Where data enters,
where it exits, where state lives.>

## Components

- **<Component>** — <1-2 sentences>. See [`modules/<module>.md`](https://github.com/NousResearch/hermes-agent/blob/main/optional-skills/software-development/code-wiki/modules/<module>.md).

## System Diagram

```mermaid
flowchart TD
    User([User]) --> Entry[Entry Point]
    Entry --> Core[Core Engine]
    Core --> StorageA[(Database)]
    Core --> ExternalAPI{{External API}}

Data Flow

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

  1. <Step> — <file> ↗
  2. <Step> — <file> ↗

Key Design Decisions

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

  • <Anything load-bearing the reader should know>
Text45 سطرًا

**Mermaid shape semantics:**
- `[]` = component
- `[()]` = database / storage
- `{{}}` = external service
- `(())` = entry point or terminal
- `-->` = sync call, `-.->` = async/event

Cap at ~20 nodes per diagram. Split into sub-diagrams if larger.

### 6. Write per-module docs in `modules/`

For each selected module, inspect its layout with `ls`, identify 3–5 most important files (by size, by being named `core.py` / `main.py` / `__init__.py`, by being imported a lot), then `read_file` those files (use `offset` / `limit` to read only what you need; prefer `search_files` for specific symbols).

````markdown
# Module: `<module>`

<1-2 sentence purpose.>

## Responsibilities

- <bullet>
- <bullet>

## Key Files

- [`<module>/<file>`](https://github.com/NousResearch/hermes-agent/blob/main/optional-skills/software-development/code-wiki/<link>) — <what it does>

## Public API

<Functions/classes/constants other code uses. Group related items. Show
signatures, not full implementations.>

## Internal Structure

<How the module is organized internally. State management.>

## Dependencies

- **Used by:** <other modules>
- **Uses:** <other modules + external libs>

## Notable Patterns / Gotchas

- <Anything non-obvious>

7. Write diagrams/class-diagram.md

Pick the 5–10 most important classes/types. read_file them, then write:

MARKDOWN19 سطرًا
# Class Diagram

## Core Types

```mermaid
classDiagram
    class Agent {
        +string name
        +list~Tool~ tools
        +chat(message) string
    }
    class Tool {
        <<interface>>
        +name string
        +execute(args) any
    }
    Agent --> Tool : uses
    Tool <|-- TerminalTool
    Tool <|-- WebTool

Notes

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

<Anything the diagram can't express — lifecycle, threading, etc.>

Text26 سطرًا

For languages without classes (Go, C, Rust): use the diagram for struct relationships, or skip class-diagram.md and explain it in prose in architecture.md. Don't force-fit.

### 8. Write `diagrams/sequences.md`

Pick 2–4 of the most important workflows. Trace each call path through the code (read entry point, follow function calls), then:

````markdown
# Sequence Diagrams

## Workflow: <Name>

<1 sentence describing what this does and when it runs.>

```mermaid
sequenceDiagram
    participant User
    participant CLI
    participant Agent
    participant LLM
    User->>CLI: types message
    CLI->>Agent: chat(message)
    Agent->>LLM: API call
    LLM-->>Agent: response + tool_calls
    Agent->>Agent: execute tools
    Agent-->>CLI: final response

Walkthrough

  1. User input — cli.py:HermesCLI.run_session ↗
  2. Message dispatch — run_agent.py:AIAgent.chat ↗
Text16 سطرًا

Don't invent participants. Every box must correspond to a real component the reader can find in the code.

### 9. Write `getting-started.md`

````markdown
# Getting Started

## Prerequisites

<From manifest files + README. Be specific — versions if pinned.>

## Installation

```bash
<exact commands>

First Run

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

Shellسطر واحد
<minimum command to see the system do something useful>

Common Workflows

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

<Workflow 1>

<commands>

Configuration

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

  • <config-file> — <what it controls>
  • Env var <VAR> — <what it controls>

Where to Go Next

إعدادات تضبطها مرة وتنساها. غيّر واحدًا في كل مرة حتى تعرف أثر كل تغيير. الأوامر هنا: hermes code-wiki skill v0. تضبط OUTPUT_DIR، REPO_NAME خارج المحادثة، في بيئة التشغيل.

Text22 سطرًا

### 10. Write `api.md` (skip if not applicable)

Only write this if the project is a library or API server. If it is:

- Find the public API surface (`__init__.py` exports, OpenAPI specs, route handlers, exported types)
- Document each public entry with signature, parameters, return type, one-line description
- Group by category

### 11. Write the state file

```bash
cat > "$OUTPUT_DIR/.codewiki-state.json" <<EOF
{
  "repo_name": "$REPO_NAME",
  "source_path": "$PWD",
  "source_sha": "$REPO_SHA",
  "generated_at": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
  "generator": "hermes-agent code-wiki skill v0.1.0",
  "modules_documented": []
}
EOF

12. Report to user

State exactly what was generated and where:

Text8 أسطر
Generated wiki at ~/.hermes/wikis/<repo-name>/:
  README.md                   project overview, module map
  architecture.md             system architecture + flowchart
  getting-started.md          setup, first run, workflows
  modules/<N files>           per-module deep-dives
  diagrams/architecture.md    Mermaid flowchart
  diagrams/class-diagram.md   Mermaid class diagram
  diagrams/sequences.md       Mermaid sequence diagrams

If you cloned to a temp dir, remind the user it can be removed (rm -rf "$WIKI_TMP") after they've reviewed the wiki.

Scope Control

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

Generating a full wiki for a 500K-LOC monorepo is wildly token-expensive. Default to bounded scope:

  • Initial scan: max depth 3 directories
  • Per-module docs: cap at 10 modules unless user expands scope
  • Per-file reads: prefer search_files for symbols + read_file with offset/limit over full reads
  • Skip vendored code (vendor/, third_party/, generated code, _pb2.py, .min.js)

If the user says "do the whole thing exhaustively", believe them — but ballpark the cost first: "this repo has ~340 source files, comprehensive coverage will be expensive — confirm?"

Re-Run / Update

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

If .codewiki-state.json already exists at the target path:

  • Read it for previous SHA and module list
  • If source SHA matches: ask user if they want to regenerate or skip
  • If SHA differs: offer to regenerate only modules with changed files (git diff --name-only <old-sha> HEAD)

Full incremental-regeneration is a future enhancement — for now, regenerating the whole thing is acceptable.

Pitfalls

شرح للفكرة نفسها. اقرأه ببطء، فبقية الأقسام تبني عليه.

  • Fabricating components. Every diagram node and claimed function call must be in the source. read_file before writing. The single biggest failure mode for auto-generated docs is plausible-sounding fabrication.
  • Generic AI prose. "This module is responsible for..." is content-free. Say what the module actually does in domain-specific terms.
  • Restating code as prose. A module doc that says "the process function processes things by calling process_item on each item" is worse than just linking to the function.
  • Mermaid > 50 nodes. They don't render legibly. Split them.
  • Documenting tests, generated code, or vendored deps as if they were product code. Skip them.
  • In-repo output without asking. Default is ~/.hermes/wikis/. Only write into the repo when the user explicitly requests it.
  • Mermaid special chars need quotes: A["Tool / Agent"] not A[Tool / Agent]. <br> for line breaks inside a node.
  • Nested code fences in SKILL.md. When writing a markdown example that contains a Mermaid block, use 4-backtick outer fences so the 3-backtick inner `mermaid doesn't close the outer. (This SKILL.md does it.)
  • classDiagram generics render as ~T~ (e.g. List~Tool~), not <T>.
  • GitHub Mermaid theme is fixed — don't include %%{init: ...}%% blocks; they're stripped on render.

Verification

إعدادات تضبطها مرة وتنساها. غيّر واحدًا في كل مرة حتى تعرف أثر كل تغيير. تضبط OUTPUT_DIR خارج المحادثة، في بيئة التشغيل.

After writing, verify:

  1. Mermaid blocks balance — opens equal closes per file:
Shell5 أسطر
   for f in "$OUTPUT_DIR"/diagrams/*.md "$OUTPUT_DIR"/architecture.md; do
     opens=$(grep -c '^```mermaid' "$f")
     total=$(grep -c '^```' "$f")
     echo "$f: $opens mermaid blocks, $total total fences (expect total = opens*2)"
   done
  1. All expected files exist —
Shellسطران
   ls "$OUTPUT_DIR"/{README.md,architecture.md,getting-started.md,.codewiki-state.json} \
      "$OUTPUT_DIR"/modules/ "$OUTPUT_DIR"/diagrams/
  1. Module count matches what you intended — ls "$OUTPUT_DIR/modules" | wc -l should equal the number of modules you committed to in Step 3.
  2. No fabricated paths — sanity-check 2–3 source links resolve to real files.