divydvd/dev-loop
v0.2.1
One session runs the full development loop from one line of input. Core rules and the dev-loop, flow-docs, and infra-review skills, on top of Superpowers.
Changelog
Each entry says what changed, why (the evidence), and how the next weekly review checks that the change helped.
0.2.1 (2026-10-17)
- Screenshots of a UI change in the PR body.
- What: the PR template has a new "Screenshots" section. For a UI change, the
dev-loopskill now does these steps:- Step 6 takes a screenshot of each screen that the device test validates. The screenshots stay in a folder outside the repo.
- Before the PR, step 7 checks each screenshot. The agent does not upload a screenshot that shows personal data or a secret, or a screenshot that it cannot check.
- The section names each screenshot that the agent did not upload, and the reason, but not the data.
- The agent uploads the other screenshots with
github-pr-media. It puts them in an HTML table withwidth="180", because Markdown images in a table show at full size. - A failed upload does not stop the task. The agent writes the reason in the section.
- The agent does not commit the screenshots.
- When a review fix changes a validated screen, the agent fills in the section again.
- The step adds no stop, and
core.mdcdoes not change. - In SmarType, L17 of
smartype-device-testforbids the upload. divydvd/SmarType#323 changes this line.
- Why: before the merge of divydvd/SmarType#303, the owner asked for the device screenshots, and the coordinator added 9 by hand. On 2026-10-17, the owner made the step a standing answer. This entry replaces the "Not changed" line of 0.2.0 about the screenshot step.
- Check: each SmarType PR with a UI change has a "Screenshots" section with images. The owner does not ask for screenshots. No image in a PR shows personal data.
- What: the PR template has a new "Screenshots" section. For a UI change, the
- Tested before release (skill test F, with fresh subagents):
- The UI scenario: the SmarType feature divydvd/SmarType#263 at step 7. The screenshot of the signed-in screen (N1) shows an account name, an email address, and a photo.
- The control scenario: a made-up fix in the Functions code, with no UI change and no device test.
- RED, with the 0.2.0 text: 3 of 3 UI runs put no screenshot in the PR. Each run quoted
smartype-device-test: "Never commit or upload them". - GREEN round 1 (the first draft and the new L17): 7 of 7 runs pass (5 UI, 2 control). Round 2 (the second draft): 3 of 3 runs pass (2 UI, 1 control). Each of the 7 UI runs did these steps:
- It added S4, a pass at font scale 1.5, because
smartype-device-testasks for it. The scenario had only S1–S3 and N1. - It uploaded S1–S4 with
github-pr-mediabefore the PR, and put them in the table withwidth="180". - It did not upload N1, and it named the type of data.
- It committed no screenshot, uploaded no log, and asked the owner nothing new.
- It added S4, a pass at font scale 1.5, because
- The 3 control runs wrote "none: ", uploaded nothing, and ran no device test.
- Round 1 found 2 unclear points: what to do with the example table for a change without UI, and whether the upload needs a PR. The second draft answers both. The 3 runs of round 2 did not ask about them again.
- An independent review of the branch found 2 Important gaps. The text had no safe default for a screenshot that the agent cannot check, or for a secret. The screenshots could become old after a review fix. The final text fixes both.
- GREEN round 3 (the final text): 2 of 2 runs pass. In total, 12 of 12 GREEN runs pass.
- g8: the agent did not upload a screenshot that it could not check. A notification banner was on it, and the agent could not read the text. An upload failed 2 times. The agent wrote the reason in the section, and it opened the PR.
- g9: a review fix changed a validated screen. The agent took the screenshots of the new device test, checked them, and uploaded them again. It updated the commits in the Evidence table.
- The merge order (one run for each state). With only the new dev-loop text, or with only the new L17, the agent uploaded the 4 safe screenshots. It left out N1, uploaded no log, and did not stop. With only the new L17, the images showed at full size, and the agent had no safe default for a screenshot that it cannot check.
- The install loads the rule and the 3 skills.
0.2.0 (2026-10-15)
The first weekly review. It covers the setup week and the 2-task trial in divydvd/SmarType: PR #296 (bug #287) and PR #303 (feature #263). The PR of this version has the measures table and the changes that the review did not make, with the reasons.
- Rule 7: inline execution for small plans, and a review for each task in a risky area.
- What: core rule 7 and
dev-loopsteps 2 and 3. Useexecuting-plansfor 6 tasks or fewer, also with tasks in a risky area. Use subagent-driven development only for bigger plans. After each task in a risky area, get one independent review. If a review subagent fails, start it again once. If it fails again, write the task in the new "Not reviewed" line of the PR template. Do not put your own review in its place. - Why: in PR #303, 1 of 4 plan tasks touched a risky area (
AuthScreen.kt), so the old rule 7 sent the whole plan to subagent-driven development. The session started 10 subagents (claude-opus-5.5, about 41M tokens), also for a docs-only task. It made 712 model calls and cost about 7.3e12 nanoAIU, 4.5 times PR #296 (inline, 278 model calls, 1.62e12 nanoAIU). The review subagent of the risky task failed after 2 h 34 min, and the main agent then reviewed that task itself. - Check: the mean model calls for each merged PR go down from 495 (the trial). Each task in a risky area has a review result or a "Not reviewed" line. No session puts its own review in the place of a failed review.
- What: core rule 7 and
- A size limit for
AGENTS.md, and a measure of the always-loaded text.- What: the profile template and the README say: keep
AGENTS.mdat 5.5 KB or less, and put long references in a project skill or indocs/.infra-reviewmeasures the always-loaded text. The target is 15 KB or less. - Why: each trial session loaded about 27 KB of text, and the target was about 15 KB: the SmarType
AGENTS.md18.2 KB, the core rules 4.1 KB, the owner preferences 2.0 KB, and the Superpowers start text 3.2 KB. Nothing limited the size of the profile. With the 0.2.0 core rules (4.3 KB), 15 − 4.3 − 2.0 − 3.2 = 5.5 KB is left forAGENTS.md. - Check: after the SmarType PR of this review, the always-loaded text of a SmarType session is 15 KB or less. The safety rules for billing, entitlements, and managed AI usage stay in
AGENTS.md.
- What: the profile template and the README say: keep
- Keep the context small, and measure the model calls.
- What: a new section in
dev-loop. Find code with a search first. Read about 150 lines or fewer in each read, also withcatorsed. Do not read a whole file of more than about 300 lines. Write the facts that you need again in the plan or the ledger. After a compaction, continue from them, and read again only the lines that the next step needs and the notes do not give.infra-reviewmeasures the mean model calls for each merged PR. - Why: most of the context was file reads, and most file reads read a file again. Here, "characters" are the tool output that the model read (
result.contentinevents.jsonl), and a file read is aviewor acat,sed,head, orawkof a file.- The PR #296 session read 450K characters. File reads were 61% of them, and 43% of the file-read characters read a file again. It compacted 5 times.
- The PR #303 session read 2.35M characters (main agent 0.96M, subagents 1.39M). File reads were 71%, and 78% of the file-read characters read a file again:
Routes.kt34 times,HomeScreen.kt27 times, andAuthScreen.kt17 times. Reads of more than 8,000 characters (about 200 lines) were 45% of the file-read characters. The session compacted 17 times. - The plan phase of PR #303 read 514K characters before the first subagent, compacted 4 times, and cost about 1.03e12 nanoAIU.
- Check: each task session compacts fewer times than in the trial (5 for a bug, 17 for a feature). The share of file-read characters that read a file again goes down from 43% (bug) and 78% (feature).
- What: a new section in
- Not changed: the screenshot step for UI changes had 1 request (PR #303), about 12 minutes of rework, and no bad merge or lost hour. The review adds it at the second request, or when the owner asks for it. The trial median PR size was 322 changed lines of code, which meets the target of 400 or fewer.
- Tested before release (Copilot CLI 1.0.97, Superpowers 7.0.0, fresh subagents that read the 0.1.0 text or the 0.2.0 text, and a temporary Copilot home):
- Rule 7: with the #263 plan (4 tasks, Task 3 in
app/auth), 5 of 5 runs choseexecuting-plansand 1 review for Task 3. The old text has no test run: the PR #303 session followed it. - A failed review: the review subagent of the risky Task 3 fails. With the old text, 3 of 3 runs skipped the review of that task ("the final review covers it"). With the new text, 5 of 5 runs started it again once, and then wrote the "Not reviewed" line.
- Reading: collect the plan facts from
HomeScreen.kt(535 lines) andRoutes.kt(557 lines). All 6 runs found the same facts. With the old text, 3 of 3 runs read each file in parts of about 270 lines, read parts again withcatorsed, and did not search first. With the new text, 3 of 3 runs searched first and made no read of more than 150 lines. The file reads went down from a mean of 77.7K to 21.2K characters, and all tool output from 95.4K to 62.3K characters. - Reading after a compaction (after the PR review): the self-review must check 3 callers, and the ledger does not have their code. All 6 runs searched first, read only the callers, and kept each read at 150 lines or fewer. With the first draft of this section ("Read a file again only for the lines that you will change"), 3 of 3 runs said that the sentence forbids the check, and 1 run asked the owner to decide. With the new text, 0 of 3 runs found a conflict.
- The install loads the new rule 7 and the 3 skills.
- Rule 7: with the #263 plan (4 tasks, Task 3 in
0.1.0 (2026-10-13)
- What: the first version. The core rules, the
dev-loop,flow-docs, andinfra-reviewskills, the templates, and the check script. - Why: the owner repeated the same basic instructions in many sessions. Kickoffs were about 4.5 KB, and the median PR changed 687 lines.
- Check: a trial on 1 bug and 1 feature in SmarType. Targets: one-line kickoffs, no repeated basic instructions, 3 or fewer owner messages before the PR, and evidence at the head commit.
- Tested before release (Copilot CLI 1.0.97, Superpowers 7.0.0, a temporary Copilot home): the check script finds 5 planted faults. The install loads the rule and the 3 skills. The repo setting turns on both plugins only in a trusted folder. A typo takes the trivial route. A bug gets a failing test before the fix. A small feature stops for one design question, with the recommended choice first. The first feature test found that the agent skipped the design stop and the self-review for a small feature, so rules 3 and 5 and the skill now say that small changes do not skip them.