From hotl
Explores intent, requirements, and design before feature work. Produces HOTL contracts (intent, verification, governance) and plans like docs/plans/YYYY-MM-DD-<topic>-plan.md.
npx claudepluginhub yimwoo/hotl-plugin --plugin hotlThis skill uses the workspace's default tool permissions.
Turn ideas into designs with explicit HOTL contracts. Ask questions one at a time. Present design for approval before any implementation.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Designs, implements, and audits WCAG 2.2 AA accessible UIs for Web (ARIA/HTML5), iOS (SwiftUI traits), and Android (Compose semantics). Audits code for compliance gaps.
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.Phase 2 — Branch on result:
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:
intent: [one sentence goal]
constraints: [what must not change/break]
success_criteria: [how we know it's done]
risk_level: low | medium | high
verify_steps:
- run tests: [test command]
- check: [what to inspect]
- confirm: [success signal]
approval_gates: [list of steps requiring human review]
rollback: [how to undo if something goes wrong]
ownership: [who is accountable]
feature or phase scope: save to docs/plans/YYYY-MM-DD-<topic>-plan.md (dated, tactical; the Slice 2 default).initiative scope: save to <designs_dir>/<topic>.md (undated, durable). <designs_dir> is the value returned by the step-2 resolver (default docs/designs). Follow the section structure of the strategic template loaded in step 2.risk_level: high = security, auth, privacy, billing (always human-gated)