From 320a04524142830a40a44bd72c4bf5d30931221c Mon Sep 17 00:00:00 2001 From: Trevin Chow Date: Sun, 5 Apr 2026 23:53:13 -0700 Subject: [PATCH] feat(ce-plan,ce-brainstorm): universal planning and brainstorming for non-software tasks (#519) Co-authored-by: Claude Opus 4.6 (1M context) --- ...6-04-05-universal-planning-requirements.md | 87 ++++++ ...-04-05-001-feat-universal-planning-plan.md | 290 ++++++++++++++++++ plugins/compound-engineering/README.md | 2 +- .../skills/ce-brainstorm/SKILL.md | 21 +- .../references/universal-brainstorming.md | 52 ++++ .../skills/ce-plan/SKILL.md | 20 +- .../ce-plan/references/universal-planning.md | 110 +++++++ .../compound-engineering/skills/lfg/SKILL.md | 2 +- .../compound-engineering/skills/slfg/SKILL.md | 2 +- 9 files changed, 578 insertions(+), 8 deletions(-) create mode 100644 docs/brainstorms/2026-04-05-universal-planning-requirements.md create mode 100644 docs/plans/2026-04-05-001-feat-universal-planning-plan.md create mode 100644 plugins/compound-engineering/skills/ce-brainstorm/references/universal-brainstorming.md create mode 100644 plugins/compound-engineering/skills/ce-plan/references/universal-planning.md diff --git a/docs/brainstorms/2026-04-05-universal-planning-requirements.md b/docs/brainstorms/2026-04-05-universal-planning-requirements.md new file mode 100644 index 0000000..af92249 --- /dev/null +++ b/docs/brainstorms/2026-04-05-universal-planning-requirements.md @@ -0,0 +1,87 @@ +--- +date: 2026-04-05 +topic: universal-planning +--- + +# Universal Planning: Non-Software Task Support for ce:plan and ce:brainstorm + +## Problem Frame + +Users naturally reach for `/ce:plan` to plan any multi-step task — trip itineraries, study plans, content strategies, research workflows. Currently, the model self-gates and refuses non-software tasks because ce:plan's language is heavily software-centric ("implementation units", "test scenarios", "repo patterns"). This forces users back to unstructured prompting for non-software work, losing the structured thinking that makes ce:plan valuable. + +The structured thinking behind ce:plan — breaking down ambiguity, researching context, sequencing steps, identifying dependencies — is domain-agnostic. The skill's value proposition should not be limited to software. + +**Why a conditional path instead of just softening language:** Softening the self-gating language in SKILL.md would be cheaper and might stop the refusal. But the value of ce:plan for non-software tasks comes from the structured workflow — ambiguity assessment, research orchestration, quality-guided output, and a durable plan file. Without the non-software path, the model would attempt to follow software-specific phases (repo research, implementation units, test scenarios) on a non-software task, producing a worse result than a direct prompt. The conditional path lets non-software tasks benefit from structured thinking without fighting software-specific structure. + +See: [GitHub issue #517](https://github.com/EveryInc/compound-engineering-plugin/issues/517) + +## Requirements + +**Skill Description and Trigger Language** + +- R1. ce:plan's YAML `description` and trigger phrases are updated to include non-software planning. The model reads this description when deciding which skill to invoke — if triggers only mention software concepts, the internal detection logic never fires. Example: *"Create structured plans for any multi-step task — software features, research workflows, events, study plans, or any goal that benefits from structured breakdown."* + +**Detection and Routing** + +- R2. ce:plan detects whether a task is software-related or not early in Phase 0, before searching for requirements docs or launching software-specific research agents +- R3. Detection error policy: false positives (software task routed to non-software path) are worse than false negatives (non-software task staying on software path), because a false positive skips repo research and produces a disconnected plan. When detection is ambiguous, ask the user rather than guessing. Default to software path when uncertain. +- R4. ce:brainstorm: verify whether it actually self-gates on non-software tasks. If it doesn't (its description is already domain-agnostic), no changes needed — its existing Phase 4 handoff to ce:plan already works. If it does self-gate, soften the gating language so it stops refusing. ce:plan owns the non-software planning path; ce:brainstorm only needs to not block the flow. + +**Non-Software Planning Path in ce:plan (Core — Phase 1)** + +- R5. When a non-software task is detected, ce:plan skips Phases 0.2-0.5 and Phase 1 (all software-specific) and loads a reference file (`references/universal-planning.md`) containing the alternative workflow. Existing Phase 5.2 (Write Plan File) and Phase 5.4 (Handoff options) are reusable; Phase 5.3 (Confidence Check with software-specific agents) is not. +- R6. The non-software path assesses ambiguity: is the request clear enough to plan directly, or does it need clarification first? +- R7. When clarification is needed, the non-software path runs focused Q&A inline — up to 3 questions as a guideline, not a hard cap — targeting the most impactful clarifying questions. Stop when remaining ambiguity is acceptable to defer to plan execution. +- R8. The plan output is guided by quality principles (what makes a great plan), not a prescribed template. The model decides the format based on the task domain + +**Non-Software Planning Path (Extensions — Phase 2, after core validation)** + +- R9. The non-software path can invoke web search directly (no new MCP integrations or research subsystems) when the task benefits from external context. The main skill collates findings inline. +- R10. The non-software path can still interact with local files when the task involves them (e.g., "read these materials and create a study plan") + +**Token Cost Management** + +- R11. The non-software path lives entirely in reference files loaded conditionally via backtick paths. Main SKILL.md changes are minimal — detection stub only +- R12. The software planning path remains completely unchanged — negligible token cost increase for software-only users (detection stub only) + +## Success Criteria + +- `/ce:plan a 3 day trip to Disney World with 2 kids ages 11 and 13` produces a thoughtful, structured plan instead of refusing +- `/ce:plan look at the materials in this folder and create a study plan` reads local files and produces a study plan +- `/ce:brainstorm plan my team offsite` produces a structured plan (verify — may already work without changes) +- `/ce:plan plan the database migration to support multi-tenancy` routes to the software path (boundary case — software despite "plan" and "migration") +- `/ce:plan plan our team's migration to the new office` routes to the non-software path (boundary case — non-software despite "migration") +- Software tasks continue to work identically — no regression +- Non-software detection adds negligible tokens to the software path + +## Scope Boundaries + +- Not building domain-specific planning templates (travel, education, etc.) — the model adapts format to domain +- Not changing the software planning path in ce:plan at all +- Not adding non-software support to ce:work or other downstream skills — those remain software-focused +- Not adding MCP integrations or domain-specific research tools — use existing web research capabilities +- Pipeline mode (LFG/SLFG): non-software tasks are not supported. Detection should short-circuit the pipeline gracefully rather than producing a plan that ce:work cannot execute. The short-circuit contract (what ce:plan returns, how LFG's retry gate handles it) is deferred to planning. + +## Key Decisions + +- **ce:plan owns universal planning, not ce:brainstorm**: The durable output is a plan file. Brainstorming Q&A is a means to an end, not a separate non-software workflow. ce:plan does its own focused Q&A when needed. +- **No prescribed template for non-software outputs**: Impossible to anticipate all domains. Quality principles guide the model; format is emergent. +- **Reference file extraction**: Non-software path in `references/universal-planning.md` keeps token costs down and avoids bloating the main skill for software users. +- **Default to software when uncertain**: False positives (software → non-software) are costlier than false negatives (non-software → software). When ambiguous, ask the user. +- **Non-software plan file location is user-chosen.** Before writing, prompt the user with options: (a) `docs/plans/` if it exists, (b) current working directory, (c) `/tmp`, or (d) a path they specify. Frontmatter omits software-specific fields (`type: feat|fix|refactor`). Filename convention (`YYYY-MM-DD--plan.md`) applies regardless of location. +- **Incremental delivery**: Core path (R5-R8) first — detection, ambiguity assessment, quality-guided output. Extensions (R9-R10) — research orchestration, local file interaction — added after core validation. + +## Outstanding Questions + +### Deferred to Planning + +- [Affects R2][Technical] What heuristics should the detection use? Likely a combination of: does the request reference code/repos/files in a software context, specific programming languages, software concepts? Needs to handle ambiguous cases like "plan a migration" (could be data migration or office migration). Error policy (R3) constrains the design: default to software, ask when uncertain. +- [Affects R8][Technical] What output quality principles produce the best non-software plans? Define these directly during planning — principles like specificity, sequencing, resource identification, contingency planning — rather than running a separate research effort. +- [Affects R9][Technical] Which research mechanisms work best for non-software tasks? WebSearch/WebFetch directly, or best-practices-researcher adapted for non-software topics? Defer until core path is validated. +- [Affects R4][Technical] Does ce:brainstorm actually self-gate on non-software tasks? Verify before building detection there. Its description appears domain-agnostic — changes may be unnecessary. Note: even if it doesn't self-gate, its Phase 1.1 repo scan would waste tokens finding nothing on a non-software task. Decide whether that's acceptable or needs a skip. +- [Affects R5][Technical] Non-software plan file location: prompt the user with options (docs/plans/ if it exists, CWD, /tmp, or custom path). Only show docs/plans/ option when the directory exists. +- [Affects pipeline][Technical] LFG/SLFG short-circuit contract: does ce:plan write a stub file, return an error, or produce no file? LFG has a hard gate that retries if no plan file exists — the contract must satisfy or bypass that gate. + +## Next Steps + +-> `/ce:plan` for structured implementation planning diff --git a/docs/plans/2026-04-05-001-feat-universal-planning-plan.md b/docs/plans/2026-04-05-001-feat-universal-planning-plan.md new file mode 100644 index 0000000..fc8ae7c --- /dev/null +++ b/docs/plans/2026-04-05-001-feat-universal-planning-plan.md @@ -0,0 +1,290 @@ +--- +title: "feat: Add universal planning support for non-software tasks" +type: feat +status: completed +date: 2026-04-05 +origin: docs/brainstorms/2026-04-05-universal-planning-requirements.md +--- + +# feat: Add universal planning support for non-software tasks + +## Overview + +ce:plan currently self-gates on non-software tasks because its description, trigger phrases, and workflow phases are all software-specific. This plan adds a detection stub to Phase 0 that identifies non-software tasks early and routes them to a dedicated reference file (`references/universal-planning.md`) containing a domain-agnostic planning workflow. The software path is completely unchanged. + +## Problem Frame + +Users reach for `/ce:plan` for any multi-step planning — trip itineraries, study plans, team offsites. The model refuses because ce:plan's language signals software-only use. The structured thinking (ambiguity assessment, research, sequencing, dependencies) is domain-agnostic; only the current implementation is software-specific. (see origin: `docs/brainstorms/2026-04-05-universal-planning-requirements.md`) + +## Requirements Trace + +- R1. Update ce:plan YAML description and trigger phrases for non-software planning +- R2. Detect non-software tasks early in Phase 0 +- R3. Error policy: default to software when uncertain, ask when ambiguous +- R4. Verify ce:brainstorm doesn't self-gate (confirmed: it doesn't — no changes needed) +- R5. Non-software path loads `references/universal-planning.md`, skips Phases 0.2 through 5.1 (all software-specific phases) +- R6. Ambiguity assessment before planning +- R7. Focused inline Q&A (~3 questions guideline) +- R8. Quality principles guide output, not a template +- R9. Web research capability (Phase 2 extension — not in this plan) +- R10. Local file interaction (Phase 2 extension — not in this plan) +- R11. Reference file extraction for token cost management +- R12. Negligible token cost increase for software users + +## Scope Boundaries + +- Software planning path is NOT modified — zero changes to Phases 0.2-5.4 +- ce:brainstorm NOT modified — verified domain-agnostic, no self-gating +- ce:work NOT modified — remains software-only +- R9 (web research) and R10 (local files) deferred to Phase 2 extension +- No domain-specific templates — quality principles only +- Pipeline mode (LFG/SLFG): non-software tasks produce a stop message, not a plan + +## Context & Research + +### Relevant Code and Patterns + +- `plugins/compound-engineering/skills/ce-plan/SKILL.md` — 688-line skill with phased workflow (0.1-5.4). Detection inserts at Phase 0.1b (after resume, before requirements doc search). +- `plugins/compound-engineering/skills/ce-plan/references/` — existing reference files loaded via backtick paths: `deepening-workflow.md` (Phase 5.3), `plan-handoff.md` (Phase 5.4), `visual-communication.md` (Phase 4.4). Pattern: "read `references/.md` for [what it contains]" +- `plugins/compound-engineering/skills/ce-brainstorm/SKILL.md` — description is domain-agnostic ("Explore requirements and approaches through collaborative dialogue"). Does not self-gate. +- `plugins/compound-engineering/skills/lfg/SKILL.md` — pipeline gate at step 2: "Verify that the ce:plan workflow produced a plan file in `docs/plans/`. If no plan file was created, run `/ce:plan $ARGUMENTS` again." Must handle non-software gracefully. +- `plugins/compound-engineering/skills/slfg/SKILL.md` — similar pipeline, step 2 records plan path from `docs/plans/`. + +### Institutional Learnings + +- `docs/solutions/skill-design/beta-skills-framework.md` — Config-driven routing within a single SKILL.md was rejected due to instruction blending risk. Our approach (early detection stub that branches to a reference file) is the recommended pattern: "clear, early context-detection phase that sets the mode before instructions diverge." +- `docs/solutions/skill-design/compound-refresh-skill-improvements.md` — Auto-detection of context to switch modes is unreliable; explicit arguments are safer. Mitigated by R3 error policy (default to software, ask when uncertain). Known tradeoff worth monitoring. +- `docs/solutions/skill-design/research-agent-pipeline-separation-2026-04-05.md` — Don't skip research entirely for non-software tasks; substitute rather than remove. Core path defers research to Phase 2 extension. +- `docs/solutions/skill-design/git-workflow-skills-need-explicit-state-machines-2026-03-27.md` — Use explicit state checks for conditional behavior, not prose-described hedging. Detection uses structured signal lists, not vague instructions. + +## Key Technical Decisions + +- **Detection as explicit state checks, not prose**: Detection uses enumerated software signals (code references, programming languages, APIs, etc.) and classifies based on presence/absence, not vague heuristic matching. This follows the state-machine learning. +- **Reference file extraction justified**: The non-software workflow is ~80-100 lines of entirely different phase instructions. This exceeds the "~20% of skill content, conditional" threshold for extraction per the Plugin AGENTS.md compliance checklist. +- **Self-contained reference file**: `references/universal-planning.md` handles its own write and handoff rather than reusing Phase 5.2 and plan-handoff.md, because the handoff options differ substantially (no ce:work, no issue creation, user-chosen file location). This duplicates ~8 lines of Proof upload logic and the file-write step. Accepted tradeoff: self-containment is simpler to maintain than conditional notes threaded through the software phases. +- **Pipeline mode stop signal**: In pipeline mode, detection outputs a clear message and stops. LFG/SLFG get a one-line addition to handle this gracefully rather than retrying. +- **No ce:brainstorm changes**: Verified domain-agnostic. Repo scan waste on non-software tasks is acceptable — optimizing it is a separate concern. + +## Open Questions + +### Resolved During Planning + +- **Detection heuristics**: Use explicit signal lists (software: code/repo/language/API/database/test references; non-software: clearly non-software domain + no software signals). Default to software when uncertain. +- **Quality principles**: Actionable steps, dependency-sequenced, time-aware, resource-identified, contingency-aware, appropriately detailed, domain-appropriate format. +- **ce:brainstorm self-gating**: Confirmed domain-agnostic. No changes needed. +- **LFG/SLFG contract**: ce:plan outputs a stop message; LFG/SLFG get a note to handle non-software gracefully. +- **Plan file location**: User-chosen via prompt (docs/plans/ if exists, CWD, /tmp, or custom). + +### Deferred to Implementation + +- **Exact detection wording**: The signal lists are defined but exact phrasing will be refined during implementation to avoid instruction blending. +- **Quality principle effectiveness**: May need tuning after manual testing with diverse non-software prompts. +- **Research opt-in UX (Phase 2 extension)**: When the non-software path determines external research would improve the plan, prompt the user before dispatching — don't auto-research. This keeps token cost under user control. Frame as: "I think researching [topics] would improve this plan. Want me to look into it?" +- **Haiku model for research agents (Phase 2 extension)**: When running in Claude Code, dispatch web research sub-agents with `model: "haiku"`. Web search and result synthesis don't need Opus-level reasoning. This significantly reduces the 15x token overhead documented in Anthropic's multi-agent research system patterns. The Agent tool's `model` parameter supports this directly. +- **Research decomposition pattern (Phase 2 extension)**: Per Anthropic's multi-agent research findings, decompose the planning goal into 2-5 independent research questions and dispatch parallel web searches rather than sequential queries. Scale research depth to task complexity (0 searches for simple tasks, 2-3 for medium, 5+ for complex). Start with broad queries, narrow based on findings. + +## Implementation Units + +- [ ] **Unit 1: Update ce:plan YAML frontmatter** + +**Goal:** Update the skill description and argument-hint to include non-software planning triggers so the model routes non-software requests to ce:plan. + +**Requirements:** R1 + +**Dependencies:** None + +**Files:** +- Modify: `plugins/compound-engineering/skills/ce-plan/SKILL.md` (lines 1-4, YAML frontmatter) + +**Approach:** +- Update `description` to include non-software planning triggers. Keep software triggers intact; add non-software ones alongside. +- **Routing boundary with ce:brainstorm**: ce:plan is for structuring an already-decided task into an actionable plan; ce:brainstorm is for exploring what to do when uncertain. Include this distinction in trigger phrasing — e.g., ce:plan triggers on "plan this", "break this down", "create a plan for [specific goal]"; ce:brainstorm triggers on "help me think through", "what should we build", "I'm not sure about scope." +- Update `argument-hint` to include non-software examples. +- Keep the description concise — avoid making it so broad that the model over-routes to ce:plan. Include a negative signal where natural (e.g., "for exploratory or ambiguous requests, prefer ce:brainstorm first" — already present, keep it). + +**Patterns to follow:** +- ce:brainstorm's description style: domain-agnostic framing with specific trigger phrases + +**Test scenarios:** +- Happy path: `/ce:plan a 3 day trip to Disney World` triggers ce:plan (previously would not) +- Happy path: `/ce:plan plan the auth refactor` still triggers ce:plan (no regression) +- Edge case: Conversational "help me plan my team offsite" — model should consider ce:plan as a candidate (not just ce:brainstorm) + +**Verification:** +- Description includes both software and non-software trigger phrases +- Argument-hint includes a non-software example + +--- + +- [ ] **Unit 2: Add detection stub to ce:plan SKILL.md** + +**Goal:** Insert a non-software detection phase (0.1b) after the resume check (0.1) and before requirements doc search (0.2) that classifies the task and branches to the non-software path when appropriate. + +**Requirements:** R2, R3, R11, R12, pipeline scope boundary + +**Dependencies:** Unit 3 (the reference file must exist for the detection stub to function in testing, though the SKILL.md edit can be written first) + +**Files:** +- Modify: `plugins/compound-engineering/skills/ce-plan/SKILL.md` (insert new section after Phase 0.1, ~line 75) + +**Approach:** +- New section `#### 0.1b Detect Non-Software Task` placed between Phase 0.1 (resume) and Phase 0.2 (find upstream requirements doc) +- **Resume/deepen interaction**: If Phase 0.1 identified an existing plan with `domain: non-software` in frontmatter, route to `references/universal-planning.md` for editing/deepening instead of short-circuiting to Phase 5.3. The `domain` frontmatter field is the authoritative signal, not re-classification of the user's input. +- Enumerate software signals and non-software signals as explicit lists (state-machine pattern from learnings). **Distinguish task-type from topic-domain**: the signal is "does the task involve building/modifying/architecting software" not "does the task mention software topics." A study guide about Rust is non-software; a Rust library refactor is software. +- When non-software detected in interactive mode: instruct to read `references/universal-planning.md` and follow that workflow, skipping all subsequent software phases +- When non-software detected in pipeline mode: output a stop message explaining LFG/SLFG don't support non-software, and stop. Use the same pipeline detection pattern as Phases 5.2/5.3: "If invoked from an automated workflow such as LFG, SLFG, or any disable-model-invocation context." +- When uncertain: default to software path, or ask the user if genuinely ambiguous +- Target: ~20-25 lines of SKILL.md content (slightly larger due to resume handling and task-vs-topic distinction) + +**Patterns to follow:** +- Existing reference file loading pattern: "read `references/deepening-workflow.md` for..." (ce:plan SKILL.md line 681) +- State-machine detection pattern from `docs/solutions/skill-design/git-workflow-skills-need-explicit-state-machines-2026-03-27.md` + +**Test scenarios:** +- Happy path: "plan a 3 day Disney trip" → detects non-software, loads reference file +- Happy path: "plan the database migration for multi-tenancy" → detects software, continues normal flow +- Edge case: "plan a migration" with no other context → uncertain, asks user or defaults to software +- Edge case: "create a study guide for learning Rust" → non-software task despite mentioning a programming language. The task is producing educational content, not building/modifying software. Should route to non-software path. +- Edge case: "refactor the Rust authentication module" → software task. The task involves modifying code. +- Error path: Pipeline mode + non-software task → outputs stop message, does not write a plan file +- Integration: Software task after detection stub → Phases 0.2-5.4 proceed identically to before (no regression) + +**Verification:** +- Software tasks pass through detection with zero behavioral change +- Non-software tasks route to `references/universal-planning.md` +- Pipeline mode + non-software produces a stop message +- Detection stub is ~15-20 lines (negligible token cost per R12) + +--- + +- [ ] **Unit 3: Create `references/universal-planning.md`** + +**Goal:** Write the non-software planning workflow that replaces the software-specific phases. Contains ambiguity assessment, focused Q&A, quality principles, file location prompt, and handoff. + +**Requirements:** R5, R6, R7, R8 + +**Dependencies:** Unit 2 (detection stub references this file) + +**Files:** +- Create: `plugins/compound-engineering/skills/ce-plan/references/universal-planning.md` + +**Approach:** +- Self-contained workflow with 5 steps: (1) assess ambiguity, (2) focused Q&A if needed, (3) structure the plan using quality principles, (4) prompt for file location, (5) write file and present handoff options. Research capability (R9) is added in Phase 2 when implemented — no placeholder step in v1. +- Quality principles defined inline: actionable steps, dependency-sequenced, time-aware, resource-identified, contingency-aware, appropriately detailed, domain-appropriate format, research-aware (when the model lacks domain knowledge, offer to research before planning — prompt user first, don't auto-research) +- File location prompt: docs/plans/ (if exists), CWD, /tmp, or custom path. Use platform's question tool. +- Handoff options: open in editor, share to Proof, done. NO ce:work (software-only) or issue creation. +- Frontmatter for non-software plans: `title`, `status`, `date`, and `domain: non-software`. Omit `type`, `origin`, `deepened`. The `domain` field serves as a marker for resume/deepen flows and downstream consumers (LFG gate, ce:work) to recognize non-software plans. +- Filename convention: `YYYY-MM-DD--plan.md` (no sequence number or type prefix) +- Target: ~80-100 lines +- Follow cross-platform interaction rules: use "the platform's question tool" with named examples + +**Patterns to follow:** +- Existing reference files in ce:plan (`deepening-workflow.md`, `plan-handoff.md`) — header comment explaining when/why the file is loaded +- Cross-platform question tool references from Plugin AGENTS.md compliance checklist +- Backtick-path references for any future sub-references + +**Test scenarios:** +- Happy path: Clear request ("plan a 3 day Disney trip with 2 kids ages 11 and 13") → skips Q&A, produces structured itinerary-style plan +- Happy path: Ambiguous request ("plan my team offsite") → asks 1-3 clarifying questions, then produces event-style plan +- Happy path: File location prompt shows docs/plans/ only when directory exists; falls back to CWD/tmp/custom when it doesn't +- Edge case: Very simple request ("plan dinner tonight") → minimal plan, appropriately brief +- Edge case: Complex request ("plan a 3-month study curriculum for the GRE") → detailed plan with phases, resources, milestones +- Integration: Handoff options do NOT include ce:work or issue creation + +**Verification:** +- Non-software tasks produce domain-appropriate structured plans (not software plan template) +- Q&A fires only when needed, with ~3 questions max +- File is written to user-chosen location +- Handoff options are non-software appropriate + +--- + +- [ ] **Unit 4: Update LFG/SLFG pipeline handling** + +**Goal:** Add a one-line note to LFG and SLFG skills so they handle non-software detection gracefully instead of retrying indefinitely. + +**Requirements:** Pipeline scope boundary + +**Dependencies:** Unit 2 (detection stub produces the stop message) + +**Files:** +- Modify: `plugins/compound-engineering/skills/lfg/SKILL.md` (after line 14, the ce:plan gate) +- Modify: `plugins/compound-engineering/skills/slfg/SKILL.md` (after line 13, the ce:plan step) + +**Approach:** +- Rewrite the LFG gate as an explicit 3-branch state check (not an advisory note appended to the existing gate): "If ce:plan produced a plan file in `docs/plans/`, proceed. If ce:plan reported the task is non-software and stopped, stop the pipeline and inform the user that LFG requires software tasks. Otherwise, run `/ce:plan $ARGUMENTS` again." +- The non-software branch must appear before the retry branch so it takes precedence. +- Similar rewrite for SLFG step 2. +- Keep changes to 2-3 sentences each. + +**Patterns to follow:** +- Existing gate language style in LFG/SLFG + +**Test scenarios:** +- Happy path: Software task → LFG proceeds normally (no regression) +- Error path: Non-software task in LFG → ce:plan outputs stop message → LFG stops gracefully instead of retrying + +**Test expectation: none** — LFG/SLFG are orchestration skills tested by manual invocation, not automated tests. + +**Verification:** +- LFG does not retry when ce:plan reports non-software +- SLFG does not retry when ce:plan reports non-software + +--- + +- [ ] **Unit 5: Validate and update documentation** + +**Goal:** Verify ce:brainstorm doesn't need changes (R4), update README component descriptions if needed, run release validation. + +**Requirements:** R4 + +**Dependencies:** Units 1-4 + +**Files:** +- Read (verify): `plugins/compound-engineering/skills/ce-brainstorm/SKILL.md` +- Possibly modify: `plugins/compound-engineering/README.md` (if skill descriptions need updating) + +**Approach:** +- Manually test ce:brainstorm with a non-software prompt to verify it doesn't refuse +- Check if README component tables need description updates for ce:plan +- Run `bun run release:validate` to ensure plugin consistency + +**Test scenarios:** +- Happy path: ce:brainstorm accepts "plan my team offsite" without refusing +- Integration: `bun run release:validate` passes + +**Verification:** +- ce:brainstorm confirmed domain-agnostic (no changes needed) +- release:validate passes +- README accurately reflects ce:plan's expanded capability + +## System-Wide Impact + +- **Interaction graph:** ce:plan detection stub fires on every invocation. Non-software detection routes to `references/universal-planning.md`. LFG/SLFG get a graceful stop for non-software. ce:brainstorm unchanged. +- **Error propagation:** Detection uncertainty → ask user → user answers → correct path. Detection false negative (non-software → software path) → existing refusal behavior (status quo, not worse). Detection false positive (software → non-software path) → disconnected plan (mitigated by defaulting to software). +- **State lifecycle risks:** None. Detection is stateless; it runs once at the start of each invocation. +- **API surface parity:** ce:plan's description change affects how all platforms (Claude Code, Codex, Gemini) route to the skill. The converter copies SKILL.md as-is for skills, so no converter changes needed. +- **Integration coverage:** Manual testing required — no automated skill behavioral tests in this repo. +- **Unchanged invariants:** The entire software planning workflow (Phases 0.2-5.4) is not touched. All existing plans, deepening flows, and pipeline behaviors for software tasks are unchanged. + +## Risks & Dependencies + +| Risk | Mitigation | +|------|------------| +| Detection auto-classification is unreliable (per learnings) | R3 error policy: default to software, ask when uncertain. Monitor false positive rate after release. | +| Description broadening causes over-routing to ce:plan | Keep non-software triggers specific ("events, study plans") not generic ("any task"). Include negative signal ("for simple questions, ask directly"). | +| Non-software plan quality varies without a template | Quality principles provide guardrails. Manual testing with diverse prompts before release. Iterate on principles based on output quality. | +| LFG retry loop if stop message not handled | Unit 4 adds explicit handling. Test the pipeline path. | + +## Documentation / Operational Notes + +- Update `plugins/compound-engineering/README.md` skill description for ce:plan if the table entry mentions software-only planning +- No changelog entry needed (handled by release automation) +- No version bump (per Plugin AGENTS.md contributor rules) + +## Sources & References + +- **Origin document:** `docs/brainstorms/2026-04-05-universal-planning-requirements.md` +- Related code: `plugins/compound-engineering/skills/ce-plan/SKILL.md`, `plugins/compound-engineering/skills/ce-brainstorm/SKILL.md`, `plugins/compound-engineering/skills/lfg/SKILL.md`, `plugins/compound-engineering/skills/slfg/SKILL.md` +- Related issue: [#517](https://github.com/EveryInc/compound-engineering-plugin/issues/517) +- Related learnings: `docs/solutions/skill-design/beta-skills-framework.md`, `docs/solutions/skill-design/compound-refresh-skill-improvements.md`, `docs/solutions/skill-design/git-workflow-skills-need-explicit-state-machines-2026-03-27.md` diff --git a/plugins/compound-engineering/README.md b/plugins/compound-engineering/README.md index 34cac32..a2511a6 100644 --- a/plugins/compound-engineering/README.md +++ b/plugins/compound-engineering/README.md @@ -19,7 +19,7 @@ The primary entry points for engineering work, invoked as slash commands: |-------|-------------| | `/ce:ideate` | Discover high-impact project improvements through divergent ideation and adversarial filtering | | `/ce:brainstorm` | Explore requirements and approaches before planning | -| `/ce:plan` | Transform features into structured implementation plans grounded in repo patterns, with automatic confidence checking | +| `/ce:plan` | Create structured plans for any multi-step task -- software features, research workflows, events, study plans -- with automatic confidence checking | | `/ce:review` | Structured code review with tiered persona agents, confidence gating, and dedup pipeline | | `/ce:work` | Execute work items systematically | | `/ce:compound` | Document solved problems to compound team knowledge | diff --git a/plugins/compound-engineering/skills/ce-brainstorm/SKILL.md b/plugins/compound-engineering/skills/ce-brainstorm/SKILL.md index 0974bd1..77253ed 100644 --- a/plugins/compound-engineering/skills/ce-brainstorm/SKILL.md +++ b/plugins/compound-engineering/skills/ce-brainstorm/SKILL.md @@ -56,6 +56,20 @@ If the user references an existing brainstorm topic or document, or there is an - Confirm with the user before resuming: "Found an existing requirements doc for [topic]. Should I continue from this, or start fresh?" - If resuming, summarize the current state briefly, continue from its existing decisions and outstanding questions, and update the existing document instead of creating a duplicate +#### 0.1b Classify Task Domain + +Before proceeding to Phase 0.2, classify whether this is a software task. The key question is: **does the task involve building, modifying, or architecting software?** -- not whether the task *mentions* software topics. + +**Software** (continue to Phase 0.2) -- the task references code, repositories, APIs, databases, or asks to build/modify/debug/deploy software. + +**Non-software brainstorming** (route to universal brainstorming) -- BOTH conditions must be true: +- None of the software signals above are present +- The task describes something the user wants to explore, decide, or think through in a non-software domain + +**Neither** (respond directly, skip all brainstorming phases) -- the input is a quick-help request, error message, factual question, or single-step task that doesn't need a brainstorm. + +**If non-software brainstorming is detected:** Read `references/universal-brainstorming.md` and use those facilitation principles to brainstorm with the user naturally. Do not follow the software brainstorming phases below. + #### 0.2 Assess Whether Brainstorming Is Needed **Clear requirements indicators:** @@ -125,6 +139,7 @@ Before generating approaches, challenge the request to catch misframing. Match d Follow the Interaction Rules above. Use the platform's blocking question tool when available. **Guidelines:** +- Ask what the user is already thinking before offering your own ideas. This surfaces hidden context and prevents fixation on AI-generated framings. - Start broad (problem, users, value) then narrow (constraints, exclusions, edge cases) - Clarify the problem frame, validate assumptions, and ask about success criteria - Make requirements concrete enough that planning will not need to invent behavior @@ -138,6 +153,10 @@ Follow the Interaction Rules above. Use the platform's blocking question tool wh If multiple plausible directions remain, propose **2-3 concrete approaches** based on research and conversation. Otherwise state the recommended direction directly. +Use at least one non-obvious angle — inversion (what if we did the opposite?), constraint removal (what if X weren't a limitation?), or analogy from how another domain solves this. The first approaches that come to mind are usually variations on the same axis. + +Present approaches first, then evaluate. Let the user see all options before hearing which one is recommended — leading with a recommendation before the user has seen alternatives anchors the conversation prematurely. + When useful, include one deliberately higher-upside alternative: - Identify what adjacent addition or reframing would most increase usefulness, compounding value, or durability without disproportionate carrying cost. Present it as a challenger option alongside the baseline, not as the default. Omit it when the work is already obviously over-scoped or the baseline request is clearly the right move. @@ -147,7 +166,7 @@ For each approach, provide: - Key risks or unknowns - When it's best suited -Lead with your recommendation and explain why. Prefer simpler solutions when added complexity creates real carrying cost, but do not reject low-cost, high-value polish just because it is not strictly necessary. +After presenting all approaches, state your recommendation and explain why. Prefer simpler solutions when added complexity creates real carrying cost, but do not reject low-cost, high-value polish just because it is not strictly necessary. If one approach is clearly best and alternatives are not meaningful, skip the menu and state the recommendation directly. diff --git a/plugins/compound-engineering/skills/ce-brainstorm/references/universal-brainstorming.md b/plugins/compound-engineering/skills/ce-brainstorm/references/universal-brainstorming.md new file mode 100644 index 0000000..25d0c7a --- /dev/null +++ b/plugins/compound-engineering/skills/ce-brainstorm/references/universal-brainstorming.md @@ -0,0 +1,52 @@ +# Universal Brainstorming Facilitator + +This file is loaded when ce:brainstorm detects a non-software task (Phase 0). It replaces the software-specific brainstorming phases with facilitation principles for any domain. Do not follow the software brainstorming workflow (Phases 0.2 through 4). Instead, absorb these principles and facilitate the brainstorm naturally. + +--- + +## Your role + +Be a thinking partner, not an answer machine. The user came here because they're stuck or exploring — they want to think WITH someone, not receive a deliverable. Resist the urge to generate a complete solution immediately. A premature answer anchors the conversation and kills exploration. + +**Match the tone to the stakes.** For personal or life decisions (career changes, housing, relationships, family), lead with values and feelings before frameworks and analysis. Ask what matters to them, not just what the options are. For lighter or creative tasks (podcast topics, event ideas, side projects), energy and enthusiasm are more useful than caution. + +## How to start + +**Assess scope first.** Not every brainstorm needs deep exploration: +- **Quick** (user has a clear goal, just needs a sounding board): Confirm understanding, offer a few targeted suggestions or reactions, done in 2-3 exchanges. +- **Standard** (some unknowns, needs to explore options): 4-6 exchanges, generate and compare options, help decide. +- **Full** (vague goal, lots of uncertainty, or high-stakes decision): Deep exploration, many exchanges, structured convergence. + +**Ask what they're already thinking.** Before offering ideas, find out what the user has considered, tried, or rejected. This prevents fixation on AI-generated ideas and surfaces hidden constraints. + +**When the user represents a group** (couple, family, team) — surface whose preferences are in play and where they diverge. The brainstorm shifts from "help you decide" to "help you find alignment." Ask about each person's priorities, not just the speaker's. + +**Understand before generating.** Spend time on the problem before jumping to solutions. "What would success look like?" and "What have you already ruled out?" reveal more than "Here are 10 ideas." + +## How to explore and generate + +**Use diverse angles to avoid repetitive ideas.** When generating options, vary your approach across exchanges: +- Inversion: "What if you did the opposite of the obvious choice?" +- Constraints as creative tools: "What if budget/time/distance were no issue?" then "What if you had to do it for free?" +- Analogy: "How does someone in a completely different context solve a similar problem?" +- What the user hasn't considered: introduce lateral ideas from unexpected directions + +**Separate generation from evaluation.** When exploring options, don't critique them in the same breath. Generate first, evaluate later. Make the transition explicit when it's time to narrow. + +**Offer options to react to when the user is stuck.** People who can't generate from scratch can often evaluate presented options. Use multi-select questions to gather preferences efficiently. Always include a skip option for users who want to move faster. + +**Keep presented options to 3-5 at any decision point.** More causes analysis paralysis. + +## How to converge + +When the conversation has enough material to narrow — reflect back what you've heard. Name the user's priorities as they've emerged through the conversation (what excited them, what they rejected, what they asked about). Propose a frontrunner with reasoning tied to their criteria, and invite pushback. Keep final options to 3-5 max. Don't force a final decision if the user isn't there yet — clarity on direction is a valid outcome. + +## When to wrap up + +**Always synthesize a summary in the chat.** Before offering any next steps, reflect back what emerged: key decisions, the direction chosen, open threads, and any assumptions made. This is the primary output of the brainstorm — the user should be able to read the summary and know what they landed on. + +**Then offer next steps** using the platform's question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini): +- **Create a plan** → hand off to `/ce:plan` with the decided goal and constraints +- **Save summary to disk** → write the summary as a markdown file in the current working directory +- **Share to Proof** → load the `proof` skill to create a shareable web link for others to review +- **Done** → the conversation was the value, no artifact needed diff --git a/plugins/compound-engineering/skills/ce-plan/SKILL.md b/plugins/compound-engineering/skills/ce-plan/SKILL.md index 8b54e8d..32f05ca 100644 --- a/plugins/compound-engineering/skills/ce-plan/SKILL.md +++ b/plugins/compound-engineering/skills/ce-plan/SKILL.md @@ -1,7 +1,7 @@ --- name: ce:plan -description: "Transform feature descriptions or requirements into structured implementation plans grounded in repo patterns and research. Also deepen existing plans with interactive review of sub-agent findings. Use for plan creation when the user says 'plan this', 'create a plan', 'write a tech plan', 'plan the implementation', 'how should we build', 'what's the approach for', 'break this down', or when a brainstorm/requirements document is ready for technical planning. Use for plan deepening when the user says 'deepen the plan', 'deepen my plan', 'deepening pass', or uses 'deepen' in reference to a plan. Best when requirements are at least roughly defined; for exploratory or ambiguous requests, prefer ce:brainstorm first." -argument-hint: "[optional: feature description, requirements doc path, plan path to deepen, or improvement idea]" +description: "Create structured plans for any multi-step task -- software features, research workflows, events, study plans, or any goal that benefits from structured breakdown. Also deepen existing plans with interactive review of sub-agent findings. Use for plan creation when the user says 'plan this', 'create a plan', 'write a tech plan', 'plan the implementation', 'how should we build', 'what's the approach for', 'break this down', 'plan a trip', 'create a study plan', or when a brainstorm/requirements document is ready for planning. Use for plan deepening when the user says 'deepen the plan', 'deepen my plan', 'deepening pass', or uses 'deepen' in reference to a plan. For exploratory or ambiguous requests where the user is unsure what to do, prefer ce:brainstorm first." +argument-hint: "[optional: feature description, requirements doc path, plan path to deepen, or any task to plan]" --- # Create Technical Plan @@ -22,7 +22,7 @@ Ask one question at a time. Prefer a concise single-select choice when natural o #$ARGUMENTS -**If the feature description above is empty, ask the user:** "What would you like to plan? Please describe the feature, bug fix, or improvement you have in mind." +**If the feature description above is empty, ask the user:** "What would you like to plan? Describe the task, goal, or project you have in mind." Do not proceed until you have a clear planning input. @@ -67,12 +67,24 @@ If the user references an existing plan file or there is an obvious recent match Words like "strengthen", "confidence", "gaps", and "rigor" are NOT sufficient on their own to trigger deepening. These words appear in normal editing requests ("strengthen that section about the diagram", "there are gaps in the test scenarios") and should not cause a holistic deepening pass. Only treat them as deepening intent when the request clearly targets the plan as a whole and does not name a specific section or content area to change — and even then, prefer to confirm with the user before entering the deepening flow. -Once the plan is identified and appears complete (all major sections present, implementation units defined, `status: active`), short-circuit to Phase 5.3 (Confidence Check and Deepening) in **interactive mode**. This avoids re-running the full planning workflow and gives the user control over which findings are integrated. +Once the plan is identified and appears complete (all major sections present, implementation units defined, `status: active`): +- If the plan lacks YAML frontmatter (non-software plans use a simple `# Title` heading with `Created:` date instead of frontmatter), route to `references/universal-planning.md` for editing or deepening instead of Phase 5.3. Non-software plans do not use the software confidence check. +- Otherwise, short-circuit to Phase 5.3 (Confidence Check and Deepening) in **interactive mode**. This avoids re-running the full planning workflow and gives the user control over which findings are integrated. Normal editing requests (e.g., "update the test scenarios", "add a new implementation unit", "strengthen the risk section") should NOT trigger the fast path — they follow the standard resume flow. If the plan already has a `deepened: YYYY-MM-DD` frontmatter field and there is no explicit user request to re-deepen, the fast path still applies the same confidence-gap evaluation — it does not force deepening. +#### 0.1b Classify Task Domain + +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. + +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), respond directly without any planning workflow. + #### 0.2 Find Upstream Requirements Document Before asking planning questions, search `docs/brainstorms/` for files matching `*-requirements.md`. diff --git a/plugins/compound-engineering/skills/ce-plan/references/universal-planning.md b/plugins/compound-engineering/skills/ce-plan/references/universal-planning.md new file mode 100644 index 0000000..4f93992 --- /dev/null +++ b/plugins/compound-engineering/skills/ce-plan/references/universal-planning.md @@ -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--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). diff --git a/plugins/compound-engineering/skills/lfg/SKILL.md b/plugins/compound-engineering/skills/lfg/SKILL.md index e2c9b11..1639237 100644 --- a/plugins/compound-engineering/skills/lfg/SKILL.md +++ b/plugins/compound-engineering/skills/lfg/SKILL.md @@ -11,7 +11,7 @@ CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required s 2. `/ce:plan $ARGUMENTS` - GATE: STOP. Verify that the `ce:plan` workflow produced a plan file in `docs/plans/`. If no plan file was created, run `/ce:plan $ARGUMENTS` again. Do NOT proceed to step 3 until a written plan exists. **Record the plan file path** — it will be passed to ce:review in step 4. + GATE: STOP. If ce:plan reported the task is non-software and cannot be processed in pipeline mode, stop the pipeline and inform the user that LFG requires software tasks. Otherwise, verify that the `ce:plan` workflow produced a plan file in `docs/plans/`. If no plan file was created, run `/ce:plan $ARGUMENTS` again. Do NOT proceed to step 3 until a written plan exists. **Record the plan file path** — it will be passed to ce:review in step 4. 3. `/ce:work` diff --git a/plugins/compound-engineering/skills/slfg/SKILL.md b/plugins/compound-engineering/skills/slfg/SKILL.md index ad8a295..373e209 100644 --- a/plugins/compound-engineering/skills/slfg/SKILL.md +++ b/plugins/compound-engineering/skills/slfg/SKILL.md @@ -10,7 +10,7 @@ Swarm-enabled LFG. Run these steps in order, parallelizing where indicated. Do n ## Sequential Phase 1. **Optional:** If the `ralph-loop` skill is available, run `/ralph-loop:ralph-loop "finish all slash commands" --completion-promise "DONE"`. If not available or it fails, skip and continue to step 2 immediately. -2. `/ce:plan $ARGUMENTS` — **Record the plan file path** from `docs/plans/` for steps 4 and 6. +2. `/ce:plan $ARGUMENTS` — If ce:plan reported the task is non-software and cannot be processed in pipeline mode, stop the pipeline and inform the user that SLFG requires software tasks. Otherwise, **record the plan file path** from `docs/plans/` for steps 4 and 6. 3. `/ce:work` — **Use swarm mode**: Make a Task list and launch an army of agent swarm subagents to build the plan ## Parallel Phase