evanflow-brainstorming

Name: evanflow-brainstorming
Author: evanklem

419stars18forks

How to install evanflow-brainstorming?

evanklem/evanflow/evanflow-brainstorming

$npx -y skills add evanklem/evanflow --skill evanflow-brainstorming

Installs into the current project.

Summary

Clarify intent, propose 2-3 approaches, embedded grill to stress-test the chosen path. Use before any creative work — new features, components, behavior changes, design questions. Mockup-only requests use mockup quick-mode (no spec/plan ceremony).

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: Brainstorming
2
3
4
5	## Vocabulary
6
7	See `evanflow` meta-skill. Key terms used here: deep modules, deletion test, mockup quick-mode, grill.
8
9	## When to Use
10
11	- "Help me think through X"
12	- "I want to build Y"
13	- New feature scoping
14	- Design questions where intent is unclear
15	- Before any creative work that will produce code
16
17	SKIP this skill when: the user is asking a factual question, requesting a quick mockup, or doing exploratory reading. EvanFlow has no skill tax — answer directly.
18
19	## Mockup Quick-Mode
20
21	If the user says "show me mockups", "give me visual options", "let's see designs", or anything similar and is NOT asking to implement — skip everything below. Produce mockups directly in whatever form the project uses:
22
23	- HTML files (often easiest — write self-contained pages and tell the user where to open them, e.g., `open mockup-1.html` or via a local HTTP server)
24	- Figma frames (if the project uses Figma)
25	- ASCII layouts (for terminal UIs)
26	- Whatever the project's CLAUDE.md documents as the design-iteration medium
27
28	No spec doc. No plan. No git operations. Just iterate visually until the user picks a direction.
29
30	## The Flow
31
32	1. Quick context check. Skim relevant files, recent commits, and any referenced docs. Do NOT exhaustively explore — just enough to ground the conversation.
33	2. Scope check. If the request describes multiple independent subsystems, flag it and propose decomposition before going further. Don't refine details on something that needs to be split.
34	3. Ask clarifying questions one at a time. Multiple-choice when possible (use AskUserQuestion). Focus on purpose, constraints, success criteria.
35	4. Propose 2–3 approaches with trade-offs and your recommendation as option (a). Lead with "here's what I'd do and why."
36	5. Embedded Grill (see below) — stress-test the chosen approach before committing.
37	6. Present the design in sections sized to their complexity. Get explicit approval after each section.
38	7. Decide: spec doc, straight to plan, or just go.
39
40	## Embedded Grill
41
42	Once an approach is chosen, ask 3–5 sharp questions targeting:
43
44	- Hidden constraints: "What breaks if a user does X?"
45	- Reversibility: "If we ship this and it's wrong, what's the rollback?"
46	- Boundaries: "What's explicitly NOT in scope?"
47	- Existing patterns: "Is there code in the project that already does something similar? Should this conform or diverge?"
48	- Domain language: "Are we using the right terms from `CONTEXT.md`?"
49
50	For each question, propose a recommended answer. The user accepts, refines, or rejects. Don't grill on every single design — only when the choice has irreversibility, security, or domain-modeling implications.
51
52	## Hard Rules
53
54	- Never auto-commit. Confirm in the current turn before any git op.
55	- No forced spec path. If a spec doc is appropriate, ask the user where to put it. Default suggestion: `docs/specs/YYYY-MM-DD-<topic>.md`. Don't write to any vendor-specific path unless user requests.
56	- No forced visual companion offer. Skip the browser-companion offer entirely; mockup quick-mode handles visual work directly.
57	- No skill tax. If the user is just chatting or asking a factual question, exit this skill — don't force the flow.
58
59	## Hand-offs
60
61	- Spec written → `evanflow-writing-plans` (if non-trivial)
62	- Substantial new feature (sprint-sized, multi-stakeholder) → `evanflow-prd` instead of writing-plans
63	- Plan exists → `evanflow-executing-plans` (which itself offers `evanflow-coder-overseer` if the plan has 3+ parallelizable units)
64	- Just go → start with `evanflow-tdd` for the first behavior
65	- Domain term emerged → `evanflow-glossary` to update `CONTEXT.md`
66	- Interface shape is the hard part of the design → `evanflow-design-interface` before writing-plans

