agentleFS
tikalktikalk/adlc-team-skills/skills/factory/factory-setup/SKILL.md

factory-setup

Skill145 starsChanged 19 days agoMITView on GitHub

Use when configuring the factory tracker provider for a repo (first factory run, missing .adlc/issues-provider.yml), verifying provider wiring, or switching trackers.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the user declines, do not write anything.

    line 41
  2. Very specific:

    Never force a mode; setup is user-consented at every step.

    line 47
  3. Very specific:

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

    line 54
  4. Very specific:

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

    line 68
  5. Very specific:

    Check: read .adlc/issues-provider.yml in the repo root (CWD.

    line 82

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

#ModeWhenDetails in
1Detect from git remotequick heuristic wanted (always confirmed)references/mode-detect.md
2Pick explicitlyheuristic wrong, non-git remote, or --provider givenreferences/mode-pick.md
3Already configuredfile exists — verify wiringreferences/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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.