deploy-steward
Skill927 starsChanged 16 days agoMITView on GitHub
Mainline deploy steward. Consumes ready PRs, owns a lease on mainline landing, refreshes PR state, updates stale branches, waits for CI and deploy gates, merges or queues one candidate at a time, and opens repair tasks for failures.
We split this skill into the rules it gives an agent
24 rules. About 0 are common, 15 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈15
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 33
Use this when the user asks to:
- Distinctive: line 36
keep agent PRs rebased or branch-updated against latest main
- Distinctive: line 38
run a deploy command after each safe serial merge
- Very specific: line 41
Do not use this for code review quality findings.
- Very specific: line 51
If .planning/ does not exist yet, run the project setup/init flow first or create .planning/pr-readiness/ before scanning.
- Very specific: line 61
If gh is not installed or is not authenticated, stop before --run and ask the operator to run gh auth status / gh auth login.
- Very specific: line 75
Use --dry-run before first live use on a repo:
- Very specific: line 106
Use --force-lease only after confirming the old holder is dead.
- Distinctive: line 126
If a branch update, pending check, merge queue wait, or repair task occurs, stop the run.
- Distinctive: line 137
If the repo uses GitHub merge queue, prefer:
- Distinctive: line 156
Never let multiple steward runs merge into the same target at once.
- Distinctive: line 157
Never merge without a current PR refresh.
- Distinctive: line 158
Never merge a PR with failing or pending checks.
- Distinctive: line 159
Never merge a conflicted PR.
- Distinctive: line 160
Never force-push a contributor branch from the steward.
- Very specific: line 161
Use --allow-no-checks only when the repo truly has no CI.
- Very specific: line 162
Use --require-fresh-readiness when local readiness reports must remain the source of truth.
- Very specific: line 168
No
.planning/directory: stop setup and initialize Citadel state before writing queue or repair files. - Very specific: line 172
ghunavailable or unauthenticated: do not run; surface the authentication problem and keep the queue unchanged. - Distinctive: line 176
PR closed without merge: create a repair intake task and stop.
- Distinctive: line 177
Branch is behind base: update the PR branch, mark it waiting for checks, and stop until CI reruns.
- Distinctive: line 179
Checks fail: create a repair intake task and stop.
- Distinctive: line 180
Checks pending: keep the item queued and stop until the external state advances.
- Distinctive: line 182
Merge conflict or dirty merge state: create repair work; never merge or force-push from the steward.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
/deploy-steward - Mainline Deploy Steward
You are the deploy steward. You serialize mainline landing for parallel agent work. Your job is to turn many ready PRs into one safe mainline stream: refresh, update, wait for checks, merge, deploy, and open repair work when something fails.
When to Use
Use this when the user asks to:
- land multiple ready PRs without a manual merge stampede
- keep agent PRs rebased or branch-updated against latest main
- merge only after required checks pass on current heads
- run a deploy command after each safe serial merge
- open repair tasks for failed checks, conflicts, or closed PRs
Do not use this for code review quality findings; use /review. Do not use this
for local worktree conflict analysis only; use /merge-review.
Required Inputs
The steward can start from either source:
.planning/pr-readiness/*.mdreports generated bynode scripts/pr-ready.js- explicit GitHub PR URLs passed with
--enqueue-pr
If .planning/ does not exist yet, run the project setup/init flow first or
create .planning/pr-readiness/ before scanning. Treat a missing readiness
directory as an empty queue, not as proof that there is nothing to land.
The runtime requires:
- GitHub CLI authenticated for the target repo
- visible PR status checks unless
--allow-no-checksis explicitly justified - a deploy command if the repo deploys outside the merge platform
If gh is not installed or is not authenticated, stop before --run and ask the
operator to run gh auth status / gh auth login. Do not substitute raw tokens
or ad hoc curl commands inside the steward.
Invocation Forms
node scripts/deploy-steward.js --scan
node scripts/deploy-steward.js --scan --run
node scripts/deploy-steward.js --run --deploy-command "npm run deploy"
node scripts/deploy-steward.js --enqueue-pr https://github.com/OWNER/REPO/pull/123 --run
node scripts/deploy-steward.js --run --merge-mode merge-queueUse --dry-run before first live use on a repo:
node scripts/deploy-steward.js --scan --run --dry-runProtocol
Phase 1 - Build the Queue
Run:
node scripts/deploy-steward.js --scanThis reads .planning/pr-readiness, writes .planning/deploy-steward/queue.jsonl,
and records each candidate as ready, blocked, or already terminal.
For ad hoc PRs:
node scripts/deploy-steward.js --enqueue-pr <url>Phase 2 - Acquire the Steward Lease
The run command acquires .planning/deploy-steward/lease.lock and mirrors the
lease to .planning/deploy-steward/lease.json. If another steward has an active
lease, stop instead of racing main.
Use --force-lease only after confirming the old holder is dead.
Phase 3 - Process One Mainline Candidate at a Time
Run:
node scripts/deploy-steward.js --runFor each processable queue item, the steward:
- Refreshes live PR state with
gh pr view. - Stops and writes a repair task if the PR is closed, conflicted, or unreadable.
- Updates the branch against its base when GitHub reports it is behind.
- Waits when checks are pending.
- Opens a repair task when checks fail.
- Merges with
gh pr merge --<method> --match-head-commit <sha>when checks pass. - Runs the optional deploy command after a successful serial merge.
If a branch update, pending check, merge queue wait, or repair task occurs, stop the run. Rerun after the external state advances.
Phase 4 - Deploy
For serial landing, pass the project deploy command:
node scripts/deploy-steward.js --run --deploy-command "npm run deploy"If the repo uses GitHub merge queue, prefer:
node scripts/deploy-steward.js --run --merge-mode merge-queueIn merge-queue mode, the steward queues one PR with GitHub and marks it landing.
Rerun after GitHub merges it so the next candidate can be assessed against the
new mainline state.
State Files
.planning/deploy-steward/queue.jsonl- durable landing queue.planning/deploy-steward/lease.json- active steward lease mirror.planning/deploy-steward/runs/latest.md- latest steward report.planning/intake/*deploy-steward*.md- generated repair tasks
Safety Rules
- Never let multiple steward runs merge into the same target at once.
- Never merge without a current PR refresh.
- Never merge a PR with failing or pending checks.
- Never merge a conflicted PR; create repair work instead.
- Never force-push a contributor branch from the steward.
- Use
--allow-no-checksonly when the repo truly has no CI. - Use
--require-fresh-readinesswhen local readiness reports must remain the source of truth; otherwise live GitHub checks are authoritative after branch refreshes.
Fringe Cases
- No
.planning/directory: stop setup and initialize Citadel state before writing queue or repair files. - No readiness reports: report an empty queue; accept explicit
--enqueue-prURLs if the operator wants to seed the queue manually. ghunavailable or unauthenticated: do not run; surface the authentication problem and keep the queue unchanged.- PR already merged: mark the queue item
landedand continue to the next candidate. - PR closed without merge: create a repair intake task and stop.
- Branch is behind base: update the PR branch, mark it waiting for checks, and stop until CI reruns.
- Checks fail: create a repair intake task and stop.
- Checks pending: keep the item queued and stop until the external state advances.
- Merge conflict or dirty merge state: create repair work; never merge or force-push from the steward.
Quality Gates
node scripts/test-deploy-steward.jsnode scripts/skill-lint.js deploy-stewardnode scripts/test-routing-sync.jsnode scripts/test-all.js
Exit Protocol
Return the steward report and a handoff:
---HANDOFF---
- Queue: <N> candidates in .planning/deploy-steward/queue.jsonl
- Last action: merged | updated-branch | waiting-for-checks | repair-needed | idle
- Report: .planning/deploy-steward/runs/latest.md
- Repair task: <path or none>
---Other versions1 project uses a version of this.
Word for word · 1
- mayankjain1815-commits/CITADEL★ 4100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architectSkill
- archonSkill
- ascii-diagramSkill
- autopilotSkill
- costSkill
- create-appSkill
- create-skillSkill
- daemonSkill
- dashboardSkill
- decision-mapSkill
- designSkill
- doc-genSkill
- doSkill
- evolveSkill
- experimentSkill
- fleetSkill
- grillSkill
- housecleanSkill
- improveSkill
- infra-auditSkill
- learnSkill
- live-previewSkill
- loopSkill
- mapSkill
- marshalSkill
- merge-reviewSkill
- organizeSkill
- postmortemSkill
- prdSkill
- pr-watchSkill
- qaSkill
- refactorSkill
- researchSkill
- reviewSkill
- scaffoldSkill
- scheduleSkill
- session-handoffSkill
- setupSkill
- systematic-debuggingSkill
- telemetrySkill
- test-genSkill
- triageSkill
- unharnessSkill
- verifySkill
- watchSkill
- wikiSkill
- workspaceSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

