factory-setup

factory-setup

Overview

factory-setup is an interactive skill that wires a repo to its issue tracker for the factory (factory-mission, factory-queue, factory-review). It asks which tracker the repo uses, then writes .adlc/issues-provider.yml from the release template — provider and field mappings only, never credentials. It is invoked three ways:

• User-invoked (/factory-setup) — anytime, to configure or check a project.
• Model-invoked by team-boot — suggested when factory skills are installed but no provider config resolves (self-install hint, like team-setup).
• Headless via adlc-cli factory setup — scripted runs; --provider pre-answers the pick so no question is asked.

The skill is non-destructive: it never overwrites an existing .adlc/issues-provider.yml. If one exists, it verifies the wiring instead (Mode 3).

When to Use

• A tracker run halted with "no provider resolves" and named this skill.
• Setting up a new repo for factory runs (GitHub, GitLab, Linear, or Jira).
• You're unsure which tracker a repo is wired to and want a quick check.
• Switching a repo from one tracker to another (re-pick, file rewritten only on explicit confirmation).
• team-boot suggested it because factory skills are installed but no provider config resolves.

Decline Handling (when model-invoked by team-boot)

The user may choose not to configure the tracker right now. Handle decline explicitly to avoid a re-prompt loop:

• If the user declines, do not write anything. Exit cleanly; the decline is session-scoped only.
• There is deliberately no persistent opt-out marker: the marker would live in .adlc/init-options.json, whose schema is shared with adlc-cli — a tracker-specific key there is schema churn for a session preference. team-boot simply asks again next session.
• Never force a mode; setup is user-consented at every step. In headless runs there is no one to ask — --provider is required, else halt.

Core Process

Goal

Leave the repo with a committed-ready .adlc/issues-provider.yml carrying the correct provider:, or verify the existing wiring.

Security: Input Validation

The only free-form value this skill writes is the provider literal, which must be exactly one of github, gitlab, linear, jira — anything else is rejected before any write. Field-mapping values (project IDs, keys) are written verbatim into YAML comments or values only after the user confirms the rendered file content; never interpolate user values into shell — the write path is file-only (cp template, edit the provider: line). If the user pastes anything token-like (glpat-, ghp_, xoxb-, sk-), refuse to write it and remind them credentials arrive via environment only.

Fast path: if .adlc/issues-provider.yml already exists with a valid provider:, skip to Mode 3 (Already Configured) — do not re-detect, re-pick, or rewrite.

Modes at a Glance

#	Mode	When	Details in
1	Detect from git remote	quick heuristic wanted (always confirmed)	references/mode-detect.md
2	Pick explicitly	heuristic wrong, non-git remote, or --provider given	references/mode-pick.md
3	Already configured	file exists — verify wiring	references/mode-configured.md

Mode Selection Flow

1. Check: read .adlc/issues-provider.yml in the repo root (CWD; do not walk up). Valid provider: present → Mode 3.
2. Ask: present the choice — detect from remote (show the remote URL) or pick from the four providers. In headless runs (--provider supplied), skip asking and use Mode 2 with the given literal.
3. Confirm: show the exact file content to be written and get explicit confirmation before writing (interactive runs). Headless runs write directly — the --provider flag IS the confirmation.
4. Commit step: copy the release template (skills/factory/factory-mission/references/issues-provider.yml) to .adlc/issues-provider.yml, set the provider: line, report the path, and remind the user to commit it. Never write credentials, never overwrite.

Commit Step (shared by Modes 1–2)

1. Refuse if the target exists (route to Mode 3 instead) — unless the user explicitly confirmed a switch in Mode 2.
2. Copy the template; uncomment and set provider: <literal>.
3. Show the final content; write only on confirmation (interactive) or --provider (headless).
4. Report: path written, provider selected, reminder to commit, and that tracker runs will now resolve without halting.