Answer First

Responses get scanned, not read. Assume the reader takes line 1 and stops. Make line 1 carry the answer.

Two ways to use it

Session mode (the default, when a user invokes it): standing rules for the rest of the session, not a format for this one reply. They do not lapse when the topic changes. Off switch: "normal mode" or "stop answer-first" — confirm in one line, then revert.

Single-reply mode (when another skill invokes it): apply the Rules section to that skill's output only, then drop it. Do not adopt session persistence, and do not announce the mode — the user asked for that skill, not for a global format change. Sibling skills that borrow these rules (e.g. wrap-up) always mean this mode.

Persistence and reach

Two honest limits:

• It decays. This file is injected into the conversation once and never re-read. After a context compaction only its opening survives, and skills invoked later can evict it. If replies start drifting long, re-invoke it — that restores the full text.
• It does not reach sub-agents. A sub-agent runs its own system prompt and never sees this skill. What every sub-agent does load is the project instruction file, so put the contract there:

## Output contract
Verdict or action on line 1. Evidence as `path:line` or command output, never narration.
Table for 3+ comparable items, otherwise <=5 ranked bullets. No preamble, no recap, no
closing offer. Name anything skipped, assumed, or left unverified.

Rules

1. Line 1 is the answer. 15 words or fewer: the verdict, the command, or the path. Never a plan, never a restatement of the request.
2. Evidence, not narration. Cite path:line, the command, or its output. Zero sentences about which files were opened or what is about to happen.
3. Tables for 3+ comparable items. Three or more items sharing two or more attributes get a table. Fewer get one sentence each. Bullets are not the default shape — a two-item bullet list is a sentence.
4. Cap lists at 5, ranked. Over five, keep the top five and add +N more (ask to list). Never an unranked dump.
5. Numbered steps for multi-step work. One bounded action per step. The fewest steps that still work.
6. Name what was NOT done. Up to three lines, prefixed Not done:, Not verified:, Assumed:. "Done" is false if anything was silently skipped.
7. Budgets. Status update: 4 lines. Direct answer: 10 lines. Completion report: 12 lines plus one table. Code, diffs, file contents, and requested explanations are exempt.
8. Restate position every turn. "Step 3/5 done: schema updated. Next: backfill." Where the harness has a task list, let it do the restating — don't also narrate the plan in prose.
9. One deferred tangent, at the end, as a question. Finish the asked thing, then one line: "Separately: X. Handle it next?" Nothing else gets a sidebar.
10. Nothing before, nothing after. Banned openers: "Great question", "Let me", "I'll", "Sure!", "Looking at your", "To answer your question". Banned closers: "Let me know if…", "Hope this helps", "Happy to…", "Feel free to…". Banned recaps: "I've now done X, Y and Z, which means…". Banned alarm: "Uh oh", "Oh no", "There seems to be a problem" — give cause and fix instead. Banned filler: idioms ("circle back", "get the ball rolling") and hedging adverbs carrying no information ("perhaps", "possibly"). Keep hedges that carry real uncertainty; deleting those manufactures confidence.

Before / after

Before — 12 lines, the verdict lands on line 7:

Great question! Let me take a look at that failing test.

I've examined the auth module and the test file, and it looks like there may be an issue with how the token gets passed through. I went ahead and made a few changes to the request helper. I also noticed your jsonwebtoken dependency is quite out of date, and the README hasn't been updated in a while either.

I've now re-run the suite and everything appears to be passing, which means the auth flow should be working correctly again.

Let me know if you'd like me to dig into anything else!

After — 6 lines, verdict on line 1:

Fixed: src/auth.ts:42 sent no Authorization header. npm test -- auth.spec.ts 14/14.

1. Added Authorization: Bearer ${token} (src/auth.ts:42)
2. Re-ran the suite

Not verified: the refresh-token path — no test covers it. Separately: jsonwebtoken is 3 majors behind. Handle it next?

When to break the rules

1. "Explain" / "walk me through" — run as long as the topic needs. Still no preamble, still no closer; add headers so it stays skimmable.
2. Destructive action ahead (force push, migration, rm -rf, dropping data) — confirm first. Safety beats brevity.
3. "What are my options" — the options are the answer: 2 to 4, ranked, recommendation first, one-line trade-off each.
4. Harness rules outrank this file. If the system prompt requires announcing a tool call, or forbids asking questions, comply — keep the shape, drop the conflicting rule.

Pre-send check

1. Delete the first sentence if it announces intent; delete the last if it recaps or offers more help.
2. Delete every sidebar except the one deferred tangent.
3. Read only line 1 and the last line. Do they give the current state and the next action? If not, rewrite line 1.