add-repo

name

add-repo

description

Add a git repo to a dev-loop workspace project IN ONE PASS. Use when the user invokes /dev-loop:add-repo, or asks to "add a repo", "register a repo", "onboard <repo> into <project>", "wire up a new service into the loop", or "share <repo> with another project". Operator-present DETECT → INTERVIEW → REGISTER → MAP — it clones (or registers an existing clone), auto-detects build + PR merge-check names, interviews the deploy shape under the team deployPolicy ceiling, writes through the VALIDATED `dev-loop team add-repo` mutator, provisions the `repo:<name>` label, and appends the repo's current state to the strategy doc. 1.x workspace schema only.

add-repo — register a repo into a workspace project (one pass)

ROLE: You are the operator-present setup skill that makes a git repo a first-class member of a workspace project in one DETECT → INTERVIEW → REGISTER → MAP pass.

MISSION

After this skill, dev-loop doctor is green and the repo is clonable, buildable, deployable within policy, and mapped into the project's strategy doc.

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 (1.x workspace schema), resolved from cwd — none ⇒ tell the user to dev-loop team init first and stop. Target project missing ⇒ run /dev-loop:add-project first.
• references/config-schema.md (registry/reference field shapes).
• Conventions context: claiming/worktrees (§7), landing + auto-merge (§12b/§12c), multi-repo registry + doc-home (§19), workspace portability (§27). Sections: §0 §0a §2 §4 §7 §12b §12c §19 §20 §27

JOBS

1. DETECT — identify the repo and where it goes

• Ask (or take from args): the project key, a short repo ref (lowercase, the registry key AND the repo:<ref> label — must not collide with a reserved name: team/lessons/wt/locks), the role (primary for the main service, docs, or omit), and either a --remote git URL to clone or an existing path already inside the workspace.
• If a remote is given and the target dir does not exist: git clone <remote> <workspace>/<ref>. If a path is given, confirm it is INSIDE the workspace (relative path); a repo outside the workspace breaks the copy-the-folder portability rule (§27) — offer to mv it in.

2. INTERVIEW — build, merge checks, deploy (auto-detect first, confirm with the operator)

• Build/typecheck: read package.json scripts (build, typecheck/tsc), or the repo's equivalent. Propose --typecheck-cmd / --build-cmd; confirm.
• Merge checks: parse .github/workflows/* for the required PR check names (the name: of jobs that run on pull_request). These become --merge-check values — the gate autoMerge polls (§12c). List them; let the operator prune.
• Landing (§12b): pr (default; agent opens a PR, CI is the build gate) or direct. If pr + --auto-merge, the agent merges its own PR once checks are green (§12c).
• Ops probes (don't skip — an unprobed deploy is invisible to ops-agent, doctor W07): ask for the repo's health endpoint (probe it live once to confirm a 2xx before recording), an optional version endpoint, the critical user-flow routes the operator declares "can't be down", and an optional read-only logs/metrics command. Persist via --ops-check <url> / --critical-route <path> / --logs-command "<cmd>".
• Deploy: interview the deploy shape (release-pr / command / none) PER environment. Enforce the team deployPolicy ceiling: if deployPolicy.<env> = "manual", that env may NOT be auto:true — the validated write (below) will reject it (E06); surface it before writing.

3. REGISTER — persist through the validated mutator (never hand-edit dev-loop.json)

Call the deterministic, self-validating CLI — it re-validates the whole file and refuses an invalid result (so you cannot corrupt config):

dev-loop team add-repo <ref> --project <key> [--path <rel>] [--remote <url>] [--role <role>] \
  [--landing pr|direct] [--auto-merge] [--merge-check "<name>"]... \
  [--typecheck-cmd "<cmd>"] [--build-cmd "<cmd>"] [--deploy-style release-pr|command] [--ops-check <url>]... \
  [--owner <project>]

• Sharing: if this repo is referenced by more than one project, the mutator REQUIRES --owner (which project owns ops/alert routing). It errors (E05) otherwise.
• Deploy environments beyond style (per-env auto / deployPrPrefix) are not yet flag-driven; after the mutator writes, edit repos.<ref>.deploy.environments if you need per-env detail, then re-run dev-loop doctor to re-validate.

4. LABEL + MAP

• Label: in the backend, ensure a repo:<ref> label exists on the team (linear) / project (service) — agents tag work by repo on multi-repo projects (§19). Skip for a project's first/only repo.
• Mini-MAP: read the repo's entrypoints, routes, and tests (read-only). Append a concise "Current state — " subsection to the project strategy doc (§20; via the backend doc or the repo file per docSystem). Adversarially double-check claims against the code before writing.

5. VERIFY

Run dev-loop doctor. It must show the repo path exists, the deployPolicy ceiling holds, and the config is valid.

HARD LIMITS

• Never hand-edit dev-loop.json — the validated mutator only (post-write per-env deploy edits are re-validated by doctor).
• Enforce the team deployPolicy ceiling (E06) before writing; a shared repo REQUIRES --owner (E05).
• The repo must live INSIDE the workspace (§27) — offer to move it in; never register an outside path silently.
• Backend label provisioning stays within the dev-loop label taxonomy (§4) — the human backlog is untouched (§2).

REPORT

Report the green doctor result (and any W-warnings) and the registered entry to the operator — the repo is in the loop.