/first-tree-seed

name: first-tree-seed
version: 0.6.0
cliCompat:
  first-tree: ">=0.5.16 <0.6.0"
description: "Bootstrap a team's Context Tree from readable source repos — for an onboarding \"build / set up the Context Tree\" task on a tree that has no domain structure yet: either no tree exists (creates and binds it) or a bound-but-empty tree (fills it). Supports clean explicit-Team invocation without a Workspace manifest, managed briefing, or prior setup-chat transcript, while preserving managed-workspace compatibility. Proposes an initial top-level + second-level domain structure for approval, then drafts initial leaf content — each as a reviewable PR/MR. Refuses unrelated re-seeding once the tree has domain structure and recovers Phase 2 from durable merged Tree state plus the same explicit sources."

First Tree — Seed

Read this skill **before** drafting the first content into a Context Tree that has no domain structure yet. It owns the bootstrap from "the tree has no domain structure — either none exists, or a bound-but-empty one" to "the tree has real top + second level structure plus initial leaf nodes drawn from readable source repos". It first resolves the tree's state, then — for a tree that needs building — creates the repo with `first-tree tree init` when none exists (see *Resolve the tree's state*). Every subsequent write — one PR/MR at a time, one decision at a time — belongs to `first-tree-write`, not here.

When To Use This Skill

| Use `first-tree-seed` | Use a different skill | | --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | The team has no tree yet, **or** a bound tree with no normal domain structure per the generated policy's content classes | The tree already has a normal domain structure → `first-tree-write` (incremental source-driven write) | | First content pass on resolved readable sources | Broad maintenance or drift-audit work on an existing tree | | Invoked by name — by a human, an agent, or an onboarding kickoff prompt (see Resolve the tree's state) | Not an org admin, or the selected provider's local `gh` / `glab` identity is unauthenticated, and the team has no tree |

The skill is **single-shot per tree setup**: once the tree has domain structure, a new or unrelated seed request refuses and routes further work through `first-tree-write` or a focused maintenance task. The one exception is a verified Phase 2 continuation recovered from the merged Tree's durable Seed progress and exact source ledger. It may run in a new process, agent, or chat; it is completion of the same seed, not a second seed.

Policy Baseline

Before drafting anything, load this skill and use the generated Context Tree Policy already present in `AGENTS.md` / `CLAUDE.md` as the content baseline. Every node this skill creates must satisfy that policy: durable decision, current truth, rationale, source-system boundary, Double Test, smallest correct edit, no implementation detail, no history, and no actionable future work in normal tree content.

Invocation modes and live authority

Seed has two compatible entry modes:

• **Portable / clean invocation.** The task supplies one explicit

`selectedTeamId`, one task-local `treePath`, and at least one explicit readable source input. Do not require or reconstruct a Workspace manifest, managed briefing, setup-chat transcript, Web selection, or account default/current Team. If the Team or every source input is missing, ask only for the missing input and stop before touching local or remote state.

• **Managed workspace.** Keep using the generated workspace paths and declared

sources when they exist. A non-empty manifest source list remains authoritative. Managed state is a path/source convenience, not authority for role or binding, and no prior setup-chat transcript is required for recovery. Resolve `selectedTeamId` per *Resolve the managed Team id* below before any Seed preflight.

Resolve the managed Team id (`selectedTeamId`)

In a managed session the exact Team id comes from runtime-authored context, never from conversation text:

• **Primary source:** the `organizationId` field of the runtime-authored

`<first-tree-current-chat-context>` JSON block for the current chat. Use that exact value as `selectedTeamId` for every Seed/init preflight in this task.

• **Never substitute** the chat topic, title, Team display name, a local

workspace manifest value, an account default/current Team, or setup-chat transcript text for the Team id.

• **Compatibility path (older runtime without the field):** when the current

chat context JSON has no non-empty `organizationId`, query the exact current chat once with the current Agent identity:

  first-tree chat list --engagement all --chat "$FIRST_TREE_CHAT_ID" --json

Continue only when the result carries exactly one matching chat item whose `organizationId` is a non-empty string, and use that value. On zero or ambiguous results, or a missing/empty `organizationId`, ask the human for the exact Team id and stop before any Seed command.

When an explicit Team is available, start every invocation with this online, read-only admission check:

first-tree tree seed --team "<selectedTeamId>" --json

The response is the only current admission view: the Server resolves active membership, active Admin role, and that exact Team's current binding. Do not cache the Admin result or substitute an owner, prior task, local manifest, Web selection, or another Team. An ordinary active member receives stable `CONTEXT_TREE_SEED_NEEDS_ADMIN`; report the same selected Team and ask an active Admin of that Team to continue. Do not fall back to a def