| 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.
