Servotab

debug

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

delegate

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.

design

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

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

finish

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

plan

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

review

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

review-feedback

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.

servotab

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.

spec-chain

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.

tdd

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

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.