--- name: ade-pr-workflows description: Use this skill when working with ADE PR workflows including PR tab data, GitHub stacked PRs, checks/comments, rebase resolution, CI fixes, or landing a PR. --- # ADE PR workflows ## Start with typed PR commands ```bash ade prs list --text ade prs show --text ade prs checks --text ade prs comments --text ``` Use `ade help prs` and `ade help git rebase` before guessing PR or rebase flags. ## Get woken when your PR changes — don't poll After you open a PR, have ADE wake you instead of sleeping and re-checking: ```bash ade prs watch # wake me on a failed check, checks passing, new comments, a conflict, merge/close ade prs ship # watch + standing orders to take it to merged; waits for CI and review bots ade prs unwatch # stop ade prs watch-status # what this chat is watching ``` `` is a PR number, URL, or ADE PR id; the watch is for your own chat. Each wake lists exactly what changed; act on it and end your turn — ADE wakes you on the next change. Comments you post through `ade prs` never wake you. ## GitHub stacked PRs A stack is two or more dependency-ordered, independently reviewable PRs. ADE creates and tracks them through built-in commands; users and agents do not need the `gh-stack` extension: ```bash ade prs stacks list --text ade prs stacks sync --text ade prs stacks create --pulls 120,121,122 --text ade prs stacks add --stack 8 --pulls 123 --text ade prs stacks unstack --stack 8 --text ``` Mechanics specific to ADE stacks: 1. Order the layers bottom to top and keep foundations below their consumers. 2. Create one deliberate branch and PR per layer. Each layer can own a child ADE lane (`ade lanes child`) and its own agent, so every layer gets an isolated worktree and ship loop; alternatively one lead keeps the whole branch chain and delegates only non-overlapping work. 3. `ade prs stacks create` expects every PR base to already match the previous PR's head branch — create the stack only after the bases line up. 4. Fix a root-layer failure once, then rebase and repoll every layer above it instead of applying duplicate fixes. 5. Report readiness bottom to top from one stack progress view. GitHub owns stack membership, review requirements, rebases performed on GitHub, merge queue state, and final merging. ADE enforces this: `ade prs land` (the `pr.land` action) refuses any PR that ADE knows is in a GitHub stack, failing with `github_stack_requires_github_merge` and "PR #N is in GitHub Stack #M. Review and merge the stack on GitHub." For an unstacked PR, `land` still merges directly via `gh pr merge`. So send review and merge decisions for a stacked PR to GitHub. ## PR creation closeout links When you create or adopt a GitHub PR, include both the GitHub URL (`githubUrl` / `html_url`) and the ADE PR link in your final handoff. The `adeUrl` printed by `ade prs create` is the ADE link; for a PR adopted through another path, mint it as described in the **ade-deeplinks** skill, which is also where the HTTPS-vs-`ade://` guidance lives. ## Post proof to the PR When the change is visible, put the proof that shows it on the PR. Pick the items yourself, usually the ones your answer already cites: ```bash ade proof publish --pr --heading "Proof" --note "" --text ``` - One command posts one comment. Each picture and video goes up as a GitHub attachment under its caption; ADE hosts nothing and pushes no proof branch. - Each posted item gets a `github_pr` link, and the proof drawer shows a "PR #N" chip on it. - It needs `gh` 2.99.0 or later. An older `gh` is refused with the upgrade command. A number needs a repository with a GitHub remote; otherwise pass the PR's URL. - GitHub limits: 10 MB for a picture; 10 MB for a video on GitHub Free, 100 MB on paid plans. A larger item is skipped and the output says why. - Post only what shows the change. Do not post every capture. ## Use actions for niche surfaces ```bash ade actions list --domain pr --text ade actions run --input-json '{"key":"value"}' ``` ## Freshness For review-thread or CI work, fetch current checks/comments with `ade prs checks` / `ade prs comments` first; the PR tab snapshot can be stale.