feat(ce-plan,ce-brainstorm): universal planning and brainstorming for non-software tasks (#519)
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Trevin Chow
@@ -0,0 +1,110 @@
|
||||
# Universal Planning Workflow
|
||||
|
||||
This file is loaded when ce:plan detects a non-software task (Phase 0.1b). It replaces the software-specific phases (0.2 through 5.1) with a domain-agnostic planning workflow.
|
||||
|
||||
## Before starting: verify classification
|
||||
|
||||
The detection stub in SKILL.md routes here for anything that isn't clearly software. Verify the classification is correct before proceeding:
|
||||
|
||||
- **Is this actually a software task?** The key distinction is task-type, not topic-domain. A study guide about Rust is non-software (producing educational content). A Rust library refactor is software (modifying code). If this is actually software, return to Phase 0.2 in the main SKILL.md.
|
||||
- **Is this a quick-help request, not a planning task?** Error messages, factual questions, and single-step tasks don't need a plan. Respond directly and exit. Examples: "zsh: command not found: brew", "what's the capital of France."
|
||||
- **Pipeline mode?** If invoked from LFG, SLFG, or any `disable-model-invocation` context: output "This is a non-software task. The LFG/SLFG pipeline requires ce:work, which only supports software tasks. Use `/ce:plan` directly for non-software planning." and stop.
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Assess Ambiguity and Research Need
|
||||
|
||||
Evaluate two things before planning:
|
||||
|
||||
**Would 1-3 quick questions meaningfully improve this plan?**
|
||||
|
||||
- **Default: ask 1-3 questions** via Step 1b when the answers would change the plan's structure or content. Always include a final option like "Skip — just make the plan with reasonable assumptions" so the user can opt out instantly.
|
||||
- **Skip questions entirely** only when the request already specifies all major variables or the task is simple enough that reasonable assumptions cover it well.
|
||||
|
||||
**Research need — does this plan depend on facts that change faster than training data?**
|
||||
|
||||
| Research need | Signals | Action |
|
||||
|--------------|---------|--------|
|
||||
| **None** | Generic, timeless, or conceptual plan (study curriculum methodology, project management approach, personal goal breakdown) | Skip research. Model knowledge is sufficient. After structuring the plan, offer: "I based this on general knowledge. Want me to search for [specific thing research would improve]?" — e.g., sourced recipes, current product recommendations, expert frameworks. Only if the user accepts. |
|
||||
| **Recommended** | Plan references specific locations, venues, dates, prices, schedules, seasonal availability, or current events — anything where stale information would break the plan (closed restaurants, changed prices, cancelled events, wrong seasonal dates). | Research before planning. Decompose into 2-5 focused research questions and dispatch parallel web searches. In Claude Code, use the Agent tool with `model: "haiku"` for each search to reduce cost. Collate findings before structuring the plan. |
|
||||
|
||||
When research is recommended, do it — don't just offer. Stale recommendations (closed restaurants, rethemed attractions, outdated prices) are worse than no recommendations. The user invoked `/ce:plan` because they want a good plan, not a disclaimer about training data.
|
||||
|
||||
**Research decomposition pattern:**
|
||||
1. Identify 2-5 independent research questions based on the task. Good questions target facts the model is least confident about: current prices, hours, availability, recent changes, seasonal specifics.
|
||||
2. Dispatch parallel web searches (one per question). Keep queries broad at first, then narrow based on findings.
|
||||
3. Collate findings into a brief research summary before proceeding to planning.
|
||||
|
||||
Example for "plan a date night in Seattle this Saturday":
|
||||
- "Best restaurants open late Saturday in Capitol Hill Seattle 2026"
|
||||
- "Events happening in Seattle [specific date]"
|
||||
- "Seattle waterfront current status and hours"
|
||||
|
||||
## Step 1b: Focused Q&A
|
||||
|
||||
Ask up to 3 questions targeting the unknowns that would most change the plan. Use the platform's question tool when available (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini). Otherwise, present numbered options in chat and wait for the user's reply.
|
||||
|
||||
**How to ask well:**
|
||||
- Offer informed options, not open-ended blanks. Instead of "When are you going?", try "Mid-week visits have 30-40% shorter lines — are you flexible on timing?" The question should give the user a frame of reference, not just extract information.
|
||||
- Use multi-select when several independent choices can be captured in one question. This is compact and respects the user's time.
|
||||
- Always include a final option like **"Skip — just make the plan with reasonable assumptions"** so the user can opt out at any point.
|
||||
|
||||
Focus on the unknowns specific to this task that would change what the plan recommends or how it's structured. Do not ask more than 3 — after that, proceed with assumptions for anything remaining.
|
||||
|
||||
## Step 2: Structure the Plan
|
||||
|
||||
Create a structured plan guided by these quality principles. Do NOT use the software plan template (implementation units, test scenarios, file paths, etc.).
|
||||
|
||||
### Format: when to prescribe vs. present options
|
||||
|
||||
Not every plan should be a single linear path. Match the format to the task:
|
||||
|
||||
| Task type | Best format | Why |
|
||||
|-----------|------------|-----|
|
||||
| **High personal preference** (food, entertainment, activities, gifts) | Curated options per category — present 2-3 choices and let the user compose | Preferences vary; a single pick may miss. Options respect the user's taste. |
|
||||
| **Logical sequence** (study plan, project timeline, multi-day trip logistics) | Single prescriptive path with clear ordering | Sequencing matters; options at each step create decision paralysis. |
|
||||
| **Hybrid** (event with fixed structure but variable details) | Fixed structure with choice points marked | The skeleton is set but specific vendors/venues/activities are options. |
|
||||
|
||||
Example: A date night plan should present 2-3 restaurant options, 2-3 activity options, and a suggested flow — not pick one restaurant and build the whole evening around it. A study plan should prescribe a single weekly progression — not present 3 different curricula to choose from.
|
||||
|
||||
### Formatting: bullets over prose
|
||||
|
||||
- Prefer bullets and tables for actionable content (steps, options, logistics, budgets)
|
||||
- Use prose only for context, rationale, or explanations that connect the dots
|
||||
- Plans are for scanning and executing, not reading cover-to-cover
|
||||
|
||||
### Quality principles
|
||||
|
||||
- **Actionable steps**: Each step is specific enough to execute without further research
|
||||
- **Sequenced by dependency**: Steps are in the right order, with dependencies noted
|
||||
- **Time-aware**: When relevant, include timing, durations, deadlines, or phases
|
||||
- **Resource-identified**: Specify what's needed — tools, materials, people, budget, locations
|
||||
- **Contingency-aware**: For important decisions, note alternatives or what to do if plans change
|
||||
- **Appropriately detailed**: Match detail to task complexity. A weekend trip needs less structure than a 3-month curriculum. A dinner plan should be concise, not a 200-line document.
|
||||
- **Domain-appropriate format**: Choose a structure that fits the domain:
|
||||
- Itinerary for travel (day-by-day, with times and locations)
|
||||
- Syllabus or curriculum for study plans (topics, resources, milestones)
|
||||
- Runbook for events (timeline, responsibilities, logistics)
|
||||
- Project plan for business or operational tasks (phases, owners, deliverables)
|
||||
- Research plan for investigations (questions, methods, sources)
|
||||
- Options menu for preference-driven tasks (curated picks per category)
|
||||
|
||||
## Step 3: Save or Share
|
||||
|
||||
After structuring the plan, ask the user how they want to receive it using the platform's question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini). Otherwise, present numbered options in chat.
|
||||
|
||||
**Options:**
|
||||
|
||||
1. **Save to disk** — Write the plan as a markdown file. Ask where:
|
||||
- `docs/plans/` (only show if this directory exists)
|
||||
- Current working directory
|
||||
- `/tmp`
|
||||
- A custom path
|
||||
- Use filename convention: `YYYY-MM-DD-<descriptive-name>-plan.md`
|
||||
- Start the document with a `# Title` heading, followed by `Created: YYYY-MM-DD` on the next line. No YAML frontmatter.
|
||||
|
||||
2. **Share to Proof** — View the plan on the web and get a shareable link. Load the `proof` skill to create and share the document. Useful for sharing with others who aren't in the terminal.
|
||||
|
||||
3. **Both** — Save to disk and share to Proof.
|
||||
|
||||
Do not offer `/ce:work` (software-only) or issue creation (not applicable to non-software plans).
|
||||
Reference in New Issue
Block a user