refactor(cli)!: rename all skills and agents to consistent ce- prefix (#503)
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Trevin Chow
@@ -96,43 +96,43 @@ Use fully-qualified agent names inside Task calls.
|
||||
**Deterministic Section-to-Agent Mapping:**
|
||||
|
||||
**Requirements Trace / Open Questions classification**
|
||||
- `compound-engineering:workflow:spec-flow-analyzer` for missing user flows, edge cases, and handoff gaps
|
||||
- `compound-engineering:research:repo-research-analyst` (Scope: `architecture, patterns`) for repo-grounded patterns, conventions, and implementation reality checks
|
||||
- `workflow:ce-spec-flow-analyzer` for missing user flows, edge cases, and handoff gaps
|
||||
- `research:ce-repo-research-analyst` (Scope: `architecture, patterns`) for repo-grounded patterns, conventions, and implementation reality checks
|
||||
|
||||
**Context & Research / Sources & References gaps**
|
||||
- `compound-engineering:research:learnings-researcher` for institutional knowledge and past solved problems
|
||||
- `compound-engineering:research:framework-docs-researcher` for official framework or library behavior
|
||||
- `compound-engineering:research:best-practices-researcher` for current external patterns and industry guidance
|
||||
- Add `compound-engineering:research:git-history-analyzer` only when historical rationale or prior art is materially missing
|
||||
- `research:ce-learnings-researcher` for institutional knowledge and past solved problems
|
||||
- `research:ce-framework-docs-researcher` for official framework or library behavior
|
||||
- `research:ce-best-practices-researcher` for current external patterns and industry guidance
|
||||
- Add `research:ce-git-history-analyzer` only when historical rationale or prior art is materially missing
|
||||
|
||||
**Key Technical Decisions**
|
||||
- `compound-engineering:review:architecture-strategist` for design integrity, boundaries, and architectural tradeoffs
|
||||
- Add `compound-engineering:research:framework-docs-researcher` or `compound-engineering:research:best-practices-researcher` when the decision needs external grounding beyond repo evidence
|
||||
- `review:ce-architecture-strategist` for design integrity, boundaries, and architectural tradeoffs
|
||||
- Add `research:ce-framework-docs-researcher` or `research:ce-best-practices-researcher` when the decision needs external grounding beyond repo evidence
|
||||
|
||||
**High-Level Technical Design**
|
||||
- `compound-engineering:review:architecture-strategist` for validating that the technical design accurately represents the intended approach and identifying gaps
|
||||
- `compound-engineering:research:repo-research-analyst` (Scope: `architecture, patterns`) for grounding the technical design in existing repo patterns and conventions
|
||||
- Add `compound-engineering:research:best-practices-researcher` when the technical design involves a DSL, API surface, or pattern that benefits from external validation
|
||||
- `review:ce-architecture-strategist` for validating that the technical design accurately represents the intended approach and identifying gaps
|
||||
- `research:ce-repo-research-analyst` (Scope: `architecture, patterns`) for grounding the technical design in existing repo patterns and conventions
|
||||
- Add `research:ce-best-practices-researcher` when the technical design involves a DSL, API surface, or pattern that benefits from external validation
|
||||
|
||||
**Implementation Units / Verification**
|
||||
- `compound-engineering:research:repo-research-analyst` (Scope: `patterns`) for concrete file targets, patterns to follow, and repo-specific sequencing clues
|
||||
- `compound-engineering:review:pattern-recognition-specialist` for consistency, duplication risks, and alignment with existing patterns
|
||||
- Add `compound-engineering:workflow:spec-flow-analyzer` when sequencing depends on user flow or handoff completeness
|
||||
- `research:ce-repo-research-analyst` (Scope: `patterns`) for concrete file targets, patterns to follow, and repo-specific sequencing clues
|
||||
- `review:ce-pattern-recognition-specialist` for consistency, duplication risks, and alignment with existing patterns
|
||||
- Add `workflow:ce-spec-flow-analyzer` when sequencing depends on user flow or handoff completeness
|
||||
|
||||
**System-Wide Impact**
|
||||
- `compound-engineering:review:architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
|
||||
- `review:ce-architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
|
||||
- Add the specific specialist that matches the risk:
|
||||
- `compound-engineering:review:performance-oracle` for scalability, latency, throughput, and resource-risk analysis
|
||||
- `compound-engineering:review:security-sentinel` for auth, validation, exploit surfaces, and security boundary review
|
||||
- `compound-engineering:review:data-integrity-guardian` for migrations, persistent state safety, consistency, and data lifecycle risks
|
||||
- `review:ce-performance-oracle` for scalability, latency, throughput, and resource-risk analysis
|
||||
- `review:ce-security-sentinel` for auth, validation, exploit surfaces, and security boundary review
|
||||
- `review:ce-data-integrity-guardian` for migrations, persistent state safety, consistency, and data lifecycle risks
|
||||
|
||||
**Risks & Dependencies / Operational Notes**
|
||||
- Use the specialist that matches the actual risk:
|
||||
- `compound-engineering:review:security-sentinel` for security, auth, privacy, and exploit risk
|
||||
- `compound-engineering:review:data-integrity-guardian` for persistent data safety, constraints, and transaction boundaries
|
||||
- `compound-engineering:review:data-migration-expert` for migration realism, backfills, and production data transformation risk
|
||||
- `compound-engineering:review:deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
|
||||
- `compound-engineering:review:performance-oracle` for capacity, latency, and scaling concerns
|
||||
- `review:ce-security-sentinel` for security, auth, privacy, and exploit risk
|
||||
- `review:ce-data-integrity-guardian` for persistent data safety, constraints, and transaction boundaries
|
||||
- `review:ce-data-migration-expert` for migration realism, backfills, and production data transformation risk
|
||||
- `review:ce-deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
|
||||
- `review:ce-performance-oracle` for capacity, latency, and scaling concerns
|
||||
|
||||
**Agent Prompt Shape:**
|
||||
|
||||
@@ -198,7 +198,7 @@ Skip this step in auto mode — proceed directly to 5.3.7.
|
||||
|
||||
In interactive mode, present each agent's findings to the user before integration. For each agent that returned findings:
|
||||
|
||||
1. **Summarize the agent and its target section** — e.g., "The architecture-strategist reviewed Key Technical Decisions and found:"
|
||||
1. **Summarize the agent and its target section** — e.g., "The ce-architecture-strategist reviewed Key Technical Decisions and found:"
|
||||
2. **Present the findings concisely** — bullet the key points, not the raw agent output. Include enough context for the user to evaluate: what the agent found, what evidence supports it, and what plan change it implies.
|
||||
3. **Ask the user** using the platform's blocking question tool when available (see Interaction Method):
|
||||
- **Accept** — integrate these findings into the plan
|
||||
@@ -242,4 +242,4 @@ Do **not**:
|
||||
If research reveals a product-level ambiguity that should change behavior or scope:
|
||||
- Do not silently decide it here
|
||||
- Record it under `Open Questions`
|
||||
- Recommend `ce:brainstorm` if the gap is truly product-defining
|
||||
- Recommend `ce-brainstorm` if the gap is truly product-defining
|
||||
|
||||
@@ -4,17 +4,17 @@ This file contains post-plan-writing instructions: document review, post-generat
|
||||
|
||||
## 5.3.8 Document Review
|
||||
|
||||
After the confidence check (and any deepening), run the `document-review` skill on the plan file. Pass the plan path as the argument. When this step is reached, it is mandatory — do not skip it because the confidence check already ran. The two tools catch different classes of issues.
|
||||
After the confidence check (and any deepening), run the `ce-doc-review` skill on the plan file. Pass the plan path as the argument. When this step is reached, it is mandatory — do not skip it because the confidence check already ran. The two tools catch different classes of issues.
|
||||
|
||||
The confidence check and document-review are complementary:
|
||||
The confidence check and ce-doc-review are complementary:
|
||||
- The confidence check strengthens rationale, sequencing, risk treatment, and grounding
|
||||
- Document-review checks coherence, feasibility, scope alignment, and surfaces role-specific issues
|
||||
|
||||
If document-review returns findings that were auto-applied, note them briefly when presenting handoff options. If residual P0/P1 findings were surfaced, mention them so the user can decide whether to address them before proceeding.
|
||||
If ce-doc-review returns findings that were auto-applied, note them briefly when presenting handoff options. If residual P0/P1 findings were surfaced, mention them so the user can decide whether to address them before proceeding.
|
||||
|
||||
When document-review returns "Review complete", proceed to Final Checks.
|
||||
When ce-doc-review returns "Review complete", proceed to Final Checks.
|
||||
|
||||
**Pipeline mode:** If invoked from an automated workflow such as LFG, SLFG, or any `disable-model-invocation` context, run `document-review` with `mode:headless` and the plan path. Headless mode applies auto-fixes silently and returns structured findings without interactive prompts. Address any P0/P1 findings before returning control to the caller.
|
||||
**Pipeline mode:** If invoked from an automated workflow such as LFG, SLFG, or any `disable-model-invocation` context, run `ce-doc-review` with `mode:headless` and the plan path. Headless mode applies auto-fixes silently and returns structured findings without interactive prompts. Address any P0/P1 findings before returning control to the caller.
|
||||
|
||||
## 5.3.9 Final Checks and Cleanup
|
||||
|
||||
@@ -29,14 +29,14 @@ If artifact-backed mode was used:
|
||||
|
||||
## 5.4 Post-Generation Options
|
||||
|
||||
**Pipeline mode:** If invoked from an automated workflow such as LFG, SLFG, or any `disable-model-invocation` context, skip the interactive menu below and return control to the caller immediately. The plan file has already been written, the confidence check has already run, and document-review has already run — the caller (e.g., lfg, slfg) determines the next step.
|
||||
**Pipeline mode:** If invoked from an automated workflow such as LFG, SLFG, or any `disable-model-invocation` context, skip the interactive menu below and return control to the caller immediately. The plan file has already been written, the confidence check has already run, and ce-doc-review has already run — the caller (e.g., lfg, slfg) determines the next step.
|
||||
|
||||
After document-review completes, present the options using the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the numbered options in chat and wait for the user's reply before proceeding.
|
||||
|
||||
**Question:** "Plan ready at `docs/plans/YYYY-MM-DD-NNN-<type>-<name>-plan.md`. What would you like to do next?"
|
||||
|
||||
**Options:**
|
||||
1. **Start `/ce:work`** (recommended) - Begin implementing this plan in the current session
|
||||
1. **Start `/ce-work`** (recommended) - Begin implementing this plan in the current session
|
||||
2. **Create Issue** - Create a tracked issue from this plan in your configured issue tracker (GitHub or Linear)
|
||||
3. **Open in Proof (web app) — review and comment to iterate with the agent** - Open the doc in Every's Proof editor, iterate with the agent via comments, or copy a link to share with others
|
||||
4. **Done for now** - Pause; the plan file is saved and can be resumed later
|
||||
@@ -44,25 +44,25 @@ After document-review completes, present the options using the platform's blocki
|
||||
**Surface additional document review contextually, not as a menu fixture:** When the prior document-review pass surfaced residual P0/P1 findings that the user has not addressed, mention them adjacent to the menu and offer another review pass in prose (e.g., "Document review flagged 2 P1 findings you may want to address — want me to run another pass before you pick?"). Do not add it to the option list.
|
||||
|
||||
Based on selection:
|
||||
- **Start `/ce:work`** -> Call `/ce:work` with the plan path
|
||||
- **Start `/ce-work`** -> Call `/ce-work` with the plan path
|
||||
- **Create Issue** -> Follow the Issue Creation section below
|
||||
- **Open in Proof (web app) — review and comment to iterate with the agent** -> Load the `proof` skill in HITL-review mode with:
|
||||
- **Open in Proof (web app) — review and comment to iterate with the agent** -> Load the `ce-proof` skill in HITL-review mode with:
|
||||
- source file: `docs/plans/<plan_filename>.md`
|
||||
- doc title: `Plan: <plan title from frontmatter>`
|
||||
- identity: `ai:compound-engineering` / `Compound Engineering`
|
||||
- recommended next step: `/ce:work` (shown in the proof skill's final terminal output)
|
||||
- recommended next step: `/ce-work` (shown in the ce-proof skill's final terminal output)
|
||||
|
||||
Follow `references/hitl-review.md` in the proof skill. It uploads the plan, prompts the user for review in Proof's web UI, ingests each thread by reading it fresh and replying in-thread, applies agreed edits as tracked suggestions, and syncs the final markdown back to the plan file atomically on proceed.
|
||||
Follow `references/hitl-review.md` in the ce-proof skill. It uploads the plan, prompts the user for review in Proof's web UI, ingests each thread by reading it fresh and replying in-thread, applies agreed edits as tracked suggestions, and syncs the final markdown back to the plan file atomically on proceed.
|
||||
|
||||
When the proof skill returns:
|
||||
- `status: proceeded` with `localSynced: true` -> the plan on disk now reflects the review. Re-run `document-review` on the updated plan before re-rendering the menu — HITL can materially rewrite the plan body, so the prior document-review pass no longer covers the current file and section 5.3.8 requires a review before any handoff option is offered. Then return to the post-generation options with the refreshed residual findings.
|
||||
- `status: proceeded` with `localSynced: false` -> the reviewed version lives in Proof at `docUrl` but the local copy is stale. Offer to pull the Proof doc to `localPath` using the proof skill's Pull workflow. If the pull happened, re-run `document-review` on the pulled file before re-rendering the options (same 5.3.8 rationale — the local plan was materially updated by the pull). If the pull was declined, include a one-line note above the menu that `<localPath>` is stale vs. Proof — otherwise `Start /ce:work` or `Create Issue` will silently use the pre-review copy.
|
||||
- `status: done_for_now` -> the plan on disk may be stale if the user edited in Proof before leaving. Offer to pull the Proof doc to `localPath` so the local plan file stays in sync. If the pull happened, re-run `document-review` on the pulled file before re-rendering the options (same 5.3.8 rationale). If the pull was declined, include the stale-local note above the menu. `done_for_now` means the user stopped the HITL loop — it does not mean they ended the whole plan session; they may still want to start work or create an issue.
|
||||
When the ce-proof skill returns:
|
||||
- `status: proceeded` with `localSynced: true` -> the plan on disk now reflects the review. Re-run `ce-doc-review` on the updated plan before re-rendering the menu — HITL can materially rewrite the plan body, so the prior ce-doc-review pass no longer covers the current file and section 5.3.8 requires a review before any handoff option is offered. Then return to the post-generation options with the refreshed residual findings.
|
||||
- `status: proceeded` with `localSynced: false` -> the reviewed version lives in Proof at `docUrl` but the local copy is stale. Offer to pull the Proof doc to `localPath` using the ce-proof skill's Pull workflow. If the pull happened, re-run `ce-doc-review` on the pulled file before re-rendering the options (same 5.3.8 rationale — the local plan was materially updated by the pull). If the pull was declined, include a one-line note above the menu that `<localPath>` is stale vs. Proof — otherwise `Start /ce-work` or `Create Issue` will silently use the pre-review copy.
|
||||
- `status: done_for_now` -> the plan on disk may be stale if the user edited in Proof before leaving. Offer to pull the Proof doc to `localPath` so the local plan file stays in sync. If the pull happened, re-run `ce-doc-review` on the pulled file before re-rendering the options (same 5.3.8 rationale). If the pull was declined, include the stale-local note above the menu. `done_for_now` means the user stopped the HITL loop — it does not mean they ended the whole plan session; they may still want to start work or create an issue.
|
||||
- `status: aborted` -> fall back to the options without changes.
|
||||
|
||||
If the initial upload fails (network error, Proof API down), retry once after a short wait. If it still fails, tell the user the upload didn't succeed and briefly explain why, then return to the options — don't leave them wondering why the option did nothing.
|
||||
- **Done for now** -> Display a brief confirmation that the plan file is saved and end the turn
|
||||
- **If the user asks for another document review** (either from the contextual prompt when P0/P1 findings remain, or by free-form request) -> Load the `document-review` skill with the plan path for another pass, then return to the options
|
||||
- **If the user asks for another document review** (either from the contextual prompt when P0/P1 findings remain, or by free-form request) -> Load the `ce-doc-review` skill with the plan path for another pass, then return to the options
|
||||
- **Other** -> Accept free text for revisions and loop back to options
|
||||
|
||||
## Issue Creation
|
||||
@@ -91,4 +91,4 @@ When the user selects "Create Issue", detect their project tracker:
|
||||
|
||||
After issue creation:
|
||||
- Display the issue URL
|
||||
- Ask whether to proceed to `/ce:work` using the platform's blocking question tool
|
||||
- Ask whether to proceed to `/ce-work` using the platform's blocking question tool
|
||||
|
||||
@@ -1,15 +1,16 @@
|
||||
# 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.
|
||||
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.
|
||||
- **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.
|
||||
- **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.
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
@@ -29,7 +30,7 @@ Evaluate two things before planning:
|
||||
| **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.
|
||||
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.
|
||||
@@ -106,8 +107,8 @@ After structuring the plan, ask the user how they want to receive it using the p
|
||||
- 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. **Open in Proof (web app) — review and comment to iterate with the agent** — Open the doc in Every's Proof editor, iterate with the agent via comments, or copy a link to share with others. Load the `proof` skill to create and open the document.
|
||||
2. **Open in Proof (web app) — review and comment to iterate with the agent** — Open the doc in Every's Proof editor, iterate with the agent via comments, or copy a link to share with others. Load the `ce-proof` skill to create and open the document.
|
||||
|
||||
3. **Save to disk AND open in Proof** — Do both: write the markdown file to disk and open the doc in Proof for review.
|
||||
|
||||
Do not offer `/ce:work` (software-only) or issue creation (not applicable to non-software plans).
|
||||
Do not offer `/ce-work` (software-only) or issue creation (not applicable to non-software plans).
|
||||
|
||||
Reference in New Issue
Block a user