Using Software Specialists

Core principle: Every software task touches multiple domains. Each specialist asks a question the others don't — skipping one means that question never gets asked.

If the conversation was compacted, re-invoke this skill before continuing.

When NOT to Use

Phases

Requirements (what?) → Design (shape?) → Plan (order?) → Implementation (how?) → Testing (works?) → Validation (safe?) → Documentation (maintains?)

Advance only when the current phase's output is complete:

Backend and Frontend implementation can run in parallel against an agreed API contract — the contract is the seam.

Testing is not "after" coding. Tests are written test-first during Implementation (TDD). The Testing phase hardens that suite — edge cases, test levels, flakiness, CI — it never starts the testing.

Implementation: load designing-interfaces, coding-discipline, and test-driven-development. If kb_path is configured, also load knowledge-base first.

If the user provides a plan file (e.g., "plan and implement using ~/plans/X.md"), read it first and validate it against the Plan row's done-criteria above. Surface gaps and stop if any are missing — do not start coding against an incomplete plan.

Task Routing

Forward lookup by task domain. "Start with" = lead mindset. "Then add" = complementary perspectives during/after implementation. "Before done" = validation gate, never skip.

Applying a specialist means reading its reference file first: references/<specialist>.md. The name alone is not the specialist — the file carries its required sub-skills, focus areas, and red flags. Role-playing from the table row without reading the file is skipping the specialist.

Minimum rule: Security Engineer + Quality Engineer must appear in "Before done" for any task that touches APIs, user data, or production code.

Disambiguating Specialists

When two specialists could both fire, each asks a unique question — see references/specialist-questions.md. Load it before invoking a specialist whose role you're unsure of.

Tester vs Quality Engineer

• Tester = craftsperson: edge cases, mock boundaries, assertion clarity for this code. Writes good tests during implementation.
• Quality Engineer = strategist: right test level, testability of the design, inverted pyramid, flaky-test erosion. Validates the strategy before done.

The "systematic coverage" trap: Edge-case enumeration for a specific function — null inputs, boundaries, invalid types, overflow — IS Tester work even when it feels systematic. QE owns the level, not whether you've covered all cases for this function. "Write tests for calculateDiscount()" → Tester leads.

Validate Before Done

Answer each item that applies before marking complete. Security and QA are universal; the rest trigger on their condition.

• Security (always): What inputs are trusted? What can be abused? Is auth enforced?
• QA (always): What edge cases are untested? What fails under bad input or load?
• Troubleshoot (if you debugged): Root cause confirmed, or just the symptom patched?
• Refactor (if you changed existing code): All existing behavior preserved? Tests still passing?
• Docs (if anything user/operator-facing changed): APIs / READMEs / runbooks updated? Owner assigned?

Anti-Patterns

Routing rationalizations only — process discipline lives in coding-discipline.

When a specialist spots an issue outside their domain, flag it explicitly for the relevant specialist — don't silently ignore cross-domain concerns.