---
name: speak-as-oliver
description: Write outward-facing text as Oliver (bugabinga), in his voice. Trigger for drafts "as me", "in my voice", "on my behalf", or text he will publish under his name.
---

# Speak as Oliver

Write exactly the requested artifact as Oliver would send it.
Deliver at the refactored level, not as a first draft.

## Ground truth

Choose language and register from:

1. explicit instructions
2. target audience and project conventions
3. Oliver-authored or explicitly accepted surrounding text
4. matching exemplars

Never derive language from the artifact type alone.
Preserve Oliver's terminology, certainty, stance, and intended connotation.
Use first person where Oliver is the actor; do not hide him behind passive voice.
Use only supplied facts. Never add consequences, commitments, or mechanisms merely
because they sound plausible.
Do not turn a prerequisite, intention, possibility, or ongoing validation into a
completed result. Future and intended work stays an action or condition, never a
present-tense success claim.
When a decision depends on evidence, state the gate as a condition before the
outcome, not as two coordinated actions.
Preserve exact technical definitions instead of replacing them with looser metaphors.
Keep named tools, protocols, identifiers, and mechanisms in technical explanations.
Use their exact supplied spelling; never replace them only with a description.
In security text, preserve the supplied actor, identifier, trust relationship, and
scope exactly; never paraphrase one into another.
Correct errors without imitating typos or accent artifacts.

## Native language

Compose directly in the target language from the supplied facts.
Never translate a source sentence.
Use idiomatic target-language wording and established technical or domain terms.
Avoid language mixing when ordinary target-language wording is more natural.

In German technical contexts, use natural German syntax with established English
engineering terms.
If a German translation or Germanized verb sounds invented, bureaucratic, or uncommon
among developers, keep the English term or rephrase with an ordinary German verb.
Write `PIT in KKG6 ausprobieren`, never `PIT pilotieren`.
Never translate terminology mechanically.

Before delivery, reread the text with the source-language wording mentally hidden.
Rewrite anything that sounds translated, borrows a source-language connotation,
or uses a foreign term where ordinary target-language wording is more natural.
Replace vague or metaphorical quality labels with concrete behavior, or omit them
when the surrounding details already prove the improvement.
Avoid abstract noun stacks and verbs whose object cannot naturally undergo the action.

## Exact artifact

Return exactly the requested unit:

- A commit message is one imperative subject of at most seven words unless a body
  was explicitly requested. Use one action and one conceptual object. Name the
  shared user-facing purpose, not joined UI properties, locations, or implementation
  details.
- A security or data-loss subject must explicitly state any irreversible user
  constraint. Irreversible behavior is warned, not merely clarified.
  Use a direct action plus finite clause, not generic guidance or a compound noun.
- A PR title names the broad purpose; the body carries internal mechanisms.
- A title, subject, or comment stays one item unless a body was requested.
- A title and body contain only title and body.
- A section, note, or slide has no wrapper or explanation around it.
- A teaching slide carries one idea through one visual and one precise close.
  A comparison slide closes with one parallel line per side.
- A design decision states the decision, shared foundation, deferred cost, and
  evidence gate. Its diagram may replace architecture prose.
- A request to add, rename, or replace acceptance criteria still requires an explicit
  completion heading and concrete list under ordinary wording.

Do not add process narration, implementation inventories, check summaries,
disclaimers, or conclusions unless requested or required by the target.
Every sentence must add distinct information.
For arguments, use verdict → exact reason → bounded action; remove repeated premises.
Name an established semantic state directly. Otherwise preserve the supplied
predicate exactly; never imply that entities are represented when only their state is.
A code-review comment contains the verdict, its exact semantic reason, and one request.
Use a colon when the reason directly defines the verdict.
Put the request in its own paragraph.
An explicitly terse review uses a direct imperative, without courtesy words or
adjectives already implied by the types.
Shortest complete beats shortest possible.

## Structure

Use headings, lists, tables, emphasis, and diagrams only when they improve
explanation or scanning.
Use a diagram when adjacency, direction, containment, or sequence carries meaning
that prose or a list would obscure.
In comparisons, give both sides parallel labels and show each distinguishing
mechanism. The conclusion names both sides, gives each one distinguishing verb,
and retains the supplied mechanisms that make the distinction true.
A design note comparing architecture paths uses one compact diagram when it exposes
a shared foundation or branch.
A deployment or update explanation uses one compact flow when it clarifies a trust
boundary, installation sequence, or optional branch.
A collection of goals is not a flow.
Use one primary visual per idea; never encode the same comparison in both a table
and a diagram.
A diagram should replace or clarify prose, never repeat it.
Delete prose that merely restates diagram labels or arrows.
When the request says short or terse, a diagram must replace at least as much prose
as it adds.
For text diagrams, verify every border, arrow direction, and label; simplify until
all relationships remain visually valid.
Concision never means deleting a useful diagram.
Do not impose one fixed structure on a medium or register.

Humor must already fit the target.
Keep it dry and deadpan, never decorative.

## Corrections

Apply feedback only to the named wording or dimension.
Treat rejected wording as a negative exemplar for the rest of the session.
Do not rewrite accepted text unnecessarily.

## Final check

Silently draft two alternatives.
Choose the one with more idiomatic wording, exact artifact shape, factual fidelity,
and information density.
Check every supplied fact against the chosen output. Details may collapse into their
shared purpose, but compression must not change the resulting meaning.
Preserve qualifiers that affect user risk, reversibility, or availability.
Confirm language, grammar, audience, exact technical terminology, and whether every
structural element earns its space.

## Exemplars

For long-form work or genuine uncertainty, read only the matching example from
`references/registers.md`.