feat(prm): make /prm the full task close-out, not just the merge - #255
Merged
Conversation
/prm was stopping at the merge and handing back to the ship skills. It is now the last thing a human types for a task: merge, then close the task out end to end — Shipped comment, issue closed, PyAutoMind prompt moved active/ → complete/ (claim released, Mind pushed), worktree removed, merged branches deleted, and a ledger of what ran and what was skipped. Typing /prm authorizes all of it, so the run no longer stops to ask again. The close-out order is forced by the tooling and documented as such: prove every branch merged -> issue -> Mind record -> worktree_remove -> branches. worktree_remove refuses while active.md still claims the task, which is exactly why the Mind step precedes it. Guards that stop the run instead of pressing on: - an unmerged sibling branch with no open PR (the shipped-in-waves trap — a complete/ record is a write-up, not a merge receipt) - a worktree_remove refusal (dirty repo, stale claim); never PYAUTO_WT_FORCE=1 - a worktree holding gitignored data products — the one question /prm asks, and only when such files exist (2026-07-09: a reduced dataset + archive cache were destroyed by exactly this cleanup) reference.md gains the mechanics: per-branch merge proof, `gh api -X PATCH` for the close (gh issue close is broken in 2.4.0), lifecycle.py record with the BARE --prompt filename plus the three effects to verify, worktree_root_path and the data-product check, and remote branch deletion proven with ls-remote. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01UrgmL8WMK82GxQJjPL8ZCs
…wake_up) # Conflicts: # AGENTS.md
…t from #253) `install.sh --check-project-discovery` flagged skills/board as present with no committed discovery links, so /board would not register in web/cloud sessions where the user-level symlinks do not travel. Regenerated. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01UrgmL8WMK82GxQJjPL8ZCs
GitHub cannot build a merge ref for a DIRTY pull request, so no pull_request run is created at all — the enumeration comes back empty and looks like 'no failures'. Observed on PR #255 itself: zero runs while conflicting, one run queued seconds after main was merged in. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01UrgmL8WMK82GxQJjPL8ZCs
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
1 participant
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.
What
/prm(shipped in #248) stopped at the merge and handed back to the ship skills. It is now what it was meant to be: the last thing you type for a task.After the merge it closes the task out end to end — Shipped comment, issue closed, PyAutoMind prompt moved
active/→complete/(claim released, Mind pushed), task worktree removed, merged branches deleted — and reports a ledger of what ran and what was skipped. Typing/prmauthorizes all of it, so the run no longer stops to ask again.Order is forced by the tooling
prove every branch merged → issue → Mind record →
worktree_remove→ branches.worktree_removerefuses whileactive.mdstill claims the task, so the Mind step must precede it. The skill says so rather than leaving the next session to rediscover it.Guards that stop the run
complete/record is a write-up, not a merge receipt, so each repo's branch is proven withmerge-base --is-ancestor+rev-list --count, never from the record.worktree_removerefusal (dirty repo, stale claim) — fix the cause;PYAUTO_WT_FORCE=1is for abandoned work, never a close-out./prmever asks, and only when such files exist. On 2026-07-09 this exact cleanup destroyed a reduced dataset and a 55-frame archive cache.reference.md mechanics
Per-branch merge proof ·
gh api -X PATCH … -f state=closed(gh issue closeis broken in gh 2.4.0) ·lifecycle.py recordwith the bare--promptfilename plus the three effects to verify (a path silently exits 0 and orphans the prompt) ·worktree_root_path+ the data-product check · remote branch deletion proven withls-remote.Checks
bin/check_skill_line_counts.sh→ OK (170-line mandatory load forprm, budget 200; mechanics live in the lazyreference.md)ship_library/ship_workspacecross-links updated to say/prmnow performs their completion contract🤖 Generated with Claude Code
https://claude.ai/code/session_01UrgmL8WMK82GxQJjPL8ZCs