factory-runbook
Skill145 starsChanged 21 days agoMITView on GitHub
Use when a factory run must post its changes — check out the run branch, commit a step's allowlisted paths, push only that branch, and open or reuse one draft MR/PR with milestone/assignee ownership. Also the shared home for factory run contracts (executor, tracker integration, lanes, brief and provider templates).
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-setupSkill
- 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
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 46
Run the lifecycle steps. After each step that changed files:
- Distinctive: line 74
Only an orchestrator-invoked runbook commits, pushes and opens the MR, and only through these helpers.
≈ “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-runbook
Scope rule: scripts stay skill-local — never source a script from another skill. For another skill's operations, invoke that skill (e.g.
architect-clarify,product-clarify,team-boot) via the Skill tool; for its documents, follow theRequiresline.scripts/andreferences/below are relative to this skill.{REPO_ROOT}denotes the project root (where.adlc/lives).
What this skill does
factory-runbook is the shared run mechanics of the software factory. It has
two halves:
- Publish procedure (below) — the deterministic branch → commit → push → draft-MR/PR sequence every factory run ends with. Factory orchestrators invoke this skill for their publish step; it is also directly usable to post a run's changes.
- Run contracts (
references/) — the executor loop, tracker integration, lanes, brief/provider templates, and run-context rules that factory skills borrow by path instead of copying.
It never approves or merges. The engine's gate after the step is the approval.
Direct-invocation guard: publishing needs a run context — ADLC_RUN_ID
(and usually ADLC_ISSUE_REF plus ADLC_STEP_OUTPUT) from a factory run, or
explicit orchestrator-provided args (orchestrator name, step id, output type,
paths). Never invent a branch name, a step, or paths to commit. Without a run
context and without them, state what is missing and stop.
Publish procedure — read this first
Requires: nothing — this skill is self-contained. (Borrowers declare the
reverse: adlc-cli skills add tikalk/adlc-team-skills --skill factory-runbook.)
- Start:
bash scripts/bash/run-branch.sh [--kind <intent|code>]— on Windows, the PowerShell twin (every helper has one underscripts/powershell/). Checks out the run branch (factory/intent/<repo>-<iid>fromADLC_ISSUE_REFfor intent runs — the default;factory/mission/<repo>-<iid>with--kind codefor mission code runs) in the project root, reusing it or continuing fromorigin. Shared by both intent lanes and with re-dispatches. WithoutADLC_RUN_IDthis is a no-op. - Run the lifecycle steps. After each step that changed files:
bash scripts/bash/commit-step.sh --orchestrator <name> --step <id> --output-type <draft|decision|artifact-ref|findings> --summary "<one line, no issue text>" --records <IDs> -- <paths the step wrote, moved or deleted>. Stages ONLY allowlisted paths; printssha: <sha>orsha: nonefor the step's bus marker. - Before returning, always:
bash scripts/bash/open-mr.sh [--kind <intent|code>]— pushes the run branch only, finds or opens one draft MR (merge commit, no squash; Issue milestone applied inline, Issue assignees else the runner's own account, pertracker-integration.mdOperation 11; the deterministic resolverscripts/bash/resolve-mr-ownership.shitself runs at caller/completion, not insideopen-mr.sh), and theagent-authoredstamp likewise lives at completion (mission Phase 6, orchestrator §7 hygiene — not in this helper). It writesmr_urltoADLC_STEP_OUTPUT. Pass--kind codefor code missions (factory/mission/*branch). Call it whatever the outcome — an empty run opens nothing and the gate shows no link. Also write a one-lineconclusioninto the same JSON object, preserving existing keys. - Never ask for approval or wait for an answer here. A helper's non-zero exit (refused path, missing committer identity, tracker scope) stops the run — report it, do not work around it.
Outside a factory run the helpers do nothing unless the user opted in
(adlc.commit_steps: true in .adlc/init-options.json, or --commit
forwarded to commit-step.sh); run-branch.sh and open-mr.sh never act
without ADLC_RUN_ID.
Only an orchestrator-invoked runbook commits, pushes and opens the MR, and only through these helpers; lifecycle skills never do.
Run contracts (references/)
| File | Borrowed by |
executor.md | every Kind-A orchestrator (step schema, run state, lanes, gates, converge) |
tracker-integration.md | tracker-integrated skills (comment bus, labels, lease, provider ops, MR ownership) |
lanes.md | lane-based dispatch consumers |
mission-brief-template.md | brief/milestone authors (queue, orchestrator) — canonical home mission-brief/references/ |
issues-provider.yml | provider resolution template (setup writes the repo copy) |
run-context.md | run-mode vs local-session rules |
mission-template.yml | run policy defaults (execution, supervision, budgets) |
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.

