How do I install the Onboarding skill?

Run npx skillmds@latest add recallnet/onboarding in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Onboarding safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Onboarding?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Onboarding free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Onboarding?

recallnet (@recallnet) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Onboarding by recallnet — Agent Skill

Name: Onboarding
Author: recallnet

Onboarding

First skill for new contributors, fresh clones, and setup questions in the mainline repo. Separates developing mainline from using mq on another repo, verifies the local baseline, explains canonical-root trust, and clarifies which commands should or should not work in this source checkout.

recallnet 4cfddbb 2.8 KB Updated Sep 17, 2026

File contents

mainline onboarding

Use this skill when someone is new to this repository and needs a reliable first pass through setup, baseline checks, and terminology.

Use this before the worktree skill when the user is still figuring out what this repo is, how it is installed, or which commands are supposed to work in this checkout.

Goal

Separate these two jobs immediately:

developing the mainline codebase in this repo
using mainline to manage some other target repo

Do not let the user conflate them.

Read first

Read these before making claims:

Contributor baseline

From the repo root, run:

make build
go test ./...
./bin/mq --help
./bin/mq repo show --repo . --json
./bin/mq repo root --repo . --json
./bin/mq status --repo . --json

Interpretation:

make build should succeed
go test ./... should succeed; test helpers intentionally neutralize global Git signing config for temporary repos
mq repo root --repo . --json is the source of truth for whether the current checkout is the canonical protected root checkout
mq status --repo . --json may fail in a fresh source clone until this repo has been explicitly initialized as a managed queue target on this machine

Canonical-root explanation

Explain this concretely:

the repo root checkout on main is the canonical protected root checkout
topic worktrees are where feature work happens
if the current checkout is not canonical, contributors should say so plainly
if mq repo root --repo . --json says trustworthy: false, explain the recommended action rather than pretending the checkout is fine

Output expectations

At the end of onboarding, summarize:

whether the user is developing mainline or using it on another repo
whether the current checkout is canonical and trustworthy
whether the local build/test baseline succeeded
which commands are expected to work in this checkout right now
the next step for a contributor versus the next step for an operator

---name: onboardingdescription: First skill for new contributors, fresh clones, and setup questions in the mainline repo. Separates developing mainline from using mq on another repo, verifies the local baseline, explains canonical-root trust, and clarifies which commands should or should not work in this source checkout.---# mainline onboardingUse this skill when someone is new to this repository and needs a reliable firstpass through setup, baseline checks, and terminology.Use this before the `worktree` skill when the user is still figuring out whatthis repo is, how it is installed, or which commands are supposed to work inthis checkout.## GoalSeparate these two jobs immediately:- developing the `mainline` codebase in this repo- using `mainline` to manage some other target repoDo not let the user conflate them.## Read firstRead these before making claims:1. [README.md](/Users/devrel/Projects/recallnet/mainline/README.md)2. [docs/install.md](/Users/devrel/Projects/recallnet/mainline/docs/install.md)3. [docs/FLOWS.md](/Users/devrel/Projects/recallnet/mainline/docs/FLOWS.md)4. [SPEC.md](/Users/devrel/Projects/recallnet/mainline/SPEC.md)5. [PLAN.md](/Users/devrel/Projects/recallnet/mainline/PLAN.md)6. [AGENTS.md](/Users/devrel/Projects/recallnet/mainline/AGENTS.md)7. [CONTRIBUTING.md](/Users/devrel/Projects/recallnet/mainline/CONTRIBUTING.md)## Contributor baselineFrom the repo root, run:```bashmake buildgo test ./..../bin/mq --help./bin/mq repo show --repo . --json./bin/mq repo root --repo . --json./bin/mq status --repo . --json```Interpretation:- `make build` should succeed- `go test ./...` should succeed; test helpers intentionally neutralize global Git signing config for temporary repos- `mq repo root --repo . --json` is the source of truth for whether the current checkout is the canonical protected root checkout- `mq status --repo . --json` may fail in a fresh source clone until this repo has been explicitly initialized as a managed queue target on this machine## Canonical-root explanationExplain this concretely:- the repo root checkout on `main` is the canonical protected root checkout- topic worktrees are where feature work happens- if the current checkout is not canonical, contributors should say so plainly- if `mq repo root --repo . --json` says `trustworthy: false`, explain the recommended action rather than pretending the checkout is fine## Output expectationsAt the end of onboarding, summarize:- whether the user is developing `mainline` or using it on another repo- whether the current checkout is canonical and trustworthy- whether the local build/test baseline succeeded- which commands are expected to work in this checkout right now- the next step for a contributor versus the next step for an operator

Frequently asked questions