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
70 lines
2.4 KiB
Markdown
70 lines
2.4 KiB
Markdown
---
|
||
name: decompose-int-items
|
||
description: How to break a mission's roadmap/research artifact into INT-XX items sized for one coder-turn each.
|
||
when_to_use: 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.
|
||
tags: [foundation, planning]
|
||
---
|
||
|
||
# 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 small `describe` block)
|
||
- 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.
|