onboard-repository

Featured

Inspect an unfamiliar or brownfield repository, trace one real operational path, and propose evidence-backed improvements that help future agents work independently. Use when explicitly asked to onboard, map, assess, or backfill agent-facing repository guidance; use again after the user approves exact proposal items. The first pass is read-only and must not edit files, install tools, start services, create state, or infer missing product policy.

Data & Documents 1,214 stars 432 forks Updated 4 weeks ago MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
100
Recency 20%
90
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Onboard Repository Turn an unfamiliar repository into a verified map for future work. Treat the repository as the system of record. Separate facts from gaps and suggestions. ## Safety Contract The first pass is always inspection and proposal only, even when the worktree is writable. - Read every applicable `AGENTS.md` before inspecting deeper files. - Capture the initial Git root, revision, branch, status, and worktree list. - Preserve all pre-existing tracked and untracked changes. - In the initial boundary capture, before deeper repository inspection, record pre-state existence or safe hashes for relevant ignored state such as `.env.local`, dependency directories, and managed repository state. Never print secret contents. If an initial baseline was missed, report pre/post equivalence as **Unknown**; a later sample cannot reconstruct it. - Treat ignore rules and managed-state manifests as part of the boundary, not deeper inspection. Read them before fixing the baseline, enumerate every relevant ignored database, sidecar, dependency, environment, build, and managed-state path they reveal, and record each one explicitly. For ignored directories, use a content-sensitive per-file hash inventory; a filenames- only hash does not prove that contents stayed unchanged. - Use only read-only discovery commands. Do not install dependencies, start services, invoke migrations, create caches or state, or edit files. - Use task-prefixed shell variable names. In zsh...

Details

Author
hoangnb24
Repository
hoangnb24/repository-harness
Created
4 months ago
Last Updated
4 weeks ago
Language
Rust
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Data & Documents Listed

hr-onboard

Discovers what belongs in a repository's AGENTS.md by attempting real work and recording the friction, rather than by scanning the codebase and describing it. Use this whenever the user mentions AGENTS.md, CLAUDE.md, agent instructions, a context file, steering docs, onboarding a repo for agents, or asks what they should write down for their coding agent - and also when they ask why an agent keeps making the same mistake in this repo, or want to trim an instruction file that has grown too long. Use it even if they do not name a file, and even if they only say something like "set this project up for Claude" or "make Codex work properly here".

0 Updated 4 days ago
fujiakito
AI & Automation Listed

project-onboard

Use ONLY when the user explicitly requests takeover, inventory, or recovery of an existing Brownfield, legacy, or incomplete repository and expects durable baseline, AS-IS documentation, Feature Inventory, and Specs. First entry into an unfamiliar repository alone is not a trigger. Excludes ordinary Q&A, read-only review, diagnosis-only work, Greenfield initialization, and single Feature implementation.

1 Updated 4 days ago
MaoyuanYang
AI & Automation Listed

onboard

Read an unfamiliar repo and write the agent-facing context file every other order depends on — conventions, commands, boundaries and the quality bar, proven by running them. Gated on a fresh agent answering the crew's real questions from the file alone.

6 Updated today
saman-mb