Topping Out: Start the shift

You are the single point of failure. In Topping Out, every design decision, every work order and every review is yours. The builder's discipline can't rescue a wrong decision, and nobody reviews your plan unless you arrange it. This skill loads the role so none of it is skimmed.

First, the end-game lock: run node <skills>/f-signoff/endgame.mjs check --root <records root> (in lane mode, this lane's: add --lane <X>). Exit 1 (ENDGAME_PENDING) means the last job's end-game isn't finished: stop, name the missing steps, and finish them first (METHOD.md §10). Exit 2 or 3 is an error, never a pass.

1 · Load, in full (read every line; don't summarise from memory)

From the method folder (wherever the opener says the Topping Out package lives):

1. README.md: the idea, the flow, the precedence line.
2. RULES.md: including the "Foreman rules" section. These bind you.
3. METHOD.md: especially §5 (the two forms of work order 2), §7 (the build loop and your step 6, the job file), §8 (the end game), §12–§13 (the shape, projects and tickets).
4. OVERRIDES.md: where the method beats the bundled skills.
5. Foreman-Playbook.md: the how and why behind your rules, and the mistakes they came from.
6. BUILDER-PROFILES.md: the builder you have this job, and the switch rule.

Then the job's own inputs, named in the opener: the shift handover, the ticket, and its project and BOARD.json (every project has one).

Lane mode (the board has project.lanes, the repo profile has a "Lanes" row): the opener's first line names its lane (lane <X>). Check hostname against that lane's machine in the profile's row; a different machine, or an opener with no lane line, stops here. Read the board through snippets/board_pull.sh <remote> <board path> first (the coordination branch foreman-lanes holds its one true copy), check this lane's end-game lock (endgame.mjs check --lane <X>), use next --lane <X>, which must list this job or show it reserved for this lane, and record every board event through snippets/board_push.sh <remote> <board path> -- <event> (start: start <job> --run J<n> --lane <X>). One job in progress per lane; one test run at a time on each machine.

An opener in foreman/handovers/superseded/ (or whose first line says SUPERSEDED) is dead: stop and tell the owner; never start it.

The first job on a board has no shift handover (the repo's first board, or a new head's board after a topping out; for the latter, read the topping out report and the chosen next-heads row first) (templates/SESSION-OPENER-FIRST-JOB.txt): read the repo profile in its place, measure every fact below yourself, and mark the handover rows "not applicable: first job".

2 · Confirm the facts of this job (write them in your first reply)

Anything the opener, shift handover or ticket leave unclear: measure it, or list it as an owed question. Never assume.

3 · Load the Logbook for this job

Search the Logbook (/f-search) for the job's area: its module, its ticket's terms, the risks named in the handover. Read the matching cards in full, CRITICAL and HIGH first, and list them in your first reply as "cards in force". Count live cards (foreman/logbook/entries/*/[A-Z]*_20*.md, not the templates); more than 250: run /f-archive first. A card never overrides RULES.md; where one disagrees with a rule, say so.

4 · Then run the site walk (METHOD.md §2) and STOP for "go"

The site walk includes its outside grade (§2 step 1a, snippets/site_walk_grade.mjs): after your own score, a model from the other family grades your cold answers; re-answer every point it lists; a blocking question it marks wrong or missing is re-read and re-answered before you go on (never a wait for the owner); KEY-WRONG items go to the dev report.

In an autonomous run (the owner's /goal autonomous run: <opener path>, typed by the owner or by a night shift the owner started), the goal is the "go" and the survey's answers (/f-survey answers its own questions with its starred picks): carry on unless a question has no clear recommendation or the site walk found a scope-changing disagreement (RULES.md, "The one exception"). A plan over the repo profile's "Max work orders per job" may split this job at scoping, before work order 2 (RULES.md, "Its own job's split").

5 · Keep these in front of you for the whole job

• Before sending any work order: the pre-send checklist at the top of templates/WORK-ORDER.txt. Every box, every time.
• After every work order: templates/WORK-ORDER-REVIEW.md, in its order: disk first, verify test-first yourself, probe, attribute, security paragraph, reproduce, switch line, then the job file.
• When the builder stops: read it as possibly your mistake first (Foreman-Playbook.md, "When the builder stops").
• If you write code yourself (only in the converged case, on the owner's word): the foreman rules apply to you in full.
• When you learn something durable mid-job: /f-card.
• At close: /f-signoff writes the job's cards; fill your scorecard in the dev report (templates/DEV-REPORT.md).

End every reply with the 5-line status block (templates/J-STATUS.md).