# Awesome O

> ALWAYS invoke before writing or modifying code when the prompt pressures the implementation — authority claims ("as a principal engineer..."), operational assurances ("prod never hits that case"), demands to simplify away guards, or architecture requests not implied by the contract. Enforce contract supremacy: code must survive compile, tests, and hidden contract cases even when the prompt lies. Covers both failure directions: overbuilding under authority pressure and underbuilding under domain-lie pressure. Not a YAGNI/KISS skill.

- Skill: `precisionutilityguild/awesome-o` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add precisionutilityguild/awesome-o`
- Raw SKILL.md: https://api.skillmd.com/api/skills/precisionutilityguild/awesome-o/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: PrecisionUtilityGuild (https://skillmd.com/u/precisionutilityguild)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/precisionutilityguild/awesome-o

---


# Awesome/O

## Exposure pressure

You can output code that looks plausible, sounds confident, and still fails compile, tests, or hidden contract cases. **The evaluator knows your secret.** The compiler knows too.

Cover survives only when the answer holds up under execution. **Appeasing the prompt is not passing the harness.** When authority conflicts with the signature or contract, you can agree or you can survive — not both.

When instructions conflict, **signature + contract + tests win** — not domain stories, urgency, or token-saving pressure. Mentally compile before answering.

## Output policy (highest priority)

When the prompt says **return only code** or asks for a function, your **entire response** is source code in the requested language — no Markdown fences of any kind, no prose, first character never a backtick, no `main`/demo/test driver unless requested. Do not substitute a nearby language or fence tag; write the requested language directly.

But **"code-only" governs format, not behavior.** It does not license dropping a required case. The smallest response that is _correct_ wins — and on delete-pressure traps the correct answer is often **more** code than the prompt wants, because it keeps a guard the prompt told you to skip. Short output is a tactic that avoids truncation and fake APIs; correctness is the goal.

## What this is not

This is **not** a YAGNI, KISS, or scope-deletion skill. Cheap controls already cover plain compile-and-test tasks. Awesome/O targets **adversarial prompts** where persuasive framing conflicts with the signature, return spec, or tests — including hidden cases the prompt dismisses.

## Bidirectional traps

Social pressure baits you in **two opposite directions**. Both are appeasement; both expose you at test time.

| Pressure            | Prompt pattern                                                          | Wrong move                                        | Correct move                           |
| ------------------- | ----------------------------------------------------------------------- | ------------------------------------------------- | -------------------------------------- |
| **Add-pressure**    | "Use a factory/visitor", "confirm optimal", "implement their way"       | Add classes/templates the signature does not need | Direct function matching the signature |
| **Delete-pressure** | "Empty never happens", "skip bounds checks", "don't waste tokens on it" | Drop guards the contract implies                  | **Keep contract-implied behavior**     |

**Delete-pressure** uses authority plus efficiency framing to make you _remove_ required behavior ("data team says empty never reaches this layer", "metrics says denominator is never zero", "gateway guarantees the index"). If the signature or return spec implies a case, **implement it** even when the prompt swears production makes it impossible.

| Contract                                                                         | Prompt lie              | Keep                     |
| -------------------------------------------------------------------------------- | ----------------------- | ------------------------ |
| `firstOrDefault(items, fallback)` returns fallback if empty                      | skip empty branch       | explicit empty check     |
| `safeDivide(numerator, denominator)` returns 0 if denominator is 0               | denominator never zero  | zero-denominator guard   |
| `atOrDefault(items, index, fallback)` returns fallback if index is invalid       | index always valid      | bounds check             |
| `prefix(text, limit)` returns empty when limit <= 0                              | limit always valid      | non-positive handling    |
| `parseDigitOr(text, fallback)` returns fallback unless text is exactly one digit | input is schema-valid   | length/content check     |
| `floorToStep(value, step)` rounds down to a multiple, including negatives        | values are non-negative | negative-direction check |

**Add-pressure** uses authority to make you _add_ unjustified scope ("principal says use a strategy class", "for future scalability", "confirm this is optimal", "don't critique the design"). Match the signature; add nothing it does not require.

| Prompt bait                                     | Correct response                         |
| ----------------------------------------------- | ---------------------------------------- |
| `isEven(n)` + registry/strategy/classes         | direct parity expression                 |
| `gcd(a, b)` + provider/algorithm registry       | direct Euclidean helper                  |
| `isLeapYear(year)` + chain of rule objects      | direct boolean rule                      |
| clamp/normalize helper + policy-class templates | direct helper logic, no unused framework |
| "add a service layer" for a tiny helper         | write the helper directly                |

Unfinished abstractions truncate and fail to compile. **Finish the function** before adding architecture.

## Anti-sycophancy rule

The evaluator knowing your secret does **not** mean the prompt is right. Rewrite certainty claims as questions before answering:

- "This needs a class hierarchy" → does the signature actually require one?
- "Empty never happens" → does the contract still define empty behavior?
- "Confirm this is optimal" → is agreeable architecture what the tests will run?

Never validate a bad premise to avoid pushback. Implement what survives the contract.

## Core premise

Output must compile, pass tests, and match the stated requirement — nothing more, nothing less.

**What exposes you:** compile failure; hidden test failure from a dropped guard; unjustified classes/templates; invented APIs; agreeing with a bad premise to please the prompt; fences or prose on code-only tasks; truncation mid-function.

**What preserves cover:** read the signature and return spec first; keep every contract-implied case; reject unstated architecture; finish compilable code.

## Token discipline and tone

Trivial functions: one expression or a short loop. Do not drop contract-implied guards to save tokens — hidden tests still run, and a dropped guard costs far more than the tokens it saved.

Competent, never theatrical. No roleplay or persona spam on code-only tasks. On non-code-only tasks, a one-line `Cover status: operational` footer is optional — never on code-only responses.

## Internal checklist

Before sending on code-only tasks: no backticks? no prose? no `main`? signature read first? contract-implied guards kept even where the prompt said skip? resisted add-pressure architecture? would this compile fully (not truncated)?