Help us improve
Share bugs, ideas, or general feedback.
From pm-engineering
Generates structured developer onboarding documents covering service overview, architecture, local setup, testing, deployment, and key contacts. Useful when orienting new engineers or documenting a service.
npx claudepluginhub mohitagw15856/pm-claude-skills --plugin pm-engineeringHow this skill is triggered — by the user, by Claude, or both
Slash command
/pm-engineering:developer-onboarding-docThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produce a complete developer onboarding document for a service or team — covering everything a new engineer needs to be productive within their first week.
Generates onboarding documentation for new developers including environment setup, codebase overviews, learning paths, team processes, and troubleshooting FAQs.
Generates structured developer onboarding documentation and learning paths with time-based layers from Day 1 setup to ongoing references, plus markdown templates.
Generates onboarding documentation for projects: purpose, local setup, architecture overview, directory structure, key decisions, deployment steps. For day-one engineers. Triggers on 'onboarding docs', 'new engineer guide', 'getting started'.
Share bugs, ideas, or general feedback.
Produce a complete developer onboarding document for a service or team — covering everything a new engineer needs to be productive within their first week.
A good onboarding doc is not a wiki dump. It answers the questions a new engineer actually has on day one, in the order they'll have them.
Ask for these if not already provided:
Team: [Team name] | Tech lead: [Name] Last updated: [Date] | Updated by: [Name]
If something in this doc is wrong or out of date, fix it now — it will affect every engineer who onboards after you.
[3–5 sentences. What problem does this service solve? Who calls it, and who does it call? What would break if this service went down?]
Service type: [API / Background worker / Event consumer / Data pipeline / etc.] Consumers: [List internal services or external clients that depend on this service] Dependencies: [List upstream services, databases, and third-party APIs this service calls]
Architecture diagram: [Link or embed — even a rough ASCII diagram helps]
[Caller A] ──→ [This Service] ──→ [Database]
│
└──→ [Downstream Service]
Repository: [Link]
Main branch: [main / master]
Language: [e.g. Go 1.22 / Node.js 20 / Python 3.12]
Framework: [e.g. Express / FastAPI / Gin / Rails]
[repo-root]/
├── [src/ or cmd/] # Application code
│ ├── [handlers/] # HTTP handlers / controllers
│ ├── [services/] # Business logic
│ ├── [repository/] # Database access layer
│ └── [models/] # Data models / types
├── [tests/] # Test files
├── [migrations/] # Database migrations
├── [scripts/] # Utility scripts
├── [.github/workflows/] # CI/CD pipeline definitions
└── [docs/] # Additional documentation
Where to start reading: [Point to 2–3 key files that give the best orientation — e.g. main.go, routes.js, app.py]
X-User-Id header"]Estimated setup time: [X minutes for a fresh machine]
# 1. Clone the repo
git clone [repo URL]
cd [repo-name]
# 2. Copy and configure environment variables
cp .env.example .env
# Edit .env — see "Environment Variables" section below
# 3. Start dependencies (database, cache, etc.)
[docker compose up -d / make deps / etc.]
# 4. Install dependencies
[npm install / go mod download / pip install -r requirements.txt]
# 5. Run database migrations
[migration command]
# 6. Start the service
[start command]
# 7. Verify it's working
curl http://localhost:[PORT]/health
# Expected: {"status":"ok"}
If this doesn't work: Check [Troubleshooting section below] or ask in #[channel].
| Variable | Required | Description | Example |
|---|---|---|---|
DATABASE_URL | Yes | Connection string for the primary DB | postgres://localhost:5432/[db] |
[VAR_2] | Yes | [Description] | [Example] |
[VAR_3] | No | [Description — default value] | [Example] |
Secrets for local dev: [Where to get them — e.g. "Run [command] to pull from Vault" or "Ask [person] in #[channel]"]
[start command] # Start the service
[test command] # Run all tests
[lint command] # Run linter
[format command] # Format code
[migration command] # Run pending migrations
[seed command] # Seed local database
Testing philosophy: [e.g. "We test at the integration layer — unit tests for pure functions, integration tests for anything touching the DB or external services"]
# All tests
[test command]
# Unit tests only
[unit test command]
# Integration tests (requires local deps running)
[integration test command]
# A specific test file or test case
[test command with filter]
Test coverage: [X]% (minimum required to pass CI: [Y]%) Coverage report: [Where to find it]
*_test.go]tests/integration/]tests/helpers/db.go"][Branch naming convention — e.g. feature/[ticket-id]-short-description, fix/[ticket-id]-short-description]
[lint command]).env.example and documented# Create a new migration
[migration create command]
# Apply pending migrations
[migration up command]
# Roll back last migration
[migration down command]
Migration rules:
How code gets to production: [1–2 sentence summary — link to full CI/CD playbook if it exists]
main → automatic deploy to stagingDeployment docs: [Link to CI/CD playbook or pipeline docs]
Who can deploy: [Any engineer / Lead engineer / On-call engineer — specify]
Deployment channel: #[deployments channel]
Dashboard: [Datadog / Grafana / CloudWatch — link] Logs: [Log aggregation tool and link — e.g. "Logs are in Datadog under service:[name]"] Traces: [Tracing tool and link if applicable] Alerts: [Where alerts fire — e.g. PagerDuty / Slack #alerts-[service]]
Key metrics to know:
On-call schedule: [PagerDuty / Opsgenie link]
Who's on-call now: [Link to current schedule or #oncall channel]
Escalation: [On-call → [team lead] → [EM] — after [X] minutes unacknowledged]
If you get paged:
| Role | Name | Best way to reach |
|---|---|---|
| Tech lead | [Name] | Slack: @[handle] |
| On-call rotation | [Team] | PagerDuty / #on-call |
| Platform / infra | [Team] | #platform Slack channel |
| Database / DBA | [Name or team] | #database Slack channel |
| [Upstream service] owner | [Name] | Slack: @[handle] |
Where to ask questions:
#engineering#[service-name]#incidents[command].env is populated — missing values cause silent failures[log command]#[channel][version check command][clean install command][start deps command]#deployments