superplan-plugin

Use when routed repo work still has meaningful ambiguity about behavior, constraints, taste, or acceptance intent, and that ambiguity would make planning or execution unsafe.

Use when a new request might involve repo work, tracked changes, workspace-specific decisions, or durable coordination and you must decide whether Superplan should engage before exploring or implementing.

Use when tracked work is already shaped and the next move is to execute, verify, block, or request feedback without replanning from scratch.

Use when the target is understood but the work still needs an execution path, task breakdown, or proof strategy before implementation begins.

Use when Superplan may engage and you need to decide whether to stay lightweight, create one tracked task, gather context first, or shape deeper structure before execution begins.

Use when Superplan has decided to engage and the work still needs plans, specs, proof paths, or multiple tracked tasks shaped before bounded execution can start.

Use when brownfield or long-running repo work lacks durable context about architecture, conventions, or recurring gotchas that future tasks will need again.

Use when tracked work hits a failing check, flaky result, runtime bug, or unexplained behavior and you need root cause before changing code.

Use when code, commands, install flow, help text, or user-visible behavior changed and docs or durable context may now be inaccurate.

Use when a fix or behavior change needs the smallest durable test, check, or proof so the contract will fail loudly if it regresses.

Use when work is pausing, switching owners, or at risk of context loss and the next agent will need a concise restart point with the current truth.

Use when completed or failed work exposed a reusable lesson, recurring trap, or process weakness worth capturing for future tasks.

Use when someone asks whether the current product slice is ready to ship, publish, or recommend and the answer depends on a disciplined release-quality check.

Use when a tracked task appears done and you need to decide whether its acceptance criteria are truly satisfied by fresh evidence.

Use when a feature, bugfix, or behavior change has a testable contract and implementation is about to begin.

Use when you are about to say work is complete, fixed, passing, or ready and need fresh proof from the real workspace harness first.

YC Office Hours — two modes. Startup mode: six forcing questions that expose demand reality, status quo, desperate specificity, narrowest wedge, observation, and future-fit. Builder mode: design thinking brainstorming for side projects, hackathons, learning, and open source. Saves a design doc. Use when asked to "brainstorm this", "I have an idea", "help me think through this", "office hours", or "is this worth building". Proactively suggest when the user describes a new product idea or is exploring whether something is worth building — before any code is written. Use before /plan-ceo-review or /plan-eng-review.