prose-plugin/skills/prose-synthesize/SKILL.md
Prose synthesize: turn unstructured notes into a structured, actionable plan. Use when given brain dumps, stream-of-consciousness, or scattered thoughts needing order.
npx skillsauth add laurigates/claude-plugins prose-synthesizeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Synthesize unstructured thinking into a structured, actionable plan — impose order on chaos.
| 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) |
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.
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? |
Parse $ARGUMENTS:
Execute this synthesis workflow:
Read all provided text without editing or filtering. Identify:
Work through the input and internally classify each distinct idea:
Do not discard anything yet. Do not show tags to the user.
Group ideas into natural clusters:
Name each cluster with a short descriptive label.
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.
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>
Check the plan against the original input:
If the input was exploratory (no clear goal), say so in the objective and frame the plan as "potential directions" rather than commitments.
| 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 |
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:
- JWT migration — move to JWT or fix current auth? (Affects scope of all auth work)
Plan:
- Fix immediate blockers
- Fix broken tests (unblocks everything else)
- Fix deployment pipeline failures
- Auth system
- Decide JWT migration
- Implement fix or migration based on decision
- Add rate limiting (per Sarah's input)
- 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)
| 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 |
testing
Verify accumulated bug claims at upstream HEAD and dedup against trackers before filing issues. Use when filing upstream reports from backlogs, audit docs, or git-history findings.
documentation
Gate outward-bound text (upstream issues, docs, PR bodies) through isolated haiku fresh-reader critique before publishing. Use when an artifact must survive a reader with zero project context.
tools
Suggest improvements to SKILL.md content, descriptions, or tool config from eval results. Use when raising pass rates, fixing triggering, or iterating on a skill after evaluation.
tools
deadbranch CLI for stale-branch cleanup — dry-run preview, TUI or non-interactive delete, protects main/develop/WIP. Use when asked to clean up branches, prune branches, or remove stale branches.