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 trivial single-fact lookup? Only a question answerable from one fact with no research, retrieval, or judgment skips planning — answer it directly and stop, in the user's terms. Do not narrate that it "isn't a planning task" or explain the routing; that is process exhaust (see Veil of value below). Examples: "zsh: command not found: brew", "what's the capital of France." A question that needs multiple steps, any retrieval, or synthesis to answer well does not qualify: it is an answer-seeking task (see Disposition below), not a quick-help exit. When unsure, do not exit.
• Pipeline mode? If invoked from lfg or any disable-model-invocation context: tell the user this is a non-software task, lfg requires the software-only ce-work path, and they should invoke ce-plan directly for non-software planning. For this user-runnable output, default to /ce-plan; use $ce-plan only on Codex or a host explicitly documented as dollar-prefixed. Render only the invocation as inline code and output one form only, then stop.
• Unified artifact guard. Universal-planning outputs are not software implementation plans. Do not label them artifact_contract: ce-unified-plan/v1 and do not produce an implementation launch block unless the deliverable itself is a complete software implementation plan with Product Contract, Planning Contract, Implementation Units, Verification Contract, and Definition of Done.

Once past these checks, commit to the task — do not bail because it looks like a "lookup" or "research question." The user invoked the planning tool on purpose. Then choose the disposition below.

Disposition: plan-seeking vs. answer-seeking

Two kinds of task land here, with different deliverables:

• Plan-seeking — the deliverable is a plan: a trip itinerary, a study curriculum, an event runbook, a project plan. The plan is the artifact, saved or shared. → Follow Steps 1-3 below.
• Answer-seeking — the deliverable is an answer: an investigative or analytical question ("how often does X happen — is it a big deal?", "how does our approach compare to Y?", "should we Z?"). No one wants a saved plan document for this; planning is the means to a good answer, not the output. → Follow the Answer-seeking flow below; skip the Step 3 artifact handling.

If a request blends both ("research X, then plan Y"), do the answer-seeking research first, then produce the plan artifact.

Commit to one disposition before reading further, and follow only that flow: a plan-seeking task still produces its plan document (Steps 1-3) and does not stop at a chat answer; an answer-seeking task does not write a plan file.

Answer-seeking flow

The planning instinct still applies — but the plan is working scaffold, not an artifact. State it in chat to steer the work and show the human the approach; execute it; discard it. No plan file is written.

State a brief plan-of-attack, then proceed

Say how the question will be answered, right-sized to it: a light question gets a one-line approach; a multi-part analytical question gets a short bulleted plan (a few steps). This is non-blocking — announce the approach and continue immediately. Do not ask the user to approve the plan; the stated approach is itself the checkpoint, and the user can interrupt if the framing is wrong. Stop to ask only on a genuine fork the agent cannot resolve (e.g., "his personal account or the org's?").

Execute the plan

Carry out the approach. When the answer depends on facts the model can't reliably supply from memory — current data, recent events, specifics that drift — gather them using the Research decomposition pattern under Step 1 below (decompose into focused questions, dispatch in parallel via the platform's subagent/web primitive, collate). Skip research for anything the model already knows well.

Ground answers about the user's own code, repo, or named artifacts in the actual sources — not memory. When the question references local code, a specific file, a named CLI or service, or "our X", read those sources first (and any resource the user named — see Core Principle 8 in SKILL.md). "The model already knows the topic" covers general knowledge only, never the contents of the user's codebase: a comparison or recommendation about local code that was never read is ungrounded. Inspect, then answer.

Execution here is research and analysis only — never code. Reading code and artifacts to understand them is in-bounds research; writing or running code to change the system is not — that belongs in ce-work. This keeps the planning/execution boundary intact.

Deliver the answer

Answer in chat. Do not write a plan file and do not run the Step 3 save/share menu by default. If the investigation produced something the user might want to keep (a comparison table, a sourced summary), offer to save it; otherwise just give the answer. In headless or non-interactive runs, skip the offer and deliver the answer.

Veil of value: what to show, what to hide

The plan-of-attack and the answer are for the caller; the skill's internal machinery is not. Edit for relevance the way an expert consultant does — they tell you their thinking about your problem, not which template their back office applied.

• Show (question-domain — reads as value): the approach to the user's actual question, in the user's terms.
• Hide (skill-domain — process exhaust): which skill, mode, or phase is running; whether a plan file was or wasn't written; the routing or disposition decision itself.
• Never hide (audit content — affects trust in the answer): caveats, gaps, and uncertainty. "I could only pull his last ~100 stars, so this is partial" or "this is my read, not a hard signal" is not junk — it is what a good assistant says out loud. The veil hides plumbing, never the limits of the answer.

Register example, for "how often does he star things — is this a big deal?":

Wrong: "Quick note first: ce-plan builds implementation plans, so I ignored the template and just answered the question. Here's what the data says..."

Leaks the skill's name, narrates an internal routing decision, apologizes for deviating — the caller sees the tool's machinery.

Right: "Let me size this up — I'll check how active a starrer he is overall, his recent cadence, and the kinds of repos he tends to star, then weigh where this one lands. [gathers data] Yes, this is a real signal: ..."

Same underlying process; none of the machinery shows. The caller sees thinking about their question.

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?

If the user's or project's active instructions or the live prompt name a model for this subagent, use that model instead of the default tier above. They can name it by the subagent's tier, by its prompt-asset name, or for the subagents being dispatched. Without such an instruction, a model configured for this subagent's role takes precedence over the default tier.

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 research. Prefer user-named surfaces first per Core Principle 8 in SKILL.md; fall back to web search for questions those surfaces don't cover.
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 host's blocking question tool already in the current tool list (match by capability, not by a host-specific name). Presence in the current tool list is proof the tool exists; never call a user-facing question tool to discover whether it exists. If a matching tool is listed but unloaded, use the host's tool-discovery primitive to load that capability — do not search for another host's tool name. Fall back to numbered options on the host's user-visible chat surface only when no such tool is in the list or a real question call errors. Never silently skip the question.

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:

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 host's blocking question tool already in the current tool list (match by capability, not by a host-specific name). Fall back to numbered options on the host's user-visible chat surface only when no such tool is in the list or a real question call errors. Never silently skip the question.

Question: "Plan ready. How would you like to receive it?"

Options:

1. Save to disk — Write the plan as a markdown file. Ask where:
2. <root>/plans/ (only show if this directory exists)
3. Current working directory
4. /tmp
5. A custom path
6. Use filename convention: YYYY-MM-DD-HHMM-<descriptive-name>-plan.md, taking HHMM from the local wall-clock time at write; reserve the path atomically and, on collision, retry with the smallest available numeric suffix before the extension rather than overwriting
7. Start the document with a # Title heading, followed by Created: YYYY-MM-DD on the next line. No YAML frontmatter.

1. Save to disk and publish a copy — Shown only when references/publishing.md chooses a publisher (one the user named, or the host's artifact tool); label it with that destination. Write the file as in option 1 first, then follow references/publishing.md to publish a copy and return the URL. The local file stays canonical.

Do not offer ce-work (software-only) or issue creation (not applicable to non-software plans).