# Brainstorm Result: Empty Topic ($${@:-default fallback})

## 1. Problem restatement

The invocation arrived with `${@:-the current problem or feature}` literally unsubstituted — there is no concrete problem statement, no target codebase, no feature request, and no constraints supplied. Because of the `:-` shell defaulting, an empty argument list silently resolves to the placeholder string rather than an empty value. We cannot compare approaches, recommend a primary, or surface real trade-offs without knowing what we are designing for. "Done" here is a single resolved, scoped problem statement that names the system, the user, and the acceptance bar.

## 2. Alternatives — three meta-approaches to handling the missing input

I considered three ways to handle a malformed/empty invocation. I am not enumerating 3–5 design alternatives to a *feature*, because no feature has been stated. Manufacturing options against a placeholder would be the strawman the prompt warns against.

### A. Refuse and ask for the topic (recommended)

**Summary** — Return a short reply explaining the placeholder issue, list the minimum info needed, and wait.
**How it works** — Detect that the rendered argument equals the default sentinel `${@:-...}`, then emit a clarifying prompt instead of a fabricated brainstorm.
**Pros** — No hallucinated work, no wasted cycles downstream, no false confidence in a recommendation.
**Cons** — Latency cost of a round-trip; user must restate the request.
**Best when** — The argument is genuinely missing or malformed, as it is here.

### B. Infer the topic from session context

**Summary** — Try to recover a problem statement from the parent session, recent files, or active plan.
**How it works** — Read the parent orchestrator's context, the working directory (`/home/liph/dotfiles/pi/.pi/agent/prompts`), recent git changes, or a pinned issue.
**Pros** — Potentially one-shot delivery without restating; respects "don't make me repeat myself."
**Cons** — High risk of guessing wrong; a brainstorm built on a guessed topic is worse than no brainstorm; the fork/subagent boundary may not have rich context anyway.
**Best when** — There is a strong, unambiguous signal in the environment (e.g., an open plan or an explicit "brainstorm on X" header nearby).

### C. Brainstorm a meta-topic: "designing a brainstorming workflow"

**Summary** — Treat the missing topic as the topic itself — design improvements to the brainstorm command's input handling.
**How it works** — Generate alternatives for how the prompt should validate, default, or fail-fast on missing input.
**Pros** — Produces a real, bounded deliverable; useful artifact for hardening this command.
**Cons** — Almost certainly not what the caller wanted; a prompt-fixing brainstorm instead of the intended feature brainstorm.
**Best when** — The user is explicitly iterating on the prompt itself.

## 3. Comparison table

| Approach | Complexity | Time-to-ship | Reversibility | Performance | Fit with existing code |
|---|---|---|---|---|---|
| A. Refuse and ask | Very low | Immediate | N/A (no commitment) | Trivial | High — matches the prompt's own "ask clarifying questions" rule |
| B. Infer from context | Medium | Medium | High — still easy to discard | One extra read pass | Low — guesses can pollute the parent session |
| C. Meta-brainstorm | Low | Low | High | Trivial | Low — sidesteps the actual request |

Scoring: 1 (worst) – 5 (best) for fit; lower complexity is better.

| Approach | Complexity | Time-to-ship | Reversibility | Fit |
|---|---|---|---|---|
| A | 5 | 5 | 5 | 5 |
| B | 2 | 3 | 4 | 2 |
| C | 4 | 4 | 4 | 2 |

## 4. Recommendation

**Pick A.** The prompt explicitly says: *"If the problem is under-specified, ask clarifying questions before brainstorming."* Silently substituting a placeholder and inventing a problem would directly violate that instruction and produce an artifact with no actionable value. The fallback, if the user insists on a non-blocking response, is **C** — turn the lens on the prompt's own input handling and ship a small set of hardening options.

## 5. Unknowns

These are the questions whose answers would change the recommendation immediately:

1. **What is the actual problem or feature?** Required. The single most important unknown; everything below is contingent on this.
2. **Is the user available to clarify now, or is this an autonomous run?** If autonomous, B (context inference) becomes more attractive.
3. **Is the goal to improve this `p-brainstorm.md` command itself?** If yes, switch to approach C and brainstorm input-validation strategies.
4. **What codebase is in scope?** Brainstorm fit-with-existing-code requires knowing the existing code.
5. **Are there hard constraints (language, runtime, deadlines, regulatory)?** These prune the alternative space before evaluation.

---