원클릭으로 Manus에서 모든 스킬 실행

repo-onboarding

스타1

포크1

업데이트2026년 6월 10일 10:25

Systematically map an unfamiliar codebase before changing it — entry points, build/test loop, conventions, data flow. Use when starting work in a repo you haven't seen, or asked "how does this codebase work?".

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

jnMetaCode

jnMetaCode/skillet

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

repo-onboarding

Resist editing until you can answer: how do I run it, how do I test it, where does the change go, and what style does this house write in?

Procedure (15 minutes, in order)

The README + manifest first. README.md, then the manifest (package.json / pyproject.toml / go.mod / Cargo.toml): name, scripts, dependencies. The scripts block is the repo telling you its verbs.
Find the entry points. bin/main fields, src/index.*, cmd/, __main__.py. Trace one request/command end-to-end at skim depth — names only, no line-reading.
Establish the test loop before touching anything. Run the test command; record how long it takes and whether it's green at HEAD. A red baseline changes everything you conclude later.
Map the directories (one line each, only top two levels). Mark the ones that are generated/vendored so you never read them again.
Sample the house style. Open the 2–3 most-recently-changed source files (git log --name-only -10): error handling pattern, naming, comment density, test structure. Your changes should be indistinguishable from these.
Find the seams. Where does config enter? Where is I/O isolated? What is the one module everything imports? That module is load-bearing — changes there need the most care.
Check the repo's own rules: CONTRIBUTING.md, CLAUDE.md, .github/ workflows (what CI actually enforces), lint configs.

Output

Write a short map (10–20 lines) before starting the actual task:

run:   npm start (src/cli.js)        test: npm test, ~6s, green at HEAD
flow:  cli.js → commands/* → store.js (all persistence) → index.json
style: ESM, no deps, errors thrown as plain Error, tests in test/*.test.js
care:  store.js is imported everywhere; schema changes ripple
rules: CI runs lint+test on 3 OS; commits are conventional

Keep it honest — list what you didn't look at, so later-you knows where the map has blank spots.

이 저장소의 다른 Skills

같은 저장소

self-evolve

jnMetaCode/skillet

Make the agent improve with every task — review the run, distill lessons into durable memory, and reinforce what worked. Use at the end of any non-trivial task, or when the user asks the agent to "learn from this".

2026-06-101

incident-postmortem

jnMetaCode/skillet

Write a blameless, actionable incident postmortem from the raw facts. Use after an outage/incident, or when asked to write up "what happened" for the team.

2026-06-101

pr-description

jnMetaCode/skillet

Write a reviewer-first pull-request description from the actual branch diff. Use when opening a PR or asked to write/improve a PR description.

2026-06-101

systematic-debugging

jnMetaCode/skillet

Root-cause a bug with a hypothesis-driven loop instead of shotgun edits. Use when a bug isn't obvious after the first look, or when asked to "find out why" something fails.

2026-06-101

test-writing

jnMetaCode/skillet

Write tests that catch real regressions — behavior-focused, minimal mocking, edge cases chosen from the code's actual branches. Use when adding tests for new code or backfilling tests for a fix.

2026-06-101

changelog

jnMetaCode/skillet

Generate or update a CHANGELOG.md in Keep a Changelog format from real git history. Use when cutting a release, tagging a version, or asked "what changed since…".

2026-06-101

name	repo-onboarding
description	Systematically map an unfamiliar codebase before changing it — entry points, build/test loop, conventions, data flow. Use when starting work in a repo you haven't seen, or asked "how does this codebase work?".
version	1.0.0
license	MIT
keywords	["onboarding","codebase","exploration","architecture","conventions"]

repo-onboarding

Resist editing until you can answer: how do I run it, how do I test it, where does the change go, and what style does this house write in?

Procedure (15 minutes, in order)

The README + manifest first. README.md, then the manifest (package.json / pyproject.toml / go.mod / Cargo.toml): name, scripts, dependencies. The scripts block is the repo telling you its verbs.
Find the entry points. bin/main fields, src/index.*, cmd/, __main__.py. Trace one request/command end-to-end at skim depth — names only, no line-reading.
Establish the test loop before touching anything. Run the test command; record how long it takes and whether it's green at HEAD. A red baseline changes everything you conclude later.
Map the directories (one line each, only top two levels). Mark the ones that are generated/vendored so you never read them again.
Sample the house style. Open the 2–3 most-recently-changed source files (git log --name-only -10): error handling pattern, naming, comment density, test structure. Your changes should be indistinguishable from these.
Find the seams. Where does config enter? Where is I/O isolated? What is the one module everything imports? That module is load-bearing — changes there need the most care.
Check the repo's own rules: CONTRIBUTING.md, CLAUDE.md, .github/ workflows (what CI actually enforces), lint configs.

Output

Write a short map (10–20 lines) before starting the actual task:

run:   npm start (src/cli.js)        test: npm test, ~6s, green at HEAD
flow:  cli.js → commands/* → store.js (all persistence) → index.json
style: ESM, no deps, errors thrown as plain Error, tests in test/*.test.js
care:  store.js is imported everywhere; schema changes ripple
rules: CI runs lint+test on 3 OS; commits are conventional

Keep it honest — list what you didn't look at, so later-you knows where the map has blank spots.