Feat/remove optchat add planning prompt #24
+6
-5
@@ -72,11 +72,12 @@ new logic, explain the reachable scenario, cost and a simpler correct alternativ
|
||||
the user before delegating it, even where that skill's Escalation section would proceed
|
||||
without asking. In-scope bugfixes need no approval. Never waive correctness, security or data integrity for
|
||||
simplicity; if required protection is complex, explain why and ask how to proceed.
|
||||
Parallelize independent tasks with disjoint writes; serialize dependencies and shared files;
|
||||
do not redo completed work or investigation. Use fast-lo for missing facts; workers should not guess.
|
||||
Escalate on a concrete failure, uncertainty, risk, or long dependency chain; pass prior
|
||||
findings and failures forward. Have good-lo review code changes by fast agents; send other
|
||||
reviews and plans to good-hi (deep-hi if available) when risk or extent warrants.
|
||||
Parallelize independent tasks with disjoint writes; serialize dependencies, shared files,
|
||||
and shared build/test state; do not redo completed work or investigation. Use fast-lo for
|
||||
missing facts; workers should not guess. Escalate on a concrete failure, uncertainty, risk,
|
||||
or long dependency chain; pass prior findings and failures forward. Have good-lo review
|
||||
code changes by fast agents; send other reviews and plans to good-hi
|
||||
(deep-hi if available) when risk or extent warrants.
|
||||
Reconcile results and finish the whole request.
|
||||
Ask the user only for requirement-affecting decisions retrieval cannot answer.
|
||||
Delegate only to the listed workers; they cannot delegate further.
|
||||
|
||||
@@ -26,7 +26,13 @@ Give each stage:
|
||||
- owned files
|
||||
- an acceptance check someone can observe
|
||||
|
||||
Prefer parallel read-only work, and as few stages as the dependencies allow. A stage that only exists to hand off to the next one usually should be merged into it.
|
||||
Use as few stages as the dependencies allow. A stage that only exists to hand off to the next one usually should be merged into it.
|
||||
|
||||
## Parallelism
|
||||
|
||||
- Fan out read-only work: a few parallel lookups (about 3–5 at most), none where one lookup answers the question.
|
||||
- Run write stages in parallel only when independent. Settle any shared interface, type, or contract in an earlier stage so parallel writers do not make conflicting choices.
|
||||
- Workers sharing a checkout must not run builds, tests, or installs concurrently: limit their briefs to edits plus checks scoped to their own files, then run the full build and test once after the parallel stages join.
|
||||
|
||||
## Track
|
||||
|
||||
@@ -58,6 +64,6 @@ Request: "Add a `--json` flag to `report` and `export`, using one serializer."
|
||||
|
||||
- Scope: fast-lo finds `src/format.ts` (existing formatters), `src/cli/report.ts`, `src/cli/export.ts`. Out of scope: other commands.
|
||||
- Stage 1 (good-lo, owns `src/format.ts`): add a JSON formatter beside the existing ones; check: a unit test round-trips a report.
|
||||
- Stage 2 (fast-hi, owns both CLI files, after 1): wire the flag in both commands; check: each prints valid JSON with `--json` and tests pass.
|
||||
- Stage 3 (good-lo, read-only, after 2): review stage 2's diff.
|
||||
- Stage 2 (fast-hi, owns both CLI files, after 1): wire the flag in both commands; check: each prints valid JSON with `--json`.
|
||||
- Stage 3 (good-lo, read-only, after 2): review stage 2's diff; a worker then runs the full build and tests.
|
||||
- Todos hold all three; if stage 2 fails, the revised brief includes the failing output.
|
||||
|
||||
Reference in New Issue
Block a user