onboarding

Initializes and maintains onboarding documentation enabling fresh contributors to bootstrap, run, and validate projects.

1|Updated Sep 11, 2026
One-click install
npx skills add https://github.com/rebuildup/my-web-2026 --skill onboarding-rebuildup
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: onboarding
Source: https://github.com/rebuildup/my-web-2026/tree/main/skills/onboarding
Command: npx skills add https://github.com/rebuildup/my-web-2026 --skill onboarding-rebuildup

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? New contributors and agents often cannot understand, launch, or validate a project without relying on chat history, tribal knowledge, or personal environment state. This Skill creates and maintains onboarding documentation so a fresh contributor can independently reach project truth. ## Core Features & Use Cases - Documentation Structure: Defines README minimums, development guides, architecture guides, ADR discovery, and progressive disclosure across docs. - Workflow & Recovery Guides: Documents GitHub workflow (release branches, stacked PRs, Draft PR rules) and recovery paths so interrupted work can be resumed from Issues, PRs, and checkpoints. - Fresh-Clone Audits: Verifies documented commands run in clean environments, checks .gitignore hygiene, .tmp/ and .reference/ contracts, and env example schemas. - Use Case: When bootstrapping a new repository or noticing setup docs are stale after a framework migration, use this Skill to generate or update README, CONTRIBUTING, architecture, and recovery docs, then validate them from a fresh clone. ## Quick Start Use the onboarding skill to initialize onboarding documentation for this repository and verify it from a fresh clone.

Frequently Asked Questions about onboarding

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write onboarding documentation for a new project?

Start with a README covering project purpose, prerequisites, bootstrap, run, and validation commands, then add architecture, development, troubleshooting, and recovery docs. Keep details in separate files with progressive disclosure rather than one giant document.

What should a README include for new contributors?

A README should state what the project builds, supported platforms, prerequisites, canonical bootstrap/run/validation commands, an internal docs index, and contribution and recovery entry points. Avoid dumping internal implementation details into it.

How do I verify setup documentation actually works?

Run documented commands in a fresh clone or clean sandbox, check for broken links, and confirm no hidden global dependencies exist. Treat docs as part of the quality gate and update them in the same PR as the changes that stale them.

Should environment variable files be committed to Git?

Actual dotenv files like .env and .env.production should be gitignored, while schema-only examples like .env.example are committed. Examples list variable names without secret values so both local and CI setups stay aligned.

When should onboarding docs be updated?

Update them whenever bootstrap commands, architecture boundaries, frameworks, release workflows, or recovery models change. Stale docs should be fixed in the same ticket or PR as the implementation change that caused the drift.