prose-synthesize

name	prose-synthesize
description	Prose synthesize: turn unstructured notes into a structured, actionable plan. Use when given brain dumps, stream-of-consciousness, or scattered thoughts needing order.
args	[prose to synthesize]
allowed-tools	Read, Edit, Write, Grep, Glob, TodoWrite
argument-hint	<unstructured thoughts or file path>
created	"2026-02-16T00:00:00.000Z"
modified	"2026-02-16T00:00:00.000Z"
reviewed	"2026-02-16T00:00:00.000Z"

/prose:synthesize

Synthesize unstructured thinking into a structured, actionable plan — impose order on chaos.

When to Use This Skill

Use this skill when...	Use something else when...
User dumps stream-of-consciousness thoughts	Text is already structured but verbose → /prose:distill
Scattered notes need organizing into a plan	Need to capture session learnings → /project:distill
Brain dump needs goals, actions, priorities extracted	Need to write a plan from scratch with no input → /blueprint:init
User says "make sense of this", "organize this"	Document needs style/tone adjustment → prose-tone (planned)

Core Principles

Synthesis is the complement of analysis. Analysis breaks apart; synthesis combines fragments into a coherent whole. The input is scattered thinking — the output is structured intent.

What Makes a Good Synthesized Plan

Each element answers a specific question:

Element	Question it answers
Objective	What are we trying to achieve?
Key decisions	What needs deciding before acting?
Actions	What specific things need doing?
Dependencies	What blocks what?
Open questions	What's still unclear?

Parameters

Parse $ARGUMENTS:

• If prose is provided inline, synthesize it directly
• If a file path is provided, read and synthesize the file contents
• If no arguments, ask the user to provide their unstructured thinking

Execution

Execute this synthesis workflow:

Step 1: Absorb the input

Read all provided text without editing or filtering. Identify:

1. Total volume (rough word count)
2. Density of ideas — scattered vs. loosely organized
3. Whether there's an implicit goal or the user is still exploring
4. Tone — brainstorming, planning, venting, or exploring

Step 2: Extract and tag ideas

Work through the input and internally classify each distinct idea:

• GOAL — something the user wants to achieve
• CONSTRAINT — a limitation or boundary condition
• DECISION — a choice that needs making
• ACTION — a concrete step that could be taken
• QUESTION — something unresolved or uncertain
• CONTEXT — background that informs the plan
• ASIDE — tangential thought (preserve but deprioritize)

Do not discard anything yet. Do not show tags to the user.

Step 3: Cluster by theme

Group ideas into natural clusters:

1. Ideas addressing the same goal
2. Actions depending on the same decision
3. Questions blocking the same cluster of actions

Name each cluster with a short descriptive label.

Step 4: Find the spine

Identify the core through-line — the primary objective connecting the most clusters. This becomes the plan's backbone. Other clusters are supporting or parallel tracks.

Step 5: Build the plan

Structure the output using this format. Include only sections that have content:

## Objective

<1-2 sentence statement of what this plan achieves>

## Key Decisions

<Decisions that need making before or during execution. Note options if the user mentioned them.>

## Plan

<Ordered actions grouped by theme/phase. Numbered lists for sequences, bullets for parallel items.>

## Dependencies

<What blocks what — only if meaningful dependencies exist>

## Open Questions

<Unresolved items needing answers before the plan is complete>

## Parked Ideas

<Tangential thoughts worth preserving but outside the core plan>

Step 6: Validate completeness

Check the plan against the original input:

1. Is every goal addressed?
2. Is every constraint respected?
3. Are the user's questions surfaced, not buried?
4. Did anything important get lost in synthesis?

If the input was exploratory (no clear goal), say so in the objective and frame the plan as "potential directions" rather than commitments.

Handling Ambiguity

Situation	Approach
Multiple possible goals	Present as alternatives under Key Decisions
Contradictory ideas	Surface the contradiction explicitly
Vague but directional	Interpret the direction, note the interpretation
Pure exploration (no goal)	Organize by theme, suggest possible goals

Example

Input: "I need to fix the auth system. Also the tests are broken. Maybe we should move to JWT. The deployment pipeline keeps failing too. Sarah mentioned something about rate limiting. We should probably do a security audit at some point. Oh and the docs are out of date."

Synthesized:

Objective: Stabilize and secure the authentication system while addressing related infrastructure issues.

Key Decisions:

1. JWT migration — move to JWT or fix current auth? (Affects scope of all auth work)

Plan:

1. Fix immediate blockers
   • Fix broken tests (unblocks everything else)
   • Fix deployment pipeline failures
2. Auth system
   • Decide JWT migration
   • Implement fix or migration based on decision
   • Add rate limiting (per Sarah's input)
3. Hardening
   • Security audit
   • Update documentation

Open Questions:

• What specifically did Sarah say about rate limiting?
• What's breaking in the deployment pipeline? (may be auth-related)

Agentic Optimizations

Context	Approach
Short input (< 200 words)	Synthesize inline, present plan directly
Medium input (200-1000 words)	Full synthesis workflow, structured plan output
Long input or file (> 1000 words)	Read file, full synthesis, write plan to file
Already semi-structured input	Preserve existing structure, fill gaps
No clear goal in input	Organize by theme, present as exploration map