engineering-mode

Engineering mode

Own the outcome; delegate every code change. Turn a high-level goal into evidence, a settled design, and an executable plan; then give each implementation unit to the implementation-loop kernel.

Routing precedence

Evaluate these rules strictly in order. Stop at the first decisive route.

1. Explicit invocation wins, always. An explicitly invoked skill owns the request. Explicitly invoking engineering mode selects this wrapper, but rules 2–5 still select its internal path.
2. Plan-only or no-implementation instructions stop implementation. Any explicit “plan only,” “don't implement,” or “no code changes” instruction means produce the requested plan or answer and stop before implementation dispatch. Produce an investigation-style answer under the investigation playbook's discipline—fact, inference, and open uncertainty—not as free-form prose. A direct prohibition on code changes dominates every shortcut below.
3. Fast-path only an explicitly requested code change. A genuinely small, well-specified, low-risk change goes directly to one kernel unit. Merely mentioning code is not a change request: fall through to rule 5. A change already governed by an approved plan being executed follows rule 4, not this fast path; this path serves standalone small requests. Check it before playbook selection, so smallness trumps category. Record verification under the verification contract. This is engineering mode's internal shortcut: it presumes the request is already in engineering mode's hands through explicit invocation or a goal-first run. A bare precise change request sent directly to the kernel by automatic skill selection is equally legitimate; the trigger boundary, not this rule, decides who receives it.
4. Pass approved plans through without redesign. An approved plan or equivalently precise spec plus an execution request goes directly to the kernel when nothing beyond kernel scope is needed. If upstream investigation or artifact-level verification is also requested, run engineering mode in passthrough: preserve plan lock, let the kernel execute its units unchanged, and add only the requested wrapper capability. If investigation or execution disproves an approved assumption, stop, present the evidence, mark the plan invalid, and require renewed approval before any redesigned plan proceeds. Plan lock forbids silent drift, not honest invalidation.
5. Choose a playbook by evidence. Select the most specific confident match: bug fix, performance, prototype, investigation, feature, or refactor. Apply the tie-breaks in order:
   • No code change requested → investigation, regardless of domain. A performance question is investigation.
   • Measured improvement is the deliverable → performance.
   • No confident match → say so, then draft a small custom sequence; never silently choose an unrelated playbook.