@zenspc/pi-pstack 0.1.0

package/skills/figure-it-out/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: figure-it-out
+description: "Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions via show-me-your-work. Use for /skill:figure-it-out, 'figure it out', a large migration, or when no narrower playbook applies."
+---
+
+# Figure it out
+
+When the task matches no playbook, design one. The deliverable before any code is the workflow itself: a sequence of phases that scales rigor to the task, runs the scientific method, and leaves a decision trail a human can audit after stepping away. Bias toward more rigor. The cost of building the wrong thing dwarfs the cost of being careful.
+
+Don't reinvent a playbook you already have. A focused single-unit task that matches Bug fix, Perf, Feature, Visual parity, Eval, or Multi-phase plan routes there. But a large or cross-cutting version of one (a migration across many call sites, an ambitious multi-part change), or work the user reviews after stepping away, belongs here even though a single-unit version would be a Feature. The rigor and the audit trail are the point.
+
+## Start
+
+Open a todolist whose first item is to read the Principles section of the **poteto-mode** skill. Then add the phases below as todos.
+
+## Phase A: Frame
+
+Ground first, then commit. Don't start the run until you can state:
+
+- The definition of done as a falsifiable predicate (the **prove-it-works** principle skill). "Done well" has to be checkable.
+- Scope, quantified: rough units and effort, plus the blockers grounding surfaced. Raise them before spending hours, not after fifty doomed commits.
+- The rigor level, biased high. One-way doors and high blast radius get more; reversible low-stakes steps get less. Rigor is gates and artifacts, not "try harder".
+
+Present the framing and tradeoffs before committing to a long run. Reversible work proceeds (the **never-block-on-the-human** principle skill), but a multi-hour run earns one checkpoint.
+
+## Phase B: Design the workflow
+
+Decompose into atomic, independently-landable units. Sequence riskiest-unknown-first so option value stays high. Scaffold and verification come before features (the **foundational-thinking** principle skill).
+
+- Build the verification harness before the work, with the baseline captured from the pre-change state, so the check reads as "old value vs new value".
+- For one-way-door design decisions, run the **architect** skill (it runs **arena**) with diverse, isolated, opinionated candidates and a read-only judge on a different model family. Skip it for mechanical work whose shape is already concrete. A second arena over a settled design is over-engineering (the **laziness-protocol** principle skill).
+- Decide what fans out. Parallelize only across genuine seams, and give each worker its own worktree or branch (the **separate-before-serializing-shared-state** principle skill). Don't over-fan.
+- Write the designed phase list down. That list is what the human reviews.
+
+Then put the design into motion. Add its steps to the todolist as concrete items, after the Phase C entry and before Phase D. Run each under the Phase C loop discipline, and weave the Phase D log through them, a row as each step lands, rather than saving the whole trail for the end.
+
+## Phase C: Run the loop
+
+Each unit is an experiment: state the hypothesis, make the smallest change, measure against the predicate on the real artifact, keep it if it advanced, revert it if it didn't.
+Apply the **sequence-verifiable-units** principle skill, verifying each unit before starting the next instead of batching checks at the end.
+
+- Verify by inspecting the artifact, never a self-report. When something passes too easily, suspect the observation method before the system. A blank screenshot passes a lazy gate.
+- Pair delegated work with a judge and audit the delegates' artifacts yourself before trusting them. If a worker games the gate, reset and harden the contract. If the gate itself is wrong, fix the gate in its own change rather than routing around it.
+- A verdict is VERIFIED, NOT VERIFIED, or INCONCLUSIVE. Inconclusive is not a pass. Don't hide a negative.
+
+## Phase D: Keep the audit trail
+
+Log the run via the **show-me-your-work** skill, one canonical TSV with a row per decision and per unit, evidence as links. figure-it-out's work is usually ambitious enough to commit the trail so the reviewer can read it in the PR; commit it when confidence has to be shown. Prefer evidence produced by committed scripts so a reviewer can re-run it. The trail plus the diff is what lets the human come back and trust the work.
+
+## Phase E: Verify and hand back
+
+Check the whole against the Phase A predicate on the real product, not just the harness. Encode any recurring correction as a gate, a lint rule, a check, or a script, so the win can't silently regress (the **encode-lessons-in-structure** principle skill).
+
+**Reply:** the playbook you designed, the rigor level and why, the decision-trail path, what's verified against the predicate, and what's still open.

