Context

The current `/onboard` skill mixes two concerns:

1. Framework bootstrap — setting up the apexstack fork for the first time (company, team, tech stack defaults, project registry)
2. Per-project discovery — configuring a specific managed project's hooks and overrides

These should be separate flows with different triggers:

• Framework bootstrap → `/setup` (new skill, first-run, once per fork)
• Per-project discovery → embedded in `/idea` and `/handover` (when a project enters the portfolio, not as a standalone skill)

Design: `/setup`

The UX follows a "describe, propose, confirm" pattern (3 exchanges instead of 7 sequential questions):

1. "Describe your company/team and tech stack" — one open-ended question. User says "We're a 3-person startup building TypeScript APIs on AWS with React frontends" or "Solo developer, Python ML pipelines on GCP, no frontend."

2. Map to defaults and propose a complete config:
   ```
   Based on your stack, I'd configure:

   • Company:
   • Default CI checks: npm run lint && npm run typecheck && npm run test && npm run build
   • Default reviewers: Rex + you (CEO)
   • Default architecture paths: [framework defaults]
   • Default UI paths: [framework defaults since you said React]
   • Default commit types: [framework defaults]
     ```

3. "Use these defaults, or customize?" — one yes/no. Most users say yes and they're done in 3 messages.

4. If customize → drill into only the specific field they want to change.

Writes to:

• `onboarding.yaml` (company config, committed)
• Optionally seeds `apexstack.projects.yaml` with the first project if the user names one
• Does NOT write `.claude/project-config.json` — that's per-project, handled by `/idea` and `/handover`

`onboarding-check.sh` changes: check whether `onboarding.yaml` has been filled in (not empty / not the example template), instead of checking for `.claude/session/onboarded`. The framework-level "has this fork been set up?" signal should be a committed file, not a gitignored session marker.

Design: fold `/onboard` into `/idea` and `/handover`

When a new project enters the portfolio:

• Via `/idea` — when an idea is approved and becomes a real project, the skill already creates a project entry. Add the per-project discovery ("describe this project's stack") as part of the idea-to-project transition. Writes `project-config.json` in the project's workspace or `projects//` docs.

• Via `/handover` — when an external repo is onboarded into apexstack management, the skill already does an assessment. Add the per-project config step ("here are the defaults I'd apply based on what I see in the repo — accept or customize?") as the final step of handover. Can auto-detect the stack by reading `package.json`, `requirements.txt`, `go.mod`, `Cargo.toml`, `*.tf`, Dockerfiles, etc.

The standalone `/onboard` skill is deprecated. Its functionality is split between `/setup` (framework-level) and `/idea` + `/handover` (project-level). The skill file can be kept as a redirect ("run /setup for framework config, or /handover for project config") during the transition, then removed.

Acceptance Criteria

/setup skill

• New `.claude/skills/setup/SKILL.md` with the "describe, propose, confirm" UX
• Reads existing `onboarding.yaml` to propose defaults (not blank-slate every time)
• Writes `onboarding.yaml` with the confirmed config
• Optionally seeds `apexstack.projects.yaml` if the user names a first project
• Idempotent — re-running shows current config and asks what to update
• `--reset` flag clears and re-runs from scratch

onboarding-check.sh update

• Change the SessionStart hook to check whether `onboarding.yaml` is filled in (not the example template / not empty), instead of checking for `.claude/session/onboarded`
• Message tells user to run `/setup`, not `/onboard`

/idea and /handover integration

• `/idea` skill gains a per-project config step when transitioning an idea to a real project
• `/handover` skill gains a per-project config step as the final assessment step, with auto-detection of the project's stack from its files
• Both write `.claude/project-config.json` in the project's workspace (or `projects//project-config.json` if the workspace doesn't exist)

/onboard deprecation

• Replace `/onboard` SKILL.md content with a redirect message ("use /setup for framework config, /handover for project config")
• Update CLAUDE.md skills table
• Update hooks/README.md references
• Remove after one release cycle

Site + docs

• Update site/index.html capability numbers (14 hooks, 17→18 skills)
• Update docs/getting-started.md to lead with /setup as the first step
• Update docs/multi-project.md step 4 ("Fill in onboarding.yaml") to reference /setup

Links

• Supersedes the current `/onboard` skill (shipped in PR feat(#103): mechanical enforcement of ticket-first, auto-review, onboarding #10)
• Related: `/handover` skill (existing), `/idea` skill (existing)
• CEO direction: "init or setup for first run, onboard can be part of /idea and /handover" (2026-04-12)