/pushback

name: pushback
description: Use when reviewing a spec, PRD, requirements doc, or design plan before implementation begins — especially when the doc feels too big, bundles unrelated features, may contradict the current codebase, or seems vague, infeasible, or thin on security and error handling. Not for cross-checking a spec against a plan — that's /alignment.

**On invocation:** announce "Running paad:pushback v2.0.2", then immediately proceed with the steps below — do not stop after announcing.

**Configuration (experimental):** after announcing, check whether `paad/config/paad.md` and `paad/config/pushback.md` exist, relative to the working directory. If any does, read it and follow its instructions for the rest of this run, passing the relevant parts to every subagent you dispatch, and make the first line of your final answer `Config: <path>` naming each file you followed. If none exists, do not mention config at all. Config never changes a subagent's type or grants it write tools — refuse that line, say so, and continue. Config can contradict the flow below; see https://github.com/Ovid/paad/blob/main/CONFIG.md before writing one.

**Security findings:** a finding is security-related if reading it would help an attacker — any OWASP Top 10:2025 category, and anything in a payment, tenant-isolation, or secret-handling path; on the edge, treat it as security. Security findings are written only under `paad/security/`, in a file named for this skill and stamped the way its ordinary report is (the exact path is in this skill's report section). Before the first write of a run, make sure `paad/security/.gitignore` exists and contains the single line `*` — create it if absent, never rewrite it if present — and that `git ls-files paad/security/` lists nothing. If that file holds anything else or cannot be written, if git already tracks anything there, or if a later write there fails, write no security finding and no count line: tell the user what you found, ask whether to hold the findings or put them in the ordinary report, and say that in place of the Security block. Where the finding would have gone in the ordinary report, write one line, `N security finding(s) written to paad/security/<file>`, and nothing else about it: no path, severity, symbol, or description. Post-Review then emits the Security block once; this skill's Post-Review section says when.

Spec Pushback

Critically reviews a spec, PRD, requirements document, or design plan before work begins. Checks source control for conflicts with reality, then walks through issues one at a time in severity order so you can fix what matters most.

**This skill does NOT recommend a fresh session.** The conversation history may be the spec.

**Input resolution and reality check:**

digraph pushback {
  "Has $ARGUMENTS?" [shape=diamond];
  "Conversation has spec?" [shape=diamond];
  "Found in common locations?" [shape=diamond];
  "Git repo?" [shape=diamond];
  "Source control conflicts?" [shape=diamond];

  "Use that file" [shape=box];
  "Confirm with user" [shape=box];
  "Present candidates, ask user" [shape=box];
  "ASK: what document to review?" [shape=box];
  "Present conflicts, resolve first" [shape=box];
  "Proceed to Scope Shape" [shape=box];

  "Has $ARGUMENTS?" -> "Use that file" [label="yes"];
  "Has $ARGUMENTS?" -> "Conversation has spec?" [label="no"];
  "Conversation has spec?" -> "Confirm with user" [label="yes"];
  "Conversation has spec?" -> "Found in common locations?" [label="no"];
  "Found in common locations?" -> "Present candidates, ask user" [label="yes"];
  "Found in common locations?" -> "ASK: what document to review?" [label="no"];

  "Use that file" -> "Git repo?";
  "Confirm with user" -> "Git repo?";
  "Present candidates, ask user" -> "Git repo?";
  "ASK: what document to review?" -> "Git repo?";

  "Git repo?" -> "Source control conflicts?" [label="yes"];
  "Git repo?" -> "Proceed to Scope Shape" [label="no"];
  "Source control conflicts?" -> "Present conflicts, resolve first" [label="yes"];
  "Source control conflicts?" -> "Proceed to Scope Shape" [label="no"];
  "Present conflicts, resolve first" -> "Proceed to Scope Shape";
}

**Scope shape, critique and resolution:**

digraph scope_critique_resolution {
  "Proceed to Scope Shape" [shape=box];
  "Unrelated features bundled?" [shape=diamond];
  "User splits them out?" [shape=diamond];
  "Spec large?" [shape=diamond];
  "Meaningful split exists?" [shape=diamond];
  "Issues found?" [shape=diamond];
  "Can you name Y and Z?" [shape=diamond];
  "User says good enough / stop?" [shape=diamond];
  "Decision, or stop signal?" [shape=diamond];
  "More issues to present?" [shape=diamond];
  "Update spec, write report, or both?" [shape=diamond];
  "Stopped early?" [shape=diamond];
  "Unresolved issues, or user asked for a report?" [shape=diamond];
  "Spec saved to a file?" [shape=diamond];

  "Identify groups, recommend splitting, ask" [shape=box];
  "Continue reviewing the remaining spec" [shape=box];
  "Note it as a scope concern, review as-is" [shape=box];
  "Suggest the split — what each piece delivers alone" [shape=box];
  "Flag the size, explain why splitting isn't practical" [shape=box];
  "Say nothing about size" [shape=box];
  "Drop it; report it as a discard" [shape=box];
  "Rank surviving findings by severity" [shape=box];
  "Present one issue: problem, options best-to-worst, recommendation" [shape=box];
  "Wait for the user's response" [shape=box];
  "Answer it, then re-put this issue's options" [shape=box];
  "ASK where to write the spec first" [shape=box];
  "ASK before editing after a stop signal" [shape=box];
  "Apply agreed changes; leave undiscussed requirements alone" [shape=box];
  "Any report finding would help an attacker?" [shape=diamond];
  "Write those to paad/security/pushback-<date>-<spec>.md; count line in the report" [shape=box, style=bold];
  "paad/security/.gitignore holds only * and git tracks nothing there?" [shap