You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
perf: cut the bodies of the most-invoked skills through progressive disclosure - part 2 of 2 #12244
I understand this as part 2 of 2 of #12240, split at intake. Its one done-when item is to measure the after figure the same way as the before figure: skill body bytes, weighted by invocations over a comparable window. That measurement depends on the body cuts in part 1 (#12243) landing first, so I listed #12243 as a blocker. The issue doesn't name the before baseline or the window. The parent issue #12240 should say where they come from.
The work-resolve-issue run that agent-ready started failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock removed and added agent-ready back to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.
The work-resolve-issue lane stopped on this issue (host-only): the run reports the work needs a host run the lane cannot make.
It added host-run and removed agent-ready: an agent run on a host builds it, and it waits on no decision from a person.
In the run's words:
host-only: the after figure weights each skill's body bytes by its invocation count, and the issue's method takes those counts from Skill tool calls in this repository's local Claude Code transcripts on the owner's machine (935 transcript files, 86 main sessions for the before figure). This lane has no access to those transcripts, so it cannot measure the invocations over a comparable window. It also cannot run a byte-count tool here, since no interpreter or wc is allowed. Someone on the host needs to rerun the before figure's method: SKILL.md body bytes with frontmatter stripped at the current origin/main, times Skill invocations over a recent 2-day window, for the six skills in ＃12240.
What the run says it did not do:
The invocation-weighted after figure: it needs the owner's local transcripts and a byte-count run on the host.
Did not check whether part 1 of ＃12240 (the progressive-disclosure cuts) has landed. The clone is shallow and the lane cannot query the tracker.
Host run: the after figure. With invocation counts held fixed, the six bodies load about 19% fewer bytes: 8.79 MB before and 7.15 MB after on this host's counts, and 13.32 MB before and 10.68 MB after on the counts in #12240's table. /source-control:pull-request supplies most of that, and /evals:plugin-eval is larger than it was.
Counts are Skill tool calls in this repository's transcripts (main checkout and worktree project folders, main sessions and subagent files).
Before window 2026-10-31T03:00Z to 2026-11-02T03:00Z: 69 main sessions, 694 subagent files.
After window 2026-11-02T15:30Z to 2026-11-04T15:30Z: 92 main sessions, 518 subagent files. Its start falls before the last cuts merged (perf(discovery): move the research practitioner test to a reference file #12876 at 2026-11-03T18:41Z), and sessions ran whatever plugin version they had installed. So these counts weight main's bytes; they do not show what those sessions actually loaded.
Its before figure does not reproduce in full. Four of its body sizes match within 1 byte, but at b1439e9809 I read 50,149 for pull-request (it lists 32,568) and 38,158 for worktree (it lists 31,533). I did not find why. Its 10.3 MB rests on those two figures, so compare against 13.32 MB, not 10.3 MB. On its own table the after figure would read as a rise.
Its counts do not reproduce either. It lists 161 pull-request calls; I count 109 in the two days before that commit. Its window and host are not stated, so the cause is UNVERIFIED.
Bytes main sessions actually received from Read calls on the pull-request skill's other files, from the tool results:
Window
Skill calls
Reads
Bytes returned
Bytes per call
Before
35
51
1.16 MB
33.2K
After
64
111
2.25 MB
35.1K
So body plus reads per main-session call fell from about 83K to about 71K (-15%): about 12.4K of the 14.3K the body lost stayed saved. reference/monitor.md, where #12739 moved the checklists, was read 4 times in 64 calls. reference/create.md was read 62 times, so nearly every call pays for it.
Done-when
The after figure is measured the same way: body bytes, weighted by invocations over a comparable window.
Closing as completed. Next-largest lever from these reads, for anyone cutting further: reference/create.md. No issue filed: no one has set a target below this figure.
Addendum: #12240's sizes for pull-request (32,568) and worktree (31,533) match no version of either SKILL.md on main's history and no cached source-control release on this host, whether counted stripped, whole or in characters. So that figure's method could not be reproduced. The before and after pair above uses one method on both sides.
Activity
github-actions commentedon Nov 2, 2026
Proposed work class: work-class: read-only
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Knowable
Flags: none
Blocked by: #12243
I understand this as part 2 of 2 of #12240, split at intake. Its one done-when item is to measure the after figure the same way as the before figure: skill body bytes, weighted by invocations over a comparable window. That measurement depends on the body cuts in part 1 (#12243) landing first, so I listed #12243 as a blocker. The issue doesn't name the before baseline or the window. The parent issue #12240 should say where they come from.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Nov 2, 2026
Not admitted to the issue lane yet: blocker #12243 is not closed by a listed human or a merge.
github-actions commentedon Nov 4, 2026
melodic-automation-lanes commentedon Nov 4, 2026
The work-resolve-issue run that
agent-readystarted failed or was cancelled before it reported, or it stopped or the token broker refused it because its workflow files differ from main's. work-unblock removed and addedagent-readyback to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.github-actions commentedon Nov 4, 2026
github-actions commentedon Nov 4, 2026
melodic-automation-lanes commentedon Nov 4, 2026
The work-resolve-issue lane stopped on this issue (
host-only): the run reports the work needs a host run the lane cannot make.It added
host-runand removedagent-ready: an agent run on a host builds it, and it waits on no decision from a person.In the run's words:
What the run says it did not do:
Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41845965231
To hand it back to the lane, remove
host-runand addagent-readyagain.kyle-sexton commentedon Nov 4, 2026
Claim. Lane 6 takes this: one host measurement of the after figure on this host's transcripts, by the method on #12240.
kyle-sexton commentedon Nov 4, 2026
Host run: the after figure. With invocation counts held fixed, the six bodies load about 19% fewer bytes: 8.79 MB before and 7.15 MB after on this host's counts, and 13.32 MB before and 10.68 MB after on the counts in #12240's table.
/source-control:pull-requestsupplies most of that, and/evals:plugin-evalis larger than it was.What ran
b1439e9809(the before commit perf: cut the bodies of the most-invoked skills through progressive disclosure #12240 names) andorigin/mainas of this run.Skilltool calls in this repository's transcripts (main checkout and worktree project folders, main sessions and subagent files).Results
/source-control:pull-request/session-flow:handoff/source-control:worktree/discovery:research/evals:plugin-eval/source-control:commitWhere this differs from #12240
b1439e9809I read 50,149 forpull-request(it lists 32,568) and 38,158 forworktree(it lists 31,533). I did not find why. Its 10.3 MB rests on those two figures, so compare against 13.32 MB, not 10.3 MB. On its own table the after figure would read as a rise.pull-requestcalls; I count 109 in the two days before that commit. Its window and host are not stated, so the cause is UNVERIFIED.What each cut left
worktreeis smaller although its own cut was reverted (revert(source-control): restore the worktree skill's nesting invariant to its body #13095). The bytes came from other changes on main, and perf(source-control): cut the worktree skill body once its suite can detect a loss #13238 tracks the cut.plugin-eval: perf(evals): move the plugin-eval iteration loop to a reference file #12875 removed 20 lines, but fix(evals): count sandbox network denials in run-validity #13005, docs(evals): state the plugin-eval route for each environment #13086, docs(evals): correct stale plugin-eval citations and the env-scrub claim #13098 and fix(evals): stop a no-plugin arm's search for its missing plugin voiding a leg #13216 have since added more.research: perf(discovery): move the research practitioner test to a reference file #12876 changed 5 lines, and the body is 233 bytes smaller.Moved text is mostly not read back
Bytes main sessions actually received from
Readcalls on thepull-requestskill's other files, from the tool results:So body plus reads per main-session call fell from about 83K to about 71K (-15%): about 12.4K of the 14.3K the body lost stayed saved.
reference/monitor.md, where #12739 moved the checklists, was read 4 times in 64 calls.reference/create.mdwas read 62 times, so nearly every call pays for it.Done-when
Closing as completed. Next-largest lever from these reads, for anyone cutting further:
reference/create.md. No issue filed: no one has set a target below this figure.kyle-sexton commentedon Nov 4, 2026
Addendum: #12240's sizes for
pull-request(32,568) andworktree(31,533) match no version of either SKILL.md on main's history and no cached source-control release on this host, whether counted stripped, whole or in characters. So that figure's method could not be reproduced. The before and after pair above uses one method on both sides.