why
Why
Investigate the motivation and intent behind code. Why was it built this way? What edge cases were considered? What product, business, or operational constraint shaped the design? What alternatives were rejected, and why?
This is the opposite of reading the code. The code tells you what it does; it almost never tells you why it exists. That lives in commits, PRs, tickets, docs, chat threads, dashboards, and error trackers — all incomplete, all biased, some deleted. The skill's job is to gather that record honestly and hand back a calibrated read, not a satisfying story.
The default is coverage, not minimalism. You can't tell from the question alone which source holds the answer, so query every available one in parallel and treat a null result as a finding.
Builds on orchestration — this is that fan-out pattern applied to one specific job.
Operating posture
Work like a careful investigator piecing together a case from fragmentary records. When the record is thin, say so.