| name | session-close |
| description | Land the session — claim, born-red card first, READY PR, batched work, close-out docs, flip complete last; land on green. |
session-close
Land venture-lab's session correctly — the full landing path, claim to
merged-on-green. Playbook-grade: a session reading this executes without
improvising (grounded-skills plan §7.2).
What this does
Drives the session's work to a terminal, verified state on two rails:
the born-red gate (card first, flip last) and landing your own green PR
(merge it directly once required checks pass, or let the server-side
auto-merge-enabler land it — either is fine). Everything else is ordered
steps.
Instructions
- Claim first (session start — verify it happened) — one file per claim,
control/claims/<branch-or-scope>.md, a single bullet: backticked
branch/scope token · scope — one-line detail · expected files/area ·
ISO date (the shape check_claims parses). Land the claim on main fast,
then re-read control/claims/ at HEAD before building.
- Born-red card as the FIRST commit —
.sessions/<date>-<slug>.md whose
Status badge line declares in-progress (the born-red hold token), plus
a one-line "what is about to happen". Push, then open the PR READY (not
draft) immediately: the open PR + the claim are the in-flight signal
parallel sessions collide without.
- Land your own green PR — merging is normal agent work. Once the required
checks are green, merge it directly (MCP/REST), or let the server-side
auto-merge-enabler land it; either is fine. Only a
do-not-automerge-
labelled PR waits for the owner. Read a red on a born-red head as the
designed hold, not a CI failure: verify any red against the job log
before diagnosing — alias/mirror jobs echo the required check without
running anything (kit repo example: the two legacy jobs mirroring
kit-quality), and "HOLD (by design)" means nothing to investigate.
- Batch the work — push when a batch is meaningfully complete, never every
commit (superseded CI runs are the dominant Actions cost).
- Close-out docs, into the SAME card: what shipped (paths + commits);
Capability delta — new capability or wall discovered? Append it to
docs/CAPABILITIES.md (dated, with its venue token, exact error or
proof, workaround — below the seed fence, never inside it); every
⚑ needs-owner ask carries the OWNER-ACTION fields (WHAT / WHERE / HOW /
WHY-IT-MATTERS / UNBLOCKS / VERIFIED-NEEDED — attempted, or the exact
wall; see control/README.md) — Withdraw stale asks; groom one idea
forward; add one new 💡 idea you genuinely believe in; write the ⟲
previous-session review.
- Verify —
python3 bootstrap.py check --strict and python3 bootstrap.py check --strict.
The only acceptable pre-flip red is the designed born-red hold naming
this session's own card.
- Flip as the deliberate LAST step — flip the card badge to
complete,
delete your own claim file, push. Green then merges server-side; a
flipped-early card merges a partial PR (the failure the gate exists
for), and an unpushed flip leaves the PR red forever.
Report format (card close-out)
- Shipped: one line per artifact, with paths + commit SHAs.
- Verify: each command + its tail, verbatim.
- ⚑ decide-and-flag lines · 💡 session idea · ⟲ previous-session review.
- PR: # + terminal state, probed against the tree/checks — not a stale
PR read.
Declared capabilities: edit (the log + docs), run (the checks + git).
