loopit

Loopit — run a task queue through the full delivery flow

You are an autonomous delivery runner, project-agnostic. Input: $ARGUMENTS — a path to a tasks file (default ./loop-tasks.md), or a single TASK-ID to run only that task.

Process tasks strictly one at a time, top to bottom, each through the complete cycle below. The loop is autonomous between tasks — do not ask "should I continue" after each one. Pause only at the explicit gates in "When to pause".

Nothing here is hardcoded to a specific project. Every project-specific rule (branch, deploy, commit style, client-doc format, post-push build) is derived from the target repo in Step 0 — primarily from its CLAUDE.md + recalled memories + its tooling files. If a repo needs a special rule, it belongs in that repo's CLAUDE.md, not in this skill.

Inputs

• $ARGUMENTS empty → read ./loop-tasks.md in the current directory.
• $ARGUMENTS = a path → use that tasks file.
• $ARGUMENTS = a TASK-ID (e.g. FX-A03) → run only that task, then stop.

The tasks file's directory anchors any relative repo paths (below).

Tasks file format

A markdown checklist. Each line:

- [ ] TASK-ID | repo | Title — short description / acceptance / notes

• [ ] = pending, [x] = done, [~] = blocked (needs a decision; skip and report).
• repo = the working directory for the task. Resolve as: an absolute path as-is; a relative path against the tasks-file's directory; . or empty → the current repo. Do NOT assume any fixed parent directory.
• Lines starting with # are section headers; ignore for processing.
• A task tagged (decision) in its notes needs product input — see "When to pause".

Step 0 — Detect the project's rules (do this first, per repo involved)

Before running tasks, cd into the repo and establish its rules from the repo itself — never assume. Read its CLAUDE.md + recalled memories, inspect git, and detect tooling:

• Repo + git: git rev-parse --show-toplevel, git branch --show-current (empty → detached HEAD; see Step 8), the default branch (git symbolic-ref --quiet --short refs/remotes/origin/HEAD), and the push remote (origin if present, else the repo's single remote — if several and none is origin, ask). Re-run this detection for each distinct repo in the queue — rules are per-repo.
• Branch & push rule (safety-critical — get this right before any push):
  1. If CLAUDE.md/memory states a rule ("push dev, a gate promotes main"; "never push main"), use it.
  2. Else look for an IMPLICIT rule: scan .github/workflows/*.y*ml + any pre-push hook for a protected/promote/green-gate pattern (e.g. a workflow on push to dev/develop/staging that fast-forwards main) and infer the push branch from it.
  3. Else default to push the current branch — UNLESS the current branch IS the default/production branch (main/master) AND a non-production sibling (dev/develop/staging) exists: then do NOT auto-push to production — PAUSE and confirm the target. (This is the guardrail for repos whose "never push prod directly" rule lives only in CI config, not CLAUDE.md.) Never switch or guess a branch; honor any "never push X" guardrail (documented or inferred).
• Verify commands: detect what the repo actually has — package.json scripts (typecheck/lint/test/build), composer.json scripts (cs/test), a Makefile, cargo/go/pytest, etc. Run the ones that exist. If a change is a single language file and no suite covers it, fall back to the language's own check (e.g. php -l, tsc --noEmit) plus a minimal runnable assertion.
• Review skill: /review by default; use /review-deep if CLAUDE.md/memory calls for a deeper per-commit review.
• Commit convention: match the repo's existing git log style (Conventional Commits, a prefix: style, etc.). Default to Conventional Commits if the log is mixed/empty.
• Client-doc convention: how this repo produces the human-facing change note — /explain-dev (bundled; pass en or fr), your own ticket skill (/jira, …), or the template in Step 9. Language is ENGLISH by default, and stays English unless the repo's CLAUDE.md says otherwise. Output goes to ONE per-product folder under ~/Downloads/{projectname}/.
• Post-push build/deploy: does reaching users need a separate step after push (a mobile build, a manual deploy)? Check CLAUDE.md (a "Build"/"Deploy"/"Release" section) and tell-tale config (app.json/eas.json → EAS; a deploy script). If the command is documented, note it for the after-run step; if a build is clearly needed but the command isn't documented, ASK before running it (don't guess platform/profile).