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
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: ce:work
|
||||
name: ce-work
|
||||
description: Execute work efficiently while maintaining quality and finishing features
|
||||
argument-hint: "[Plan doc path or description of work. Blank to auto use latest plan doc]"
|
||||
---
|
||||
@@ -38,7 +38,7 @@ Determine how to proceed based on what was provided in `<input_document>`.
|
||||
|-----------|---------|--------|
|
||||
| **Trivial** | 1-2 files, no behavioral change (typo, config, rename) | Proceed to Phase 1 step 2 (environment setup), then implement directly — no task list, no execution loop. Apply Test Discovery if the change touches behavior-bearing code |
|
||||
| **Small / Medium** | Clear scope, under ~10 files | Build a task list from discovery. Proceed to Phase 1 step 2 |
|
||||
| **Large** | Cross-cutting, architectural decisions, 10+ files, touches auth/payments/migrations | Inform the user this would benefit from `/ce:brainstorm` or `/ce:plan` to surface edge cases and scope boundaries. Honor their choice. If proceeding, build a task list and continue to Phase 1 step 2 |
|
||||
| **Large** | Cross-cutting, architectural decisions, 10+ files, touches auth/payments/migrations | Inform the user this would benefit from `/ce-brainstorm` or `/ce-plan` to surface edge cases and scope boundaries. Honor their choice. If proceeding, build a task list and continue to Phase 1 step 2 |
|
||||
|
||||
---
|
||||
|
||||
@@ -97,7 +97,7 @@ Determine how to proceed based on what was provided in `<input_document>`.
|
||||
|
||||
**Option B: Use a worktree (recommended for parallel development)**
|
||||
```bash
|
||||
skill: git-worktree
|
||||
skill: ce-worktree
|
||||
# The skill will create a new branch from the default branch in an isolated worktree
|
||||
```
|
||||
|
||||
@@ -285,7 +285,7 @@ Determine how to proceed based on what was provided in `<input_document>`.
|
||||
For UI work with Figma designs:
|
||||
|
||||
- Implement components following design specs
|
||||
- Use figma-design-sync agent iteratively to compare
|
||||
- Use ce-figma-design-sync agent iteratively to compare
|
||||
- Fix visual differences identified
|
||||
- Repeat until implementation matches design
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ This file contains the shipping workflow (Phase 3-4). Load it only when all Phas
|
||||
|
||||
Every change gets reviewed before shipping. The depth scales with the change's risk profile, but review itself is never skipped.
|
||||
|
||||
**Tier 2: Full review (default)** -- REQUIRED unless Tier 1 criteria are explicitly met. Invoke the `ce:review` skill with `mode:autofix` to run specialized reviewer agents, auto-apply safe fixes, and surface residual work as todos. When the plan file path is known, pass it as `plan:<path>`. This is the mandatory default -- proceed to Tier 1 only after confirming every criterion below.
|
||||
**Tier 2: Full review (default)** -- REQUIRED unless Tier 1 criteria are explicitly met. Invoke the `ce-code-review` skill with `mode:autofix` to run specialized reviewer agents, auto-apply safe fixes, and surface residual work as todos. When the plan file path is known, pass it as `plan:<path>`. This is the mandatory default -- proceed to Tier 1 only after confirming every criterion below.
|
||||
|
||||
**Tier 1: Inline self-review** -- A lighter alternative permitted only when **all four** criteria are true. Before choosing Tier 1, explicitly state which criteria apply and why. If any criterion is uncertain, use Tier 2.
|
||||
- Purely additive (new files only, no existing behavior modified)
|
||||
@@ -54,7 +54,7 @@ This file contains the shipping workflow (Phase 3-4). Load it only when all Phas
|
||||
|
||||
Do not invoke `ce-demo-reel` directly in this step. Evidence capture belongs to the PR creation or PR description update flow, where the final PR diff and description context are available.
|
||||
|
||||
Note whether the completed work has observable behavior (UI rendering, CLI output, API/library behavior with a runnable example, generated artifacts, or workflow output). The `git-commit-push-pr` skill will ask whether to capture evidence only when evidence is possible.
|
||||
Note whether the completed work has observable behavior (UI rendering, CLI output, API/library behavior with a runnable example, generated artifacts, or workflow output). The `ce-commit-push-pr` skill will ask whether to capture evidence only when evidence is possible.
|
||||
|
||||
2. **Update Plan Status**
|
||||
|
||||
@@ -65,16 +65,16 @@ This file contains the shipping workflow (Phase 3-4). Load it only when all Phas
|
||||
|
||||
3. **Commit and Create Pull Request**
|
||||
|
||||
Load the `git-commit-push-pr` skill to handle committing, pushing, and PR creation. The skill handles convention detection, branch safety, logical commit splitting, adaptive PR descriptions, and attribution badges.
|
||||
Load the `ce-commit-push-pr` skill to handle committing, pushing, and PR creation. The skill handles convention detection, branch safety, logical commit splitting, adaptive PR descriptions, and attribution badges.
|
||||
|
||||
When providing context for the PR description, include:
|
||||
- The plan's summary and key decisions
|
||||
- Testing notes (tests added/modified, manual testing performed)
|
||||
- Evidence context from step 1, so `git-commit-push-pr` can decide whether to ask about capturing evidence
|
||||
- Evidence context from step 1, so `ce-commit-push-pr` can decide whether to ask about capturing evidence
|
||||
- Figma design link (if applicable)
|
||||
- The Post-Deploy Monitoring & Validation section (see Phase 3 Step 4)
|
||||
|
||||
If the user prefers to commit without creating a PR, load the `git-commit` skill instead.
|
||||
If the user prefers to commit without creating a PR, load the `ce-commit` skill instead.
|
||||
|
||||
4. **Notify User**
|
||||
- Summarize what was completed
|
||||
@@ -92,10 +92,10 @@ Before creating PR, verify:
|
||||
- [ ] Linting passes (use linting-agent)
|
||||
- [ ] Code follows existing patterns
|
||||
- [ ] Figma designs match implementation (if applicable)
|
||||
- [ ] Evidence decision handled by `git-commit-push-pr` when the change has observable behavior
|
||||
- [ ] Evidence decision handled by `ce-commit-push-pr` when the change has observable behavior
|
||||
- [ ] Commit messages follow conventional format
|
||||
- [ ] PR description includes Post-Deploy Monitoring & Validation section (or explicit no-impact rationale)
|
||||
- [ ] Code review completed (inline self-review or full `ce:review`)
|
||||
- [ ] Code review completed (inline self-review or full `ce-code-review`)
|
||||
- [ ] PR description includes summary, testing notes, and evidence when captured
|
||||
- [ ] PR description includes Compound Engineered badge with accurate model and harness
|
||||
|
||||
@@ -103,7 +103,7 @@ Before creating PR, verify:
|
||||
|
||||
Every change gets reviewed. The tier determines depth, not whether review happens.
|
||||
|
||||
**Tier 2 (full review)** -- REQUIRED default. Invoke `ce:review mode:autofix` with `plan:<path>` when available. Safe fixes are applied automatically; residual work surfaces as todos. Always use this tier unless all four Tier 1 criteria are explicitly confirmed.
|
||||
**Tier 2 (full review)** -- REQUIRED default. Invoke `ce-code-review mode:autofix` with `plan:<path>` when available. Safe fixes are applied automatically; residual work surfaces as todos. Always use this tier unless all four Tier 1 criteria are explicitly confirmed.
|
||||
|
||||
**Tier 1 (inline self-review)** -- permitted only when all four are true (state each explicitly before choosing):
|
||||
- Purely additive (new files only, no existing behavior modified)
|
||||
|
||||
Reference in New Issue
Block a user