showlisted

# Show — make the evidence visible Answer three questions at a glance: 1. What connects to what? 2. What changed? 3. What proves it? Build an evidence view, not a decorative diagram. The view summarizes reality; source files, diffs, and command results remain the ground truth. ## 1. Set the focus Use the user's question and current task context as the input. Do not ask for details that can be discovered from the repository. Narrow broad requests to the smallest boundary that answers the question, and state that boundary. Gather only the relevant evidence: - definitions, callers, consumers, configuration, and ownership; - the current diff or before/after revisions; - verification command, exit code, shortest decisive output, and coverage gaps. Never expose private chain-of-thought. Show observable structure, evidence, and concise conclusions instead. ## 2. Normalize the evidence Reduce what was found to five kinds of information: - **Entities** — files, functions, components, services, states, or commands; - **Relations** — calls, owns, reads, writes, emits, depends on, or verifies; - **Changes** — added, removed, or modified entities and relations; - **Proof** — commands and observations that confirm or refute a claim; - **Gaps** — unknown, inferred, or unverified parts. Label inference as `? inferred`; never draw a guessed edge as fact. ## 3. Choose the smallest useful view Prefer the first form that carries the relationship clearly: | Question | View | |---|-