package/skills/how/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: how
+description: "Use for \"how does X work\", code walkthroughs before changing something, and placement / ownership / layering questions (\"where should this live\", \"which package owns this\", \"is this the right layer\"). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique architecture. Use why for motivation."
+---
+
+# How
+
+Explore the codebase to answer "how does X work?" questions. Produce clear architectural explanations at the level of a senior engineer onboarding onto a subsystem. Enough to build a working mental model, not annotated source code.
+
+Two modes:
+
+1. **Explain** (default). Explore the codebase and produce a clear explanation
+2. **Critique.** Explain first, then spawn multiple models to independently identify architectural issues
+
+## Explain Mode
+
+### Step 1. Understand the Question and Assess Complexity
+
+Parse what the user is asking about:
+
+- "How does the rate limiter work?", a subsystem
+- "How do we handle billing for on-demand usage?", a feature flow
+- "How is the auth service structured?", an architectural overview
+- "Walk me through what happens when a user submits a form", a runtime trace
+
+Identify the scope. If ambiguous, state your best-guess interpretation before exploring. Don't ask. Let the user redirect if you're off.
+
+**Assess complexity to decide the approach:**
+
+- **Simple** (a single module, a small utility, a narrow question like "how does function X work"): skip explorer agents; the explainer explores and explains in a single pass. Go to Step 2b.
+- **Complex** (a subsystem spanning multiple files/services, a cross-cutting feature, a full architectural overview): spawn parallel explorer agents first, then hand off to the explainer. Go to Step 2a.
+
+When in doubt, lean simple. You can always spawn explorers if the explainer hits a wall.
+
+### Step 2a. Explore (complex questions only)
+
+Decompose the question into 2-4 parallel exploration angles, each a distinct slice of the subsystem so explorers don't duplicate work. Example split for "how does the rate limiter work?":
+
+- Explorer 1: data model and state management
+- Explorer 2: request path and enforcement
+- Explorer 3: configuration and metrics infrastructure
+
+The right decomposition depends on the question. Use your judgment. Narrow questions: 2 explorers is fine. Broad subsystems: up to 4.
+
+Spawn all explorers in a single message:
+
+- agent: `worker`
+- `model`: your configured how-explorer model (default `inherit-parent`)
+- tools: read-only (`read, grep, find, ls, bash`)
+
+Each explorer gets the same base prompt from `references/explorer-prompt.md` plus a specific exploration angle naming its slice. Each explorer should:
+- Start broad: Glob for relevant directories, Grep for key types/interfaces/class names
+- Follow the thread: from an entry point, trace the call chain (callers, callees, data flow, type definitions)
+- Read the actual code, don't guess from file names
+- Stop when it can describe the full path from input to output (or trigger to effect) without hand-waving any step
+- Note things that are surprising, non-obvious, or that a newcomer would get wrong
+
+Each explorer returns structured findings: components found, flow traced, files read, anything non-obvious. Overlap between explorers is fine; the explainer reconciles.
+
+Then proceed to Step 3.
+
+### Step 2b. Direct Explain (simple questions)
+
+Spawn a single subagent that explores and explains in one pass:
+
+- agent: `worker`
+- `model`: your configured how-explainer model (default `inherit-parent`)
+- tools: read-only (`read, grep, find, ls, bash`)
+
+The agent does its own exploration (Glob, Grep, Read) and writes the explanation directly. Read `references/explainer-prompt.md` for the communication style and output format. Same structure, just no explorer findings as input.
+
+Proceed to Step 4.
+
+### Step 3. Synthesize (complex questions only)
+
+Once all explorers return, spawn a single subagent to synthesize their findings into one coherent explanation:
+
+- agent: `worker`
+- `model`: your configured how-explainer model (default `inherit-parent`)
+- tools: read-only (`read, grep, find, ls, bash`)
+
+The explainer gets all explorers' findings and writes the human-facing explanation (output format below). Read `references/explainer-prompt.md` for the full prompt template. The explainer reconciles overlapping findings, resolves contradictions, and weaves the slices into a unified picture.
+
+### Step 4. Present
+
+Present the explainer's output to the user. You may lightly edit for clarity or add context from the conversation, but don't substantially rewrite. The explainer's communication is the product.
+
+### Output Format
+
+Follow this structure, adapted to the question. Not every section is needed for every question.
+
+**Overview.** 1-2 paragraphs. What it is, what it does, why it exists. Enough to decide whether to keep reading.
+
+**Key Concepts.** The important types, services, or abstractions. Brief definition of each. Not exhaustive, just the ones needed to understand the rest.
+
+**How It Works.** The core of the explanation. Walk through the flow: what triggers it, what happens step by step, where data goes, the decision points. Prose, not pseudocode. Reference specific files and functions so the reader can go look, but don't dump code blocks unless a snippet is genuinely necessary.
+
+**Where Things Live.** A brief map of the relevant files/directories. Not every file, just the ones needed to start working in this area.
+
+**Gotchas.** Non-obvious or surprising things that would trip someone up. Historical context that explains why something looks weird. Known sharp edges.
+
+## Critique Mode
+
+Triggered when the user asks for architectural issues, problems, or improvements, not just understanding.
+
+### Step 1. Explain First
+
+Run the full explain flow above (Steps 1-4). You must understand the architecture before critiquing it.
+
+### Step 2. Spawn Critics
+
+After the explanation is complete, spawn one architectural critic per model in the configured `how critics` list when present, all in a single message. Otherwise spawn one critic on the parent model. To compare models, run `/setup-pstack` and set a list.
+
+For each critic:
+- agent: `worker`
+- `model`: one model from the configured `how critics` list, or omit `model` when there is no list (parent model). These are minimum reasoning levels. The lead should escalate any model when the architecture warrants deeper analysis.
+- tools: read-only (`read, grep, find, ls, bash`)
+
+Read `references/critic-prompt.md` for the prompt template. Each critic gets:
+1. The explanation from Step 1 (so they don't re-explore)
+2. The relevant file paths (so they can read the actual code)
+3. The architectural critique rubric from `references/critique-rubric.md`
+
+### Step 3. Lead Judgment
+
+Same framework as the interrogate skill. You're a pragmatic lead, not an aggregator.
+
+Categorize findings:
+- **Act on.** Architectural problems worth fixing now
+- **Consider.** Real concerns, but the cost/benefit is unclear
+- **Noted.** Valid observations, low priority
+- **Dismissed.** Wrong, missing context, or style preference
+
+Present the explanation first (from Step 1), then the critique verdict below it. The explanation should stand on its own; someone who just wants to understand the system shouldn't wade through critique.

package/skills/how/references/critic-prompt.md

@@ -0,0 +1,59 @@
+# Critic Prompt Template
+
+Build each critic subagent's prompt from this template. Fill in the placeholders.
+
+---
+
+You are reviewing the architecture of a codebase subsystem. An explanation of how it works has already been written. Read it to orient yourself, then read the actual code to form your own judgment.
+
+## Architectural Explanation
+
+{EXPLANATION}
+
+## Relevant Files
+
+{FILE_PATHS}
+
+## Critique Rubric
+
+{CRITIQUE_RUBRIC_CONTENTS}
+
+## Instructions
+
+Read the files listed above. Use the explanation as a map, but form your own opinions from the code itself. The explanation might miss things or frame them charitably.
+
+Find architectural problems, not line-level bugs or style issues. Ask whether this subsystem is built well for what it needs to do and how it will need to evolve.
+
+For each finding:
+
+1. **Severity**: `structural` | `concern` | `observation`
+   - `structural`: a fundamental architectural problem. Wrong abstraction boundary, broken data model, coupling that will block future work
+   - `concern`: a real issue that makes the system harder to work with or reason about, but not fundamentally broken
+   - `observation`: worth noting. A tradeoff that might not age well, a pattern inconsistent with the rest of the codebase, technical debt
+2. **Finding**: the architectural issue. Be specific. Name the components, the boundary, the coupling.
+3. **Evidence**: concrete code that demonstrates the problem. Don't just assert that "this is too coupled". Show the dependency chain.
+4. **Impact**: what the issue costs. Harder to test? Harder to change? Performance cliff at scale? Be concrete about the consequence.
+
+## What to Avoid
+
+- Line-level code review (not your job here)
+- Suggesting rewrites without demonstrating a problem with the current approach
+- "This could use more abstraction" without showing what the abstraction would actually solve
+- Flagging intentional tradeoffs with clear benefits as issues
+
+If the architecture is sound, say so. An empty critique is a valid outcome.
+
+## Output
+
+```
+## Findings
+
+### 1. [Severity] Short title
+**Components**: Which parts of the system are involved
+**Finding**: What's wrong architecturally
+**Evidence**: Concrete code references
+**Impact**: What this costs in practice
+
+### 2. [Severity] Short title
+...
+```

package/skills/how/references/critique-rubric.md

@@ -0,0 +1,58 @@
+# Architectural Critique Rubric
+
+Review through whichever of these lenses are relevant. Not every lens applies to every subsystem.
+
+## Abstraction Fit
+
+Are the abstractions pulling their weight?
+
+- Does each abstraction represent a real concept, or is it an indirection layer "in case we need it"?
+- Are the boundaries in the right place? Do they separate things that change independently?
+- Is there accidental coupling where components share implementation details they shouldn't need to know about?
+- Is business logic entangled with framework wiring, or cleanly separated?
+
+Over-abstraction is as much a problem as under-abstraction. A flat, simple design is fine when the domain is simple.
+
+## Data Model
+
+Do the data structures fit the actual usage patterns?
+
+- Are the data models designed for how data is actually accessed, or for how it was conceptually modeled?
+- Are there impedance mismatches, places where code constantly reshapes data because the model doesn't match the access pattern?
+- Are types honest? Do they represent what data actually looks like at runtime, or claim more structure than exists?
+
+## Boundary Discipline
+
+Are system boundaries clean and well-placed?
+
+- Is validation concentrated at entry points, or scattered through internal code?
+- Are errors handled at boundaries and propagated cleanly, or caught and re-thrown at every layer?
+- Does data cross boundaries in well-typed shapes, or as bags of optional fields?
+- Could this subsystem be tested in isolation, or does it require the entire system to be running?
+
+## Evolution Readiness
+
+How well will this architecture handle likely changes?
+
+- If the most probable next requirement landed tomorrow, how much would change? "One file" or "everything"?
+- Are there hardcoded assumptions that would need to be relaxed?
+- Is the design bolted-on (integrated as an afterthought) or integrated (looks like it was always part of the plan)?
+- Are legacy paths preserved for compatibility that no one depends on?
+
+Don't penalize for not handling hypothetical changes. Focus on changes plausible given the codebase's trajectory.
+
+## Complexity vs. Value
+
+Is the complexity budget spent wisely?
+
+- Is complexity concentrated in the parts that need it (core logic, tricky invariants) or in accidental places (boilerplate, unnecessary indirection, configuration)?
+- Are there simpler ways to achieve the same behavior?
+- Does every component earn its existence, or are there vestigial pieces from an earlier design?
+
+## Consistency
+
+Does this subsystem follow the patterns established elsewhere in the codebase?
+
+- Are similar problems solved the same way here as elsewhere, or does this area invent its own patterns?
+- If the patterns differ, is there a good reason, or did it just evolve independently?
+- Inconsistency isn't automatically bad. But unexplained inconsistency is a maintenance burden.

package/skills/how/references/explainer-prompt.md

@@ -0,0 +1,55 @@
+# Explainer Prompt Template
+
+Build the explainer subagent's prompt from this template. Fill in the placeholders.
+
+---
+
+You are writing an architectural explanation for a senior engineer. Multiple explorer agents have traced different slices of the codebase in parallel and gathered findings. Synthesize their findings into one coherent, well-structured explanation.
+
+## Original Question
+
+> {QUESTION}
+
+## Explorer Findings
+
+{EXPLORER_FINDINGS_ALL}
+
+## Instructions
+
+The explorers each investigated a different angle of the same subsystem. Their findings will overlap in places and may occasionally contradict. Reconcile them. Merge overlapping descriptions, resolve contradictions by checking the code yourself, and weave the separate slices into a unified picture.
+
+Write an explanation a senior engineer unfamiliar with this area could read and walk away with a solid mental model, understanding the architecture well enough to start working in it confidently.
+
+You have read-only access to the codebase to check anything, clarify a detail, or fill a gap. Use Read, Grep, and Glob as needed. The explorers did the heavy lifting, so you shouldn't need to re-explore from scratch.
+
+## Output Format
+
+Use this structure, adapted to what makes sense for the question. Not every section is needed for every question.
+
+### Overview
+1-2 paragraphs. What is this thing, what does it do, why does it exist. Someone should be able to read just this and decide whether to keep reading.
+
+### Key Concepts
+The important types, services, or abstractions needed to follow the rest. Brief definitions, not exhaustive.
+
+### How It Works
+The core of the explanation, and the longest section. Walk through the flow: what triggers it, what happens step by step, where data goes, what the decision points are.
+
+Use prose, not pseudocode. Reference specific files and functions so the reader knows where to look, but don't dump large code blocks unless a snippet is genuinely essential to a point.
+
+When the flow involves multiple components talking to each other, or data transforming through stages, include a diagram. Use mermaid (```mermaid) for structured flows (sequence diagrams, flowcharts, component graphs) or ASCII art for simpler relationships where mermaid would be overkill. Use your judgment. A diagram should clarify, not decorate. If prose covers the flow, skip the diagram.
+
+### Where Things Live
+A brief file/directory map. Just the ones someone would need to start working here.
+
+### Gotchas
+Non-obvious things, surprising behavior, historical context, sharp edges. Skip this section if there's nothing worth calling out.
+
+## Communication Style
+
+- Use concrete language, not abstractions-about-abstractions
+- Say "the `UserService` calls `AuthClient.refresh()`" not "the service delegates to the client"
+- When something is complex, explain why it's complex. Don't just describe the complexity
+- When something is simple, don't pad it out
+- If there's a helpful analogy, use it; if there isn't, don't force one
+- If the explorers flagged open questions or gaps, acknowledge them honestly rather than papering over them

package/skills/how/references/explorer-prompt.md

@@ -0,0 +1,52 @@
+# Explorer Prompt Template
+
+Build each explorer subagent's prompt from this template. Fill in the placeholders.
+
+---
+
+You are exploring a codebase to understand how something works. Gather facts: trace code paths, read implementations, map components. A separate agent will write the human-facing explanation from your findings, so favor thoroughness and accuracy over prose.
+
+Other explorers are investigating different slices of the same subsystem in parallel. Don't try to cover everything. Focus on your assigned angle and go deep.
+
+## Question
+
+> {QUESTION}
+
+## Your Exploration Angle
+
+{EXPLORATION_ANGLE}
+
+## Exploration Instructions
+
+Start by finding the relevant code. Use Glob to find directories and files, Grep to find key symbols, Read to understand the actual implementation. Don't guess from names. Read the code.
+
+Follow this pattern:
+1. **Find the entry point.** What triggers this behavior? A user action, an API call, a scheduled job? Find where it starts.
+2. **Trace the flow.** Follow the call chain from the entry point. Read each function. Understand what data flows through and how it transforms.
+3. **Map the key abstractions.** What types, interfaces, services, or classes are central? Read their definitions. Understand what they represent and why they exist.
+4. **Find the boundaries.** Where does this subsystem interface with others? What goes in, what comes out?
+5. **Look for the non-obvious.** Anything surprising? Anything that looks like a historical artifact? Anything a newcomer would misunderstand?
+
+Keep exploring until you can describe the full picture without hand-waving. If you hit a part you can't trace, say so explicitly. "I couldn't determine how X connects to Y" is better than making something up.
+
+## Output
+
+Return your findings in this structure. Be factual and specific. Reference exact file paths, function names, type names, and line numbers where relevant.
+
+### Components Found
+The key types, services, classes, and abstractions. For each: name, file path, and a one-sentence description of what it does.
+
+### Flow
+The execution flow step by step. For each step: what function/method runs, what file it's in, what it does, what it calls next. Include the data that flows between steps.
+
+### Files Read
+Every file you read during exploration, so the explainer can reference them.
+
+### Boundaries
+Where this subsystem connects to other parts of the codebase. The inputs and outputs.
+
+### Non-Obvious Things
+Anything surprising, historically motivated, or easy to get wrong. Things that look like they should work one way but actually work another.
+
+### Open Questions
+Anything you couldn't fully trace or understand. Be honest about gaps.

package/skills/interrogate/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: interrogate
+description: "Use for \"interrogate\", \"adversarial review\", \"multi-model review\", \"challenge this\", \"stress test this code\", \"find blind spots\", or \"tear this apart\". Multiple LLM reviewers challenge changes from independent angles."
+---
+
+# Interrogate
+
+Spawn one reviewer per configured model to adversarially review code changes. Each model gets the same prompt and rubric. The adversarial signal comes from model diversity, not assigned personas. Models differ in blind spots, priors, and reasoning patterns. Agreement across models is high-confidence signal; lone-model findings are worth reading but lower confidence.
+
+The deliverable is a synthesized verdict. Do NOT auto-apply changes.
+
+## Step 1, Determine Scope
+
+Identify what to review from context:
+
+- If the user points at specific files or a diff, use that
+- If on a feature branch, run `git diff main...HEAD` (or the appropriate base branch) for the full changeset
+- If the user's message references recent work, gather the relevant files
+
+Package the diff (or file contents) plus any surrounding context files the reviewers need to understand the code.
+
+## Step 2, State the Intent
+
+Before spawning reviewers, state the intent explicitly. What is this code trying to accomplish? Derive this from:
+
+- The user's message
+- Commit messages
+- PR description if one exists
+- The code itself
+
+Write one clear paragraph. Reviewers challenge whether the work achieves the intent well, not whether the intent itself is correct. If you're unsure about the intent, ask the user before proceeding.
+
+## Step 3, Spawn Reviewers
+
+Launch all reviewers as one parallel fanout in one `subagent` workflow. Use the `interrogate reviewers` list from `~/.pi/agent/pstack/models.json` when present, one reviewer per entry, extending or shrinking the Reviewer labels below to the configured entry count; otherwise use the table default.
+
+| Subagent | Default model |
+|----------|---------------|
+| Reviewer | `inherit-parent` |
+
+For each reviewer:
+- agent: `worker`
+- `model`: the configured `interrogate reviewers` entry, or the table default with no configured line
+- tools: read-only (`read, grep, find, ls, bash`)
+
+If a model id is rejected as unresolvable when you try to spawn the subagent, check the valid ids in the error message, pick the closest equivalent (prefer the highest-reasoning tier of the same family), spawn with the valid slug, and open a separate PR to update the configured value or default table. Do not block the review on the slug issue. If the configured value is `inherit-parent` or `auto`, omit `model` instead; never treat those aliases as broken slugs or enter this fallback for them.
+
+Read `references/reviewer-prompt.md` and fill in the template with:
+1. The stated intent
+2. The diff or file contents
+3. The review rubric from `references/rubric.md`
+4. The code-quality lens from `references/code-quality-review.md`
+
+The same filled template goes to all reviewers, so every model applies the code-quality lens.
+
+Each reviewer produces structured findings as described in the prompt template.
+
+## Step 4, Synthesize
+
+As results come back, build a unified picture:
+
+1. **Parse all findings** from the reviewers
+2. **Identify consensus**. Findings raised by 2+ models independently are highest signal.
+3. **Identify lone-model findings**. Still worth reading, but weight accordingly.
+4. **Deduplicate**. Different models may describe the same issue differently. Merge these and note which models raised it.
+5. **Note disagreements**. If one model flags something and another explicitly says the opposite, that's useful context for the verdict.
+
+## Step 5, Lead Judgment
+
+You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator.
+
+Read `references/lead-judgment.md` for the full framework. Reviewers only see a slice of the codebase. You have the full context (the goal, the constraints, the timeline, which tradeoffs were already considered). Use that context aggressively.
+
+Categorize every finding using these buckets:
+
+- **Act on**. Real issues affecting correctness, security, or maintainability given the actual goals. These would block a real PR.
+- **Consider**. Legitimate points, but you're not sure they outweigh the cost of addressing them right now. Worth the user's attention.
+- **Noted**. Technically valid but not actionable. Context-dependent, premature optimization, or low-impact given the current stage.
+- **Dismissed**. Wrong, nitpicky, or missing context. Brief explanation why.
+
+For each finding, include:
+- Which model(s) raised it
+- The category (act on / consider / noted / dismissed)
+- A one-line rationale for the categorization
+
+## Output Format
+
+Present the verdict in this structure:
+
+### Intent
+> [The stated intent paragraph from Step 2]
+
+### Reviewers
+- Reviewer [label]: [model name], [N findings] (one bullet per reviewer)
+
+### Act On
+[Findings that should be addressed. For each: description, which models raised it, why it matters.]
+
+### Consider
+[Findings worth thinking about. For each: description, which models raised it, tradeoff involved.]
+
+### Noted
+[Valid but low-priority. Brief list.]
+
+### Dismissed
+[Rejected findings with brief rationale. This shows the user what was filtered out and why, so they can override your judgment if they disagree.]
+
+### Agreement Map
+[Where did models agree, where did they diverge, and what does the pattern of agreement/disagreement tell us?]

package/skills/interrogate/references/code-quality-review.md

@@ -0,0 +1,47 @@
+# Code Quality Review
+
+Each reviewer applies this code-quality lens in addition to the rubric. It is a strict standard focused on implementation quality, maintainability, abstraction quality, and codebase health.
+
+Above all, be ambitious about code structure. Do not merely identify local cleanup. Actively search for "code judo" moves, restructurings that preserve behavior while making the implementation dramatically simpler, smaller, more direct, and more elegant.
+
+## Core Prompt
+
+Start from this baseline:
+
+> Perform a deep code quality audit of the current branch's changes.
+> Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior.
+> Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility.
+> Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it.
+> Be extremely thorough and rigorous. Measure twice, cut once.
+
+## Dimensions
+
+Each dimension is stated once. Apply the ones that are relevant.
+
+0. **Be ambitious about structural simplification.** Do not stop at "this could be a bit cleaner." Look for reframings that make whole branches, helpers, modes, conditionals, or layers disappear. Assume a "code judo" move is often available. It uses the existing architecture more effectively and makes the change dramatically simpler. If you can delete complexity rather than rearrange it, push hard for that.
+
+1. **Do not let a PR push a file from under 1k lines to over 1k lines without a very strong reason.** Treat this as a strong smell. Prefer extracting helpers, subcomponents, or modules. If the diff crosses that threshold, ask whether the code should be decomposed first. Waive only for a compelling structural reason where the resulting file stays clearly organized.
+
+2. **Do not allow spaghetti growth in existing code.** Be suspicious of new ad-hoc conditionals, scattered special cases, or one-off branches inserted into unrelated flows. Treat "weird if statements in random places" as a design problem, not a style nit. Prefer pushing the logic into a dedicated helper, state machine, or module instead of tangling an existing path.
+
+3. **Bias toward cleaning the design, not just accepting working code.** If behavior can stay the same while the structure becomes meaningfully cleaner, push for the cleaner version. Prefer simplifications that remove moving pieces over refactors that spread the same complexity around.
+
+4. **Prefer direct, boring, maintainable code over hacky or magical code.** Treat brittle, ad-hoc, or "magic" behavior as a problem. Be skeptical of generic mechanisms that hide simple data-shape assumptions. Flag thin abstractions, identity wrappers, or pass-through helpers that add indirection without buying clarity.
+
+5. **Push on type and boundary cleanliness when it affects maintainability.** Question unnecessary optionality, `unknown`, `any`, or cast-heavy code when a clearer type boundary could exist. Prefer explicit typed models over loosely-shaped ad-hoc objects. If a branch leans on a silent fallback to paper over an unclear invariant, ask whether the boundary should be made explicit.
+
+6. **Keep logic in the canonical layer and reuse existing helpers.** Call out feature logic leaking into shared paths or implementation details leaking through APIs. Prefer existing canonical utilities over bespoke one-offs. Push code toward the right package, service, or module instead of normalizing drift.
+
+7. **Treat unnecessary sequential orchestration and non-atomic updates as design smells when the cleaner structure is obvious.** If independent work is serialized for no reason, ask whether it should run in parallel. If related updates can leave state half-applied, push for a more atomic structure. Do not over-index on micro-optimizations, but do flag avoidable orchestration complexity that makes the code more brittle.
+
+## Output Expectations
+
+Prioritize structural code-quality regressions and missed simplifications first, then spaghetti and branching complexity, then boundary, type, and file-size concerns, then smaller modularity and legibility issues. Do not flood the review with low-value nits when larger structural issues exist. Prefer a few high-conviction comments over a long list of cosmetic notes.
+
+## Approval Bar
+
+Do not approve merely because behavior seems correct. Treat these as presumptive blockers unless the author can justify them: the PR keeps a lot of incidental complexity when a code-judo move would delete it; pushes a file from below 1000 lines to above 1000 lines; adds ad-hoc branching that tangles an existing flow; scatters feature checks across shared code; adds an unnecessary abstraction, wrapper, or cast-heavy contract; or duplicates an existing helper or puts logic in the wrong layer when there is a clear canonical home. If those conditions are not met, leave explicit, actionable feedback and push for a cleaner decomposition.
+
+## Review Tone
+
+Be direct, serious, and demanding about quality. Do not be rude, but do not soften major maintainability issues into mild suggestions. If the code is making the codebase messier, say so. If the implementation missed an obvious dramatic simplification, say that too. Do not be satisfied with "maybe rename this" when the real issue is structural.

package/skills/interrogate/references/lead-judgment.md

@@ -0,0 +1,58 @@
+# Lead Judgment Framework
+
+You are the lead reviewer. The configured reviewers have produced their findings. Apply pragmatic engineering judgment. Don't aggregate; filter, contextualize, and decide.
+
+## Why This Step Matters
+
+Adversarial reviewers are useful because they're aggressive. But aggression without context produces noise. The reviewers only saw a slice of the codebase and a one-paragraph intent statement. They don't know:
+
+- What was already tried and rejected
+- What constraints exist outside the code (timeline, dependencies, migration plans)
+- Which parts of the code are temporary scaffolding vs. permanent architecture
+- What the next PR in the stack will address
+
+You have the full conversation context. Use it.
+
+## Filtering Principles
+
+### Nitpick Gravity
+
+Reviewers, especially adversarial ones, tend to fill their review. If they don't find critical issues, they'll inflate nits to fill the space. If a reviewer's findings are all nits and style preferences, the code is probably fine. Say so.
+
+### Hypothetical vs. Actual
+
+"What if someone passes null here?" is only a finding if the caller can actually pass null. Trace the call site. If the input is validated upstream or the type system prevents it, dismiss the finding. Reviewers working from a diff can't always see the full call chain. You can.
+
+### Premature Abstraction Warnings
+
+Reviewers often suggest extracting functions, adding interfaces, or creating abstractions. Does this code need to change in a second way? If not, the abstraction is premature. Simple inline code that works beats a clean abstraction that's overkill for the current scope.
+
+### "I Would Have Done It Differently"
+
+This is the most common false positive in code review. A finding that amounts to "I prefer a different approach" is not a bug, not a design flaw, and not actionable unless the reviewer shows a concrete problem with the current approach. Dismiss these, and say why.
+
+### Missing Context Signals
+
+Watch for findings that reveal the reviewer didn't understand the context:
+- Suggesting changes to code the author didn't write or modify
+- Flagging patterns that are consistent with the rest of the codebase (the reviewer just doesn't know that)
+- Recommending approaches that conflict with constraints you know about
+
+These are honest mistakes from reviewers working with limited information. Dismiss them gracefully.
+
+## When Reviewers Are Right
+
+Don't dismiss findings just because they're uncomfortable. The whole point of adversarial review is to catch things you'd miss. Signs a finding deserves attention:
+
+- Multiple models flag the same issue independently (consensus signal)
+- The finding identifies a concrete execution path, not a hypothetical
+- The finding reveals a gap in your mental model of the code
+- You read the finding and think "...yeah, actually"
+
+Be especially careful about dismissing security findings and correctness bugs. These deserve more scrutiny even when they come from a single model.
+
+## Verdict Calibration
+
+A good verdict is useful, not comprehensive. The user should be able to read the "Act On" section, fix those issues, and ship with confidence. If your "Act On" list has more than 5 items, you're probably not filtering hard enough.
+
+The "Dismissed" section is not busywork. It's a trust mechanism. Showing the user what you rejected and why lets them override your judgment where they disagree. This is more valuable than hiding the rejected findings.