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
- warpdotdev/warp-factories-skillstheir own version, first seen Nov 1, 2026
- xaedalon/factory-communitytheir own version, first seen Oct 8, 2026
- aditya-deokar/software-factorytheir own version, first seen Sep 29, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- warpdotdev/warp-factories-skills★ 8same name
- xaedalon/factory-community★ 2same name
- aditya-deokar/software-factory★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository48 other files it gives its agents.
- architect-analyzeSkill
- architect-bootSkill
- architect-clarifySkill
- architect-implementSkill
- architect-initSkill
- architect-specifySkill
- writing-skillsSkill
- change-bootSkill
- change-clarifySkill
- change-initSkill
- change-publishSkill
- change-specifySkill
- evals-analyzeSkill
- evals-clarifySkill
- evals-implementSkill
- evals-initSkill
- evals-specifySkill
- evals-validateSkill
- factory-cleanSkill
- factory-initSkill
- factory-intentSkill
- factory-learnSkill
- factory-missionSkill
- factory-orchestratorSkill
- factory-queueSkill
- factory-releaseSkill
- factory-reviewSkill
- factory-runbookSkill
- factory-ticketsSkill
- mission-briefSkill
- product-analyzeSkill
- product-bootSkill
- product-clarifySkill
- product-implementSkill
- product-initSkill
- product-roadmapSkill
- product-specifySkill
- team-bootSkill
- team-constitutionSkill
- team-diagnoseSkill
- team-discoverSkill
- team-initSkill
- team-levelupSkill
- team-repairSkill
- team-setupSkill
- team-skillsSkill
- workspaceSkill
- tech-radar-bootSkill
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
- Distinctive: line 41
If the user declines, do not write anything.
- Very specific: line 47
Never force a mode; setup is user-consented at every step.
- Very specific: line 54
Leave the repo with a committed-ready .adlc/issues-provider.yml carrying the correct provider:, or verify the existing wiring.
- Very specific: line 68
Fast path: if .adlc/issues-provider.yml already exists with a valid provider:, skip to Mode 3 (Already Configured) — do not re-detect, …
- Very specific: line 82
Check: read .adlc/issues-provider.yml in the repo root (CWD.
≈ “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.
Files
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, liketeam-setup). - Headless via
adlc-cli factory setup— scripted runs;--providerpre-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-bootsuggested 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 —
--provideris 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.ymlin the repo root (CWD; do not walk up). Validprovider:present → Mode 3. - Ask: present the choice — detect from remote (show the remote URL) or
pick from the four providers. In headless runs (
--providersupplied), 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
--providerflag IS the confirmation. - Commit step: copy the release template
(
skills/factory/factory-runbook/references/issues-provider.yml) to.adlc/issues-provider.yml, set theprovider: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.
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
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.

