$npx -y skills add rlaope/oh-my-hermes --skill codebase-onboarding[omh] Hermes Codebase Onboarding workflow: create a repo map, reading path, glossary, risk map, and first-task runway for unfamiliar codebases.
| 1 | # Codebase Onboarding |
| 2 | |
| 3 | This is a Hermes-native `codebase-onboarding` workflow skill. |
| 4 | |
| 5 | ## Why This Exists |
| 6 | |
| 7 | `codebase-onboarding` adapts ECC's code-tour and onboarding surfaces into an OMH-native first-read workflow so unfamiliar repos become navigable before implementation pressure starts. |
| 8 | |
| 9 | ## Do Not Use When |
| 10 | |
| 11 | - The user already named a concrete implementation task and acceptance criteria; use `ultraprocess` or `idea-to-deploy`. |
| 12 | - The user needs a whole-workspace capability inventory; use `workspace-audit`. |
| 13 | - The user wants a code diff review; use `code-review`. |
| 14 | |
| 15 | ## Examples |
| 16 | |
| 17 | Good example: |
| 18 | |
| 19 | - Prompt: codebase-onboarding 처음 보는 레포라서 구조, 주요 모듈, 테스트, 첫 작업 후보를 잡아줘. |
| 20 | - Expected behavior: Prepare repo_map/v1, reading_path/v1, domain_glossary/v1, risk map, and first_task_runway/v1 from observed files. |
| 21 | - Why: The request is repo orientation before implementation. |
| 22 | |
| 23 | Bad example: |
| 24 | |
| 25 | - Prompt: codebase-onboarding 파일 안 읽고 이 레포 아키텍처를 확정해줘. |
| 26 | - Expected behavior: Mark architecture as unobserved and inspect source evidence before making claims. |
| 27 | - Why: Onboarding is only useful when grounded in current repo evidence. |
| 28 | |
| 29 | ## Completion Checklist |
| 30 | |
| 31 | - The plan names goals, non-goals, assumptions, acceptance criteria, and verification shape. |
| 32 | - Draft recommendations, accepted decisions, and executor handoffs are separate states. |
| 33 | - Rejected options or unresolved tradeoffs are recorded before handoff. |
| 34 | |
| 35 | ## Recovery Notes |
| 36 | |
| 37 | - If acceptance criteria or verification are missing, route back to clarification before handoff. |
| 38 | - If assumptions materially affect the plan, keep them visible and avoid treating the plan as accepted. |
| 39 | |
| 40 | ## OMH Context Rail |
| 41 | |
| 42 | - This skill is part of OMH's Hermes workflow layer, not a standalone executor. |
| 43 | - Product context: OMH is a Hermes-native workflow pack: choose skills, shape work, prepare artifacts, show status, and hand off with evidence boundaries. |
| 44 | - Current lane: **Intent -> plan** (`oh-my-hermes`, `deep-interview`, `plan`, `ralplan`, `codebase-onboarding`, `codegraph-refresh`, `ultragoal`, `ultraprocess`, `+3 more`) - clarify, plan, ship, or loop goals. |
| 45 | - If the user intent belongs to another OMH lane, hand back to `oh-my-hermes` or name the adjacent workflow instead of force-fitting this skill. |
| 46 | - Cross-skill context: every OMH skill: match lane; generic tool can render or execute. |
| 47 | - Generic-tool checkpoint: image->img-summary; frontend->frontend/a11y/visual-qa; paper->paper-learning; content->content-operator; media->media-input-operator; file->materials-package; search->web-research; live->live-info-operator; audit->workspace/production/security; failures->build-failure; verify->verification-gate; code->codegraph/onboarding/ultraprocess. |
| 48 | - Coverage: Every generated workflow skill carries this rail. |
| 49 | - Normal users talk to Hermes; OMH CLI is infra. |
| 50 | - Boundary: Prepared OMH routing, cards, handoffs, or artifacts are not observed execution, image generation, delivery, review, CI, merge-readiness, or merge evidence. |
| 51 | |
| 52 | ## Use When |
| 53 | |
| 54 | Use when Hermes should help an operator or coding executor understand an unfamiliar repository before planning implementation. |
| 55 | |
| 56 | Strong routing signals: `codebase-onboarding`, `codebase onboarding`, `repo onboarding`, `repository onboarding`, `codebase tour`, `code tour`, `new repo orientation`, `understand this repo`, `how this repo works`, `first task runway`, `개발자 온보딩`, `레포 온보딩`, `코드베이스 온보딩`, `처음 보는 레포`, `레포 구조 설명` |
| 57 | |
| 58 | ## Catalog Metadata |
| 59 | |
| 60 | Category: `planning` |
| 61 | Phase: `codebase-onboarding` |
| 62 | Hermes role: `planner` |
| 63 | Quality tier: `onboarding-gated` |
| 64 | |
| 65 | Quality bar: |
| 66 | |
| 67 | - Name the audience, depth, repo root, read-only boundary, and stop condition. |
| 68 | - Separate observed files and commands from inferred architecture and unknowns. |
| 69 | - Produce a practical reading path and first-task runway rather than a flat file tour. |
| 70 | - Route follow-up implementation to plan, ultraprocess, verification-gate, or workspace-audit as needed. |
| 71 | |
| 72 | Handoff policy: |
| 73 | |
| 74 | Keep codebase orientation in Hermes as prepared local context. File reads, generated maps, and first-task recommendations need observed repo evidence; code edits and executor handoffs happen only after onboarding identifies a concrete task. |
| 75 | |
| 76 | Required inputs: |
| 77 | |
| 78 | - repo root or supplied source context |
| 79 | - target audience: operator, new contributor, maintainer, or executor |
| 80 | - desired depth: quick map, architecture tour, first issue, or handoff pack |
| 81 | - known constraints such as no network, no secrets, or read-only mode |
| 82 | |
| 83 | Expected outputs: |
| 84 | |
| 85 | - codebase_onboarding_plan/v1 |
| 86 | - repo_map/v1 |
| 87 | - reading_path/v1 |
| 88 | - domain_glossary/v1 |
| 89 | - risk_and_unknowns_map/v1 |
| 90 | - first_task_runway/v1 |
| 91 | - not-evidence boundary |
| 92 | |
| 93 | Artifact expectations: |
| 94 | |
| 95 | - repo_map/ |