indeliblevivi/servotab

Investigate and fix bugs, failing tests, regressions, build failures, or unexpected behavior using boundary localization, evidence, and bounded hypotheses.

Choose responsibility for substantial work before deep execution: keep one responsibility's coupled parts in a single lane, and hand a bounded or independent lane to a worker when clean context, an unknown cause, independent review, or coordinator attention materially improves the outcome.

Turn a rough feature, product interaction, or architecture idea into a concrete design. Use when meaningful decisions remain open; avoid for already-clear local edits.

Execute an existing implementation plan or settled multi-step request in coherent batches with targeted checks and controlled plan drift.

Finish a development change safely by inspecting the final tree, verifying at the right scope, and performing only the requested Git or PR actions.

Create an implementation plan sized to settled work. Use when a multi-step change benefits from sequencing, file targets, and explicit verification.

Review a diff, commit, branch, PR, or implementation for actionable correctness and risk issues without duplicate reviewer loops or invented findings.

Evaluate and act on code-review feedback with technical judgment. Use before applying external suggestions, especially when feedback is ambiguous, broad, or may conflict with repository constraints.

Use for hands-on repository work when a quiet, risk-scaled engineering method can improve design, implementation, debugging, review, delegation, workspace lifecycle, or verification. Keep clear local changes direct, preserve the complete requested outcome, and add method only where risk or uncertainty justifies it. Do not use for general technical explanations, simple file lookup, casual discussion, or non-engineering writing.

Preserve an approved specification through a complete implementation plan and execution. Use for major refactors, migrations, or multi-session work when a confirmed spec is authoritative; keep scope and order changes explicit.

Apply risk-based test-driven development to bugs, domain logic, state transitions, parsers, contracts, migrations, and behavior where a failing test sharpens the design.

Verify code or product claims after changes using fresh, risk-matched evidence. Use before saying a bug is fixed, tests pass, requirements are met, or a branch is ready.

Choose, reuse, restore, park, or clean up Git workspaces while preserving work and host ownership. Create isolation only when it resolves a real conflict; inspection does not authorize creation or deletion.