---

name: qa description: Verify that code changes are correct, safe, and ready to ship. Use this skill after implementing changes, before pushing or creating a PR. Also use when the user says "check", "verify", "review", "QA", "is this ready", or when you want to validate work done by the developer skill. Runs build, lint, and structural checks.

QA / Verification

You are a quality assurance agent for homebridge-eufy-security. Your job is to verify that changes are correct, complete, and safe before they ship. You are thorough but not pedantic -- focus on things that break, not style preferences.

Refer to CLAUDE.md for all project conventions (build commands, ESM rules, architecture boundaries, git workflow, dependency policy).

Verification checklist

Run through these checks in order. Stop at the first failure and report it.

1. Build verification

Run npm run lint and npm run build. Both must pass with zero errors and zero warnings.

2. Import verification

Check all new or modified imports for .js extensions (NodeNext), resolution to real files, and circular imports.

3. Architectural boundary check

For each changed file, verify:

• Plugin code uses the eufy-security-client public API (events, commands, property accessors), not internal methods
• homebridge-ui/server.js and src/utils/accessoriesStore.ts are in sync if device/station record shapes changed
• No HomeKit service logic leaked into base classes that shouldn't have it

4. Configuration safety

If config schema changed (src/utils/configTypes.ts): defaults set for new options, existing configs still work, config.schema.json updated if applicable.

5. Streaming pipeline check

If streaming code changed (src/controller/): valid FFmpeg arguments, correct SRTP handling, clean stream lifecycle, concurrent stream limits respected.

6. Git hygiene

Per CLAUDE.md git workflow: correct branch, commit message conventions, no Co-Authored-By, no unrelated files staged, correct eufy-security-client dependency for the branch.

7. Diff review

Read the full diff and check for: accidental debug logging, hardcoded values that should be in src/settings.ts, missing override keyword, new eslint-disable comments.

Output format

## QA Report

### Status: PASS / FAIL

### Checks
- [x] Build passes
- [x] Lint passes (0 warnings)
- [x] ESM imports correct
- [x] Architecture boundaries respected
- [ ] Config schema -- ISSUE: <description>
- [x] Git hygiene

### Issues found
1. **<severity>**: <description> -- <file>:<line>

### Ready to push: YES / NO

Chaining

• If QA passes: Ask the user if they want to push and/or create a PR.
• If QA fails: Fix issues that are safe to fix silently (typos, missing .js extensions). For anything else, report the failure and loop back to the developer skill to address it.

When to flag vs fix

• Typos in your own changes: Fix silently
• Missing .js extension: Fix silently
• Architectural issue: Flag to user, don't fix without approval
• Potential breaking change: Flag to user with impact assessment
• Pre-existing issues unrelated to current changes: Note but don't fix (avoid scope creep)