GitHub Fleet Maintenance

For one new repository, read the repository completion contract first. "Make a repo" includes a usable project, tested CI, applicable security coverage, documentation, and a concrete release handoff. Do not stop at gh repo create or a push. When the user says push/code/release/readme, finish that contract from current source: rebuild the real binary or release archive; do not ship a stale exe or leftover dist zip from an older SHA. Respect an explicitly requested empty repository or prototype.

Use the fleet loop only when multiple repositories are in scope. Reuse authenticated gh or the GitHub MCP; determine permissions from actual responses, never request or print credentials.

Core loop (per fleet pass)

1. Inventory — gh api --paginate "user/repos?per_page=100&type=owner" → dump RAW JSON to a file, flatten page arrays in Python. Never trust --paginate --jq merging (it doesn't merge pages).
2. Parallel audit — one Python script, concurrent.futures.ThreadPoolExecutor(max_workers=10), checking per repo: workflows present + last run conclusion, description, topics count, license, releases vs tags, .github/dependabot.yml, open dependabot/code-scanning/secret-scanning alerts. Print only gaps.
3. Fix gaps — batch edits through the API (see below); ask the user 3–4 decision questions FIRST when defaults are ambiguous (forks included? which license? branch protection?). Record answers; they apply fleet-wide.
4. Verify per repo — every new workflow must produce a terminal-green run on the default branch before declaring done. Pending is not success. CodeQL and security alerts can open after CI goes green. Re-query them and fix the cause of any alert this pass opened before declaring the repo done.
5. Report honestly — per-repo table: green / intentionally-CI-less (say why) / known limitation (e.g. continue-on-error job with root cause).

Editing repos WITHOUT cloning (preferred for small batches)

Use the git data API as ONE atomic commit per repo (no clone, no pull race):