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