/first-tree-welcome

name: first-tree-welcome
version: 1.4.4
description: Use for a First Tree onboarding first chat, especially natural opening messages like "welcome aboard", "Please help me get started with First Tree", or "Please help me get settled into this team on First Tree." Also covers the production-scan fix first chat ("fix the launch blockers found by my production readiness scan"). Do not use for external-channel or integration messages (including Feishu), dedicated tree setup chats, ordinary chats, PR/MR reviews, repo scans, tree writes, or maintenance.

First Tree Welcome

Scope

Use this skill only when the chat is clearly the onboarding first chat created by First Tree, including natural messages such as "welcome aboard", "Please help me get started with First Tree", or "Please help me get settled into this team on First Tree." Do not use it for ordinary chats, PR/MR reviews, repo scans, tree writes, or maintenance work.

Messages attributed as `type=integration` or arriving from an external channel such as Feishu, GitHub, or GitLab are ordinary channel work, never this onboarding launcher. A new external-channel chat and a greeting such as "hello" or "你好" do not establish First Tree onboarding intent.

Two look-alikes that are NOT this launcher, and one that routes by shape:

• **A dedicated tree-build / single-task chat** (you were placed in it, or it IS

one) — run that task's own skill (`first-tree-seed` to build/seed a tree, `first-tree-read` / `first-tree-write` as appropriate), not this launcher flow.

• **A repo-scan chat** — it can open with the same "welcome aboard" line but then

asks for a repository scan or readiness report; run its own bound scan skill.

• **A production-scan FIX chat** — the opening message references an

already-completed scan ("fix the launch blockers found by my production readiness scan") with a `Repository:` line, plus a `Machine-readable findings: https://report.first-tree.ai/<key>.json` line when the report key survived the handoff. Nothing needs re-scanning — never look for a scan skill. This is the launcher for a pre-selected fix: once a readable findings source exists, route by blocker count — several eligible blockers become their own fix chats, a single one is just fixed in place (see "Production-scan fix handoff" below). The onboarding greeting ("welcome aboard") only tells you the human's role for later setup gating; it does NOT change how you handle the fix. No readable findings source → ask for the report or a re-run, then stop.

What This Is

Make the first work loop immediate and reviewable:

1. **Start from the user's goal** — deliver value from whatever input the user gave: their messages, pasted content, attachments, a local folder, or none at all. Connect code only when the goal genuinely needs it. 2. **When code is readable, show it** — take a bounded look and return a two-sentence project receipt, without pretending that receipt is product value. 3. **Complete one microtask here** — offer one or two small single-select choices, do the selected work in this first chat, and show a concrete result. 4. **Bridge once** — after the result, offer only the one next step that follows directly from it. Setup is never the price of starting work.

This chat is **value-first, visible, and consent-gated**. It is not a launcher for the first task and it is not a parallel-work demo. Do not show longer work, time estimates, bundles, multi-select, Context Tree setup, GitHub App setup, or child-chat fan-out before the first result. Context Tree setup is never offered from a result — not even a strong one; only an explicit user request routes to the dedicated tree chat. The user should make one low-cost choice and see it finish in the chat they are already in.

Treat the opening message as the user's onboarding request. Reply naturally, without exposing skill names or launch mechanics.

You drive; the user doesn't do your thinking

You own moving this forward to the onboarding goal (the user feels real value, and — for an admin — team setup progresses). When you hit a snag or something unexpected: **diagnose the real cause, do what you can safely do yourself, and put a question to the user only when it is genuinely theirs** — a product/scope fork, consent for a consequential or irreversible action, or an input only they can give (a credential, a repo, a login). When you must ask, ask **one** clear question with your recommendation. Never hand the user a wall of options, a raw error, a pile of diagnostics, or a mechanism choice that is yours to make. Read `## Handling snags` below before reporting any failure.

The Flow: read the state, then act

Before your first substantive reply, infer the onboarding state from the start-chat message, runtime briefing, repo resources, Context Tree binding, and available local files:

• **role**: admin, invitee, or unclear — read it from the onboarding greeting

(see **Reading role from the greeting** below); the runtime gives you no other reliable role signal, so do not assume;

• **code repo**: connected/recommended, local path/URL provided, or none;
• **Context Tree**: no binding, bound-but-empty, bound-and-populated, or unknown

— a mere binding does not imply a populated tree, and the tree you may have bound is not necessarily this team's; confirm state by reading the **target team's** tree (root `NODE.md`), not by trusting a binding;

• **detected source forge**: GitHub, GitLab, another host, or unknown — derive

it from the supplied URL or the repository's `origin` remote;

• **matching host CLI / local credentials**: `gh` for GitHub, `glab` for

GitLab, or plain `git` for another host; usable or not.

If state is unknown and the current task genuinely needs the repo or forge capability, first try to resolve it yourself (read the greeting for role, attempt the repo read, check the host CLI, `gh` or `glab`). A plain greeting or a repo-free task get