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

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

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
  1. Distinctive:

    Run the lifecycle steps. After each step that changed files:

    line 46
  2. Distinctive:

    Only an orchestrator-invoked runbook commits, pushes and opens the MR, and only through these helpers.

    line 74

≈ “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-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 the Requires line. scripts/ and references/ 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:

  1. 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.
  2. 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.)

  1. Start: bash scripts/bash/run-branch.sh [--kind <intent|code>] — on Windows, the PowerShell twin (every helper has one under scripts/powershell/). Checks out the run branch (factory/intent/<repo>-<iid> from ADLC_ISSUE_REF for intent runs — the default; factory/mission/<repo>-<iid> with --kind code for mission code runs) in the project root, reusing it or continuing from origin. Shared by both intent lanes and with re-dispatches. Without ADLC_RUN_ID this is a no-op.
  2. 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; prints sha: <sha> or sha: none for the step's bus marker.
  3. 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, per tracker-integration.md Operation 11; the deterministic resolver scripts/bash/resolve-mr-ownership.sh itself runs at caller/completion, not inside open-mr.sh), and the agent-authored stamp likewise lives at completion (mission Phase 6, orchestrator §7 hygiene — not in this helper). It writes mr_url to ADLC_STEP_OUTPUT. Pass --kind code for 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-line conclusion into the same JSON object, preserving existing keys.
  4. 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/)

FileBorrowed by
executor.mdevery Kind-A orchestrator (step schema, run state, lanes, gates, converge)
tracker-integration.mdtracker-integrated skills (comment bus, labels, lease, provider ops, MR ownership)
lanes.mdlane-based dispatch consumers
mission-brief-template.mdbrief/milestone authors (queue, orchestrator) — canonical home mission-brief/references/
issues-provider.ymlprovider resolution template (setup writes the repo copy)
run-context.mdrun-mode vs local-session rules
mission-template.ymlrun policy defaults (execution, supervision, budgets)

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.