Repository navigation
Add maintainer loop (orchestrator + triage skills) - #1
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dfb3a91bf9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ```bash | ||
| # Copy the skills + this runbook into every ITSEZMONEY repo and open a PR each. | ||
| scripts/fanout-maintainer-skills.sh # all org repos (needs gh + perms) |
There was a problem hiding this comment.
Remove or add the missing fan-out script
This runbook tells maintainers to execute scripts/fanout-maintainer-skills.sh, but the commit does not add that script and a repo-wide search only finds this reference. Anyone following the documented “Fan out to all repos” path will hit a missing-file error instead of opening the promised PRs, so either include the script or remove/replace these commands.
Useful? React with 👍 / 👎.
| | --- | --- | --- | | ||
| | Steady backlog sweeps | **Scheduled** trigger | Hourly is the floor; daily/weeknightly is usually plenty and cheaper. | | ||
| | Real-time on PRs/releases | **GitHub event** trigger | Fires on `pull_request.*` / `release.*` — the closest thing to "instant". Subject to per-account hourly caps. | | ||
| | Literal 5-minute polling | **API** trigger + external pinger | Your own cron/codex driver POSTs to the routine's `/fire` endpoint every 5 min. This is where a 5-min cadence actually lives. | |
There was a problem hiding this comment.
Prevent overlapping 5-minute routine runs
When the external pinger fires every 5 minutes and a maintenance pass runs longer than that, the next API trigger starts another autonomous session against the same repos. The orchestrator later acknowledges that overlapping triggers create duplicate ledgers, but this setup path does not tell the pinger to skip while a prior run is active, so two writers can triage, comment, open PRs, or merge from the same queue concurrently; add a lock/in-flight check or avoid recommending fixed 5-minute polling without one.
Useful? React with 👍 / 👎.
| (see *Autonomy policy* below). Stop touching an item the moment it stops | ||
| meeting the bar and reclassify it as needs-owner. | ||
| 5. **Escalate needs-owner items.** Don't guess at product/direction/secret | ||
| decisions. Label `needs-owner`, leave a one-paragraph comment stating the |
There was a problem hiding this comment.
Create the needs-owner label before applying it
In any repo that has not pre-created needs-owner (it is not a GitHub default label), this escalation step will fail or leave the item unlabelled, so owner-blocked work will not show up in the label queue even though the ledger says it was escalated. The same skill already ensures maintainer-ledger exists before applying it; do the same for needs-owner before labeling items.
Useful? React with 👍 / 👎.
dfb3a91 to
70eb98c
Compare
70eb98c to
138488c
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 138488c930
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## Item card | ||
|
|
||
| For every open issue/PR, produce: |
There was a problem hiding this comment.
Exclude the ledger from triage
On second and later runs, the required 🤖 Maintainer Loop — Ledger is itself an open issue, so building cards for every open issue/PR pulls the ledger into the backlog. Since the orchestrator then acts on triage buckets, it can label, comment on, defer, or even close the durable state issue as if it were normal work; add an explicit skip for the maintainer-ledger label or exact ledger title before creating item cards.
Useful? React with 👍 / 👎.
| Trust here is an **explicit allowlist for auto-merge**, not a vibe: only | ||
| `adityash8` is trusted. Untrusted authorship doesn't mean a bad patch — it means | ||
| the item cannot auto-merge and routes to **needs-owner** (draft PR), even with | ||
| green CI. The sole exception is a **bot dependency bump**, which may auto-merge |
There was a problem hiding this comment.
Don't route issue reporters through PR trust
For open issues rather than PRs, this treats the reporter's GitHub account as the patch author and sends any issue opened by someone other than adityash8 to needs-owner. In practice a low-risk docs typo or clear bug report from an external user would never be fixed autonomously even though the actual PR would be authored by the loop and still pass the normal CI/risk gates; limit this trust gate to existing PRs or submitted patches, not issue reporters.
Useful? React with 👍 / 👎.
| open ledger, close the rest as duplicates (`state_reason: duplicate` with | ||
| `duplicate_of` set to the survivor), and continue on the survivor. If none exists, create it, ensure the |
There was a problem hiding this comment.
Mark duplicate ledgers through a supported path
When duplicate ledgers exist and the run follows this REST path, duplicate_of is not a documented body parameter for GitHub's Update issue endpoint (the current docs only list state_reason for the close reason), so the request can fail or close without linking the survivor. Use the documented Duplicate of #... comment/connector operation before closing so the duplicate relationship actually sticks.
Useful? React with 👍 / 👎.
| - Author is **trusted** per the allowlist below (or the change was authored by | ||
| this loop, which runs as `adityash8`) — **or** it is a bot dependency bump that | ||
| independently meets every other gate in this list. | ||
| - No unresolved review thread requests changes. |
There was a problem hiding this comment.
Honor blocking requested-change reviews
When a trusted or loop-authored low-risk PR has a submitted CHANGES_REQUESTED review whose inline comments were resolved/outdated, or a summary-only requested-changes review, this gate only checks unresolved threads and can still merge over the reviewer block unless branch protection happens to enforce reviews. Add an explicit check of the latest review states/requested-changes status before auto-merging.
Useful? React with 👍 / 👎.
| - Only broaden to multiple repos / the whole `ITSEZMONEY` org when the prompt | ||
| explicitly says `all`, `broad`, `org-wide`, or `everything`. |
There was a problem hiding this comment.
Recognize the documented multi-repo prompt
The documented kickoff prompt says to run over “every repository cloned,” but this scope gate only broadens on the exact tokens all, broad, org-wide, or everything. In a routine with several selected repos and that prompt, the triage subskill can stay on the current repo and leave the other cloned repos untouched while the orchestrator reports a sweep; include the documented wording here or invoke triage separately per repo.
Useful? React with 👍 / 👎.
Adds the maintainer-loop tooling copied from gate-slip:
.claude/skills/maintainer-orchestrator/.claude/skills/github-project-triage/docs/MAINTAINER_LOOP.mdGenerated by Claude Code