AGENT SKILL

brainstorming

Use before creative work — creating features, building components, adding functionality, or modifying behavior — to explore user intent, requirements, and design before implementation. One question at a time; 2–3 approaches; design validated in sections.

使用场景视觉设计
License 许可
MIT
最近更新
2026-11-10
Stars
★ 0
Forks
0

01 前言 Front Matter

name
brainstorming
metadata
{ "owner": "tze", "status": "active", "authors": [ "obra/superpowers (upstream)", "Claude Fable 5.1" ], "last_reviewed": "2026-09-02" }
description
Use before creative work — creating features, building components, adding functionality, or modifying behavior — to explore user intent, requirements, and design before implementation. One question at a time; 2–3 approaches; design validated in sections.

02 资源文件 1

03 SKILL.md 正文

Brainstorming Ideas Into Designs

Overview

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.

The Process

Understanding the idea:

  • Check out the current project state first (files, docs, recent commits)
  • Ask questions one at a time to refine the idea
  • Prefer multiple choice questions when possible, but open-ended is fine too
  • Only one question per message - if a topic needs more exploration, break it into multiple questions
  • Focus on understanding: purpose, constraints, success criteria

Exploring approaches:

  • Propose 2-3 different approaches with trade-offs
  • Present options conversationally with your recommendation and reasoning
  • Lead with your recommended option and explain why

Presenting the design:

  • Once you believe you understand what you're building, present the design
  • Break it into sections of 200-300 words
  • Ask after each section whether it looks right so far
  • Cover: architecture, components, data flow, error handling, testing
  • Be ready to go back and clarify if something doesn't make sense

After the Design

Documentation:

  • Write the validated design to docs/plans/YYYY-MM-DD-<topic>-design.md
  • Commit the design document to git

Implementation (if continuing):

  • Ask: "Ready to set up for implementation?"
  • Create an isolated workspace: a feature branch in its own git worktree (never implement on main/master without explicit consent)
  • Write the implementation plan to docs/plans/YYYY-MM-DD-<topic>.md (ordered tasks, each with its verification step), then hand off to executing-plans

Key Principles

  • One question at a time - Don't overwhelm with multiple questions
  • Multiple choice preferred - Easier to answer than open-ended when possible
  • YAGNI ruthlessly - Remove unnecessary features from all designs
  • Explore alternatives - Always propose 2-3 approaches before settling
  • Incremental validation - Present design in sections, validate each
  • Be flexible - Go back and clarify when something doesn't make sense

04 同仓库更多 Skills

tzeusy-org
tzeusy-org/ai-bootstrap

user-run

Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

requesting-code-review

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

开发工程师代码审查
★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

receiving-code-review

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

开发工程师代码审查
★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

finishing-a-development-branch

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

executing-plans

Use when you have a written implementation plan to execute in a separate session with review checkpoints

★ 0
tzeusy-org
tzeusy-org/ai-bootstrap

dispatching-parallel-agents

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

★ 0