Skills became part of the engineering system

In the previous post I wrote about artifacts, plans and persistent memory. The next step was making the recurring working patterns reusable for agents too.

At first I thought of skills as shortcuts: a better prompt that saves a few minutes. That was not enough. The useful version is a small, repository-owned operating procedure: when it applies, what evidence it needs, what it must not assume, and what a finished result looks like. It gives an agent enough structure to start safely in a complicated area without rediscovering the method every time.

This became especially important in PeakTrace, where DSP, native audio capture, rendering and macOS diagnostics can easily produce a plausible but wrong conclusion.

The skills set we assembled

The set is still small and intentionally practical.

• Session replay turns a complete captured audio session into fixed input for debugging, tests, visual checks and performance comparisons. It keeps the meaningful timing and stream context that a synthetic sine wave cannot always reproduce.
• Live test is for bounded, native verification: real audio capture, runtime telemetry, lifecycle checks and a defined observation. It forces the agent to state what would count as success before opening the application.
• App screenshot provides visual evidence from the actual native window. A successful screenshot command is not accepted as visual proof until the image itself is inspected.
• Perf test selects the smallest suitable performance profile and diagnostic intensity. It keeps normal health checks separate from the heavier system and GPU investigations that can influence the system being measured.
• Code review gives changes an independent correctness, performance, allocation and maintainability pass before they are considered done.
• Concilium is for decisions that deserve more than one model's first answer. It organizes independent proposals, peer review and a documented selection process.

None of these skills replaces engineering judgement. They make the next reasonable action explicit, preserve the evidence, and prevent a useful investigation from becoming another context-dependent conversation.

Replay made oscilloscope and pitch work discussable

Oscilloscope phase sync and pitch tracking were a good test for this approach. Synthetic signals are valuable, but they do not always carry the awkward timing, polarity changes and musical content that create a real visual failure.

We added capture and replay around complete recorded sessions, then used the replay skill to treat them as immutable, validated input. A candidate can now run through the normal audio path against the same material that exposed the issue. The result can be inspected in a targeted test, in runtime diagnostics, and when needed in the live application.

That changed the loop from “it seems better during this playback” into something much more useful: state the hypothesis, replay the same material, inspect the specific failure signal, and keep or reject the change. It was important for stabilising the pitch-to-oscilloscope hand-off, where a local improvement can otherwise hide a discontinuity somewhere else in the track.

Spectrum taught us to separate cadences

Spectrum had a different problem. The UI could repaint quickly while the analyzer legitimately had no new spectrum to show. Depending on the audio delivery path, that could create an uneven visual rhythm which looked like a renderer problem even when the renderer was doing its job.

The investigation used the performance and runtime-evidence skills to distinguish input delivery, analysis publication and UI repaint cadence. That let us improve the spectrum update policy without pretending that every repaint contains new audio analysis.

The useful lesson was simple: a visual should not imply that its data is new just because the frame was drawn.

Data Bus and frame clock: making freshness explicit

The same lesson grew into the Analysis Data Bus and a global frame clock. They give the data path and the presentation path separate, explicit responsibilities.

DSP settles a result for every enabled visual, together with enough provenance to say whether the result is fresh, held or unavailable. The frame clock owns presentation cadence, while audio continues to arrive at its own natural cadence. The UI therefore has a meaningful answer to “what am I drawing, and why is it not new?” rather than only a non-empty value.

This makes logic-to-visual desync observable instead of mysterious. It also lets components avoid treating unchanged data as fresh work, which gave us a far cleaner way to control refresh behaviour and reduce wasteful rendering cycles without inventing audio data that does not exist.

Concilium for decisions that should not be a hunch

For a complex architectural question, one strong model response is often not enough. Concilium gives GPT, Claude and Grok the same evidence, but complementary roles. Each agent writes an independent proposal, then cross-reviews the other proposals against a small decision matrix with defined metrics and scoring anchors.

The design matters here. A proposer does not vote for itself. Hard constraints are gates, not weighted preferences. Missing evidence stays missing evidence. And a “do not build this now” outcome is allowed to win when the measured benefit is too small or the risk is too high.

This is much healthier than asking several models for opinions and averaging their confidence. It leaves a decision record: what was observed, what was inferred, why the selected direction won, and what measurement would be needed to reopen the question.

I still see these skills as evolving engineering material, not a finished framework. But they already make agent work more repeatable, more critical, and much easier to continue after a session ends.