docs: improve the spec-driven loop (stack maintenance, re-entry, stacked-PR upkeep)#166
Merged
Merged
Conversation
When a PR is added/removed/reordered in a stack, the other PRs' "📚 PR stack" sections (and the spec's Delivery sequence) go stale. Nothing assigned that refresh: the implementer is scoped to one PR and only kept its own section, and the build loop didn't mention the stack at all. - CLAUDE.md: the orchestrator refreshes every other PR's stack section (and the spec) whenever the stack changes. - implementer.md: clarify the implementer maintains only its own PR's stack section. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Clarifies ownership of “📚 PR stack” maintenance across stacked PRs by explicitly assigning cross-stack refresh duties to the orchestrator (in CLAUDE.md) while scoping the implementer agent to only maintain the current PR’s stack section (in .claude/agents/implementer.md).
Changes:
- Add orchestrator responsibility to refresh other PRs’ “📚 PR stack” sections (and the spec’s Delivery / PR sequence) whenever the stack changes.
- Update implementer guidance to maintain only its own PR’s “📚 PR stack” section, deferring cross-PR consistency to the orchestrator.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
CLAUDE.md |
Adds explicit orchestrator instruction to keep stacked-PR metadata consistent across the stack and in the spec’s delivery sequence. |
.claude/agents/implementer.md |
Clarifies implementer scope: maintain stack section only for the PR it is building; orchestrator handles cross-stack updates. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
✅ No security or compliance issues detected. Reviewed everything up to 735d3cd. Security Overview
Detected Code Changes
|
|
Three additions to the spec-driven loop, from gaps that surfaced in practice (an open PR accrued review comments after the loop "stopped", and a maintenance push re-checked CI but not comments): - Step 3: after ANY push (fix, main-merge, rebase) re-run both the CI check and the unresolved-comment check — never one without the other. - Step 4: "ready for review" / STOP is a pause, not the end — new commits or comments on an open PR re-enter the loop at step 3. - Stacked PRs: when a base PR merges, retarget + merge parent + resolve + re-green + refresh the stack section of each dependent. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mbjorkqvist
approved these changes
Jun 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Tighten the spec-driven build loop in
CLAUDE.md(and theimplementeragent) based on gaps that surfaced while running the DEFI-2853 stack.Changes
implementeronly maintains its own PR's section (implementer.mdclarified).main-merge, a rebase) re-run both the CI check and the unresolved-comment check — never one without the other. (A maintenance push that re-triggered CI also re-triggers bot review.)Why
Detection of unresolved comments was already specified in the loop, but the loop terminated at "ready" and a later maintenance push only re-checked CI — so comments that landed afterward went unseen. These edits make re-entry explicit and codify the stacked-PR upkeep we'd been doing ad hoc.