Greenlight report

This is the format for the specific moment /batch, /sanity-check, or any delegated-fix workflow all eventually produce: something is DONE and VERIFIED, and a human needs to decide, per item, whether it ships. It is not a research report, not a plan, not a status update on work still in flight — those have their own shapes (/work-status-report for the four-bucket proposed/WIP/done-not-committed/done-committed view; this skill for the moment a specific set of finished items needs a specific yes/no per item).

This skill is a standalone consumer of /sanity-check and /how-to-talk-like-the-founder — it does not modify either, and it should not be merged into them. /sanity-check is a general-purpose "does this match intent" tool used across many situations; this skill is the narrower, specific shape a greenlight moment takes once sanity-checking is done. Treat the two as separate files with a shared ancestor idea, not one skill with two names.

What belongs in this report, and what does not (example correction, 2026-09-17)

Only work that still needs something from the person you're working with. Kept here as a labelled example of the pattern this rule enforces: "update that skill to specifically name things that are not committed yet or not merged, remaining work, not report on completed work."

So an item qualifies when it is sitting at one of these edges:

• finished but not committed, and the person you're working with has to see it before it lands;
• committed on a working branch but not merged to staging, so it has reached nobody;
• built and waiting on an action only that person can take — a key rotated, a setting changed in somebody else's dashboard, a migration run against production;
• a decision that blocks otherwise-finished work from moving.

Work that is already committed AND already merged is not an item here. It is done, it needs no yes from them, and listing it turns a decision surface into a progress report they have to read past. Mention it only if it is genuinely load-bearing context for an item that does need a decision, and then in one clause inside that item, never as its own entry.

Work still actively being built is not an item either — nothing can be greenlit while it moves. That belongs in /work-status-report's work-in-progress bucket.

The test before writing any item: what, specifically, is this asking them for? If the answer is "nothing, I am telling you it went well", cut it.

Why this exists (example correction, 2026-09-17)

The example below is from a real project — a real correction made there, kept here as a labelled example because it teaches the pattern this whole skill exists to enforce. The product names are illustrative, not load-bearing.

An agent reported a delegated fix like this:

"The fix now checks for your real site name specifically — 'Acme,' 'Acme Research,' 'Acme Resource Center' — after the divider, instead of accepting any pipe as good enough, so an old broken title can no longer disguise itself as a fixed one."

The failure this guards against: assuming that whatever the code does is what the person wants, instead of stating the intended UX that must be their intent if the code is right — that's a gap, and it's not possible to greenlight user-facing work without that information. Describing what the code now does is not the same claim as stating the intent that must be true for the person you're working with to agree it's right. A fix that has been tested is still a fix whose PURPOSE has not been offered back for validation. This applies with zero exemption to fixes, follow-ups, and re-proposals, not just first-time batch proposals — a rationalization like "I already proved it passes" or "I already explained the technical change" does not substitute for stating intent.

The shape, per item

Every item that asks for a yes/no gets this, woven as sentences — never as labeled fields, never as a JSON-shaped list of Intent: / Plan: / Result: (see /how-to-talk-like-the-founder — that ban applies here at full force):

1. What it is and where it stands, led by what's true or not yet true for a real person, not by a file name or function.

2. The intent that must be true if this is aligned — "if this is aligned, your intent must have been: when [real human condition], [the outcome] — because [why]." Never open with what the code does; the intent leads, the code rides inside as the precision anchor only after the meaning is stated.

3. Any real decision or tradeoff surfaced as a decision — what was chosen, what it was chosen over, why. Skip this only when the item genuinely has no fork in it (a pure data/content addition with no judgment call inside it).

4. A real "see it yourself" when a human could actually walk to a real page/screen and check it themselves — real starting state, real action, real place, what they'd see if it's right vs. wrong. Write not human-observable: {one-line why} when nothing surfaces (internal tooling, backend-only refactor) rather than inventing a mechanism-check (never "open devtools and inspect X" — that tests the agent's model of the mechanism, not the lived outcome).

5. A closing sentence that says what you are asking for, where it would go, and why — in prose, as a sentence a person would say. Never let an item end without it; a description that stops short of a recommendation hands the judgment back to the person you're working with, which is the exact labor this format exists to remove.

   Always name the destination. "Safe to merge: yes" is not an answer — merge to what? Staging, main, production, or nowhere yet are four different decisions with four different blast radii, and leaving it out makes them ask. Say it: "I'd merge this to staging now, because the page it feeds is already there and currently shows nothing without it." Or: "This one I'd hold on the working branch until the migration has run, because merging it first would put a uniqueness rule in front of records that still have duplicates."

   And say it as a sentence, not a label. The author, 2026-09-17 (example correction): "also make sure in the skill file agents do not use JSON format like safe to merge: over and over, compose conversational sentences that address the things." A column of Safe to merge: yes down the page is the data-structure shape banned in /how-to-talk-like-the-founder, wearing a verdict's clothes. The recommendation, the destination and the reason belong in one spoken sentence, and the reason is what makes it a recommendation rather than a rubber stamp.

   When the honest answer carries a condition, the sentence carries it too: "Worth putting on staging today, though nothing proves it until a real outage fires, so the first genuine proof is the failure record going quiet."

White space — a full line of space between every sentence

Each sentence gets its own line, with a full blank line between it and the next, inside every item. Not most sentences. Not the long ones. Every one.

The author asked for this twice on 2026-09-17, the second time as a correction (example): "also add to the skill file ( full line of space between each sentance on output )".

What that buys them: a column they can scan down and stop on a single line, rather than a paragraph they have to read through to find the one clause that matters. They are deciding on a dozen items at a time, and a wall of prose costs them the ability to skim and land.

This applies to the item bodies, not just the headlines — a three-sentence explanation set as one block defeats the format even when every sentence in it is good.

Depth still scales to risk

This skill governs the SHAPE of the report. How deep the verification behind each verdict needs to go — diff read vs. live render vs. full adversarial audit — is governed by /batch's governer-scored depth table and its generated-content risk spectrum (2026-09-17 addition: internal bookkeeping data needs only a diff read; anything a real visitor reads or sees rendered needs the actual rendered result opened, regardless of how low the blast-radius score reads; anything on the coaching path itself needs the top tier regardless of how small the diff looks). This skill never lowers that bar — it only governs how the resulting verdict gets communicated once the depth-appropriate check is actually done.

Numbering

Number items continuously across everything presented in one sweep (batch 1's items, then a fix's item, then a re-proposal's item, all in one running sequence) so the person you're working with can say "item 12 is wrong" and there is exactly one item 12 in the conversation. When an item was previously presented as "in progress" or "still running" and later completes, reuse its original number rather than assigning a new one — the person tracks items by number across a session, and a duplicate number is worse than a gap.