Use before any feature work — explores intent, requirements, and design. Produces HOTL contracts (intent, verification, governance) before implementation.
Turn ideas into designs with explicit HOTL contracts. Ask questions one at a time. Present design for approval before any implementation.
<HARD-GATE> Do NOT write any code or create any files until design is approved and a `hotl-workflow-<slug>.md` is generated by writing-plans. </HARD-GATE>Explore context (cheap preflight first)
Phase 1 — Cheap preflight (Glob only, current project directory):
docs/plans/*.mdREADME.md, .gitignore, LICENSE, and scaffolding boilerplate do not count.Hard rule: Never scan parent directories, sibling folders, or workspace-wide paths unless the user explicitly provides a path.
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/plans/YYYY-MM-DD-<topic>-plan.md (dated, tactical).phase — one slice of a multi-phase initiative. Same output shape as feature: docs/plans/YYYY-MM-DD-phase-N-<topic>-plan.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):
hotl-plugin repo itself, use adapters/strategic-design.template.md~/.codex/hotl/adapters/strategic-design.template.md~/.codex/plugins/hotl-source/adapters/strategic-design.template.md~/.codex/plugins/cache/codex-plugins/hotl/*/adapters/strategic-design.template.md~/.cline/hotl/adapters/strategic-design.template.md~/.claude/plugins/hotl/adapters/strategic-design.template.mdRead the resolved template once at session start — its section structure (problem, vision, non-goals, stakeholders, architecture, phase breakdown, risks) becomes the skeleton of the design doc you produce. Do not assume adapters/strategic-design.template.md exists in the repo being worked on.
For initiative scope, resolve the output directory via hotl-config-resolve.sh:
bash <resolved-hotl-config-resolve.sh> get designs_dir --default=docs/designs
Resolve hotl-config-resolve.sh via the same six-location order. The default is docs/designs when no .hotl/config.yml is present; opted-in projects may override via that config.
Ask clarifying questions — one at a time, understand purpose/constraints/success criteria. Prefer multiple-choice when the likely answer space is known (e.g., "Which constraints apply? (a) Must not break existing API (b) Backward-compatible (c) Performance-sensitive (d) Other"). Fall back to open-ended only when the problem is unusual or exploratory.
Propose 2-3 approaches — with trade-offs and recommendation
Present design in sections — get approval after each section
Define HOTL contracts — always include all three: