model a direct-use skill for inquiry cycle audit and LLM usage analysis

[ccisnedev]

Problem

Inquiry now has reusable direct-use skills such as kritik, legion, and research, but it still lacks a first-class skill for auditing a completed Inquiry cycle itself.

The current audit of cycle #165 required an ad hoc mix of:

• bounded-corpus reasoning
• transcript mining
• debug-log parsing
• git / gh timeline reconstruction
• manual comparison between problem scale and LLM/tool consumption

That work is useful, but today it is not modeled as a reusable protocol.

Goal

Model a new skill analogous to kritik, legion, or research whose purpose is to audit an Inquiry cycle as an empirical object.

This skill should be usable in at least one of these modes:

1. as a direct-use analysis skill invoked by the user after a cycle
2. as an optional EVOLUTION-time protocol that DARWIN or the EVOLUTION state can consume
3. as an analysis tool focused on LLM/tool usage, cost shape, and process overhead

Why this matters

A completed Inquiry cycle already leaves a rich corpus:

• cleanroom artifacts
• git / PR history
• FSM state evidence
• transcript logs
• debug logs with tool and LLM request metadata
• release / version signals

Inquiry should be able to turn that corpus into a disciplined, repeatable audit instead of depending on one-off manual investigation.

Desired capability

The skill should help answer questions such as:

• what problem was actually solved?
• how large was the diff and how broad was the touched surface?
• how much of the work was runtime change versus docs/tests/process artifacts?
• how many tool calls were used?
• how much wall-clock time was consumed?
• how many LLM requests and tokens were consumed?
• how much of token usage was cached versus uncached?
• how much work came from subagents versus the top-level agent?
• is the cycle proportionate to the size/complexity of the problem?
• what deviations, drifts, or forensic gaps remain after completion?

Suggested scope

The skill does not need to decide absolute truth or cost efficiency in the abstract. It should instead:

• define a bounded audit corpus
• extract measurable cycle facts
• compute normalized ratios
• compare resource usage against problem scale
• separate facts, inferences, and undecidable points
• persist one durable report

Possible output contract

One acceptable direction would be a report that includes:

• corpus definition
• cycle chronology
• problem-scale metrics
• tool-volume metrics
• LLM-volume metrics
• top-level vs subagent split
• cached vs uncached token split
• process-overhead share
• summary judgment about proportionality
• methodological limitations

A second optional artifact could be a machine-readable metrics file for future empirical research.

Acceptance direction

• A new direct-use skill exists for cycle audit / usage analysis.
• The skill can consume a bounded corpus made of transcript, debug logs, git history, PR metadata, and cleanroom artifacts.
• It can quantify both top-level and all-logs usage, including subagent contributions.
• It distinguishes cached from uncached token usage.
• It compares consumption against problem-scale metrics such as changed files and churn.
• It persists one durable markdown report.
• Its protocol states explicit inferential limits when logs or traces are incomplete.

Naming

Open question: whether this should be framed as a neutral audit skill, a retrospective skill, or a telemetry/usage-analysis skill.

Possible candidates:

• retrospect
• cycle-audit
• telemetry-audit
• usage-audit

The important part is the protocol, not the final name.