Measure usage and pick the core

The data decides what stays eager.

First time here? Paste the Context Pack first so the AI understands your project - open it from the header above.

Prompt Capsule

Analyze tool usage to define the core set. From transcript logs, compute per-tool: call frequency across sessions, task-type coverage (which task categories touch it), and first-call timing (tools needed in early turns favor eager loading). Also measure the token cost of each tool's definition. Core-set criteria: high frequency OR early-turn necessity OR safety-critical (permission gates should not be deferred). Everything else defers. Deliver: the ranked usage table, the core list (aim for the smallest set covering ~90% of calls), and the projected context savings from deferring the rest.

Paste into EmergentFull Build: complete implementation prompt with explicit requirements

Quick is short. Full Build is recommended for most steps. Strict forces real logic when the AI keeps faking output.

Actual change check

Expected after this step

A data-backed core set with projected savings.

Should NOT happen

An existing feature broke
A button only logs to console
Data disappears after refresh
Errors fail silently with no visible state

This is what should exist before you continue. If reality does not match, do not move on.

Your notes for this step

Track what changed, failed, or needs follow-up. Notes export with the flow.

Pass the Verify Gate to complete this step

Verify before continuing

Do not move on until every check is true. The complete button stays locked until then.

Frequency and timing measured from real logsSafety-critical tools kept eagerSavings projection computed

Do not continue if…

! Deferring a tool the model needs but never discovers, silently degrading capability
! A catalog so verbose it costs as much as the definitions it replaced
! Cache-hostile loading that invalidates the prompt prefix every registration
! No measurement, so the 'optimization' is faith-based

If the AI messes this up

Use this when:

- it only made visual forms or placeholder UI
- buttons do nothing or only log to console
- data is not persisted - state disappears on refresh
- something that worked before is now broken

Use this when the AI fakes progress or breaks the feature. It forces a real fix.

No usage logs exist. Instrument tool-call logging now and run a week of normal usage first - core-set guesses without data produce exactly the discovery failures this flow exists to avoid.