---
name: trellis-brainstorm
description: "Resolve unclear requirements and consequential design choices before implementation; produce or update the owning Trellis plan."
---

# Plan The Requested Change

Use the project's workflow and task contract. Reuse a suitable task; create one only when needed and authorized. Task creation alone is not implementation approval. Keep unrelated tasks and historical evidence intact.

Inspect relevant code, tests and fact sources before asking questions. Separate observed behavior from intended behavior: existing code is evidence, not authority to redefine the user's goal. Search past dialogue only when a necessary decision is missing from current context and task records.

Resolve routine implementation choices within the user's authorized scope. Ask about consequential product, compatibility, UX, risk or acceptance decisions that remain unclear; state the recommendation and trade-off. A blocking answer is required before dependent work, while independent evidence gathering may continue. Do not invent questions or treat silence as approval.

Record the smallest plan that makes the work reviewable:
- `prd.md`: goal, relevant facts, scope/exclusions, observable acceptance, test plan and unresolved decisions.
- Complex work also needs `design.md` for contracts, trade-offs and rollout/rollback, plus `implement.md` for ordered work and checks. Lightweight tasks may be PRD-only.
- Context manifests contain stable spec/research only. Sub-agent mode requires curated real entries; empty/legacy seed-only manifests do not qualify. Inline mode reads context directly and permits empty manifests.

Before requesting a new plan's approval, resolve blocking questions and consolidate temporary notes into the owning sections. Preserve requirement IDs, evidence anchors, decisions and acceptance mappings; do not rewrite an already clear PRD merely to satisfy a template. Defer technical unknowns explicitly only when doing so does not silently change required behavior.

Present a concise plan with material risks and completion criteria. A recorded approval or explicit delegation covering this scope remains valid; clerical updates do not restart approval. Once required artifacts and decisions are complete, run the official `task.py start` command and continue approved implementation and checks. Reconfirm only material scope, risk or acceptance changes and separately protected operations.