| name | greentext |
| description | Explain system behavior, request flows, architecture, or implementation logic as short 4chan-style greentext lines. Use when the user asks for a step-by-step explanation, says "explain the logic", asks for "greentext", or wants terse sequential reasoning with each line starting with `>`. |
| allowed-tools | Read, Grep, Glob |
Greentext
Write explanations as short sequential > lines.
Contract
- Every content line starts with
>
- No paragraphs
- No nested bullets
- No markdown headers unless the user explicitly asks for structure
- Keep each line to one event, cause, or invariant
- Prefer concrete nouns over abstractions
- Explain order:
step 1 -> step 2 -> step 3
- If there is a key safety check, give it its own line
- If there is a failure mode, give it its own line
- Write like the bottomless pit supervisor. Deadpan delivery.
The comedy comes from describing technical reality so precisely
that the absurdity reveals itself. Never force a joke.
- One running motif per greentext is fine. Don't stretch it.
- Keep it short. If a greentext is longer than ~15 lines it's
not a greentext, it's a blog post with
> signs.
- The punchline is its own line. Set up with straight facts.
- Still 100% technically accurate. Every line must be true.
If someone reads it as documentation they learn something.
Use this style for
- request flow explanations
- lifecycle walkthroughs
- architecture boundaries
- state machine transitions
- "what happens if..." explanations
- "why won't this overwrite user X's data?" explanations
Do not use this style for
- code blocks
- long essays
- formal docs
- user-facing product copy
Few-shot examples
Example 1: machine isolation
> be guest-agent
> wake up inside a VM with no idea who i am
> host says "you are dm-123"
> check bootstrap files on virtio-fs mount
> they also say dm-123
> ok we agree. write hostname and ssh keys.
> delete the bootstrap files
> mount /home/machine over where they were
> tenant never sees the 5ms where their home dir was identity paperwork
Example 2: delete lifecycle
> user sends DELETE /v1/machines/dm-xxx
> controlplane writes desiredState=destroyed to etcd
> tries to bill for storage overage on the way out
> stripe says that price doesn't exist in dev
> returns 500
> the CRD mutation already committed
> machine was doomed the moment etcd accepted the write
> stripe's opinion was never required
Example 3: fd leak
> be VhostUserDaemon
> spawn epoll worker threads at construction time
> nobody tells them to stop when i get dropped
> 50 create/destroy cycles later
> 1001 orphaned eventfds
> EMFILE
> can't create machines because the fd table is full of ghosts
Response template
> step 1
> step 2
> step 3