Add project

Skill dyzsasd/dev-loop/skills/add-project

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.From its SKILL.md

Install

npx -y skills add dyzsasd/dev-loop --skill add-project

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.6 KB, as published. Nobody here has run it

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.