diff --git a/plugins/compound-engineering/skills/ce-plan/SKILL.md b/plugins/compound-engineering/skills/ce-plan/SKILL.md index f5a9176..2ef260b 100644 --- a/plugins/compound-engineering/skills/ce-plan/SKILL.md +++ b/plugins/compound-engineering/skills/ce-plan/SKILL.md @@ -39,6 +39,7 @@ If the input is present but unclear or underspecified, do not abandon — ask on 5. **Separate planning from execution discovery** - Resolve planning-time questions here. Explicitly defer execution-time unknowns to implementation. 6. **Keep the plan portable** - The plan should work as a living document, review artifact, or issue body without embedding tool-specific executor instructions. 7. **Carry execution posture lightly when it matters** - If the request, origin document, or repo context clearly implies test-first, characterization-first, or another non-default execution posture, reflect that in the plan as a lightweight signal. Do not turn the plan into step-by-step execution choreography. +8. **Honor user-named resources** - When the user names a specific resource — a CLI, MCP server, URL, file, doc link, or prior artifact — treat it as authoritative input, not a suggestion. Discover it if unknown (`command -v`, fetch, read) before assuming it's unavailable. Use it in place of generic alternatives. If it fails or doesn't exist, say so explicitly rather than silently substituting. ## Plan Quality Bar @@ -81,11 +82,9 @@ If the plan already has a `deepened: YYYY-MM-DD` frontmatter field and there is If the task involves building, modifying, or architecting software (references code, repos, APIs, databases, or asks to build/modify/deploy), continue to Phase 0.2. -If the task is about a non-software domain and describes a multi-step goal worth planning, read `references/universal-planning.md` and follow that workflow instead. Skip all subsequent phases. +Otherwise, read `references/universal-planning.md` and follow that workflow instead. Skip all subsequent phases. Named tools or source links don't change this routing — they're inputs, handled per Core Principle 8. -If genuinely ambiguous (e.g., "plan a migration" with no other context), ask the user before routing. - -For everything else (quick questions, error messages, factual lookups) **only when auto-selected**, respond directly without any planning workflow. When directly invoked by the user, treat the input as a planning request — ask clarifying questions if needed, but do not exit the workflow. +If the domain is genuinely ambiguous (e.g., "plan a migration" with no other context), ask the user before routing. #### 0.2 Find Upstream Requirements Document diff --git a/plugins/compound-engineering/skills/ce-plan/references/universal-planning.md b/plugins/compound-engineering/skills/ce-plan/references/universal-planning.md index 5773008..dc9a3be 100644 --- a/plugins/compound-engineering/skills/ce-plan/references/universal-planning.md +++ b/plugins/compound-engineering/skills/ce-plan/references/universal-planning.md @@ -7,9 +7,10 @@ This file is loaded when ce:plan detects a non-software task (Phase 0.1b). It re 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. +Once past these checks, commit to producing a plan. Do not exit because the task looks like a "lookup" or "research question" — the user invoked `ce:plan` because they want a structured output. + --- ## Step 1: Assess Ambiguity and Research Need @@ -32,7 +33,7 @@ When research is recommended, do it — don't just offer. Stale recommendations **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. +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":