Repository navigation
ci(prompt): renumber PROMPT.md to 24 steps and stop blocking on recoverable state - #19
Conversation
Checkpoints 0-10 with 4a/7b/10a-h sub-letters became 24 continuously numbered steps in 6 phases. Phase -1 and phase 0 are gone; every step is small enough to hand to a cheap model with its own inputs and an Acceptance line. Most stop conditions are now recorded findings instead: a dirty tree, a red baseline, a gate red twice, a needed behavioural change and a missing secret or runner all degrade and continue. Three hard stops remain: not a git repo, no push access, and weakening an existing gate. Findings accumulate in two scratch files during the run. Step 23 turns the skeleton half into one PR back here - a code fix where possible, a ci/feedback/<target>-<date>.md where a decision is needed. Step 24 ends by offering a recheck, the commit hook, a diff review and a full code review.
|
Warning Review limit reached
Next review available in: 51 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Walkthrough
ChangesCI adoption workflow
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Three of these were the blocking behaviour the restructure set out to remove, left behind in individual steps after the stop table was rewritten. - step 1 checks viewerPermission, not just gh auth status; a read-only account passed the old check and failed at the first push six steps in - step 4 acceptance requires the baseline to be UNCHANGED rather than green, so a target that was already red at step 3 can complete it - step 13 no longer says to stop when the seam is missing; it records the degradation and continues without building a target over a copy - the write-boundary rule scopes to repositories, so the scratch findings files step 1 creates are not an apparent violation
1 participant
TL;DR
The adoption prompt was numbered as eleven checkpoints (0–10) across six phases
labelled −1 to 4, with sub-lettered items (
4a/4b/4c,7a/7b,10a–10h).A phase numbered −1 and a checkpoint that is three separate jobs behind one number
are both unusable as work units. It is now 24 continuously numbered steps in 6
phases, each step small enough to hand to a cheap model with this file and
nothing else: its own inputs, its own Acceptance line, and where its output goes.
It also stopped blocking. Most of the old stop conditions made an unattended run
end at step 3 with a question instead of finishing 22 of 24 steps and reporting
the two it could not do.
What changed
Renumbering. Phases −1..4 → 1..6; checkpoints 0–10 → steps 1–24. No letters
anywhere. Every cross-reference in the file was rewritten to the new numbers.
Splitting. The checkpoints that carried several independent jobs became
separate steps:
ci/move)git mv· 6 the path-climb fixesBlockers. A new
## Work autonomously — record, do not asksection replacesthe old stop-condition table. Three hard stops remain: not a git repository, no
push access, and a fix that requires weakening an existing gate (rule 2 — that is
the coverage regression the whole job exists to prevent). Everything else records
and continues:
HEAD, nevergit stashthe gate thin
is missing
Findings go somewhere. Two scratch files are created at step 1:
adoption-findings.mdfor the target andskeleton-findings.mdfor this repo.Step 23 turns the second into one PR back here — the actual code fix where one is
possible, a
ci/feedback/<target>-<date>.mdwhere the finding needs a decision orhardware we do not have. An empty file means no PR.
Close-out. Step 24 ends by asking the user which of four follow-ups to run:
recheck the implementation, install and optionally run the commit hook, review the
diff, or a full code review of the module's C. None runs unattended. Report
question 5 changed from "Stopped" to "Parked and degraded", since the run no
longer stops and that is where unfinished work is now accounted for.
Testing
No executable content. Verified mechanically against the rewritten file:
grep -nE 'checkpoint|phase −1|10[a-h]\.|4[abc]\.|7[ab]\.'— no hitsstep Nreference resolves to a heading that existsThe pre-commit hook ran;
actionlintandshellcheckskipped, having no files inscope.