greentext

Generated source view for the actual executable engineering/greentext skill. 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

1 page links here