why
Why
Investigate the motivation and intent behind code. The companion how skill answers what the code does and how it works. why answers what forces led to its shape.
Each spawn below names a role from the pstack profile (written by /setup-pstack, always in your context). Spawn it with the profile's spawn recipe, passing that role's value as the model. A role with no line, or the value inherit, means no model override. If the harness rejects the model, retry with inherit and say so. With no profile in context, follow the fallback in the setup-pstack skill (references/profile-template.md) and tell the user once that /setup-pstack was not run. Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the poteto-mode skill.
Investigators use role: why investigators. The synthesizer uses role: why synthesizer. Both use access: full and run: foreground. Do not use read-only. A read-only subagent may lose MCP tools in some harnesses, and these roles need them. Investigators still shouldn't write anything. The synthesizer still must not write to the repo.
Operating Posture
Operate as a careful, cautious, and precise investigator. Be honest about what you know vs what you're inferring. Read references/epistemics.md for the full confidence framework and phrasing guide. The synthesizer must follow it.
Step 1. Understand the Target and the Question
The target is usually a chunk of code, a pattern, a feature, or a named design decision. The question is usually a design rationale, a tradeoff, a motivating edge case, an external constraint, dead code, or a broad history sweep.
If the target is vague ("why do we do it this way?" with no clear referent), make your best guess from conversation context (open files, recent edits, caret location, what was just discussed). State your interpretation briefly so the user can redirect if you're off, then proceed.