Context
Identified during review of PR #108. The pr-pre-merge command's Step 4 (Run pre-merge checklist) runs four sub-steps (4a: documentation, 4b: version bump, 4c: CHANGELOG, 4d: tests) but has no resilience pattern for sub-step failures.
Problem
If a sub-step encounters a hard error (e.g., test runner crashes, file write fails), there is no instruction for how to handle partial completion. Compare with pr-review.md Step 7, which has an explicit "If any operation fails or is interrupted, proceed to Step 8 anyway" instruction.
Suggested Approach
Add a resilience pattern to Step 4: if a sub-step fails, note the failure for the report and continue with remaining sub-steps. Mark Step 4 based on whether any failures occurred (leave as in_progress if any sub-step had a hard error; mark completed only if all sub-steps completed).
Notes
- This is a nice-to-have improvement, not a blocking issue
- The current behavior (Claude uses natural judgment to handle errors) is adequate for most cases
- Priority should be low unless experience shows Step 4 failures are common
Context
Identified during review of PR #108. The
pr-pre-mergecommand's Step 4 (Run pre-merge checklist) runs four sub-steps (4a: documentation, 4b: version bump, 4c: CHANGELOG, 4d: tests) but has no resilience pattern for sub-step failures.Problem
If a sub-step encounters a hard error (e.g., test runner crashes, file write fails), there is no instruction for how to handle partial completion. Compare with
pr-review.mdStep 7, which has an explicit "If any operation fails or is interrupted, proceed to Step 8 anyway" instruction.Suggested Approach
Add a resilience pattern to Step 4: if a sub-step fails, note the failure for the report and continue with remaining sub-steps. Mark Step 4 based on whether any failures occurred (leave as
in_progressif any sub-step had a hard error; markcompletedonly if all sub-steps completed).Notes