360 Secure SkillHub
360 安全技能中心

factory-setup

面向仓库的交互式设置技能：询问用户或从 git remote 推断 GitHub、GitLab、Linear、Jira 之一，按模板生成 .adlc/issues-provider.yml，已有配置时转为校验；不写入凭据，切换需显式确认，支持以 --provider 无头运行。

分类：自动化
tikalk
热度 0.00
最近更新 2026-11-06 00:25:20

安装

发给 Agent
帮我安装这个技能：npx secure-skills-cli add tikalk/adlc-team-skills/factory-setup
兼容性
通用兼容
联网要求
需要联网
数据出网
可选出网
Metadata
name
factory-setup
description
Use when configuring the factory tracker provider for a repo (first factory run, missing .adlc/issues-provider.yml), verifying provider wiring, or switching trackers.

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

  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.