brainstorming

分类: 内容与多媒体 | 上传者: yimwoo | 下载: 0 | 版本: v1.0（最新）

在任何功能工作之前使用——探索意图、需求和设计。在实施之前生成 HOTL 合同（意图、验证、治理）。

更新日志: Source: GitHub https://github.com/yimwoo/hotl-plugin

目录结构

当前层级: tree/main/skills/brainstorming/

📄 SKILL.md 3.4 KB

SKILL.md

---
name: brainstorming
description: "Use before any feature work — explores intent, requirements, and design. Produces HOTL contracts (intent, verification, governance) before implementation."
---

# HOTL Brainstorming

## Overview

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>

## 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 `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, 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. **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.
3. **Propose 2-3 approaches** — with trade-offs and recommendation
4. **Present design in sections** — get approval after each section
5. **Define HOTL contracts** — always include all three:

### Intent Contract
```
intent: [one sentence goal]
constraints: [what must not change/break]
success_criteria: [how we know it's done]
risk_level: low | medium | high
```

### Verification Contract
```
verify_steps:
  - run tests: [test command]
  - check: [what to inspect]
  - confirm: [success signal]
```

### Governance Contract
```
approval_gates: [list of steps requiring human review]
rollback: [how to undo if something goes wrong]
ownership: [who is accountable]
```

6. **Write design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md`
7. **Self-check the design doc** — before presenting for human approval, review the saved design doc for: missing constraints, vague success criteria, contract mismatches (do verification steps actually test the intent?), risk_level appropriateness, and scope creep. Fix any issues found. Lightweight: 1-2 passes by default, max 3 only if real issues are found. Do not ask the user to review — this is an internal quality pass.
8. **Invoke writing-plans** — transition to implementation planning

## Key Principles

- One question at a time — prefer multiple-choice when practical
- YAGNI ruthlessly — remove unnecessary features
- Always propose alternatives before settling
- `risk_level: high` = security, auth, privacy, billing (always human-gated)

登录后下载/点赞/收藏 ❤ 16 | ★ 0

brainstorming

目录结构

SKILL.md

举报内容

提示