メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | deploy-steward |
| license | MIT |
| description | 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. |
| user-invocable | true |
| auto-trigger | false |
| trigger_keywords | ["deploy steward","deploy queue","merge steward","mainline steward","land prs","land PRs","deploy prs","deploy PRs","merge queue","release train"] |
| effort | high |
| last-updated | "2026-06-20T00:00:00.000Z" |
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.
Use this when the user asks to:
Do not use this for code review quality findings; use /review. Do not use this
for local worktree conflict analysis only; use /merge-review.
The steward can start from either source:
.planning/pr-readiness/*.md reports generated by node scripts/pr-ready.js--enqueue-prIf .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:
--allow-no-checks is explicitly justifiedIf 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.
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-queue
Use --dry-run before first live use on a repo:
node scripts/deploy-steward.js --scan --run --dry-run
Run:
node scripts/deploy-steward.js --scan
This 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>
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.
Run:
node scripts/deploy-steward.js --run
For each processable queue item, the steward:
gh pr view.gh pr merge --<method> --match-head-commit <sha> when checks pass.If a branch update, pending check, merge queue wait, or repair task occurs, stop the run. Rerun after the external state advances.
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-queue
In 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.
.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--allow-no-checks only when the repo truly has no CI.--require-fresh-readiness when local readiness reports must remain the
source of truth; otherwise live GitHub checks are authoritative after branch
refreshes..planning/ directory: stop setup and initialize Citadel state before
writing queue or repair files.--enqueue-pr
URLs if the operator wants to seed the queue manually.gh unavailable or unauthenticated: do not run; surface the authentication
problem and keep the queue unchanged.landed and continue to the next
candidate.node scripts/test-deploy-steward.jsnode scripts/skill-lint.js deploy-stewardnode scripts/test-routing-sync.jsnode scripts/test-all.jsReturn 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>
---
Focused research investigations. Converts questions into structured findings with confidence levels and source citations. Single agent by default; with --parallel (or when the question decomposes into 3+ independent angles) it spawns scout agents whose findings are compressed into a unified brief. Does not make decisions; produces information that informs the next step.
Unified router that auto-routes user intent to the right orchestrator or skill. Classifies input by scope, complexity, persistence needs, and parallelism, then dispatches to the cheapest path that can handle it: direct command, skill, marshal, archon, or fleet. Single entry point for all work.
First-run experience for the harness. Three modes: Recommended (guided, ~3 min), Full Tour (guided + skill walkthrough, ~8 min), and Express (zero questions, ~30 sec). Installs hooks first, detects stack, configures harness.json, runs a live demo on real code, and prints a reference card.
Replace with description of the skill and when Claude should use it.
Turn a loose idea into a git-tracked, session-resumable map of typed investigation tickets, then drive them to resolution one at a time. The planning-loop engine for work that is still being figured out — too fuzzy for a campaign, too big for a single intake item. Resolved tickets graduate into .planning/intake/ for the autopilot to build.
Relentless one-question-at-a-time interview that sharpens a vague plan or design into shared understanding before any build. The elicitation engine other planning skills call instead of inventing their own interview. Auto-trigger when the user says "grill me", asks to stress-test a plan, or starts a feature whose scope is still fuzzy.