howlisted

# How — Architectural Explanation Explore the codebase to answer "how does X work?" Produce the mental model a senior engineer needs to start working in an unfamiliar subsystem — the architecture, the flow, and the sharp edges. Not annotated source code. Companion to `skills/why/SKILL.md`: `how` answers what the code does and how it works; `why` answers what forces led to its shape. When the user asks about motivation, rejected alternatives, or history, that is `why`'s job. This skill is **read-only**. It writes no files, records no artifacts, and changes no state — in this session and in every subagent it dispatches. Two modes: 1. **Explain** (default) — explore and produce a clear explanation. 2. **Critique** — explain first, then dispatch fresh-context critics to judge the architecture. ## Input `$ARGUMENTS` is the question — a subsystem ("the rate limiter"), a feature flow ("what happens when a user submits the form"), or a placement question ("where should this validation live"). Two resolution paths: - **Given** — parse the target and scope directly from the argument. - **Empty or vague** — infer the target from conversation context: open files, recent edits, what was just discussed. **State your interpretation in one line before exploring** so the user can redirect if you are off. Do not ask first; a stated best guess beats a questionnaire. Choose the mode from the ask: a request for problems, issues, or improvements ("critique the architecture", "w