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

Check: read
```
.adlc/issues-provider.yml
```
in the repo root (CWD; do not walk up). Valid
```
provider:
```
present → Mode 3.
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.
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.
Commit step: copy the release template (
```
skills/factory/factory-runbook/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.

Requires: the

factory-runbook

skill (provides

references/issues-provider.yml

adlc-cli skills add tikalk/adlc-team-skills --skill factory-runbook

Commit Step (shared by Modes 1–2)

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

factory-setup

NPX Install

Tags

SKILL.md Content

factory-setup

Overview

When to Use

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

Core Process

Goal

Security: Input Validation

Modes at a Glance

Mode Selection Flow

Commit Step (shared by Modes 1–2)