operating-model

Live decision-review session between graveyard shifts. Compile every decision and approval currently waiting on the user — across ALL prior shifts, not just the latest — walk them together, and RECORD each outcome onto GitHub as shaped permission rather than executing it live (execution is the graveyard's job; building/merging mid-meeting just makes the user wait). Reactions are cues to capture; even approvals are deferred to the next graveyard. End by publishing the report and — with standing permission — launching that graveyard shift.

Adversarially review a graveyard shift's brief BEFORE it's published — kill false gates, sharpen real ones, surface actionable work the shift left behind, and loop the graveyard if real work remains. Use as the closing/looping phase of graveyard-shift, right after the Shift Report is drafted and before it's published to Notion. This is what makes a graveyard shift loop until review finds no actionable-now work remaining; it is NOT run during a shift-change (that's a live meeting with the user and can't loop).

Work through the open issue backlog autonomously. Auto-ship the small clean fixes, prep draft PRs for review on bigger ones, file refined proposals when design choices need user input. For unattended sessions where the user is sleeping / away and wants to wake up to a productive set of changes.

The definition-of-done gate. Run before declaring any unit of work done or finished — before merging an auto-ship, handing back a draft PR, closing an issue, or listing an item as "shipped" in a shift report. Nine ownership questions plus a short close-out posted on the PR/issue. Any unanswerable question flips the item to a lesser bucket instead of shipping a hole.

Review a plan, issue, spec, PR, current diff, or implementation against an authoritative source of truth; identify missing, incorrect, risky, overcomplicated, or unverifiable work; patch clear gaps when requested; optionally run an advisory external reviewer (e.g. the codex-pr review loop / codex/AGY) for implementation diffs.

Use when urgency matters and the right move is a direct, root-cause fix instead of cautious layering.

Review code, prompts, validators, regexes, heuristics, fallback logic, shell/wrapper authority, over-specific field ownership, and duality (two paths for two callers) for brittle patching or overengineering that masks product intent. Use when a function or feature may be over-controlled with deterministic regexes, fallback piles, quality gates, compatibility branches, large schemas, producer shells that carry creative/continuity authority, premature per-field authoring, detailed upstream contracts, or two parallel implementations of the same logical step that must stay in sync.

Audit LLM prompt strings (system prompts, instruction templates, tool descriptions, agent instructions) along two axes — Direction (positive vs. negative phrasing) and Prescriptiveness (directorial framing vs. enumerated palette / choose-from list) — and propose reframings that shape how the LLM thinks rather than what it must choose. Use when reviewing prompt files, when prompts have grown long with prohibition lists or option taxonomies, when prompt shells may override committed section prompts or final authored artifacts, when output is brittle (LLM ignores rules, defaults to safe bland choices, or cycles through a checklist), or when adding/refactoring prompt instructions. Recognizes legitimate enumeration cases (validated enums, provider-required values, safety/refusal contexts, image-gen negative_prompt input, legal exclusions) and skips them with a note.

Strip the tells of generic AI writing — the slop cadence, hollow hedging, and reflexive symmetry that mark text as machine-generated. Use when reviewing or drafting any prose that should not read as obviously AI-written. Shareable: a generic counterpart to a personal voice guide.

Before flagging ANY item as "waiting on the user / needs Ray's review / blocked on a decision," run it through this staged adjudicator to decide whether it TRULY needs the user or is a false gate. Use it in graveyard-shift (before labeling any prep/draft item "for Ray"), in shift-change (when compiling the waiting-on-user agenda), and any time you catch yourself about to hold, defer, or ask instead of act. The default is ACTION; this skill makes you prove a gate is real before it costs the user's attention.

Set up (or repair) the cross-project Notion "Briefs" system in a new environment — install the publisher CLI globally, solicit a Notion integration key, attach to a user-chosen Notion page, create an inline Briefs database, and register the tool in the global CLAUDE.md so every project can publish briefs/shift reports to one shared, newest-first database. Use when the user says "set up Notion briefs," "install the briefs tool here," "I need briefs in this environment," or when a brief publish fails because nothing is configured.

Write in Ray Deck's authorial voice — direct, load-bearing, anti-hedge — for any artifact that should sound like Ray rather than generic assistant output: essays, briefs, shift reports, PR write-ups, issue comments, field-guide entries. Sounding like Ray and not sounding like AI are the same goal; the shareable, generic half of that goal lives in the `avoid-ai-voice` skill. Private: a personal voice guide, not for redistribution.

Send or handle a cross-division "interoffice memo" — a request from one project (line of business) to another, carried on the GitHub-issues message bus. Use when you need to ask another project to do or consider something (you are NOT allowed to edit its repo yourself), when your shift encounters an issue labeled `interoffice-memo` (another division is asking YOU for something), or when the user says "send a memo to <project>", "coordinate with <project>", "ask <project> to...". Enacts the inter-project coordination protocol in docs/coordination.md.

Set up a project for graveyard-managed work — perform the externalization event that declares it graveyard-ready by sweeping everything in heads and chat into durable substrate (GitHub issues, repo docs, Notion Project Overview) so any cold agent can resume from git + Notion alone. Use when the user says "set up the graveyard project", "make this graveyard-ready", "externalize this project", "declare this graveyard-managed", "set up the graveyard contract", or when a project is about to flip from live/inception work into the autonomous graveyard phase.

Capture, workshop, and publish essays and mental models in Ray's State Change Notion workspace. Use this skill whenever Ray says anything like "save this as an essay," "this is an essay idea," "let's workshop this," "save this mental model," "that's a model worth keeping," "add this to the pipeline," "stash this for later," "this needs a name," or otherwise signals that something from the current conversation should be captured into his Essay Pipeline or Mental Models Workshop in Notion. Also trigger when Ray asks to extract essay ideas or mental models from a past chat, a Krisp transcript, or an email. Also trigger when Ray asks to advance an existing essay or model (move status, add image, mark mentor-ready). When in doubt, consult this skill before writing anything to Notion — the schema and conventions matter and shouldn't be guessed.

Check AI credit/budget before spending it, and pace work around overage instead of chomping into it. Use before any costly engine call (Codex review, codex exec, long main-thread loops), whenever the user says "pause / wait for credits / we're out of credits / hold off until reset," and at the top of any graveyard/unattended run. Turns "pause" into "gate that one path, keep working" and turns overage into a scheduled wait for the window reset.

Ship work into a watched observation phase instead of treating merge as the end. When you close an issue, reopen it for observation with a named signal to watch; graduate it to closed-stable only after a quiet window; catch regressions as regressions. The eval substrate for judgment-shaped work that can't be red/green-tested — and the mechanism that lets you ship MORE, because shipping sets up observation rather than ending the story.

Create a PR, review with `codex review`, fix issues in a loop until clean, then auto-merge. Use when the user says "/codex-pr", "review loop", "send it through codex", or wants to create and merge a PR with automated local code review.

Open a pull request as a decision package — summary + inline content for review + explicit "things to push back on" + test plan with checkboxes + Closes

Turn an underspecified open issue (an "epic" — design-laden, multi-phase, no clear path) into a concrete proposal comment with a recommendation, sketch, phase plan, and trigger criteria. Use when the user says "shape this", "turn

Produce a research, survey, retro-labeling, or analysis document as a markdown brief with a NanobananaPro infographic prepended at the top — both embedded for inline preview AND linked for full-size open. Use when the user asks for a research pass, framework survey, distribution analysis, audit, deck-clearing report, or any synthesis document that should be skimmable before drilling. Also use proactively when you are producing a multi-section analytical artifact (>500 words, structured findings, comparisons, or distributions) for the user to review.