john/claude-engineering-plugin
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

feat(plugin): add execution posture signaling to ce:plan-beta and ce:work (#309)

Browse Source
This commit is contained in:
Trevin Chow
2026-03-18 09:05:19 -07:00
committed by GitHub
parent 74b286f9bf
commit 748f72a57f
2 changed files with 38 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
plugins/compound-engineering/skills/ce-work/SKILL.md
View File

@@ -25,9 +25,11 @@ This command takes a work document (plan, specification, or todo file) and execu
- Read the work document completely
- Treat the plan as a decision artifact, not an execution script
- If the plan includes sections such as `Implementation Units`, `Work Breakdown`, `Requirements Trace`, `Files`, `Test Scenarios`, or `Verification`, use those as the primary source material for execution
- Check for `Execution note` on each implementation unit — these carry the plan's execution posture signal for that unit (for example, test-first or characterization-first). Note them when creating tasks.
- Check for a `Deferred to Implementation` or `Implementation-Time Unknowns` section — these are questions the planner intentionally left for you to resolve during execution. Note them before starting so they inform your approach rather than surprising you mid-task
- Check for a `Scope Boundaries` section — these are explicit non-goals. Refer back to them if implementation starts pulling you toward adjacent work
- Review any references or links provided in the plan
- If the user explicitly asks for TDD, test-first, or characterization-first execution in this session, honor that request even if the plan has no `Execution note`
- If anything is unclear or ambiguous, ask clarifying questions now
- Get user approval to proceed
- **Do not skip this** - better to ask questions now than build the wrong thing
@@ -79,6 +81,7 @@ This command takes a work document (plan, specification, or todo file) and execu
3. **Create Todo List**
- Use your available task tracking tool (e.g., TodoWrite, task lists) to break the plan into actionable tasks
- Derive tasks from the plan's implementation units, dependencies, files, test targets, and verification criteria
- Carry each unit's `Execution note` into the task when present
- For each unit, read the `Patterns to follow` field before implementing — these point to specific files or conventions to mirror
- Use each unit's `Verification` field as the primary "done" signal for that task
- Do not expect the plan to contain implementation code, micro-step TDD instructions, or exact shell commands
@@ -99,7 +102,7 @@ This command takes a work document (plan, specification, or todo file) and execu
**Subagent dispatch** uses your available subagent or task spawning mechanism. For each unit, give the subagent:
- The full plan file path (for overall context)
- The specific unit's Goal, Files, Approach, Patterns, Test scenarios, and Verification
- The specific unit's Goal, Files, Approach, Execution note, Patterns, Test scenarios, and Verification
- Any resolved deferred questions relevant to that unit
After each subagent completes, update the plan checkboxes and task list before dispatching the next dependent unit.
@@ -125,6 +128,14 @@ This command takes a work document (plan, specification, or todo file) and execu
- Evaluate for incremental commit (see below)
```
When a unit carries an `Execution note`, honor it. For test-first units, write the failing test before implementation for that unit. For characterization-first units, capture existing behavior before changing it. For units without an `Execution note`, proceed pragmatically.
Guardrails for execution posture:
- Do not write the test and implementation in the same step when working test-first
- Do not skip verifying that a new test fails before implementing the fix or feature
- Do not over-implement beyond the current behavior slice when working test-first
- Skip test-first discipline for trivial renames, pure configuration, and pure styling work
**System-Wide Test Check** — Before marking a task done, pause and ask:
| Question | What to do |