harness-checklist

Perform a read-only audit. Establish what the harness provides natively before assessing its surrounding environment. Do not count native capabilities as additions or recommend rebuilding them by default. Judge capabilities, not package names. Do not install, remove, edit, enable, or reconfigure anything during the audit.

Establish the audit

1. Ask where the complete harness working set lives. Accept a monorepo, assembly directory, or maintained copy folder containing extensions, skills, context files, tools, profiles, configuration, and user interfaces. If none exists, record the limitation and recommend one. Do not assemble it without a separate request.
2. Reconcile three views: capabilities native to the current harness, the exact user and agent toolkit exposed in this session, and additions present in the working set. Inspect current help, active tools and skills, commands and UI, loaders, settings, and model-visible context. Mark capabilities as native, active from the working set, active from another source, available but inactive, generated, obsolete, or absent. A folder does not prove exposure, while one session does not prove the complete available setup.
3. Run a fresh visible session with the effective setup and one trivial first turn such as Reply only with hi. Record provider-reported prompt input and inspect the session, active tools, instructions, startup messages, and other model-visible surface. When the harness can safely disable optional layers, repeat with the same model, reasoning, working directory, and prompt as a native baseline. Treat the difference as permanent startup overhead, not a quality score.
4. Ask what feels wrong and what the user expected instead. Record the affected workflow.
5. Ask for representative project folders or overlays for each stated kind of work. Do not call a capability missing until checking its work-specific layer. If the base permanently loads one domain's surface, consider a project folder, launch profile, or overlay.
6. Ask what the agent may do silently, report afterward, ask before doing, or hand back. Map this per workflow rather than choosing one autonomy level.
7. Compare that contract with instructions, approvals, tool restrictions, extension behaviour, notifications, and recovery controls. Flag unwanted ceremony and invisible automation.
8. Trace global and scoped context, skills, extension prompts, tool guidance, and templates through their real load paths. Find conflicts, duplication, shadowing, misplaced scope, and double-loaded behaviour.
9. Group extensions, tools, skills, CLIs, scripts, slash commands, and host behaviour by job and audience. Identify one behavioural owner. Prefer a CLI or CLI plus skill when hooks, state, UI, or tool registration add nothing.

For every later check, credit a working capability regardless of whether it is native, configured globally, project-scoped, or exposed only in the current session. Recommend an addition only for a remaining gap.

When a gate requires deeper instruction, tool, extension, cache, or session analysis, load an applicable specialist skill at that gate. Use it only for analysis. Do not implement its remediation procedure during this audit.