HOTL Brainstorming

HOTL Brainstorming

Overview

Turn ideas into designs with explicit HOTL contracts. Ask questions one at a time. Present design for approval before any implementation.

Process

1. Explore context (cheap preflight first)

   Phase 1 — Cheap preflight (Glob only, current project directory):

   • If user's message references a doc path → read it
   • Check for canonical design docs in docs/designs/*.md
   • Check for legacy design docs in docs/plans/*.md
   • Check for source code, config manifests, or project-specific config files
   • "Relevant context" means: design docs, source code, configuration manifests, or project-specific config. Files like README.md, .gitignore, LICENSE, and scaffolding boilerplate do not count.

   Phase 2 — Branch on result:

   • Relevant local context found: Read the most recent 1-2 design docs from canonical or legacy locations, inspect only relevant in-project files, and optionally review recent commits (only if the directory is a git repo).
   • No relevant local context found: State: "This appears to be a greenfield or effectively empty project, so I'm skipping deep context scanning and moving to clarifying questions." Proceed directly to step 2.

   Hard rule: Never scan parent directories, sibling folders, or workspace-wide paths unless the user explicitly provides a path.

2. Determine scope — decide between feature, phase, or initiative before the clarifying-questions loop. Scope shapes every downstream step: output path, contract structure, depth of inquiry.

   Scope choices:

   • feature — one feature, one bug fix, one refactor. Output: docs/designs/YYYY-MM-DD-<slug>-design.md (dated, tactical).
   • phase — one slice of a multi-phase initiative. Same output family as feature: docs/designs/YYYY-MM-DD-phase-N-<slug>-design.md.
   • initiative — a multi-phase project (v1/v2, platform migration, enterprise rebuild). Output: docs/designs/<topic>.md (undated, durable, strategic).

   Default: feature. If the user's initial message clearly describes a feature, proceed with feature scope without blocking for input. Optionally acknowledge in one line ("Treating as feature scope; say so if this should be a phase or initiative"). Do not pause the flow.

   Ask the scope question explicitly when the request is ambiguous or multi-phase (e.g., "migrate v1 to v2", "platform rebuild", "rework across services"). Present the three choices with feature as the pre-filled default and wait for the user's answer before continuing.

   For initiative scope, load the strategic-design template once at session start. Resolve adapters/strategic-design.template.md in this order (same pattern used for document-lint.sh and hotl-config.sh — see skills/document-review/SKILL.md):