readout

Name: readout
Author: warpdotdev

4.1kinstalls1forks

How to install readout?

warpdotdev/common-skills/readout

$npx -y skills add warpdotdev/common-skills --skill readout

Installs into the current project.

Summary

Produce a polished, self-contained HTML "readout" document under ~/.readouts (with an auto-maintained index page), either by snapshotting the findings accumulated in the current conversation or — when invoked fresh, e.g. "/readout on how github webhook events are processed" — by

Files · 1

View on GitHub

SKILL.md

1	# Readout
2
3	A readout turns an investigation into a durable HTML document someone can read weeks later without any of the original context. It starts one of two ways:
4
5	- Snapshot mode — invoked mid-conversation ("write this up"): the conversation's accumulated findings are the source material.
6	- Research mode — invoked fresh ("/readout on how github webhook events are processed in the server"): there is no conversation to mine, so the investigation itself is part of the job.
7
8	Either way, invoking this skill is a side task. Your job as the main agent is to sharpen the scope, launch a child agent with a good brief, and get out of the way — the child does the mining/research and the writing, keeping that (often large) work out of your context window.
9
10	## Orchestrator workflow
11
12	### 1. Sharpen the scope — ask before launching
13
14	A vague brief produces a vague document. Before launching you should be able to list the specific questions the document will answer; if you can't, interview the user first:
15
16	- Ask 2–4 targeted questions, offering concrete options rather than open prompts — take a quick look at the code or topic first so the options are real (subsystems, entry points, competing concerns). For "/readout on how github webhook events are processed": which direction matters — inbound triggers, post-back, or both? a current-state reference or a gotcha hunt? which repo(s)?
17	- Always pin down depth and audience: high-level orientation vs. deep mechanics with line-level grounding; personal notes vs. shared with the team.
18	- Respect a shrug. "Just a high-level overview" is a valid answer — record it in the brief and move on rather than interrogating. Even then, try to extract the two or three questions the reader most needs answered; specificity is what makes a readout useful.
19	- Skip the interview when the scope is already specific — a snapshot of a focused conversation, or a precise research request, needs no questions. In snapshot mode the conversation usually supplies the questions; ask only when the invocation is ambiguous about which threads to include.
20
21	### 2. Compose the brief
22
23	Write a short brief (roughly 10–20 lines) carrying pointers, not payloads:
24
25	- A working title / topic, and the mode (snapshot or research)
26	- The specific questions the document must answer (from the conversation or the interview), plus depth and audience
27	- Scope: which threads/subsystems to cover, and anything to explicitly exclude
28	- Snapshot mode: headline conclusions worth centering the doc on, one line each — the child pulls the full content from conversation history itself, so don't paste findings wholesale
29	- Research mode: starting pointers — entry-point files, symbols, or directories you already know about
30	- Absolute paths to the repos/directories that ground the work
31	- Each repo's hosted URL and the examined commit when known (e.g. `github.com/org/repo @ abc123`), so the document can hyperlink code references
32
33	### 3. Launch one local child agent
34
35	Spawn exactly one child agent via `run_agents`, local execution. Local matters: the document lands on the user's filesystem and opens in their browser. Name the child `readout-<topic-slug>`.
36
37	Build the child's prompt from the template below. It must include:
38
39	- The brief
40	- The source-material block matching the mode (snapshot mode also needs your agent run ID — `current_run_id` from the orchestration runtime context — so the child can mine the parent conversation with `search_conversation_history`)
41	- The instruction to read `references/doc-guide.md` from this skill's directory before writing
42	- The output path convention and completion protocol
43
44	### 4. Get back to work
45
46	After launching, resume whatever you were doing, or end your turn — the child's completion message arrives on its own; relay the file path to the user with a one-line description when it does. In research mode a fresh conversation may have nothing else pending; just end the turn. Don't sit in a wait loop unless the user asked to wait for the document.
47
48	## Child agent prompt template
49
50	Adapt this; keep the structure, and include the source-material block that matches the mode.
51
52	```
53	You are producing a "readout": a single self-contained HTML document that answers a
54	specific set of questions about <topic>, for a reader who h

People who liked this also viewed

6 picks

Type

readout

4.1kinstalls1forks

View on GitHub

How to install readout?

warpdotdev/common-skills/readout

$npx -y skills add warpdotdev/common-skills --skill readout

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Readout
2
3	A readout turns an investigation into a durable HTML document someone can read weeks later without any of the original context. It starts one of two ways:
4
5	- Snapshot mode — invoked mid-conversation ("write this up"): the conversation's accumulated findings are the source material.
6	- Research mode — invoked fresh ("/readout on how github webhook events are processed in the server"): there is no conversation to mine, so the investigation itself is part of the job.
7
8	Either way, invoking this skill is a side task. Your job as the main agent is to sharpen the scope, launch a child agent with a good brief, and get out of the way — the child does the mining/research and the writing, keeping that (often large) work out of your context window.
9
10	## Orchestrator workflow
11
12	### 1. Sharpen the scope — ask before launching
13
14	A vague brief produces a vague document. Before launching you should be able to list the specific questions the document will answer; if you can't, interview the user first:
15
16	- Ask 2–4 targeted questions, offering concrete options rather than open prompts — take a quick look at the code or topic first so the options are real (subsystems, entry points, competing concerns). For "/readout on how github webhook events are processed": which direction matters — inbound triggers, post-back, or both? a current-state reference or a gotcha hunt? which repo(s)?
17	- Always pin down depth and audience: high-level orientation vs. deep mechanics with line-level grounding; personal notes vs. shared with the team.
18	- Respect a shrug. "Just a high-level overview" is a valid answer — record it in the brief and move on rather than interrogating. Even then, try to extract the two or three questions the reader most needs answered; specificity is what makes a readout useful.
19	- Skip the interview when the scope is already specific — a snapshot of a focused conversation, or a precise research request, needs no questions. In snapshot mode the conversation usually supplies the questions; ask only when the invocation is ambiguous about which threads to include.
20
21	### 2. Compose the brief
22
23	Write a short brief (roughly 10–20 lines) carrying pointers, not payloads:
24
25	- A working title / topic, and the mode (snapshot or research)
26	- The specific questions the document must answer (from the conversation or the interview), plus depth and audience
27	- Scope: which threads/subsystems to cover, and anything to explicitly exclude
28	- Snapshot mode: headline conclusions worth centering the doc on, one line each — the child pulls the full content from conversation history itself, so don't paste findings wholesale
29	- Research mode: starting pointers — entry-point files, symbols, or directories you already know about
30	- Absolute paths to the repos/directories that ground the work
31	- Each repo's hosted URL and the examined commit when known (e.g. `github.com/org/repo @ abc123`), so the document can hyperlink code references
32
33	### 3. Launch one local child agent
34
35	Spawn exactly one child agent via `run_agents`, local execution. Local matters: the document lands on the user's filesystem and opens in their browser. Name the child `readout-<topic-slug>`.
36
37	Build the child's prompt from the template below. It must include:
38
39	- The brief
40	- The source-material block matching the mode (snapshot mode also needs your agent run ID — `current_run_id` from the orchestration runtime context — so the child can mine the parent conversation with `search_conversation_history`)
41	- The instruction to read `references/doc-guide.md` from this skill's directory before writing
42	- The output path convention and completion protocol
43
44	### 4. Get back to work
45
46	After launching, resume whatever you were doing, or end your turn — the child's completion message arrives on its own; relay the file path to the user with a one-line description when it does. In research mode a fresh conversation may have nothing else pending; just end the turn. Don't sit in a wait loop unless the user asked to wait for the document.
47
48	## Child agent prompt template
49
50	Adapt this; keep the structure, and include the source-material block that matches the mode.
51
52	```
53	You are producing a "readout": a single self-contained HTML document that answers a
54	specific set of questions about <topic>, for a reader who h

People who liked this also viewed

6 picks

Type