Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions plugins/compound-engineering/skills/ce-plan/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -365,6 +365,12 @@ For each unit, include:
- **Error and failure paths** (when the unit has failure modes) - invalid input, downstream service failures, timeout behavior, permission denials
- **Integration scenarios** (when the unit crosses layers) - behaviors that mocks alone will not prove, e.g., "creating X triggers callback Y which persists Z". Include these for any unit touching callbacks, middleware, or multi-layer interactions
- **Verification** - how an implementer should know the unit is complete, expressed as outcomes rather than shell command scripts
- **Wires_into** - optional, include when this unit produces outputs consumed by other units or connects to existing code that must call into it. List critical-path integration contracts — connections where, if missing, the feature doesn't work end-to-end. Typically 1–3 entries per unit; if a unit needs more than 4, it may be doing too much — consider splitting. Write each entry as a natural-language statement describing what must connect to what and why, at the same abstraction level as the rest of the plan (decisions, not code). Example entries:
- "The orchestrator (Unit 1) must invoke the condensation loop (Unit 2) when sections exceed the character limit"
- "The revision UI (Unit 4) must call the revise-section API (Unit 3) on user edit"
- "The revision API (Unit 3) must emit a completion event consumed by the notification handler (Unit 5)"
- Omit this field entirely for leaf-node units with no outbound cross-unit connections
- This field complements (does not replace) the System-Wide Test Check and Integration test scenarios — those catch within-unit cross-layer issues during implementation; `wires_into` catches between-unit connections that only become visible after all units are complete

Every feature-bearing unit should include the test file path in `**Files:**`.

Expand Down Expand Up @@ -524,6 +530,10 @@ deepened: YYYY-MM-DD # optional, set when the confidence check substantively st
**Verification:**
- [Outcome that should hold when this unit is complete]

**Wires_into:**
<!-- Optional — include when this unit has critical cross-unit connections. Omit for leaf nodes. -->
- [Natural-language integration contract: what must connect to what, and why]

## System-Wide Impact

- **Interaction graph:** [What callbacks, middleware, observers, or entry points may be affected]
Expand Down Expand Up @@ -621,6 +631,7 @@ Before finalizing, check:
- Deferred items are explicit and not hidden as fake certainty
- If a High-Level Technical Design section is included, it uses the right medium for the work, carries the non-prescriptive framing, and does not contain implementation code (no imports, exact signatures, or framework-specific syntax)
- Per-unit technical design fields, if present, are concise and directional rather than copy-paste-ready
- Feature-bearing units with cross-unit dependencies include `wires_into` entries as natural-language integration contracts describing what must connect to what and why. Entries are at the same abstraction level as the rest of the plan (decisions, not implementation code). Units with no outbound connections correctly omit the field rather than leaving it blank
- Would a visual aid (dependency graph, interaction diagram, comparison table) help a reader grasp the plan structure faster than scanning prose alone?

If the plan originated from a requirements document, re-read that document and verify:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,21 @@ This file contains the shipping workflow (Phase 3-4). Load it only when all Phas
# Use linting-agent before pushing to origin
```

1b. **Connection Verification Gate** (`wires_into`)

If the plan includes `wires_into` entries on any implementation unit, verify each declared connection before proceeding to code review. If no `wires_into` entries exist in the plan (legacy plans or all-leaf-node plans), skip this step.

Re-read the plan file and extract all `wires_into` entries. For each entry, read the relevant source and target code and confirm the integration is actually wired — the call is made, the endpoint is hit, the event is sent and handled. Trace through intermediary functions, wrappers, or renamed exports as needed. Read unchanged files when one side of the connection is existing code.

**For each entry:**
- Read the source and target code identified by the entry
- Trace the connection: confirm the call chain exists, arguments are passed correctly, and the integration is functional — not just that both symbols exist
- If the connection is verified, log it briefly: "Verified: [entry summary]"
- If the connection is missing or incomplete, fix the wiring before proceeding
- If the connection exists but through a different path than the plan described (e.g., via a wrapper or renamed export), that counts as verified — the intent is satisfied

After all entries are checked, summarize: "Connection verification: N/N verified" or list what was fixed.

2. **Code Review** (REQUIRED)

Every change gets reviewed before shipping. The depth scales with the change's risk profile, but review itself is never skipped.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,21 @@ This file contains the shipping workflow (Phase 3-4). Load it only when all Phas
# Use linting-agent before pushing to origin
```

1b. **Connection Verification Gate** (`wires_into`)

If the plan includes `wires_into` entries on any implementation unit, verify each declared connection before proceeding to code review. If no `wires_into` entries exist in the plan (legacy plans or all-leaf-node plans), skip this step.

Re-read the plan file and extract all `wires_into` entries. For each entry, read the relevant source and target code and confirm the integration is actually wired — the call is made, the endpoint is hit, the event is sent and handled. Trace through intermediary functions, wrappers, or renamed exports as needed. Read unchanged files when one side of the connection is existing code.

**For each entry:**
- Read the source and target code identified by the entry
- Trace the connection: confirm the call chain exists, arguments are passed correctly, and the integration is functional — not just that both symbols exist
- If the connection is verified, log it briefly: "Verified: [entry summary]"
- If the connection is missing or incomplete, fix the wiring before proceeding
- If the connection exists but through a different path than the plan described (e.g., via a wrapper or renamed export), that counts as verified — the intent is satisfied

After all entries are checked, summarize: "Connection verification: N/N verified" or list what was fixed.

2. **Code Review** (REQUIRED)

Every change gets reviewed before shipping. The depth scales with the change's risk profile, but review itself is never skipped.
Expand Down