Why

A skill named in bold or in backticks, or run as /<name>, is the file ../<name>/SKILL.md beside this skill's directory, and a principle named without its prefix is ../principle-<name>/SKILL.md. Read the file and follow it. Most pstack skills are user-only, so your skill tool cannot load them. Every subagent is a Rex worker pane: spawn, wait and close it per ../rex-subagents/SKILL.md, with the defaults in the Subagents section of ../poteto-mode/SKILL.md.

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 line in ~/.config/pstack/pstack-models.md. Pass the entry to subagent spawn --entry as written. When the value is auto or inherit-parent, or the file or the line is missing, run the worker on your own harness and its default model. With no file, say so and suggest /setup-pstack. If a worker's model is rejected, run it on that harness's default model and say so. Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the poteto-mode skill. A worker gets only its brief, so paste each reference file it gets into the brief, or give its absolute path. End the turn after spawning and let the wake-up lines start your next turns.

Every spawn gets --read-only and a plain brief. In Rex that only adds the line "read-only: inspect only, no writes, no git commands" to the brief, so each worker keeps its MCP servers, which the MCP-backed investigators and the synthesizer's citation spot-checks need. A worker sees the MCP servers configured for its own harness, so an MCP investigator runs on your own harness, which has the MCPs you listed. Take its model from the why investigators line only when that entry names your harness.

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, what was just discussed). State your interpretation briefly so the user can redirect if you're off, then proceed.