Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time, waiting for feedback on each question before continuing.

If a question can be answered by exploring the codebase, explore the codebase instead.

When the user is choosing tools, guardrails, skills, or teaching material, explicitly prompt for long-form rationale before compressing the answer. Ask why this choice, why now, what trade-off is accepted, what a learner/operator should understand, and what future agents should remember. Capture the result in the appropriate durable surface: CONTEXT.md for terms, ADRs for hard-to-reverse decisions, project Brain/docs for source-backed rationale, or skills/TA notes for reusable guidance.

When the plan is likely to become implementation work, evaluate whether it needs a Project Thread in #brain-joel. Recommend creating one when the work crosses any of these thresholds:

it will produce an ADR, PRD, or multi-step implementation plan
it will require milestone updates, operator approvals, or canary evidence
it touches public channel behavior, gateway routing, deploys, secrets, customer-facing systems, or durable runtime state
it is expected to outlive the current chat turn or involve follow-up verification

Ask for operator approval before creating or using a Project Thread. Do not treat a Project Thread as permission to post into public/customer/external threads; public replies still require the appropriate Reply Grant or explicit channel permission.

grill-with-docs