AgentSkillsCN

Brainstorming Ideas Into Designs

在合作伙伴描述任何博客或通讯创意时，采用苏格拉底式方法进行互动式想法打磨，以形成完善的方案，然后再撰写推介或文章。

SKILL.md
--- frontmatter
name: Brainstorming Ideas Into Designs
description: Interactive idea refinement using Socratic method to develop fully-formed designs when partner describes any blog or newsletter idea, before writing a pitch or articles

Brainstorming Ideas Into Designs

Overview

Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.

Core principle: Ask questions to understand, explore alternatives, present design incrementally for validation.

Announce at start: "I'm using the Brainstorming skill to refine your idea into a pitch."

The Process

Phase 1: Understanding

  • •Check current state by reading the post, 'discussion.md' and other materials in the post folder
  • •Ask ONE question at a time to refine the idea
  • •Prefer multiple choice when possible
  • •Gather: Purpose, constraints, success criteria

Phase 2: Exploration

  • •Propose 2-3 different approaches
  • •For each: Core architecture, trade-offs, complexity assessment

For blog posts — vulnerability framing: When exploring emotional hooks or opening angles, FIRST ask: "What personal experience from your own life connects to this topic?" Use the user's answer as the source. Do not construct a vulnerability from the subject matter itself — it must come from a real experience the user shares.

  • •Ask your human partner which approach resonates

Phase 3: Presentation

  • •For a new pitch: present in one or two paragraphs
  • •To edit an outline or post: show what you intend to change
  • •Ask after each section: "Does this look right so far?"

Phase 4: Implementation

When the pitch or idea is approved and implementation will follow:

  • •New pitch: save the pitch in the post folder
  • •Edit an outline or post: make the change

Phase 5: Record discussion

Create or update the 'discussion.md' in the post folder using recorder skill.

When to Revisit Earlier Phases

You can and should go backward when:

  • •Partner reveals new constraint during Phase 2 or 3 → Return to Phase 1 to understand it
  • •Validation shows fundamental gap in requirements → Return to Phase 1
  • •Partner questions approach during Phase 3 → Return to Phase 2 to explore alternatives
  • •Something doesn't make sense → Go back and clarify

Don't force forward linearly when going backward would give better results.

Remember

  • •One question per message during Phase 1
  • •Apply YAGNI ruthlessly
  • •Explore 2-3 alternatives before settling
  • •Present incrementally, validate as you go
  • •Go backward when needed - flexibility > rigid progression
  • •Announce skill usage at start
  • •For blog posts and newsletters, reference /docs/Houfu_Voice_Guide.md when exploring approaches
  • •Houfu's voice favors: frameworks over advice, nuance over binary thinking, vulnerable admissions over polished authority