Idea Framing

A lightweight framework for turning a hunch into a clear, defensible concept. Five sections, each answering one question. Works for products, research, art pieces, services — anything that needs to justify itself to a future you (or a collaborator) two months from now.

When to use

Invoke this skill when the user wants to:

• Frame a new idea from scratch ("I've got an idea about X, help me think it through")
• Structure a rough dump of notes into a coherent concept doc
• Critique an existing draft before they share it more widely
• Pick a name for a concept that's still untitled

Detect the mode by what the user provides:

If ambiguous, ask once which mode they want.

The Template

Five sections. Keep them in this order — each builds on the previous.

# <Title>

**Concept:** <one-sentence concept statement>

## Problem
What problem does this solve? For whom? Why does it matter right now?

## Why it's interesting
Why is this worth pursuing? What's the underlying insight or unmet desire?

## State of the art
What existing solutions exist? What do they do well? Where do they fall short?

## Solution
What is your approach, in enough detail to picture it? Why is it better than the state of the art — concretely?

## Technical
What does it take to build? Major components, dependencies, hardest parts.

The Concept line at the top is a single sentence — the elevator pitch. If you can't say it in one sentence yet, that's the first thing to nail.

Mode 1: Guided Q&A

When the user arrives empty-handed or with only a topic, walk through the template one section at a time.

Rules:

• Ask one question per turn. Resist batching — the answers are richer when given full attention.
• Go in template order: Concept → Problem → Why interesting → SOTA → Solution → Technical.
• After each answer, reflect it back as a tightened prose paragraph and confirm before moving on. This catches misreads early and gives the user something concrete to react to.
• When the answer reveals a deeper question (e.g., "who is this really for?"), follow that thread before advancing.
• Don't ask the user to define every term — fill in reasonable interpretations and let them correct.

Opening prompt: "What's the idea, in one sentence? Rough is fine — we'll refine it."

After Concept is captured, offer title candidates (see Title Suggestion below) before moving on.

Mode 2: Dump & Structure

When the user pastes a rough dump or notes, map their content onto the five sections without asking new questions first.

Steps:

1. Read the dump end-to-end.
2. For each section, extract what's already there. Quote or paraphrase from the user's words — don't invent.
3. List explicit gaps: which sections have nothing, which have hand-waves, which contradict.
4. Only then ask follow-up questions, one at a time, targeting the gaps. Skip what's solid.
5. Assemble the final doc once gaps are filled.

A useful framing: "Here's what I pulled from your notes for each section. Three sections look strong, two need more — let's tackle those."

Mode 3: Critique & Refine

When the user provides an existing draft, review it section by section. Be specific and a little adversarial — empty agreement is useless.

Per-section checks:

• Concept: Is it one sentence? Does it actually describe the thing, or just gesture at the space?
• Problem: Is the problem real and felt, or theoretical? Who specifically has it? Why now?
• Why interesting: Does this say more than "it's cool"? What's the non-obvious insight?
• State of the art: Are existing solutions named, or hand-waved as "most services"? Be skeptical of dismissive sweeps — push for concrete examples of what's out there.
• Solution: Does the solution actually solve the stated problem? Is the differentiation from SOTA specific, or generic ("better UX")?
• Technical: Does this read like the author has thought about how to build it, or is it a wishlist? What are the hardest parts — are they acknowledged?

Output format: For each section, give a one-line verdict (Strong / Workable / Weak), then a short critique, then a concrete suggestion. End with the top 2–3 things to fix.

Title Suggestion

After the Concept line is clear (in any mode), offer 3–5 candidate titles. Mix styles:

• Descriptive: says what it is (e.g., "Realtime Voice Network")
• Codename: evocative, non-literal (e.g., "Switchboard", "Hailfrequency")
• Compound/portmanteau: short and brandable (e.g., "Voxcast")
• Phrase / tagline-as-title: captures the feeling (e.g., "Anyone, Listening")

Present them as a numbered list. Note tradeoffs briefly (memorable vs. searchable vs. clear). Let the user pick, mix, or veto — and offer more if none land.

Don't propose titles unsolicited if the user already has one. Ask: "You have a title in mind, or want suggestions?"

Output Format

The final doc uses clean markdown — no decorative emoji, just structure.

# <Title>

**Concept:** <one-line concept>

## Problem
<prose>

## Why it's interesting
<prose>

## State of the art
<prose>

## Solution
<prose>

## Technical
<prose>

Default: print the finished doc inline in the conversation. The user can copy it wherever they want.

Saving

If the user asks to save the result to a file:

• Filename: kebab-case slug of the title + .md (e.g., realtime-voice-network.md).
• Location: current working directory, unless the user specifies otherwise.
• If a file with that name already exists, ask before overwriting.

Don't proactively save — wait to be asked.

Section Guidance Cheatsheet

Quick reference for what "strong" looks like vs. common failure modes.

Worked Example

This is a calibration anchor — what a finished idea-framing doc should feel like.

# Hailfrequency

**Concept:** A real-time, interest-driven audio network where anyone can dial into a conversation about a topic by browsing short voice intros.

## Problem
People want to hear a live voice — especially when something is happening right now. Hotlines and 800 numbers were built on this premise, but they're rigid: you can only call about predefined topics, and you talk to a service, not a peer. There's no way to say "I want to talk to someone, right now, about X."

## Why it's interesting
A firsthand voice in real time carries information that text and indexed video can't — tone, hesitation, freshness. The closest analog (talk radio, podcasts) is one-to-many and asynchronous. No one has built a peer-to-peer, intent-routed version of this for the mainstream.

## State of the art
Discord and Clubhouse offer voice rooms, but discovery is community- and schedule-driven, not intent-driven. Random-pairing apps (Omegle-style) lack topical filtering. Search engines and YouTube return indexed, post-captured media — never a live person. Hotlines are topic-specific but operator-mediated.

## Solution
Two surfaces. **Discovery:** a swipeable feed of 5-second voice intros — each user's elevator pitch for what they want to talk about. Filter by keyword (voice or text search) and geography (radius or country). **Conversation:** a peer-to-peer audio call between the listener and the intro's author, followed by a rating and an optional bookmark. The intro acts as both signal of intent and consent to be called.

Better than SOTA because: discovery is intent-driven (not social-graph), connection is one-to-one (not broadcast), and the medium is live voice (not indexed media).

## Technical
Three client roles: intro discovery, intro creation, peer-to-peer call. Server provides the intro directory, search (voice-to-text + keyword index), and call signaling. Real-time audio uses WebRTC over a TURN/STUN backbone. Hardest parts: discovery ranking that surfaces freshness without becoming a popularity contest; moderation of voice content at scale.