rubber-duck

name	rubber-duck
description	Use for "rubber duck", "/rubber-duck", "second opinion", "critique this plan", "critique these changes", "get a critique", or when the consult-rubber-duck rule says to seek a constructive second opinion. Spawns a read-only critic on a contrasting model family; does not edit files.
disable-model-invocation	true

Rubber Duck

Get a constructive second opinion on a plan, design, implementation, or tests from a different model family than the one driving this session. The critic is read-only. You decide what to do with the feedback.

Inspired by GitHub Copilot’s rubber duck agent: articulate the work, have an independent critic scrutinize it, then continue with eyes open.

Step 1 — Package the work

Gather what the critic needs:

• Intent: one clear paragraph — what this work is trying to accomplish (from the user request, plan, commits, or code).
• Artifact: the plan, design notes, diff / changed files, or tests under review.
• Focus (optional): any question from the user (e.g. "What edge cases are missing?").
• Constraints: known non-goals, deadlines, or decisions already locked.

Before handoff, redact or omit credentials, secrets, tokens, private keys, and obvious PII from the artifact. Do not send blocked sensitive content unless the user explicitly opts in. Prefer the smallest sufficient context. For branch work, git diff <base>...HEAD (default base main) plus contents of changed files is usually enough.

Step 2 — Pick one contrasting critic model

Choose one model from a different family than the session model. Use Task model slugs as accepted by the Task tool (same convention as other plugins in this marketplace, e.g. pstack):

Session model family	Critic model (preferred)
Claude	gpt-5.5-high
GPT / Codex	claude-opus-4-8-thinking-high
Composer / other / unknown	claude-opus-4-8-thinking-high

If a slug is rejected as unresolvable, pick the closest resolvable alternative from a different model family (prefer the highest-reasoning tier from the Task tool’s valid list). If no cross-family model is available, tell the user the critique cannot preserve model contrast and ask whether to proceed with the best available model or skip.

Step 3 — Spawn the critic

Launch a single Task subagent:

• subagent_type: rubber-duck
• model: the critic model from Step 2
• readonly: true

Fill references/critic-prompt.md with intent, artifact, optional focus, and the severity rubric from references/severity-rubric.md. Pass that filled prompt as the Task user message.

Do not spawn multiple critics. Do not ask the critic to edit files or run mutating commands.

Step 4 — Act on the critique

When the critic returns:

1. Read Blocking, Non-blocking, and Suggestions.
2. Fix or revise for Blocking before continuing implementation or declaring done.
3. Apply Non-blocking items when they are cheap and clearly improve success odds.
4. Note Suggestions briefly; do not expand scope unless the user wants that.
5. Summarize for the user in one or two sentences (what mattered, what you changed). Expand only if asked.

If the critic reports no issues, say so briefly and continue.

Guardrails

• Constructive critic, not a rubber-stamp and not a hostile teardown.
• Skip style, formatting, naming, comment grammar, and nit best-practices that do not affect correctness or success.
• Never auto-apply critic edits; you own all file changes.
• Skip the consult for trivial, well-understood edits (see consult-rubber-duck rule).
• Do not reproduce redacted secrets in the user-facing critique summary.