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

Implement a settled request or current execution strategy through connected slices, feed observations into the same task record, and revise affected work when evidence changes.

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.

incorporate

Assess, adapt, and apply specified discussions, feedback, findings, or references to existing project work. Preserve coverage, corrections, and selected intent; judge fit and carry adopted effects through the authorized result. Includes technical review feedback; incidental sources or understanding material without a target-work adoption question need no separate incorporation workflow.

plan

Form and maintain execution strategy when order, effort, evidence timing or recovery materially affects the outcome, even with a settled goal. Reuse durable task records when continuity needs them; keep clear work direct.

review

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

servotab

Use for hands-on repository work when a quiet, risk-scaled engineering method can improve design, execution strategy, implementation, material incorporation, 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.