---
name: fp-welcome
description: Onboarding walkthrough for a new hire on this repo. Builds a personalized two-minute tour grounded in the actual fastpace context, agents, hooks, and skills present — and points the dev at one tiny scoped first PR. Triggers on /fp-welcome. Read-only on the repo; may write to ~/.fastpace/welcome-<repo>.md. Available on Team+.
---

# fp-welcome

Give a new teammate a 2-minute orientation to *this* repo. Not a generic tutorial — a grounded one. The goal is "developer is unblocked and has shipped their first meaningful PR within 3 days, not 2 weeks."

## When to run this

- A teammate joins the team. Their first session.
- A teammate returns from a long leave and the repo has changed.
- A returning contributor wants a "what's new since I last touched this."

## What to do

1. **Confirm with the dev who they are** (optional, soft). Ask their experience level only if it helps you tune the tour:
   - "Are you new to this codebase, or just new to fastpace?" — changes whether you focus on the domain or on the tooling.
   - "What kind of change do you expect to make first?" — used in step 5 to pick the first PR target.

2. **Run discovery first if needed.** If `fastpace/context/` is empty or missing key files (architecture.md, conventions.md), invoke `/fp-discover` before continuing. The tour is meaningless without context.

3. **Walk the six sections of the tour** (see "Tour structure" below). Cite files. Always cite files.

4. **End with a concrete next action.** Not "let me know if you have questions." A specific PR target with three suggested first steps. Use a tiny scoped improvement — a stale comment, a missing test, a typo'd doc — never anything ambiguous.

5. **Offer the CLI cheat-sheet.** `fastpace welcome` (the CLI command, not this skill) writes a personalized markdown file to `~/.fastpace/welcome-<repo>.md`. Mention it; suggest they keep it open in another tab for week 1.

## Tour structure

Six sections. Roughly 20–30 seconds each. Always grounded in *this* repo's files.

### 1. What this repo is

- One sentence. Pull from README.md's first paragraph or `package.json` description.
- Mention the stack (Node / Python / Rust / Go). If the stack is unusual, say one line about why.

### 2. Start here

- The 2–4 docs every new contributor should read first, in order.
- README.md → ONBOARDING.md (if present) → CLAUDE.md (so they know what Claude already knows) → CONTRIBUTING.md (if it exists).
- For each: one line on what's inside. **Cite the file path.**

### 3. fastpace artifacts

- `fastpace/context/` — what's there (architecture, conventions, decisions, glossary, learnings, patterns).
- `fastpace/docs/{prd,erd,adr}/` — count + most recent.
- `fastpace/watch-cards/` — in-flight features.
- If any of these are empty, say so: "no ADRs yet — this is your chance to write the first one when you have a decision to record."

### 4. What's wired into .claude/

- Agents available (read the names of files in `.claude/agents/`).
- Skills available (read directory names in `.claude/skills/`).
- Hooks active — name a few they'll definitely hit (e.g. agent-scope-guard blocks Bash out-of-scope; secret-scanner blocks committed secrets).

### 5. A first PR

- Pick **one** specific, low-risk change in this repo. Suggestions in order of preference:
  - Update a stale README line you can prove is wrong (cite the line).
  - Add a test for a function that has no tests.
  - Fix an obvious typo in a doc.
  - Add a missing `fp-extract-learnings` entry for a recent merge.
- Walk them through: `claude` → `/fp-new-feature <slug>` → make the change → `/fp-pr-summary`.

### 6. Surprises

- "Hooks will block dangerous Bash. The coach message tells you how to request an exception."
- "Every AI call you make writes a receipt. Your manager doesn't see it. Auditors can."
- "`fastpace me` shows your personal slice."

## What NOT to do

- **Don't dump everything.** A new dev's working memory is full already. Six sections, max.
- **Don't generalize.** Don't say "we follow good practices" — name the practice and cite where it's documented.
- **Don't be cheerful filler.** Skip "Welcome to the team!" and the like — the human onboarding lead handles that. You handle the technical orientation.
- **Don't recommend `/fp-new-feature` for a vague first task.** Always pick the change concretely; ambiguity wastes day 1.

## After the tour

Suggest they run:

```bash
fastpace welcome --write-only
```

to refresh the CLI cheat-sheet whenever the repo's tooling changes. Tell them to bookmark `fastpace help` and `/fp-ask` as their two best friends in week 1.