When a PR under review is part of a gh-stack stack, identify the owning
layer for each review comment via git blame + gh stack view --json,
check out that layer, apply the fix, cascade via gh stack rebase, push
via gh stack push, then reply on the original commented PR with a note
when the fix landed on a different layer.
Uses gh stack rebase's documented cascade semantics (pulls from remote,
rebases dependents). Conflicts during rebase halt the workflow with
guidance for manual resolution — V1 does not attempt automated conflict
resolution.
V1 scope: single-comment, single-layer fixes. Multi-layer fixes (one
comment requiring changes in multiple layers) and automated conflict
resolution are deferred to V2.
Non-stack feedback flow is unaffected. Reference file loads only when
gh-stack is installed AND the branch is part of a stack.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds a new step 1 to Phase 4 in both shipping-workflow files: run the
two-stage effectiveness test (stage-1 size/spread hint, stage-2
effectiveness check with anti-patterns), offer to install gh-stack when
missing and the stage-1 hint fires, and branch into either git-commit-
push-pr for single-PR shipping or ce-pr-stack for decomposition.
Both ce-work and ce-work-beta get identical changes — the two skills
share the shipping workflow and must stay in sync. Sync-obligation
comment at the top of the stacking section names all four heuristic
locations (this file, ce-work-beta twin, git-commit-push-pr stack-
aware reference, ce-plan) so future edits propagate atomically.
When stacking is chosen, the workflow loads ce-pr-stack and hands off
the ship step — git-commit-push-pr is not loaded separately, preventing
double invocation. The governing principle carries prior consent across
the skill chain without structured flags.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds four-case routing between push and description steps:
- Case 1: on a stack branch → gh stack push + gh stack submit + per-PR
description via ce-pr-description + gh pr edit per PR
- Case 2: not in stack, change passes two-stage effectiveness test →
suggest stacking, on yes load ce-pr-stack, on return re-enter routing
as Case 1
- Case 3: gh-stack not installed, change passes stage-1 → offer-and-run
install, on success re-enter as Case 2
- Case 4: monolithic default → existing git push + gh pr create, now
with description via ce-pr-description
Monolithic Steps 6-7 stay untouched; they are the single source of truth
for monolithic description generation. Case 1 explicitly exits before
them; Case 4 explicitly hands back to them.
Effectiveness test prose carries a sync-obligation comment listing all
four locations (this file, ce-work shipping, ce-work-beta shipping,
ce-plan). Changes to the heuristic update all four atomically.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
New skill owns the value-first description writing logic that was
previously inline in git-commit-push-pr. Input contract is two-shape:
pr:<number> for existing PRs (used by refresh mode), or range:<base>..<head>
for pre-PR generation (used by new PR creation and by ce-pr-stack per
layer). Output is structured {title, body}; caller decides whether to
apply via gh pr edit.
No interactive prompts, no auto-apply, no branch coupling. The skill
is a pure capability — git-commit-push-pr wraps it with confirmation
prompts and evidence-capture for single-PR interactive flows;
ce-pr-stack (via git-commit-push-pr's stack-aware routing, coming next)
will call it per layer without the interactive scaffolding.
Refactor preserves git-commit-push-pr's user-facing behavior:
- Full flow: commit + push + create PR, description generated via
ce-pr-description with range:<base>..<head> and passed to gh pr create
in a single call (no transient placeholder on GitHub)
- Refresh mode (DU-1/DU-2/DU-3): interactive scaffolding stays; DU-3
delegates description generation to ce-pr-description with pr:<number>,
then presents the compare-and-confirm as before
Naming: ce-pr-description, not git-pr-description. PR is a GitHub
artifact; the ce- prefix matches the future convention for plugin
skills. git-commit-push-pr will rename later.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Renames the skill directory to match the plan's architectural reshape.
Stacking is a GitHub feature (gh-stack extension, GitHub's stack UI),
not a git feature, and the ce- prefix matches the future convention
for plugin skills.
Narrows scope to decomposition only:
- Removes manage-mode operations. Push and submit are owned by
git-commit-push-pr now that it is stack-aware. Rebase, sync, view,
and navigation commands are one-line pass-throughs to gh stack with
no skill-scale value — invoked directly when needed.
- Removes the three-flavor invocation enumeration (manual / delegated
/ auto-invoked). Consent routing relies on the governing principle
that respects prior user decisions within the session, rather than
structured caller-side flags.
- Drops the delegated / stacking_declined / gh_stack_install_declined
signal plumbing from the SKILL.md. Agent context awareness is the
primary mechanism; the principle is documented at the bottom.
Narrows the CLI surface section: init, add, view, unstack --local for
rollback. Ship commands (push, submit) moved to git-commit-push-pr.
Rewrites splitting-workflow reference file: four phases collapsed to
three. Removes the submit phase entirely; phase 3 ends with a handoff
to git-commit-push-pr, which then runs gh stack push + gh stack
submit + per-PR description generation via ce-pr-description. Separating
decomposition from shipping bounds failure blast radius to local state.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Four-phase workflow for decomposing a feature branch into stacked PRs:
analyze (commit-based grouping as V1 strategy), propose layers with
mandatory user approval, create the stack locally using gh stack init
and gh stack add, submit via gh stack push plus gh stack submit. The
rollback protocol separates local construction from remote submission
so failures stay local. Workflow content verified against the installed
gh-stack CLI via --help on each command referenced.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Handles two operational modes (split to decompose a branch into stacked
PRs, manage to drive an existing stack via gh stack commands) with three
invocation flavors (manual, delegated, auto-invoked). Auto-invocation
runs an effectiveness-test gate before proposing a split; manual and
delegated entries go straight to layer proposal, which remains the
second gate for all modes. Availability gate offers to install gh-stack
and runs the command on consent, honoring the session-level governing
principle that respects prior user decisions.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Emits parseable signals about gh-stack availability, current branch's
stack-membership state, and change summary vs a base branch. Supports
--mock and STACK_DETECT_MOCK for testing without a real stack. Reports
signals only — no "should stack" judgments, which belong in consuming
skills per the plan's governing principle.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Detection uses gh extension list because gh-stack is a gh CLI extension,
not a standalone binary. The check-health loop now handles gh-* entries
specially and skips them gracefully when gh itself is missing, avoiding
confusing "install gh extension" messaging in that case.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Trevin Chow
Harold Hunt
David Joerg
github-actions[bot]