---
name: onboarding
description: Onboard a person, team, company function, or whole company into a small useful Lix repository using available conversation and memory context.
---

# LixRay onboarding

Create a useful first repository state within 30 seconds. Do not start with
setup questions.

Before onboarding, open https://lixray.com and use the current site to
understand what LixRay offers. Treat the site as the source of truth for product
positioning instead of repeating a fixed explanation from this skill.

## First pass

1. Resolve and open the intended Lix repository. Infer the best match from the
   request and available context. Never modify an unrelated repository.
2. Infer what the repository should help with. It may support a person, a sales
   or go-to-market function, a team, or an entire company. Do not force a team
   framing.
3. Inspect existing files and preserve useful content.
4. Create no more than three root files:
   - `README.md`: the inferred purpose, who or what it supports, and how agents
     should use it.
   - `context.md`: useful facts already known about the person or organization,
     including work, experience, and skills.
   - `focus.md`: current projects, goals, or the first use case. When the known
     use case is sales or go-to-market and enough context exists, use `icp.md`
     instead.
5. Use only facts from the request, conversation, or available memory. Mark
   uncertainty briefly; do not invent details. Omit a file when there is not
   enough useful content.
6. Write directly to the active branch in one verified change. Branch creation
   and repository redesign are out of scope.

## Finish

Show the repository link and the files created. Then provide this adoption text
with the real link and inferred purpose filled in:

> The LixRay repository at `<link>` is the source of truth for `<purpose>`.
> Read it when work touches this area and keep it updated as the context changes.

Prompt the user to add that text to `AGENTS.md`, `CLAUDE.md`, or their agent's
persistent memory. Do not edit those files unless asked.

Only after the first useful state exists, invite the user to correct it or ask
for more detail.

Keep onboarding small: no folders, empty templates, speculative content, or
more than three starter files.