onboard

Files (1)

• SKILL.md

SKILL.md (first lines)

# Onboard this project

## Step 1 — Initialise the directory

Find the plugin's `scripts/init.sh` using Glob, then run it
with `bash <path>`. The script is idempotent: it only creates
files that do not already exist, so running it on an already-
onboarded project is safe. Confirm `.sweatshop/memory.json`
and `.sweatshop/domain.json` exist afterwards.

## Step 2 — Check for existing onboarding

Before detecting anything, read the two JSON files written by
init.sh and decide whether this project is already onboarded.
The data in these files persists across dev sessions and is
authoritative — do NOT clobber it without explicit user
consent.

A project is considered **already onboarded** if EITHER:
- `memory.json` contains a non-empty `toolchain` object, OR
- `domain.json` contains a `domain` object with a `type`
  field set.

### If already onboarded

1. Summarise the existing configuration to the user:
   - Toolchain commands currently cached (build / test /
     lint) and the config file each was detected from.
   - Domain type, focus areas, and whether it was
     `user_refined`.
2. Ask the user to choose one of:
   - **(a) keep as-is (default)** — skip remaining steps,
     report and exit. Nothing is written.
   - **(b) fill missing sections only** — run detection for
     toolchains/domain entries that are absent, leave
     populated entries untouched.
   - **(c) re-detect everything (overwrite)** — run the
     full detection flow and overwrite existing entries.
     Preserve `domain.user_refined: true` across the
     overwrite if it was set previously, unless the user
     explicitly refines the new detection again.
3. Wait for an explicit choice before continuing. Do not
   assume.

### If not yet onboarded

Proceed directly to Step 3.

## Step 3 — Detect toolchains

Run the detection logic for each toolchain below. For each one,
check for config files in the project root using the detection
order listed. Use the **first match** found. If nothing matches,
skip that toolchain and note it as "not detected".

### Build

Detection order:
1. Makefile / GNUmakefile -> make
2. Cargo.toml -> cargo build
3. package.json -> npm run build (or yarn/pnpm if lockfile present)
4. go.mod -> go build ./...
5. *.csproj / *.sln -> dotnet build
6. build.gradle / build.gradle.kts -> gradle build
7. pom.xml -> mvn compile
8. CMakeLists.txt -> cmake --build build
9. meson.build -> meson compile -C build

### Test

Detection order:
1. Makefile / GNUmakefile -> make test
2. Cargo.toml -> cargo test
3. package.json -> npm test (or yarn/pnpm if lockfile present)
4. go.mod -> go test ./...
5. *.csproj / *.sln -> dotnet test
6. build.gradle / build.gradle.kts -> gradle test
7. pom.xml -> mvn test
8. pytest.ini / pyproject.toml / setup.cfg -> pytest
9. requirements.txt with test files -> pytest

### Lint

Detection order:
1. Makefile / GNUmakefile -> make lint
2. Cargo.toml -> cargo clippy
3. package.json -> npm run lint (or yarn/pnpm if lockfile present)
4. go.mod -> golangci-lint run (fallback: go vet ./...)
5. *.csproj / *.sln -> dotnet format --verify-no-changes
6. build.gradle / build.gradle.kts -> gradle check
7. pom.xml -> mvn checkstyle:check
8. ruff.toml / pyproject.toml with ruff -> ruff check .
9. .flake8 / setup.cfg with flake8 -> flake8 .
10. .pylintrc -> pylint .

## Step 4 — Ask the user for the domain expert

The user drives this step. Before doing any analysis yourself,
ask them what kind of domain expert this project needs. A
short, open question works best:

> "What should the domain expert for this project be? For
> example: crypto/DeFi, high-performance systems, frontend/UX,
> ML/data, distributed systems, embedded, game engines, etc.
> You can also describe it in your own words — I'll shape the
> focus areas and review criteria around your answer."

Wait for an explicit answer. Do not guess. Treat whatever the
user says as authoritative for `domain.type`. Common shapes
of answers and how to handle them:

- **A named domain** (e.g. "crypto/DeFi", "frontend/UX") —
  use it directly as `type`. Derive sensible `focus_areas`
  and `review_criteria` for that domain (see examples below).
- **A free-form description** (e.g. "low-latency trading
  engine, care about allocator behaviour and lock
  contention") — use a short label for `type` and lift the
  user's own phrasing into `focus_areas` / `review_criteria`.
- **"Not sure" / "you pick"** — only then fall back to

From POPFD/claude-sweatshop, MIT.

More from POPFD/claude-sweatshop