People who liked this also viewed

6 picks

Type

evanflow-brainstorming

419stars18forks

View on GitHub

How to install evanflow-brainstorming?

evanklem/evanflow/evanflow-brainstorming

$npx -y skills add evanklem/evanflow --skill evanflow-brainstorming

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: Brainstorming
2
3
4
5	## Vocabulary
6
7	See `evanflow` meta-skill. Key terms used here: deep modules, deletion test, mockup quick-mode, grill.
8
9	## When to Use
10
11	- "Help me think through X"
12	- "I want to build Y"
13	- New feature scoping
14	- Design questions where intent is unclear
15	- Before any creative work that will produce code
16
17	SKIP this skill when: the user is asking a factual question, requesting a quick mockup, or doing exploratory reading. EvanFlow has no skill tax — answer directly.
18
19	## Mockup Quick-Mode
20
21	If the user says "show me mockups", "give me visual options", "let's see designs", or anything similar and is NOT asking to implement — skip everything below. Produce mockups directly in whatever form the project uses:
22
23	- HTML files (often easiest — write self-contained pages and tell the user where to open them, e.g., `open mockup-1.html` or via a local HTTP server)
24	- Figma frames (if the project uses Figma)
25	- ASCII layouts (for terminal UIs)
26	- Whatever the project's CLAUDE.md documents as the design-iteration medium
27
28	No spec doc. No plan. No git operations. Just iterate visually until the user picks a direction.
29
30	## The Flow
31
32	1. Quick context check. Skim relevant files, recent commits, and any referenced docs. Do NOT exhaustively explore — just enough to ground the conversation.
33	2. Scope check. If the request describes multiple independent subsystems, flag it and propose decomposition before going further. Don't refine details on something that needs to be split.
34	3. Ask clarifying questions one at a time. Multiple-choice when possible (use AskUserQuestion). Focus on purpose, constraints, success criteria.
35	4. Propose 2–3 approaches with trade-offs and your recommendation as option (a). Lead with "here's what I'd do and why."
36	5. Embedded Grill (see below) — stress-test the chosen approach before committing.
37	6. Present the design in sections sized to their complexity. Get explicit approval after each section.
38	7. Decide: spec doc, straight to plan, or just go.
39
40	## Embedded Grill
41
42	Once an approach is chosen, ask 3–5 sharp questions targeting:
43
44	- Hidden constraints: "What breaks if a user does X?"
45	- Reversibility: "If we ship this and it's wrong, what's the rollback?"
46	- Boundaries: "What's explicitly NOT in scope?"
47	- Existing patterns: "Is there code in the project that already does something similar? Should this conform or diverge?"
48	- Domain language: "Are we using the right terms from `CONTEXT.md`?"
49
50	For each question, propose a recommended answer. The user accepts, refines, or rejects. Don't grill on every single design — only when the choice has irreversibility, security, or domain-modeling implications.
51
52	## Hard Rules
53
54	- Never auto-commit. Confirm in the current turn before any git op.
55	- No forced spec path. If a spec doc is appropriate, ask the user where to put it. Default suggestion: `docs/specs/YYYY-MM-DD-<topic>.md`. Don't write to any vendor-specific path unless user requests.
56	- No forced visual companion offer. Skip the browser-companion offer entirely; mockup quick-mode handles visual work directly.
57	- No skill tax. If the user is just chatting or asking a factual question, exit this skill — don't force the flow.
58
59	## Hand-offs
60
61	- Spec written → `evanflow-writing-plans` (if non-trivial)
62	- Substantial new feature (sprint-sized, multi-stakeholder) → `evanflow-prd` instead of writing-plans
63	- Plan exists → `evanflow-executing-plans` (which itself offers `evanflow-coder-overseer` if the plan has 3+ parallelizable units)
64	- Just go → start with `evanflow-tdd` for the first behavior
65	- Domain term emerged → `evanflow-glossary` to update `CONTEXT.md`
66	- Interface shape is the hard part of the design → `evanflow-design-interface` before writing-plans

People who liked this also viewed

6 picks

Type