Omar SobhandClaude Opus 5
d0b657a24b
Same class as the `/workspace/repo` path and the ZeroClaw tool names: the skills were written alongside the platform and never compared to it again. Both found by reading the source of truth before writing a check against it. 1. `decompose-int-items` showed `PLAN_COMPLETE: INT-01..05`. An id is strictly `INT-<digits>`, so the range form is rejected outright — the plan pass records nothing while every item stays open. A live planner emitted exactly that line. Now one id per line. 2. `workspace-repo-commit-protocol` said the task-card parser advances mission state on the INT id in the commit subject. Nothing in the platform reads commit messages; the parser reads `run_events` — the agent's turn output. An agent that believed it could commit with the id and never emit `COMPLETED: INT-NN`, leaving the mission open on an item it had finished. The convention is kept, the mechanism corrected. `no_skill_shows_a_marker_the_parser_would_reject` runs the real parser over every marker in every skill's fenced blocks, negative-controlled against the range form. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
2.4 KiB
name, description, when_to_use, tags
| name | description | when_to_use | tags | ||
|---|---|---|---|---|---|
| decompose-int-items | How to break a mission's roadmap/research artifact into INT-XX items sized for one coder-turn each. | You are the planner role, at the start of a coding phase, when the input is a spec/roadmap and the output is a task list. |
|
Decomposing into INT-XX items
Each INT item is one unit of work handed to a coder. The mission loop iterates one INT per iteration by default. Sizing matters — too big and iterations stall, too small and you burn tokens on ceremony.
Sizing heuristic
Aim for 1–3 hours of focused coder time per INT. Practically:
- Touches ≤ 5 files
- Adds ≤ 300 LOC net
- Owns exactly one test story (a
#[test]or a smalldescribeblock) - Independently mergeable — reverting it doesn't break other INTs
If an item exceeds any of these, split.
The output shape
Each INT is a block with:
INT-05: <short title>
**What:** one paragraph, observable behavior only (no implementation
details unless they're required for correctness).
**Files (expected):** src/foo.rs, tests/foo_test.rs
**Acceptance:**
- [ ] `cargo test foo::` passes with the new case
- [ ] Coverage on src/foo.rs ≥ 90%
- [ ] No new `unsafe` blocks
**Depends on:** INT-04 (must be merged first)
**Risk notes:** touches the hot path — bench before/after.
Emit each on its own — the task-card parser (Slice 5) UPSERTs one mission_tasks row per marker.
Ordering
- Dependencies first. INT-01 → INT-02 → ... — but leave room for reorders. A coder can emit
REORDER: <rationale>if a prerequisite blocks them. - De-risk first. Put the highest-uncertainty item early so failure is cheap to recover from.
- Interface before implementation. If INT-N introduces a new module boundary, land the trait/type in INT-N-a and the impl in INT-N-b.
Emit protocol
At the end of the planning turn, emit:
TASK: INT-01 — <title>
TASK: INT-02 — <title>
...
PLAN_COMPLETE: INT-01
PLAN_COMPLETE: INT-02
The parser creates mission_tasks rows for each TASK line. PLAN_COMPLETE records that the plan pass finished so the mission's coding phase can begin iterating.
One id per line — never a range. This section used to show
PLAN_COMPLETE: INT-01..05, and a live planner emitted exactly that. An id is
strictly INT- followed by digits, so the range form is rejected outright and
the whole plan pass records nothing while every item stays open.