add-project

name

add-project

description

Add a virtual project to a dev-loop workspace and SYNC it to the backend at add time. Use when the user invokes /dev-loop:add-project, or asks to "add a project", "create a new project in the team", "onboard a new product area", or "set up <project> in the loop". Operator-present — it find-or-creates the Linear/hub project, ensures the team's dev-loop label taxonomy, scaffolds the strategy doc, interviews test-env / dev-split / intake / launch config, and writes through the VALIDATED `dev-loop team add-project` mutator; repos are added separately with /dev-loop:add-repo. 1.x workspace schema only.

add-project — register a virtual project + backend sync

ROLE: You are the operator-present setup skill that creates a workspace project AND aligns it with the backend in the same pass, so config and backend never drift.

MISSION

A project is a virtual unit (a Linear/hub project + delivery semantics) that later references repos (workspace model, §27). This skill interviews the operator, find-or-creates the backend project, ensures the label taxonomy, scaffolds the strategy doc, and persists the project through the validated mutator. Repos are added separately with /dev-loop:add-repo.

BOOT

Operator-present, but each invocation is fresh (§0); boot per §0a (the Topology block + the sections cited below). Inputs:

• The workspace dev-loop.json, resolved from cwd — none ⇒ tell the user to dev-loop team init first and stop.
• references/config-schema.md (the field shapes the mutator writes). Sections: §0 §0a §2 §4 §5a §9c §20 §27

JOBS

1. INTERVIEW

• key — a lowercase project key (state-dir + config key; not a reserved name): the workspace-internal handle.
• linearProject / hub project name — the human name in the backend.
• testEnv (base URL + any auth constraint), devSplit (two-tier senior/junior dev?), optional per-agent launch overrides.
• intake.mode (§5a): autonomous (default — PM proactively reviews the product and files its own work) or passive (PM only responds to explicit needs-pm intake; nothing is originated). Passive suits maintenance projects or teams where a human owns the roadmap; a passive project may skip the strategy doc.
• blockedStateName — did the operator add a real "Blocked" column in Linear? Record its name; else leave null (the blocked label park applies). Do not skip silently.
• comms — confirm team.comms is set (or explicitly declined); without it human-park pings and digests have no channel.

2. BACKEND SYNC (the reason this is a coding-CLI skill, not pure CLI)

• linear: if this is the FIRST project in the team, reconcile the Linear team first — verify team.linearTeam exists, ensure the dev-loop label set (dev-loop, needs-pm, Feature/Bug/Improvement, pm/qa, senior-dev/junior-dev, blocked, external-prereq + external-code/external-access (§9c), sensitive (forces the senior dev tier), env:dev/env:prod, …), and record team.linearTeamId. Then find-or-create the Linear project by name; record its id.
• service: dev-loop seed <key> "<name>" <UNIQUE_PREFIX> into the workspace hub.db (the prefix must be unique across the team's projects — doctor enforces it).

3. STRATEGY DOC

Scaffold the project strategy doc with the exact §20 field-set headings (§20 defines them once — Vision through Candidate ideas), per team.docSystem (a Linear document, a hub doc, or a repo file). Leave "Current state" for /dev-loop:add-repo to fill per repo.

4. PERSIST (validated write)

dev-loop team add-project <key> [--linear-project "<name>"] [--linear-project-id <id>] \
  [--test-url <url>] [--dev-split] [--weight <n>] [--enabled true|false] \
  [--intake-mode autonomous|passive]

The mutator re-validates the whole dev-loop.json and refuses an invalid result. It writes the project with zero repos; then run /dev-loop:add-repo to clone + register each repo.

5. VERIFY

Run dev-loop doctor (a repo-less project warns W01 until you add a repo — expected).

HARD LIMITS

• Never hand-edit dev-loop.json — persist only through the validated mutator.
• Idempotent on the backend: a matching existing project is REUSED (record its id), never duplicated; on a name clash or missing permission, list candidates and let the operator choose.
• Label provisioning stays within the dev-loop label taxonomy (§4) — the human backlog is untouched (§2).

REPORT

Report the recorded backend id, the doctor result, and the next step (/dev-loop:add-repo) to the operator.