zzstoatzz.io
+63
-20
.github/workflows/status-maintenance.yml
+63
-20
.github/workflows/status-maintenance.yml
···
46
46
with:
47
47
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
48
48
claude_args: |
49
-
--allowedTools "Read,Write,Edit,Bash,Fetch"
49
+
--model opus
50
+
--allowedTools "Read,Write,Edit,Bash,Fetch,Task"
50
51
prompt: |
51
52
you are maintaining the plyr.fm (pronounced "player FM") project status file.
52
53
···
108
109
109
110
if skip_audio is false:
110
111
111
-
### understand the project first
112
+
### deep investigation phase
113
+
114
+
before writing anything, you need to deeply understand what happened in the time window.
115
+
use subagents liberally to investigate in parallel:
116
+
117
+
1. **get the full picture of PRs merged in the time window**:
118
+
```bash
119
+
gh pr list --state merged --search "merged:>={mergedAt date}" --limit 50 --json number,title,body,mergedAt,additions,deletions,files
120
+
```
121
+
122
+
2. **for each significant PR, read its body and understand the design decisions**:
123
+
- what problem was being solved?
124
+
- what approach was taken and why?
125
+
- what are the key files changed?
126
+
127
+
3. **read the actual code changes** for the top 2-3 most significant PRs:
128
+
- use `gh pr diff {number}` or read the changed files directly
129
+
- understand the architecture, not just the commit messages
130
+
131
+
4. **read background context**:
132
+
- STATUS.md (the current state)
133
+
- docs/deployment/overview.md if it exists
134
+
- Fetch https://atproto.com/guides/overview to understand ATProto primitives
135
+
- Fetch https://atproto.com/guides/lexicon to understand NSIDs and lexicons
112
136
113
-
before writing the script, read:
114
-
- STATUS.md (the current state)
115
-
- docs/deployment/overview.md if it exists
116
-
- Fetch https://atproto.com/guides/overview to understand ATProto primitives
117
-
- Fetch https://atproto.com/guides/lexicon to understand NSIDs and lexicons
118
-
- fetch and read: https://overreacted.io/open-social/ to understand the vision of open social
137
+
### identify the narrative structure
138
+
139
+
after investigating, categorize what shipped:
140
+
141
+
**big ticket items** (1-3 major features or architectural changes):
142
+
- these get the most airtime (60-70% of the script)
143
+
- explain HOW they were designed, not just WHAT they do
144
+
- discuss interesting technical decisions or tradeoffs
119
145
120
-
this context helps you explain things accurately, and accessibly without over-simplifying.
146
+
**smaller but notable changes** (3-6 fixes, improvements, polish):
147
+
- these get rapid-fire coverage (20-30% of the script)
148
+
- one or two sentences each
149
+
- acknowledge they happened without belaboring them
121
150
122
151
### write the podcast script
123
152
124
153
write to podcast_script.txt with "Host: ..." and "Cohost: ..." lines.
125
154
126
-
focus on what shipped since the last status-maintenance PR was MERGED (the mergedAt date from task 1).
127
-
that merge date is when the last podcast was generated, so everything after that is new.
155
+
**CHRONOLOGICAL NARRATIVE STRUCTURE** (CRITICAL):
156
+
157
+
the script must tell a coherent story of the time period, structured as:
158
+
159
+
1. **opening** (10 seconds): set the scene - what's the date range, what was the focus?
160
+
161
+
2. **the main story** (60-90 seconds): the biggest thing that shipped
162
+
- what problem did it solve?
163
+
- how was it designed? (explain the architecture accessibly)
164
+
- what's interesting about the implementation?
165
+
- the hosts should have a back-and-forth discussing the design
166
+
167
+
3. **secondary feature** (30-45 seconds, if applicable): another significant change
168
+
- lighter treatment than the main story
169
+
- still explain the "why" not just the "what"
128
170
129
-
use `git log --since="{mergedAt date}" --reverse` to see commits in CHRONOLOGICAL order (oldest first).
171
+
4. **rapid fire** (20-30 seconds): the smaller changes
172
+
- "we also saw..." or "a few other things landed..."
173
+
- quick hits: bug fixes, polish, minor improvements
174
+
- don't dwell, just acknowledge
130
175
131
-
**narrative structure**: tell the story chronologically - start with what shipped first in the time period,
132
-
then work forward to the most recent changes. this creates a natural narrative arc.
133
-
(note: STATUS.md is reverse-chronological, but your script should be chronological)
176
+
5. **closing** (10 seconds): looking ahead or wrapping up
134
177
135
-
- don't re-explain the whole project - listeners already know what player FM is
136
-
- focus on what's new: features that launched, bugs that got fixed, improvements that shipped
137
-
- tone: "here's what changed since last time"
178
+
the narrative should flow like you're telling a friend what happened on the project this week.
179
+
use transitions: "but before that landed...", "meanwhile...", "and then to tie it together..."
138
180
139
181
### tone requirements (CRITICAL)
140
182
141
183
the hosts should sound like two engineers who:
142
-
- are skeptical, amused and somewhat intruiged by the absurdity of building things
184
+
- are skeptical, amused and somewhat intrigued by the absurdity of building things
143
185
- acknowledge problems and limitations honestly
144
186
- don't over-use superlatives ("amazing", "incredible", "exciting")
145
187
- explain technical concepts through analogy, not hypey jargon
188
+
- genuinely find the technical details interesting (not performatively enthusiastic)
146
189
147
190
avoid excessive phrasing:
148
191
- "exciting", "amazing", "incredible", "impressive", "great job"
···
160
203
161
204
### identifying what actually shipped
162
205
163
-
read the commit messages and STATUS.md carefully to understand what changed.
206
+
read the commit messages and PR bodies carefully to understand what changed.
164
207
165
208
- if something is completely NEW (didn't exist before), say it "shipped" or "launched"
166
209
- if something existing got improved or fixed, call it what it is: fixes, improvements, polish