feat(marketplace): command consolidation + 8 new plugins (v8.1.0 → v9.0.0) [BREAKING]

Phase 1b: Rename all ~94 commands across 12 plugins to /<noun> <action>
sub-command pattern. Git-flow consolidated from 8→5 commands (commit
variants absorbed into --push/--merge/--sync flags). Dispatch files,
name: frontmatter, and cross-reference updates for all plugins.

Phase 2: Design documents for 8 new plugins in docs/designs/.

Phase 3: Scaffold 8 new plugins — saas-api-platform, saas-db-migrate,
saas-react-platform, saas-test-pilot, data-seed, ops-release-manager,
ops-deploy-pipeline, debug-mcp. Each with plugin.json, commands, agents,
skills, README, and claude-md-integration. Marketplace grows from 12→20.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

plugins/saas-test-pilot/skills/fixture-management.md

@@ -0,0 +1,88 @@
+---
+description: Fixture organization, factories, shared test data, and conftest patterns
+---
+
+# Fixture Management Skill
+
+## Overview
+
+Patterns for organizing test fixtures, factories, and shared test data. Well-structured fixtures reduce test maintenance and improve readability.
+
+## Python Fixtures (pytest)
+
+### conftest.py Hierarchy
+
+```
+tests/
+  conftest.py              # Shared across all tests (db connection, auth)
+  unit/
+    conftest.py            # Unit-specific fixtures (mocked services)
+  integration/
+    conftest.py            # Integration-specific (real db, test server)
+```
+
+Fixtures in parent conftest.py are available to all child directories. Keep fixtures at the narrowest scope possible.
+
+### Fixture Scopes
+
+| Scope | Lifetime | Use For |
+|-------|----------|---------|
+| `function` | Each test | Default. Mutable data, unique state |
+| `class` | Each test class | Shared setup within a class |
+| `module` | Each test file | Expensive setup shared across file |
+| `session` | Entire test run | Database connection, compiled assets |
+
+### Factory Pattern (factory_boy)
+
+Use factories for complex model creation:
+- Define a factory per model with sensible defaults
+- Override only what the specific test needs
+- Use `SubFactory` for relationships
+- Use `LazyAttribute` for computed fields
+- Use `Sequence` for unique values
+
+## JavaScript Fixtures
+
+### Factory Functions
+
+```
+function createUser(overrides = {}) {
+  return {
+    id: generateId(),
+    name: "Test User",
+    email: "test@example.com",
+    ...overrides
+  };
+}
+```
+
+### Shared Test Data
+
+- Place in `__tests__/fixtures/` or `test/fixtures/`
+- Export factory functions, not static objects (avoid mutation between tests)
+- Use builder pattern for complex objects with many optional fields
+
+## Database Fixtures
+
+### Seeding Strategies
+
+| Strategy | Speed | Isolation | Complexity |
+|----------|-------|-----------|------------|
+| Transaction rollback | Fast | Good | Medium |
+| Truncate + re-seed | Medium | Perfect | Low |
+| Separate test database | Fast | Perfect | High |
+| In-memory database | Fastest | Perfect | Medium |
+
+### API Response Fixtures
+
+- Store in `tests/fixtures/responses/` as JSON files
+- Name by endpoint and scenario: `get_user_200.json`, `get_user_404.json`
+- Update fixtures when API contracts change
+- Use fixture loading helpers to avoid hardcoded paths
+
+## Anti-Patterns
+
+- Global mutable fixtures shared between tests
+- Fixtures that depend on other fixtures in unpredictable order
+- Overly specific fixtures that break when models change
+- Fixtures with magic values whose meaning is unclear