3 min read
greentext
Generated source view for the actual executable
engineering/greentextskill. The durable routing article is Agent Engineering Skills. Source: skills/engineering/greentext/SKILL.md
Runtime Source
| Field | Value |
|---|---|
| Category | engineering |
| Origin | personal |
| Slug | greentext |
| Source slug | greentext |
| Family | Agent Engineering Skills |
| Source | skills/engineering/greentext/SKILL.md |
Bundled Resources
No bundled resource files.
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 >.
Skill Source
---
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 `>`.
origin: personal
source_slug: greentext
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
```text
> 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
```text
> 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
```text
> 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
```text
> step 1
> step 2
> step 3
```
Timeline
- 2026-07-15 | Generated a browseable source page from the actual executable skill file. Source: skills/engineering/greentext/SKILL.md